連載 究極ホーム・ネットワークへの道 −実例に学ぶホーム・ネットワーク・デザイン− 第7回 電子メールを一元管理するための宅内メール・サービスの運用 渡邉利和 2001/08/21

　前回の「第6回 ネットワーク・サービスの配置を検討する」で紹介したように筆者宅では、基本的にLAN内部にファイル・サービスとプリント・サービスといった最低限必要のサービスしか用意していない。インターネット接続では、このほかにDNSと電子メールが中核的なサービスとして挙げられるだろうし、情報発信のためにWebサーバを運用している人もいまや珍しくないだろう。筆者としては、こうしたサービスの自宅内での運用は、かかる手間と得られる効果を勘案するとコストパフォーマンスが悪いと考えており、基本的にはISP任せにしている。ただし、電子メールに関しては利用頻度が高いこともあり、ISPのメール・サーバを利用しつつも、さらに内部に補助的な環境を用意している。今回は、この電子メール環境を紹介しよう。

宅内メール・サーバの必要性

　筆者はこうした原稿を書くことが主たる仕事の、いわゆる「ライター」稼業である。インターネットでビジネスを展開するドットコム企業などとは異なり、基本的にはインターネット向けにサービスを提供する必要はほとんどない。「書いた原稿を公開するためにWebサーバを用意する」ということも考えられなくはないが、現状ではお読みいただいているように@ITなどの専門サイトが原稿を掲載してくれているため、自前でWebサーバを用意する必要性を感じたことはない。つまり、インターネット接続に関しては、費用を別にすれば環境的にはダイヤルアップ接続でも不便はない（実際には、費用などを考えて、次回から紹介するようにADSLを導入しているが）。

　ただし、電子メールだけは別である。電子メールに関しては、ISPのメール・サーバが最良の使い勝手を提供してくれるわけではないため、多少工夫した方が便利になる。もちろん、いまでは独自のメール・サーバを運用してくれるホスティング・サービスなども豊富にあり、独自ドメイン／独自メール・アドレスを使っても、月額数千円程度で維持できる。以前に比べるとISPのメール・サーバでも運用の自由度は高まっている。しかし、筆者の場合は「独自ドメイン」にさほど魅力を感じないため、現状ではそこまでする気もない。単に、「POPによるアクセスの不便さを多少解消する工夫」があれば十分、というレベルにある。

　独自ドメインを取得して独自のメール・サーバを運用すれば、メール・アドレスを好きなだけ好きなアカウント名で作成できる。自前でサーバを運用するなら、メール・スプールのサイズや保存期間といった要素も自分の好きに決められるので、便利なこともあるだろう。一方、面倒なのは日常のメンテナンスやセキュリティに対する配慮である。スパムの配信に使われてしまうなどというのは論外としても、外部からアクセス可能なサーバを運用するならやはりクラッキングやウイルス、ワームなどといったセキュリティ侵害の危険を意識せざるを得ない。先ごろ話題となった「Code Red」などの例を挙げるまでもなく、こうしたワームは最近増える傾向にある。これまで以上にセキュリティ管理に対する気遣いと、手間が必要になると思った方がよい。こうした手間に見合う価値が得られるかどうかが、メール・サーバを運用すべきかどうかの目安になるわけだが、筆者の場合は根が横着だということもあり、いまのところ「とてもやってられない」というのが結論である。

POPによるメール取得の不便さ

　ISPのメール・サーバを利用するとなると、一般的にはPOP3プロトコルを使ってサーバにアクセスすることになる。筆者の場合もそうである。ただ、この方法では、複数台のPCを使っている場合、そのままでは「電子メールが分散してしまう」という使いにくい面もある。

　POPによるアクセスでは、アクセスしたクライアント・マシンに電子メールのメッセージ本文を移動する、という動作が基本となる。もちろん、いまどきのメール・クライアントでは、設定によってメール・サーバに電子メールを残すコピー動作も可能だが、ISPのメール・サーバではほとんどの場合、容量や保存期間に制限が課せられており、ずっと残しておくわけにはいかない。筆者はそう大量の電子メールのやりとりを行っているわけではないが、数日放っておけば100通くらいはすぐにたまってしまう。資料や発表会の案内、新製品の写真など、画像やWordファイルが添付されているものもあり、容量もすぐに数Mbytesに達してしまう。

　一方で、筆者はそのときの気分や作業内容によってLAN内のマシンを使い分けている。かつ、生来の貧乏性のために最低限必要なマシンしか電源を入れないため、何の手も打たないままでは、それぞれのマシンにバラバラに電子メールが保存されてしまうことになる。これでは、後で参照する場合に探し出すのが大変だ。

　また、保存された電子メールはそれぞれのPOPクライアントに固有の形式（ファイル・フォーマット）となることも問題といえば問題である。メール・クライアントによっては、代表的な形式からの変換ツールを用意しているものもあるが、あるメール・クライアントで保存した過去の電子メールは別のメール・クライアントでは読み出せないことも珍しくない。現状では、電子メールの保存形式として一番汎用的なのは、実はPOPサーバだといえなくもない。POPサーバに電子メールがあれば、どんなOS上のどんなツールであっても、まず読み出せないことはない。こうしておけば、新規にPCを導入した場合でも、これまでの電子メールを読み出して、同じ環境状態（過去の電子メールを保存した状態）を作ることも容易だ。

　そこで、「LAN内に任意のクライアントから参照できるPOPサーバを用意すること」にした。これが必ずしもベストの策とは限らないが、筆者が感じた使いにくさのほとんどは解消できたので、この構成について紹介しよう。

ローカルPOPサーバの運用

　ISPのメール・サーバを利用しつつ、ローカルでもPOPサーバを運用するには、そのためのソフトウェアが必要になる。Linux環境では古くから「fetchmail」と呼ばれるフリー・ソフトウェアが有名だが、Windowsにはどうも手ごろなものが見つからない。Windows向けのPOPクライアントは豊富にそろっているものの、POPサーバ・ソフトウェアはあまり多くなく、しかもたいていはシェアウェアである。とはいえ、皆無というわけではないので興味のある方は探してみてほしい。筆者は「ZMailServer」というシェアウェアのPOPサーバを利用している。

ZMailServerのユーザー情報の設定画面

外部のPOP3サーバからのメールの取り込みは、システム全体に対しても、アカウントごとにも設定可能だ。通常、外部のPOP3サーバのIDは、ユーザーごとに異なるため、個別に設定するほうが自然だが、ISPのメール・サーバの1つのアカウントをLAN内の複数のユーザーで共用する、といった利用法も考えられる。

　筆者宅のメール・サーバにおける電子メールの取り扱いは、大きく2つのフェーズに分かれる。まず、ISPのメール・サーバにアクセスして電子メールを取得する。これは、POPクライアントとしての動作だ。次いで、LAN内のPOPクライアントのリクエストに応じて、取得したメール・データを送出するPOPサーバとしての動作を行う。Linuxでfetchmailを利用する場合、fetchmailがPOPクライアントとして動作し、POPサーバの部分はまた別のプロセスを利用することになるが、Windowsの場合はこの2つの機能を両方ともサポートするものが一般的だ。筆者が利用しているのもこのタイプである。

　常時稼働しているWindowsサーバ（OSはWindows 2000 Professional）にこのメール・サーバ・ソフトウェアをインストールし、必要な設定を行う。今回はごく単純に、ISPのメール・サーバにアクセスするためのIDとパスワードを設定し、チェック間隔を指定した程度だ。どの程度の間隔でチェックするかは好みだが、常時接続ということもあって、筆者の場合は5分間隔としている。これで、実際のところISPのメール・サーバがそのまま自宅のLAN内部に移動してきたかのような環境になる。この状態でLAN内部の各クライアントで電子メールをチェックするには、ISPのメール・サーバの代わりにLAN内部のメール・サーバにアクセスすればよい。このとき、「サーバ上のメールを削除しない」という設定にしておくと、メール・データの分散を心配する必要はなくなる。常にメール・データの完全なセットがサーバのスプールに保管されているからだ。

　これだけでも、ISPとは異なり、メールのサイズや保管期間の制限を気にする必要はなくなる。ただし、実際に電子メールを取り扱う場合にはWindowsクライアント上で作業を行う場合が多いので、そこでも多少の工夫を追加している。具体的には、LAN内のクライアントすべてに同じメール・クライアント・ソフトウェアをインストールしておき、電子メールの保管先ディレクトリとしてファイル・サーバを指定しているのだ。LAN内の各クライアントからファイル・サーバのディレクトリをネットワーク・ドライブとしてマウントしておき、ここにあるメール・データを参照するようにしている。

筆者の電子メール環境

図のように複数台のクライアントから電子メールを参照し、かつメール・データが分散しないように工夫している。

サーバがISPに5分おきに電子メールをチェックに行き、スプールに保存する。 　 新着電子メールをチェックする場合、各クライアントはサーバのスプールをコピー・モードで参照する。 　 過去のメール・ログを参照する場合は、共有ディスク上のログを参照する。実際には、このディスクは電子メールのスプール領域と同じサーバ上にある。

　なお、こうした設定が可能かどうかは利用しているメール・クライアントに依存するので注意していただきたい。筆者は、Becky!のバージョン1.xを利用している。このメール・クライアントはマルチアカウントに対応しているので、LAN内のメール・サーバにアクセスするアカウントと保存してある過去のメール・データにアクセスするアカウントを分けておく、といった小細工をして使っている。最新のバージョン2.xではなく旧バージョンを利用している理由は、2.x系では、同じメール・データを参照しているインスタンスが複数あった場合に排他制御を行って一方を止める、といったことを行うので、筆者の環境では少々使いにくいためだ。

Becky! 2.xのエラー・ダイアログ

Becky! 2.xで同じように共有を試みると、このように警告が表示されてしまう。確かに今回紹介した方法は、操作を誤るとデータを破壊してしまう可能性もあるので、あまりおすすめできる方法ではないのも確かだ。

　筆者宅ではWindowsマシンが主体であるため、メール・クライアントを統一してファイル・サーバに置いたデータを共有、というスタイルはかなり有効だが万能ではない。実際Windows以外のOS（LinuxやSolarisといったUNIX系OS）も使っており、場合によってはこれらの環境からも新着メールをチェックしたいこともある。この場合でも、最低限ローカルのメール・サーバにPOPでアクセスすることは可能だ。逆に、そうした柔軟性を確保するために、ファイル・サーバを介したデータ共有に全面的に依存するのではなく、ローカルのPOPサーバと併用している、ということもできる。また、このような構成にすることで、メール・サーバとファイル・サーバの2カ所に事実上の電子メールのバックアップを作ることにもなっている。

POPサーバの活用

　実のところ、単に複数のWindowsクライアントから新着メールを確認する、というだけの用途であれば、メール受信マシンを1台決めておいて定期的にISPにメールを取りに行き（この機能はたいていのメール・クライアントに備わっている）、そのメール保存ディレクトリをほかのクライアントから参照する、という方法によってPOPサーバなしでも実現できる。ただ、POPサーバがあれば多少応用が利くこともある。

　メール・クライアントにはいろいろな種類があるが、万能のものはないと思う。一方、アドレス帳や電子メールそのもののデータは、ツールごとに独自の形式で保存されていることが多いため、ツールを変更するには手間がかかるものだ。過去の電子メールがたまってくると、使いやすいメール・クライアントが見つかっても、メール・データやアドレス・データの移行が面倒になってくる。そのため、一部の機能に多少不満があっても、なかなか別のツールに乗り換える気にならないことも多いだろう。また、ある機能には不満があるものの、そのほかの点ではとても気に入っている、という場合にも乗り換えは実行しにくい。

　筆者の場合は、電子メールの転送機能が不満点に相当する。新着メールを外出時にも確認するため、現在筆者はPHSに電子メールを転送している。この場合、行ったきりになっても困るのでバックアップを自宅に保存しておくことと、PHSの特性に合わせた加工を施したいのだが、転送時にメールの加工ができるメール・クライアントはあまり一般的ではない。具体的には、添付ファイルである。PHSで添付ファイルを見るのは現実的ではないうえ、ファイル・サイズが大きくなると不便なので添付ファイルは転送したくない。さらに、小さな画面で見る場合には罫線代わりに使われている同一キャラクタの繰り返し（「■■■■■■」といった感じのモノ）も邪魔である。

　よくしたもので、こうした需要を満たすツールも探せばちゃんと見つかるものだ。筆者が利用しているのは「ForwardMail」というWindows用のツールである。基本はPOPクライアントであり、POPサーバからコピーしてきた電子メールをオプション設定に従って適宜加工し、指定のアドレスに転送してくれる。こうしたツールを組み合わせて利用する場合、ローカルにPOPサーバを持っておくのが便利である。

ForwardMailの基本画面

左端のアイコンで赤いバツ印が付いているものは転送されなかったもの。ここでは、筆者が明示的に転送を禁止したものが示されている。アカウントの「DDI Pocket」は、PHSに対して転送したことを示す。

　

ForwardMailの環境設定画面

携帯電話向けの電子メール書き換えルールの設定が行える。引用部分を省略したり、同一文字の連続を削除したり、サイズの大きなメールを分割したり、といった処理が可能だ。

ヘッダ情報を削除することで、電子メールの文字数を少なくする設定 　 引用記号が付いた部分を削除する設定。引用記号の設定も可能だ 　 「■■■■■■」といった連続文字を削除して、携帯電話上で読みやすくする設定 　 文字数制限がある携帯電話のメール・サービスでも本文を分割して送ることが可能

　というのも、通常のメール・クライアントでダウンロードしてしまった電子メールは、独自形式で保管されてしまうため、別途転送ツールを組み合わせて利用するのには不向きである。転送ツールはPOPサーバ上の電子メールを削除しないため、ISPのメール・サーバを直接チェックして転送を実行することも不可能ではないが、この場合はメール・クライアントによるダウンロードとのタイミング問題を考える必要がある。ISPのメール・サーバには長期間、電子メールを置きっぱなしにしておくことはできないのが一般的だ。そのため、通常はメール・クライアントは電子メールをコピーするのではなく移動を行う。つまり、POPサーバ上の電子メールは削除するわけだ。このとき、同じサーバを監視して動作している転送ツールがあった場合、先にメール・クライアントがアクセスして電子メールを削除してしまっては具合が悪い。転送し損なう電子メールが出てくる可能性があるからだ。一方、これを避けるためにメール・クライアントがPOPサーバ上の電子メールを削除しないようにしておいた場合には、後から不要な電子メールの削除を実行しないと、メール・サーバの容量制限に引っかかる。こうした条件をいろいろ考えると、制約なく自由に使えるPOPサーバをローカルに持つというのは、唯一の解ではないまでもかなり有効な解決策ではあるはずだ。

■

　さて、次回は、現在の筆者宅のネットワーク構成を改めて紹介していく予定だ。半年ほど前にADSLを導入した結果、現在の筆者宅のネットワークでは当初の設計とは、少々違ってきている。最大の変更は、ADSL回線を自室に直接引き込んだことだ。これによって、従来は基幹バックボーンと位置付けられたHomePNAの重要性が大幅に低下し、現在では妻がリビングで作業をするときのためにのみ利用される「おまけ回線」になってしまっている。

ソフトウェア名	概要	入手先ホームページ
fetchmail	Linux環境では有名なツールで、たいていのディストリビューションには標準で収録されている	http://www.tuxedo.org/ ~esr/fetchmail/
ZMailServer	Windows用のメール・サーバ・ソフトウェア。無償版とシェアウェア版（3000円）がある。もともと金額の安さで選んだものだが、順調に使えている	http://www.teddy.ath.cx/ soft/
Becky!	有名なWindows用メール・クライアント。筆者はいまだに1.x系を利用	http://www.rimarts.co.jp/ index-j.html
ForwardMail	携帯電話なども意識したメール転送専用クライアント。同種のものはほかにもいくつかあるが、比較したわけでもなく何となく選んだ。使ってみても特に不満はないのでそのまま運用している	http://hp.vector.co.jp/ authors/VA009014/
紹介したソフトウェア

　

「連載：究極ホーム・ネットワークへの道」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）