連載 究極ホーム・ネットワークへの道−実例に学ぶホーム・ネットワーク・デザイン− 第13回 複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【前編】(1) 渡邉利和 |
前回の「第12回 ワークグループ・ネットワークにおけるファイル・サーバ運用術」で記したとおり、筆者宅のLAN環境は、サービスという観点から見ると、すべてがファイル・サーバを中心として構成されている。古いコピーをもじってみると「ファイル・サーバのある暮らし」という感じであろうか。実は、電子メール環境もファイル・サーバの存在を前提として構築されているのである。「第7回 電子メールを一元管理するための宅内メール・サービスの運用」で概要を解説したが、今回から数回に分けてより詳しくメール・サーバの構築と運用について説明していく予定だ。
メール・サーバはいくつ必要か?
少し前には、LinuxなどのUNIX系OSを利用して家庭内にメール・サーバを構築する、といったハウツー記事をよく見かけたものだが、最近ではずいぶんと下火になったようだ。ISPやホスティング事業者のサービスの低価格化が進んだため、いまでは独自のメール・サーバ/Webサーバを運用するだけなら、月額数千円でホスティング・サービスを利用できるようになっている。この状況では、本格的に利用するのであればわざわざメール・サーバを構築するよりも、こうしたサービスを利用する方が手間がかからなくて都合が良いだろう。というわけで、「自宅にメール・サーバを立てよう」というのもあっという間に「昔の流行」になってしまったようだ。
もっとも、筆者が自宅にメール・サーバを用意したのは別に流行に乗ったからというわけでもなく、単に「どのクライアントPCからでも電子メールが確認できるようにしておきたい」という複数台のPCを適当に使い分けているLANならではの要求があったためである。ただ、実をいうと現状はあまりうまい構成とは言い難い。要求仕様や実装方法がいろいろ変化した結果、よくある「歴史的経緯」を背負い込んだ無用に複雑な構成になってしまっているからだ。
そもそも最初にメール・サーバ運用プランを考えた時点では、筆者が利用する電子メール・アドレスは2種類であった。これはつまり、POPでアクセスするメール・サーバが2つあるといい換えてもいいだろう。これに自宅に用意する「個人サーバ」を足して3つというのは、まぁ適当に使い分けながら利用してもさして混乱をきたすことはない妥当な数だろう。しかし、その後フリーメールのアカウントを取得してみたり、新しいISPと契約してみたりで、電子メール・アドレスの数は4つ増え、合計6つ+個人サーバ分ということになっている。これは少々多く、しっかりとした整理方針に基づいて管理を行わないと、混乱をきたす状況になってしまった。本当なら、こうした場合にこそ個人サーバが役に立つはずなのだが、長らくただ放置して惰性による運用を続けているため、追いついていないのが現状だ。
読者のみなさんは、いくつの電子メール・アドレスを所有し、そのうちのいくつが常時チェックの対象になっているだろうか。最近では、たいていの人が常用のISPの電子メール・アドレスと携帯電話/PHSの電子メール・アドレスの2つは持っているだろう。そして、会社勤めの人であれば、会社の電子メール・アドレスもあるだろうから、現在の一般的な電子メール・アドレスの最低数は3つくらいだと考えるのが妥当かもしれない。このくらいならまぁ、役割を決めて適当に使い分けるのもそう困難ではないはずだ。例えば、以下のような使い分けが一般的かもしれない。
- 会社の電子メール・アドレスは仕事関係の連絡用
- 常用ISPの電子メール・アドレスはプライベートの連絡用
- 携帯電話の電子メール・アドレスは緊急連絡先
ただ、実際に使い分けを実現するとなると、実は電子メールの送信者側にも協力を求める必要が出てきてしまう。仕事上のつきあいしかない相手には会社の電子メール・アドレスだけを伝えればいいとしても、緊急の連絡を出先で受け取るためには携帯電話の電子メール・アドレスに送ってほしい場合がある。しかし、携帯電話に届いた電子メールをPCに転送するのは結構面倒なので、うっかりするとそのまま携帯電話でしか見られなくなってしまう可能性があるし、携帯電話の内部メモリが一杯になるなどの理由で削除してしまうかもしれない。後から電子メールを参照する必要が生じた場合、これは大変困ることになる。また、送信相手に「会社の電子メール・アドレスに送るべきか、携帯電話に送るべきか」という問題で悩ませるのも気が引ける点だ。
つまり、電子メール・アドレスを目的ごとに使い分けたいと思っても、その使い分けを想定どおりに運用するのは結構大変なことになる。さらに、電子メール・アドレスの数が増えてくると、チェック漏れが起こる可能性も高くなり、連絡の行き違いといったトラブルの原因になることも考えられる。
分散した電子メール・サーバを統合したい
複数の電子メール・アドレスを利用するということは、電子メール・ファイルが複数のメール・サーバに分散して格納されるということでもある。うっかり読み漏らしたり、保存し損ねたりすることがないように、どのメール・サーバに届いた電子メールであっても確実に受信し、整理する仕組みを用意したい。
また、最初に簡単に触れたが、筆者の場合は自宅で複数のPCを適当に使っているため、どのPCを利用している際にも電子メールの確認ができると都合がよい。もちろん、管理上は特定のPCを電子メール用に決めてしまい、そのPCでしか送受信しないようにするのが手間がかからない方法なのだが、何しろPCの起動に時間がかかることもあり、できればそのときに動いているPCでサッと電子メールの確認ができるほうが都合がよい。
というわけで、筆者が利用するメール環境では、「サーバ」と「クライアント」の双方ともが分散状態にある。これを効率よく利用するためには、サーバ・サイド/クライアント・サイドの両方で統合を実現していく必要があるわけだ。ただ、この両者の統合は作業としても考え方としてもまったく異なるものなので、今回はサーバ・サイドの統合を中心に説明したい。
電子メール・サーバの統合といっても、ここで考えるのは最近流行の「サーバ・コンソリデーション(サーバを集約して統合管理する方法)」のようなサーバ自体を1台にまとめるという発想ではもちろんない。サーバ・コンソリデーションの発想に従うなら、実は「電子メール・アドレスを整理して、1つしか使わないようにする」ということになるのだが、この手は今回は採用しない。もちろん、1つの電子メール・アドレスで用が済むなら、それはそれで使い勝手はよいのだが、現状では各電子メール・サーバにそれぞれ機能や使い勝手に違いがあり、すべての用途を完全に満たせるものはないからだ。では、どう統合するかというと、とりあえず各電子メール・サーバに届いた電子メールをすべてちゃんとチェックし、必要に応じて保存できるようにする、というのが当面の目標となる。
この実現方法にはいくつか考えられる。一番簡単なのは、クライアント・サイドで一般に「巡回」と呼ばれる機能を使うことだ。いまどきの電子メール・クライアントであれば、マルチアカウントに対応しているのが普通であり、異なるアカウントに届く電子メールを順次受信するという設定も簡単にできる。これであれば、電子メール・アドレスを複数持っていても、特に問題はない。電子メールの送受信を1台のPCで実行するのであれば、この方法が一番簡単かつ有効だろう。筆者がこの巡回方式を利用していない理由はいくつかあるのだが、基本的には「複数のクライアントPCで電子メールの確認ができるようにしておきたい」ということと、あとはシステム設計時のインターネット接続環境が現在よりも貧困な環境だったため、という要因による。
「巡回」方式のメリット 複数の電子メール・アドレスを使っている場合、どの電子メール・アドレスに届いたものなのかでメールを分類したいことはよくある。しかし、場合によっては電子メールを一度混ぜてしまうと、もともとどの電子メール・アドレスに届いたものなのか分からなくなるケースもある。というのは、電子メールの宛先を指定する「To:」フィールドにダミーのアドレスを設定し、実際の宛先は「Bcc:」に指定しておく、というスタイルで届く電子メールも結構あるからだ。この場合は、どの電子メール・アドレスを指定して送られたものなのかが一見して分かりにくい。もちろん、メール・ヘッダを表示させて「Received:」フィールドをたどっていけば、まず間違いなく送信者が宛先として指定した電子メール・アドレスがどれなのかを知ることはできるが、面倒だし、自動的な振り分けでこの情報を使う場合には、多少工夫しないと思うような結果にならないことも多い。 この点で、届いた電子メールをそこから移動させず、各メール・サーバに巡回で取りに行く方法であれば「To:」フィールドの内容がどうなっていようとも、宛先となった電子メール・アドレスを確実に区別できるのである。 |
関連記事 | |
第12回 ワークグループ・ネットワークにおけるファイル・サーバ運用術 | |
第7回 電子メールを一元管理するための宅内メール・サービスの運用 |
INDEX | ||
複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【前編】(1) | ||
複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【前編】(2) | ||
「連載:究極ホーム・ネットワークへの道」 |
- Intelと互換プロセッサとの戦いの歴史を振り返る (2017/6/28)
Intelのx86が誕生して約40年たつという。x86プロセッサは、互換プロセッサとの戦いでもあった。その歴史を簡単に振り返ってみよう - 第204回 人工知能がFPGAに恋する理由 (2017/5/25)
最近、人工知能(AI)のアクセラレータとしてFPGAを活用する動きがある。なぜCPUやGPUに加えて、FPGAが人工知能に活用されるのだろうか。その理由は? - IoT実用化への号砲は鳴った (2017/4/27)
スタートの号砲が鳴ったようだ。多くのベンダーからIoTを使った実証実験の発表が相次いでいる。あと半年もすれば、実用化へのゴールも見えてくるのだろうか? - スパコンの新しい潮流は人工知能にあり? (2017/3/29)
スパコン関連の発表が続いている。多くが「人工知能」をターゲットにしているようだ。人工知能向けのスパコンとはどのようなものなのか、最近の発表から見ていこう
|
|