anchor
今度はメールサーバにチャレンジ〜とりあえずPostfix Enablerが一番簡単そう
さて先日も予告した通り、自宅のネットワークの整備をしていたらまたまた目についた老兵iBook DualUSB（G3）の再生化計画をまた紹介する。
この１０年来のつきあいのiBookがあたらホコリをかぶって、博物館の展示品みたいに鎮座しているのだが、実は完動品なのだ。時々モニタスクリーンは真っ黒になってしまうが。
このiBookG3再生化計画はこれまで何度も企画され、その度に挫折してきた。
（以下の一連の記事参照。
ホコリをかぶっていたiBook DualUSBをWebサーバに転用してみた〜InsomniaXでフタ閉じノートサーバは危険か？＜追記あり＞
今度は自宅サーバでftpサーバを実現するぞ〜老兵iBook DualUSBにはもうひと働きしてもらおうか
さらにiBookG3を再生させるためにLinux／PowerPCをインストールしたりの悪あがきの記録はこちら
ことの起こりはiBook〜そしてFedora本格始動に向けて戦いは始まった・・・）
折角あるんだから何かに使いたい。
WebサーバやFTPサーバなど結構リアルタイム性が要求されるサーバとして稼働させるのは、老兵iBook DualUSBにはスペック的に厳しいのなら、メールサーバなら動くかもしれない・・・メールが数十秒遅れたって誰も気にしない。
そうだメールサーバやってみよう！
と、こんないきさつで、主に勉強でやってみる。
anchor
Postfix Enabler（Shareware)
OS10.3Panther対応
OS10.4Tiger対応
MacOSXに元々インストールされているsendmail、postfixをGUIでアクティベートするアプリ。
勉強でやるっていうなら、ちゃんとTerminal起動してgccとか駆使してpostfix設定しろよ・・・というツッコミは無しの方向でお願いします。
昔一度メールサーバーにチャレンジしてあまりのメンドクサさとコンパイルした受信用ソースコードがちゃんと動かなかったり、いろいろ懲りていますんで、こんなに簡単に送受信メールサーバが構築できる方法があるということを知った時には狂喜乱舞したのでした（やや大げさ）。
実際これはすごく簡単というかTerminalでvi等を使う方法を知っているだけにこのシンプルさは驚くべきものがある。
よくこれだけシンプルにまとめたもんだ。
それでシェアウエアではあるのだけど、円高の影響もあって８００円ほどのライセンスだし思わず買ってしまった。
途中で苦労するよりもその先に興味があったもので。
もうディスコンに近い古いシェアウエアなのでお試し版は無し
起動にはシリアルナンバーと管理者パスワードを要求される
Postfix Enablerを起動するとSend Mailタブの
Administratorに現在ログインしているユーザ名がもう入っている筈
それを確認して右下の「Enable Postfix」ボタンをクリック
下のActivityLogをクリックするとドロワが出てきて
「All Done」と出ればイネーブル完了
次にMailServerタグに移動するとこのようにIMAPの
オープンソースライセンスの同意を求められる
IMAPを使わない場合でもとりあえずAgreeしておく
使用するドメイン名を入れる
私はこちらの無料DDNSサービスを利用しているので
その取得したドメインを使用する
その上で右下のPOP3サーバを有効にするボタンをクリック
「All Done」と出るのを待つ
さらにその下の「Restart Postfix」をクリック
postfixを再起動する
「All Done」が出たらサーバ側の設定は完了
次はネットワーク関係の設定を進める
当然サーバはファイアウォールを立てているべきなので
メールに必要なポートを開いておく
システム環境設定の「共有」に入って
「新規」ボタンで新しいルールを設定する
ここのプルダウンを開く
メールのプリセットはないので「その他」で新規ルールを作成する
開くポートは25、110、143
スペース無しのカンマ区切りで入力
説明は自分が分かりやすい適当な名前でいい
自宅ネットワークもセキュリティのためにルータを
噛ませている筈（ていうか噛ませないでネットにつないじゃダメだよ）
ルータにもポートマッピングを設定して外部からこのサーバに接続を誘導する
とりあえず固定IPでないテスト用IPを割り当てておく
25、110、143をメールサーバのIPに割り当てる
割り当てるのはTCPだけでUDPは必要ない
説明は例によって自分が分かりやすい名前を適当に付ければいい
ポートマッピングの設定が完了したらルータをアップデートするために再起動
これで設定は完了！
動作確認のためにまずインターナルの受信テストのためにサーバでMailを起動する
アカウントを登録する他面設定へ
「説明」は例によって適当でいい
E-MMailアドレスはアカウント名＠ドメイン名とする
ログインしているのがibookg3というアカウント名で
使いたいドメインがnmuta.dip.jpならibookg3@nmuta.dip.jpとなる
とりあえずインターナルのテストなので受信サーバは「localhost」でいい
ユーザ名とパスワードはログイン名、パスワードと同じ
送信サーバは下のサーバセッティングのボタンをクリック
こちらもサーバードメインは「localhost」でいい
認証は後日設定するのでとりあえず認証無しでいい
ここで別のMacBook Proでこの設定したibookg3@nmuta.dip.jp
というアドレスにメールを送ってみる
サーバ側で起動したMailで見事受信に成功した
今度は送信のテスト
サーバのMailからibookg3@nmuta.dip.jpにメールを送信してみる
そしてサーバのMailで受信に成功
今度はサーバのメールから外部メールホストにメールを送信してみる
試しに私が普段使いしているメールアドレスにテストメールを送信する
ここで問題が発生した
ログを見るとyahoo.co.jpのメールホストへの接続にオペレーションタイムアウトしている
セッションがうまくいっていないということだ
ここでメールの仕組みについておさらい。
非常に多くの人が誤解しているのだが、メールというのは自分のパソコンに直接ハガキのように届けられるわけではない。
パソコンのメールソフトのことを「メールクライアント」と呼ぶことがあるが、これはまさにメールソフトはサーバクライアントシステムのクライアント側で、メールの動作の本体ではないという意味では、とても正しい用語だと思う。
メールを送るという動作はどういうものか順を追って説明すると以下のようになる。
自分のパソコンのメールクライアントを起動してメールを書く、そしてメールを送信するボタンをクリック
↓
メールクライアントソフトはとりあえずそのメールをテキストとしてアウトゴーイング（送信箱）に保存する
↓
保存したテキストをアカウントの設定で指定したドメイン名のメールサーバにアップロードする
↓
アップロードされたメールサーバーはそれをセンドメール（送出箱）に保存する
↓
保存したメールを読み込んだメールサーバーはそのメールのヘッダ（見出しというより宅配便の荷送り票のようなものと思った方が正確）を認識しその送り先のサーバに転送する
↓
実際には相手サーバに直接届くわけではなくこの間にいくつかの中継サーバに転送リレーが展開される
↓
転送されたメールサーバーはインカミング（受信箱）にそのメールを保存、メールはここに蓄積される
↓
受信側のパソコンでメールクライアントを起動して「受信」ボタンをクリックする（この操作は定時自動で行われる設定が多い／これがメールは自分のパソコンに直接届くという誤解の元になっている）
↓
クライアントソフトのアカウントで設定したドメイン名のサーバにリクエストが送られる。するとそのメールサーバに届いたメールがクライアントソフトの受信箱にダウンロードされる
↓
クライアントソフトでダウンロードしたメールテキストを開くと新着メールが読めるようになる
図式的に記述するとメールの送信と受信てこういうことをやっているわけだ。
まことにめんどくさいことをやっているのが分かる。
これに比べたらFTPなんて実に簡単だと思う。
しかも実際にはここでは端折ったが保存したテキストや添付ファイルの画像、音声、動画をMIMEのルールに従って転送可能なコードに変換して転送したり、転送を受けたクライアントはそれを還元したりとかのいくつかのメンドクサイプロセスがある。
サーバが受信したメールはここらあたりに保存されると思われる。
/private/var/mail/ibookg3
もしマルチアカウント化にチャレンジする場合必要かもしれないので。
今回はこのサーバ側の動作をiBookで展開しているわけだ。
Mailを起動して送受信のテストをしたのはサーバのサービスが正常に動いているか確認するためで、これはメールサーバの動作とは直接関係ない。
つまり上記の図式的記述を見ていただいたら分かるように、ここまでの設定でサーバ側の動作を確認したから、次はメールクライアントで送受信ができてこそメールの送受信の一連の動作が完成したことになる。
以下クライアント側の設定にチャレンジ。
とりあえず当初の予定通りクライアントの設定にもチャレンジ
ここでは愛用のMacBook Proで常用しているメールクライアントのGyazMailを設定する
説明は適当、名前、メールアドレス、アカウントID、パスワードはインターナルの設定と同じ
受信メールサーバ（ホスト）は今度はWAN経由で送信するのでドメイン名を入れる
送信用のサーバも説明は適当、サーバネーム(ホスト）はドメイン名、認証はなしでテスト
外部のクライアントから自鯖メールアドレスを差出人にしてとりあえず自分のメールを送る
そしてクライアントで受信成功
これで送信、受信共にクライアントからの操作だけで成功したことになる
メールサーバの設定としては一応ここで第１段階は成功となるのだが・・・
例によってYahoo!メールアドレスに向けて自鯖アドレスで送信すると・・・
SMTPプロトコルエラーコード554
これは「何らかの原因で相手ホストとの接続に失敗した」という
非常に大まかなコードで原因究明に役に立つような立たないような・・・
ということでメールサーバ自体は稼働に成功し、クライアントからの送受信も成功したのだが、Yahooメール、GMailなどのいくつかのアドレスへの送信に失敗した。
いろいろ調べてみた結果、このコード554はメールプロバイダーのセキュリティポリシーが原因だったようだ。
何年か前にYahoo！からメールのセキュリティポリシーでOP25Bを導入するというお知らせメールが来ていた。
その時はあまり気にもしていなくて、また大して意味も無いことをするのかなぐらいにしか思っていなかった。
ところが調べてみるとメールプロバイダーの大部分は今、送信のセキュリティポリシーOP25Bと受信のポリシーIP25Bを採用している。
IP25Bは端的に言うと身元がはっきりしない個人メールサーバを締め出すために動的IPアドレスが送信元とヘッダーに記述されているメールは拒絶するというもの。OP25Bはプロバイダーの身元保証のない個人メールサーバからの送信をシャットダウンするというもの。
スパムメールが２０００年以降等比級数的に増えており、一説によると世界のインターネットのトラフィックの半分以上はスパムメールだというくらいになっている。
そのスパムメールの送信元を集計すると日本の場合、OCNとかYahoo!とか比較的ユルかったところが送信元になっているケースが多かったようで、こういうところが軒並みもう今ではセキュリティポリシーを導入している。
YahooやGMailの自分のメールアドレスに、自鯖メールサーバのメールが届かなかったのはこういう理由だった。
ドメイン名は固定だがIPアドレスはDDNS経由の動的アドレスだからだ。
IPアドレスは0.0.0.0から255.255.255.255まで組み合わせがある。（ひとつのオクテットが８ビットの数字を表現しているため）
オクテットの000と0は同じと看做す、010と10は同じと看做すなどルールがあるし使用目的が決まっている組み合わせもあるので、使えるIPアドレスは単純に見かけの数字の組み合わせでは１兆ぐらいありそうだが、実際には４０億ぐらいしか無くて、世界中の人にひとつ割り当てることができない。
それである領域を動的なアドレスとして使うということで割り当てられている。
代表的というか、お馴染みなのは
192.168.0.1
10.0.1.1
から始まるブロックで、これはローカルIPアドレスとしてどこでも自由に使っていいことになっている。
同じようにインターネットプロバイダーも１０万人加入者が居たら１０万個IPアドレスをもらえるわけではなくて、実際には数百個の動的なNAT方式でIPアドレスを振っているようだ。
メールサーバはこの動的なIPアドレスから送信された場合、ヘッダに差出人のその動的IPアドレスが記入される。
メールのヘッダは表示しないクライアントアプリが多いが
実際には全てのメールの頭にはこういう情報がテキストで記入されている
その最初の部分にローカルIPとともにプロバイダーが動的に割り当てているIPも記入されている
どのIPアドレスが固定でどれが動的かはリストが公表されているから、プロバイダが採用しているIP25Bはそのリストを元に動的なものをカットするし、OP25Bは自社サービスのメールドメインを使わない、つまり身元が確認できないサーバの送信メールは弾くというのが今のポリシーらしい。
それでこの折角立てたメールサーバを実用的に使うには、メール用のプロキシみたいな方法を探すのか、ヘッダの偽装をする方法を考えるか・・・でもそんな手間かけるくらいだったら、素直にGMailやYahooメール使っている方が手間要らずで、簡単だしメリットがわからないな。
メールは誰かにクレーム入れたりする手紙ツール以外に、実は自動機器の動作をアラートとして飛ばす機能があるから、こういう事情があったとしても自鯖でメールサーバを運用するのには意味があると思う。
ちょっと専門的な使い道になってしまうけど。
もし普通に自鯖でコミュニケーションツールとしてメールを運用したいなら、固定IPを割り振ってもらうのが根本的な解決だと思われる。
固定IPを代価を払って導入するのは、ちょっと練習でやるには高価なのだがやろうと思えばやれることが分かったのは大きい。
勿論このままではセキュリティの問題があるので、現状iBookサーバは停止してある。
セキュリティがかかっていないメールサーバはスパム業者の踏み台にされるので。
その辺のセキュリティやマルチアカウントも近日中にチャレンジしてみたいと思う。
2011年11月27日
