連載 究極ホーム・ネットワークへの道 −実例に学ぶホーム・ネットワーク・デザイン− 最終回 複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【後編】（2） 渡邉利和 2002/03/26

電子メール転送のための仕組み

　電子メールの転送機能は、筆者が利用しているISPのメール・サーバでは無料サポートとなっているため、単にあて先メール・アドレスを指定すれば転送が行われる。この際に、ISPのメール・サーバに電子メールを残すかどうか（完全転送かコピー送付か、と言い換えることもできるだろう）の指定もできる。ただし、固定的に転送設定を仕掛けておく分には問題ないが、「外出時のみ」といった、細かい設定変更は残念ながらやりやすいとはいえない。

　もちろん、セキュリティ面での懸念もあるため、設定ページにアクセスするのにユーザー認証があるのは当然だが、さらに設定ページの仕様の問題として、毎回転送先アドレスを手入力しなくてはいけないようになっている点が面倒だ。このISPでは、複数の転送先を指定できるのだが、「転送停止」という概念は存在せず、転送を一時的に止める場合でも、「転送先アドレスからの削除」という操作になる。つまり、あらかじめ登録した外出時用アドレスに対して、「転送のオン／オフを切り換える」という操作ができない。このため、外出時用アドレスを毎回新しい転送先として登録する必要があり、それでなくても時間ギリギリに慌てて出かけるような場合に毎回この設定をできるとは思えない。

　さらに、ISPのメール・サーバから機械的に転送してしまっては困ることもある。それは、大容量のメールの取り扱いである。筆者あてのメールの中には、出版社などから校正原稿がPDFファイルで届くことや、資料として精細な画像データが送られてくることもある。こうしたファイルは、外出時に急いで見る必要のあるものはそう多くはないし、事実上ノートPCでしか見られない。PHSやPDAでメールを受信する際にこうしたデータをダウンロードするのはまったくの無駄である。しかし、ISPからの転送はすべての電子メールが有無をいわさず機械的に転送されるので、こうした「不要な大容量データ」を排除することは不可能だ。

　現在では、「携帯電話／PHSへのメール転送」のための専用ツールがいろいろとリリースされており、フリーソフトウェア／シェアウェアといった形態で配布されている。筆者もこうしたツールの1つを選んで使っている。こうしたツールは、多くはPOP3クライアントとして実装されている。現状、メール・データへのアクセス手段としてもっとも利用範囲が広いのがPOP3だから、という理由だろう。ユーザーが電子メールの読み書きに利用するメール・クライアント・ソフトウェアも電子メールをファイルに記録してくれるが、こちらはそれぞれ独自のファイル形式を使うため、標準的に読み出す電子メール用ツールというのはちょっと考えられない。一方、POP3アクセスであれば、メール・サーバがスプールにどういう形式で電子メールを保存しているか、といった実装の詳細に関わらず、共通のインターフェイスで電子メールを取り出せるので対応は容易である。逆にいうと、こうした転送ツールを利用するためにはPOP3サーバ上の電子メールを対象とすることになる。

　さて、筆者の環境で転送ツールの読み出し先として考えられるメール・サーバは次の3つである。

• ISPのメール・サーバ
• OCNのメール・サーバ
• 無料電子メール・サービスのメール・サーバ

　この中で、一番完全なデータを保持しているのはOCNのメール・サーバなのだが、これは転送元として利用するには難がある。というのも、このメール・サーバ上には電子メールは保存されず、ごく短い周期でどんどん削除される設定になっているからだ。これは、このサーバ上での電子メールの保存容量があまり多くないため、LAN内から頻繁にチェックに行き、電子メールがあればダウンロードした後に削除する、という設定にしているからだ。つまり、転送元のスプールとしてOCNのメール・サーバを指定しても、実際にはほとんどの電子メールは転送されずにLAN内に蓄積されてしまうことになる。これでは実用上不便だ。最初に挙げた大原則の、「届いた電子メールは確実に確認できる」というルールに反することになる。次に、ISPのメール・サーバだが、こちらはスプールに電子メールを残す設定になっているため、新着の電子メールを確実に転送するには都合がよいが、ごく一部OCNのメール・サーバに直接届いた電子メールは転送対象にならないという問題がある。さらに、すでに自宅で読んだ電子メールも残されたままになっている可能性があるため、うっかり転送を仕掛けると大量の既読の電子メールがPHSに送りつけられる可能性もある。ISPから機械的に転送を受けている無料電子メール・サービスのサーバも、ISPのメール・サーバと同じ問題を抱える。

　というわけで、筆者が転送先として選んだのは、上記3つに含まれない4つ目の選択肢「自宅のLAN内に独自に設置したローカル・メール・サーバ」である。もともとはLAN内の各マシンから任意のメール・クライアント・ソフトウェアを使って電子メールが参照できるように、「共通データ形式」として用意したPOP3サーバであるが、転送の際の「転送元スプール」としても具合よく機能することに気が付いたわけだ。これで、PHSで読み出す電子メールに関しては、添付ファイルを切り捨てて容量を削減し、さらに外出先で読む必要がないことが分かっている定期的に届く通知電子メールの類はフィルタ設定を行うことで転送を回避するといった細かい運用も実現できるようになった。

ローカル・メール・サーバのスプール管理

　最後に残る問題は、ローカル・メール・サーバのスプールをどう管理するかである。結局のところ、これまで述べてきた電子メールの取り扱いに関する問題の多くは、POP3というプロトコルの使いにくさに起因している。基本的には、メール・サーバのスプールから電子メールをコピーしてくることに特化したプロトコルなので、多くを望んでも仕方ないのだが、「既読か未読か」といった個々のメールに関する状態を保存してくれるようになっていないため、読み出すべき電子メールだけをスプールに残しておき、既読の電子メールは速やかにスプールから削除する、といった運用体制をきちんと作らなければならないわけだ。

　もちろん、既読の電子メールを改めてダウンロードし直す無駄を無視できるならよいのだが、通信コストやダウンロード時間の問題からそうもできないということは前述のとおりである。この問題は、実はLAN内にローカルのメール・サーバを設置した場合にも同じように存在し、結局は運用体制の工夫でしか回避しようがないのである。

　自宅のメール・サーバのスプールは、ISPのメール・サーバとは多少制約条件が異なる。まず、容量や保存期間に関する規則は自分が任意に決められる。このスプールをどんなPOP3クライアントからもアクセス可能な「共通メール・ストレージ」として利用する場合には、スプールから電子メールを削除しないのが一番使いやすいことになる。ただし、この設定にした場合、ここを参照して電子メールの転送を仕掛けるツールを使うと、既読の電子メールを大量に転送してしまう危険もある＊3。

＊3　筆者が利用しているForwardMailというツールの場合、利用を開始した当時のバージョン（2.x）ではこの危険があったが、現在配布されているVer.3では「起動時にスプールに残っているメールは転送しない」というオプションが追加されているため、対応が容易になっている。ただ、筆者は「うまく動いている環境には手を加えない」という形の横着を決め込んでいたため、この改良に気付いたのはつい最近のことである。

　一方、使うメール・クライアント・ソフトウェアを統一してしまえば、電子メールを保存したファイルにネットワーク経由でアクセスすることで「共通データ形式」として運用することも可能である。実際、筆者はこの方針も併用している。

　筆者宅では、常時運用のサーバは1台のみで、ここに基本的なサービスが集約されている。列挙すると、ファイル共有サービス、プリンタ共有サービス、そしてローカルのメール・サーバと電子メール転送ツールがこのサーバ上で動作する。ここにはメール・クライアント・ソフトウェアもインストールされているが、これはローカルのメール・サーバのスプールをチェックするだけの設定で、スプール上の電子メールは削除しない設定になっている。

　一方、LAN内には主として電子メールの読み書きに利用する別のマシンが存在する。このマシンでは、サーバ上で「スプール・チェック」に使っているメール・クライアント・ソフトウェアとは別の（旧バージョンの）メール・クライアント・ソフトウェアが動作しており、こちらはサーバから電子メールをダウンロードした後、スプール上の電子メールを削除する設定にしてある。つまり、このマシンでメール・チェックを行うと、電子メールはスプールから独自形式ファイルに移動されることになる。ただし、この「独自形式ファイル」自体はファイル・サーバ上、つまりメール・スプールが存在するサーバ上に保存され、LAN上のすべてのマシンから参照可能になっている。こうした運用をすると、ファイル・サーバ上の「独自形式ファイル」への書き込み競合が発生する危険があるため、基本的にはほかのマシンからは参照のみで、データの書き換えに繋がるような作業は行わないようにしている。

　電子メールを読むのはどのマシンでもできるが、読んだ電子メールに返事をしたり、新規メールを発信したりするのは特定の1台のマシンでしか実行しない、という形になってしまっている。そのため、わざわざメール・データを共有する環境を作った効果は予想よりも低かった、というのが正直なところである。ただ、過去に受け取った電子メールを資料として参照することがたまにあるので、こうした場合にどこからでもファイルを参照できるのは便利なこともある。例えば、ネットワークのテストの都合で別室でノートPCを使って作業している場合などには、自室に戻らなくても新着の電子メール／過去の電子メールのいずれもその場で確認できるため、移動するのも億劫な横着な筆者には好適な環境となっている。

LAN内のメール環境の概要

OCNのメール・サーバからスプールに移動した電子メールは、メール用クライアントによって専用形式ファイルに変換されるが、それ以前にほかのクライアントからPOP3で参照されることもある。また、専用形式ファイルに変換された電子メールは、ファイル・サーバ上で公開されているので、こちらをほかのクライアントが参照することもできる。参照用クライアントは、メール用クライアントのメール・クライアント・ソフトウェアのレジストリ・データをコピーすることでまったく同じ設定になっている。ネットワーク上の全マシンで共有ファイル・スペースに同じドライブ名（H:）を割り当ててあるといった環境統一も寄与しているが、こうした設定のコピーが可能かどうかは、メール・クライアント・ソフトウェアの実装方法による。

　この環境の注意点は、「スプールから電子メールを削除するマシンは1台に限定しておく」ということである。いまどきのメール・クライアント・ソフトウェアはたいていマルチアカウントに対応しているものと思うが、筆者の場合も各マシンのメール・クライアント・ソフトウェアにはかなりの数のメール・アカウントが作ってある。ローカル・メール・サーバの「スプール・チェック」用に加え、ISPやOCN、無料電子メール・サービスなどの各メール・サーバのスプールを直接チェックする設定もすべて行っており、どのメール・サーバに届いた電子メールも確認できる。ただし、いずれも「既読の電子メールをサーバに残す」設定にしておき、うっかりローカル・マシンに電子メールを「移動」してしまわないよう注意している。この確認を怠ると、電子メールが複数のマシンに分散してしまって管理不能になる、という状況に陥ってしまうので注意が必要だ。

　なお、各メール・サーバのスプールをそれぞれチェックするように設定する理由は、実は自宅のローカル・メール・サーバの信頼性があまり高くないからだ。残念ながら、運用中にダウンすることはそう珍しくないのである。参考までに、筆者が経験しているトラブルの例をいくつか挙げておこう。

• OCNのメール・サーバがOCN側の問題で応答しなくなることがたまにある。このとき、ある程度以上長い間リトライを繰り返し、失敗が続くと、ローカルのメール・サーバがPOP3アクセスを諦めてしまい、以後届いた電子メールをダウンロードしなくなってしまう
• ローカルのメール・サーバのOSであるWindows 2000 Professionalの問題のようだが、ときどきリゾルバが機能を停止することがあるようで、DNSの参照ができなくなって外部との通信が不能となることがある。当然、OCNのメール・サーバからのメール・ダウンロードもできなくなる。

　ローカルのメール・サーバが単独でダウンしているケースの多くは、リトライの失敗がある程度長く続くことによるようだが、詳細は確認していないため何ともいえない。単にある程度以上長く運用し続けるだけでも駄目になることがあるようなので、念のため海外出張などに出かける場合は出発直前にサーバをリブートするようにしているが、これでも回避できない場合もある。この場合、駄目になるのはOCNのメール・サーバから電子メールを移動してくるPOP3クライアント機能のみであり、LAN内のメール・クライアント・ソフトウェアからのアクセスを受け付けるPOP3サーバ機能は問題なく動作しているので、余計問題が複雑になる。つまり、「単に新着の電子メールがまったく届いていない状態なのか、OCNのメール・サーバからのダウンロードに失敗しているのか、見分けがつかない」のである。このため、ある程度長い期間、新着の電子メールがまったくない場合は、ISPのメール・サーバなどを確認して本当に新着の電子メールがないのかどうか確認する必要がある。

　また、2番目に挙げたリゾルバの問題は、どうもOS側のTCP/IPプロトコル・スタックの内部で起こっているようだ。LAN内のほかのマシンからは普通に表示できるWebページが、サーバ・マシンからはDNSエラーでWebサーバを見つけられなくなる、という症状が発生するのでリゾルバのトラブルと考えているが、これも原因をきちんと究明したわけではない。こちらのトラブルは、結局サーバ・マシンをリブートするほか復旧手段がないようだ。ただし、こちらのトラブルに関してはWebサイトにアクセスできなくなるため、最初の問題に比べれば気が付くのは容易である。

　というわけで、ローカルのメール・サーバに電子メールを集約し、LAN内で自由に参照できる環境を作ってはいるものの、運用上トラブルになることも多く、必ずしも便利になっているとはいい難い状況だ。ただ、現状の筆者のニーズに合わせるうえで、メリットとデメリットのバランス点としてこのような構成に落ち着いている、というところである。万人向けとはいい難いと思うが、常時接続環境も一般的になってきた現在、同様の構成を試みる人もそれなりの人数はいるものと思う。そんな人の参考になれば幸いである。

その後のメール・サーバのトラブル 　実は、本稿執筆中にメール・サーバが本格的にダウンし、単なるリブートでは復旧できなくなってしまった。症状としては意外なことに、これまでトラブル続きだったOCNのメール・サーバからの電子メールの移動ではなく、内部向けのPOP3サーバ機能のトラブルであった。確認してみると、OCNのメール・サーバからの電子メールの移動は通常どおり行われており、ローカルのスプールに新着の電子メールが着々と保存されていくのだが、LAN内のメール・クライアント・ソフトウェアからPOP3でアクセスしてもメールの参照ができないのである。TELNET接続でPOP3クライアントの動作を手動でまねて確認したところ、POP3サーバ自体は正常に動いており、ログインまでは正常に処理されるが、スプールのメール一覧を取得するためにSTATコマンドを発行したとたんにコネクションが切断されてしまうのである。どうやら、スプールの先頭にあるメール・データをPOP3サーバがチェックして落ちているらしいのだが、スプール上のファイルを直接開いてみても特に変わったところは見つからなかった。 　結果として、外から電子メールを受け取るだけで、外部には一切出さない「電子メールのブラックホール」状態であり、これではさすがに困るので、対症療法としてスプール上のメール・ファイルのもっとも古いものを削除してその場はしのいだ。ちょうど潮時という判断もあったため、その後サーバのハードディスクをより大容量のものに交換し、OS（Windows 2000 Professional）から完全に再インストールを行うことにした。 　もともとのハードディスクは18Gbytesのもので、当時としては普通の容量ではあったが、ファイル・サーバとしての利用によって残り容量は1Gbytesを切るところまで達していたし、全体が1パーティションになっていた点も不安があった。そこで、まずディスクを40Gbytesのものに替えて容量を2倍にし、さらにこれを10Gbytes＋30Gbytesの2パーティション構成にして、OS部分とファイル・サーバ用のストレージ・スペースに分割したのである。これで、メンテナンス性が向上したのと同時に、長年の利用の結果溜まったゴミが掃除されたようで、現在はまた快調な運用が続いている。本文中で触れた、リゾルバの不調もこれまでのところ発生していないようだ。 　このサーバは、2000年6月頃に運用を開始したものだ。ネットワーク環境の変更に合わせてさまざまな設定変更こそ行ったものの、基本的にはサーバ専用であり、余分なアプリケーションのインストールは行わなかったこともあり、これまでOSの再インストールは一切行わずに済んでいた。おおよそ1年半である。この期間に関しては、サーバ専用で運用すれば1年半も再インストールなしで使えるとも、ここまで気を遣っても1年半しかもたないのかともいえると思うが、筆者としてはどちらかといえば後者で、「やはりWindowsは使い減りするんだなぁ」というのが正直な感想である。可動部分のある機械なら摩耗は避けがたいが、なぜソフトウェアであるOSが長期間運用すると調子が悪くなるような実装になっていないといけないのか、と不思議に思う。稼働中にレジストリを勝手に書き換え続けることに問題があるのだとは思うが、ユーザーとしては納得しがたい部分である。 　こうした経験から、Windowsベースのサーバを運用する場合には、いつか再インストールを迫られる、ということを念頭に置いた運用体制を構築しておくことが重要だと感じている。筆者の場合は、バックアップもあったし、ハードディスクがクラッシュする前に替えたことでデータの保全に関しては問題がなかった。また、メール・サーバがダウンしている期間はISPのメール・サーバに直接アクセスすることで最低限のメール流量を確保できたこともあって、致命的な影響にはつながらなかったことは幸いであった。やはり「備えあれば憂いなし」ということであろう。

　

関連記事
究極ホーム・ネットワークへの道	第12回 ワークグループ・ネットワークにおけるファイル・サーバ運用術
究極ホーム・ネットワークへの道	第7回 電子メールを一元管理するための宅内メール・サービスの運用

INDEX
	複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【後編】（1）
	複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【後編】（2）

　

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

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