連載 究極ホーム・ネットワークへの道−実例に学ぶホーム・ネットワーク・デザイン− 第13回 複数の電子メール・アドレスを統合するための受信用メール・サーバの構築と運用【前編】(2) 渡邉利和 |
少し複雑な筆者の電子メール環境
まずは、現在の筆者の電子メール利用環境の概略を下図に示しておこう。筆者の場合は会社勤めではないため、「会社の電子メール・アドレス」というものはない。そこで、常用するISPの電子メール・アドレスが、対外的に公開している唯一のものとなっている。従って、基本的にはすべての電子メールがこのアドレスに届く、というのが建前である。しかしながら、実際には筆者が住んでいるマンションはいわゆる「インターネット・マンション」的なサービスを一部導入しており、マンション全体で独自ドメインを取得し、メール・サーバも運用されている。ここに引っ越してきた当初は、この電子メール・アドレスを常用していたため、一部の電子メールはいまでもマンションのメール・サーバに直接届いてしまうものがある。なお、図には示していないが、最近新しく契約したISPでもメール・アドレスを取得しているし、フリーメールのアドレスも複数あるため、実際に筆者が持っている電子メール・アドレスはもっと多いのだが、これらはまだあまり活用していないため、図からは省いてある。
筆者の電子メール利用環境 | ||||||||||||||||||
筆者の電子メールの流れを図に示してみた。このようにISPに届いた電子メールは、転送を繰り返すことになる。 | ||||||||||||||||||
|
さて、筆者の電子メール環境は、基本的には最初に設計を行った約1年半ほど前の状態から変わっていない。その一方で、インターネット接続などほかのネットワーク環境は変更された部分も多いため、現状とは不整合を生じている部分もあるし、かなり無駄なことをしている部分もある。多少話が前後してしまうが、当時の状況を振り返りながらこの構成のポイントを紹介してみたい。
電子メールをまとめる手法
まず問題になるのは、公開アドレスであるISPのメール・サーバに届く電子メールと、マンションの独自ドメインのメール・サーバに届く電子メールを取りまとめて扱う方法をどうするか、である。前述のとおり、電子メール・クライアントの巡回機能を使えば簡単だが、ここではその手法は取らず、ISPのメール・サーバに「転送」設定を行い、届いた電子メールをすべていったんマンションのメール・サーバに集約することにした。
当時、筆者宅のインターネット接続回線は、マンション共用として導入されたOCNエコノミーの128kbpsのラインであった。そして、マンションのメール・サーバもOCNのホスティング・サービスを利用して運用されているものだ。現在では、筆者はこのOCNの回線はそのまま維持しつつ、別途ADSL回線を導入してインターネット接続環境を2重化しているのだが、当時はOCN回線のみを利用していたことから、メール・サーバもOCN側にした方が確実だろうという判断を行った。そこでマンションのメール・サーバに電子メールを集約することにしたのだ。もっとも、技術的な制約としては、ISPのメール・サーバでは任意のアドレスへの電子メールの転送をサポートしていたが、マンションのメール・サーバはほかのアドレスへの転送機能を提供していなかったため、マンションのメール・サーバに集めるほかなかったという事情もある。
ISP側からマンション側のメール・サーバに転送する際には、ISPのメール・サーバにも電子メールを残す設定にした。これは、モバイル・アクセスの都合を考えたためだ。外出時にメールを確認する場合には、モバイル環境でアクセスできる場所にメール・サーバがなくてはならない。しかし、マンションのメール・サーバは共用のOCN回線から利用することが前提となっており、ダイヤルアップのアクセス・ポイントなどは提供されていなかった。そのため、モバイル・アクセスのためには別途ISPと個人契約を結ばざるを得なかったわけだ。となると、ISPにダイヤルアップで接続して電子メールを確認するには、接続に利用したISPのメール・サーバを使う方が「ネットワーク的な距離」の観点から都合がいい。そこで、モバイル・アクセスで電子メールを見る都合を考えて、ISPのメール・サーバに電子メールを残しておくようにしたわけだ。
されに、これには別の理由もある。マンションのメール・サーバはアカウントごとに割り当てられたディスク容量があまり大きくないため、こまめに削除しないとすぐに容量があふれてしまうという問題があった。そのため、自宅からのPOPアクセスでこまめに電子メールを取り出し、サーバに残さず削除するようにしている。ところが、こうした方法を採用したため、モバイル・アクセスの際にこのメール・サーバをチェックしても、電子メールはないことになる。そのため、外出時にアクセスできる場所に別途メール・サーバが必要となったのだ。
マンションのメール・サーバに集約された電子メールは、自宅に用意したメール・サーバからのPOPアクセスによって自宅に移動する。ネットワークの構成にもよるが、筆者の場合はファイアウォールの内側にあるプライベート・アドレスのネットワークとしてLANを構成しており、そこにメール・サーバを配置しているため、インターネットから直接このメール・サーバにSMTPで電子メールを転送することができない。このため、「POPで電子メールを取りに行き、クライアントにもPOPでアクセスさせる」タイプのメール・サーバが必要となる。自宅内のメール・サーバは、インターネット側のメール・サーバに対してPOPクライアントとして働くわけだ。Linuxなどであれば、sendmail+fetchmailという環境で実現できる機能だが、Windowsの場合は標準で揃っているわけではないので、必要なソフトウェアを別途探す必要がある。筆者の場合はシェアウェアのメール・サーバを利用している。
筆者が利用しているシェアウェアのメール・サーバ |
シェアウェアの「ZMailServer」のユーザー情報の設定画面。外部のPOPサーバからのメールの取り込みは、システム全体に対しても、アカウントごとにも設定可能だ。 |
ここで、自宅にメール・サーバを設置した理由を改めて説明すると、要はPOPサーバに電子メールを集約しておきたいから、ということになる。メール・クライアントは、電子メールの保存にそれぞれ独自のファイル形式を利用している。そのため、いったん電子メール・クライアントで保存した電子メールは、別のPCに移動したり、異なる電子メール・クライアントで読み出したりするのに、ファイル形式の変換などの余分な作業が必要となる。しかし、一般的な電子メール・クライアントはまず例外なくPOPクライアントであり、電子メールがPOPサーバに保管されていれば間違いなく読み出せる。さらに、電子メール・クライアントにはPOPサーバ上に保存された電子メールを読み出す際に、削除せずにそのまま残しておくように設定できる。つまり、最も汎用性の高い電子メール保存方法は、実はPOPサーバに電子メールを置いておくという方法になる。ただし、通常のISPのメール・サーバでは、容量や保存期間の問題があるため、電子メールを置いたままにしておくことができない。そのため、自宅に電子メール保管専用のPOPサーバを用意することを考えたわけだ。
これで、一応の基本構造ができあがった。対外公開用の電子メール・アドレスをISPのメール・サーバのものとし、ここで受信した電子メールはサーバに残しておく一方、マンションのメール・サーバに転送する。マンションのメール・サーバは実質的には中継サーバとして動作し、ここで直接受信した電子メールとISPから転送されてきた電子メールを混合して集約する。自宅のメール・サーバは、マンションのメール・サーバにPOPアクセスで電子メールを取りに行き、ローカルのスプールに溜め込む一方で、マンションのメール・サーバからは削除するという形になる。
さて、こうして自宅に電子メールを運び込んで保存する作業とは別に、外出先などで電子メールを確認できるように、という要素も配慮してある。ISPのメール・サーバに電子メールを残してあるのもそのためだが、メール・サーバ構築後にPHSでメールを確認する、ということも始めたため、いまとなってはここに機能が無駄に重複している。
PHSでのメール確認は、PHS自体に割り当てられたメール・アドレスに対して、自宅のメール・サーバで受け取ったメールを転送することで実現している。ただ、実際にはPHSでのメール受信は量が増えると通話料がかかるという問題に加え、添付ファイルはまず見られない(表示するためのアプリケーションがない)という問題もあるため、全メールをまったくそのまま転送するのではあまり具合がよくない。そこで、自宅のメール・サーバのスプールを確認し、ヘッダ情報に基づくフィルタリングや添付ファイルの切り捨て、一定サイズでの分割といった処理を行ってから転送するための専門のツール(シェアウェア)を併用して、PHSへのメール転送を実現している。
PHSに電子メールを転送するためのシェアウェア |
シェアウェアの「ForwardMail」。同様の転送ソフトウェアはフリーソフトウェアなどでもあるのだが、最初に試した「ForwardMail」の使い勝手が比較的よかったため、そのまま利用している。 |
この構成は、自宅ではOCN経由でアクセスし、外出時はノートPCにPHSを接続してISPのメール・サーバにダイヤルアップ接続する、という環境で電子メールのチェックを行っていたときに作ったものなので、その後の環境の整備に追従できていない。モバイル・アクセス用にISPのサーバに電子メールを残してあるのは、ノートPCで電子メールのチェックをしていたときの名残なのだが、現在では外出時にはPHSにメールが届くようになっているため、必要性がほとんどなくなっている(海外に取材に出たときなどには必須なのだが)。一方でPDA(Palm OS機)の利用も始めたため、そこで電子メールを見るために別途フリーメールのアドレスを取得している。なぜ端末が増えると電子メール・アドレスも増えるのかというと、これは単純にスプールに電子メールを残すのか/削除するのか、という問題と絡んでくるからである。というわけで、少々整理が付かなくなった感があるが、次回はLAN内での設定の様子について説明し、混乱した状況を解きほぐしてみたい。
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)
スパコン関連の発表が続いている。多くが「人工知能」をターゲットにしているようだ。人工知能向けのスパコンとはどのようなものなのか、最近の発表から見ていこう
|
|