こんにちは。フリーエンジニアの木下です。
インフラ管理上メールを配送する流れを把握しておく、というのはいろいろな局面で役に立つものです。
ネットワークの構成管理の一貫としてネットワーク構成図などのドキュメントを整備されているシステム部門は多いと思います。
ですが、電子メールについてはどうでしょうか？電子メールの送受信の流れは把握されていないシステム管理者の方もそれなりの数はいらっしゃるのではないでしょうか？
- 連載『メールと添付ファイルについて学ぼう』のほかの記事はこちら
第1回：メール添付ファイルでユーザーが思っている4つのこと - 第2回：なぜ、複雑な電子メールのルールは形骸化するのか
- 第3回：メール添付ファイルで遭遇するトラブル一例
- 第4回：ファイル分割が使われなくなった理由は
- 第5回：この記事
昨今の電子メールを取り巻く環境は厳しくなっています。コンピューターウィルス対策、迷惑メール対策、情報漏えい対策、と「本来の電子メールの機能として実装されていない機能」をインフラ・セキュリティという視点で導入することによって、電子メール環境の周辺は複雑になりつつあります。
電子メール周辺の付加機能で複雑になる際に、どうしても把握しておきたい情報が、電子メールはどのようにしてインターネットから各ユーザーのクライアントまで配送されるか、という「電子メールの流れ」です。よくメールトラフィック、メールフローなどと表現されます。
こういった電子メールの流れは、メールシステムのリプレイスやサービス更改、メールシステムの機能追加、グループウェアのメッセージングシステムと統合する、など、電子メールにまつわる環境変更の際に把握しておきたい情報となります。
既存の電子メールを機能拡張するようなソリューションを導入するときにはメールのデータがどのように流れていくかのフローを考えて追加するシステムの構成を考慮し既存のメールシステムの設定変更を実施する必要があります。
実際の構成図を見てみましょう。
この図は社内のメールサーバーをPCが参照してインターネットの向こう側のユーザーとメールの送受信をする図です。構成としては単純な構成で、メールサーバーを各PCが参照して電子メールを送受信しているとします。
メールサーバーは最終的に自ホスト内のユーザー領域（MailBoxやMailDir）にローカル配送をして、PCはPOP受信やIMAP参照などで電子メールを利用する、という構造です。
オンプレミスのメールサーバーを置いている企業などではDMZなどにメールサーバーが配置されているケースが多いです。インターネット上にあるレンタルサーバーでメールサーバーを賄っている企業も世の中には多く存在しています。メールサーバーが社内ネットワークか社外ネットワーク（インターネット上）かに関わらず、構成としてはとてもシンプルな「メールサーバー1対パソコン1」となります。電子メールの流れる経路としては一本道なので、これくらいでは特に構成をドキュメント化しなくても暗記できる、というシステム管理者の方も多いのではないでしょうか。
それではこの環境に社内メールサーバーが冗長化され、グループウェアで電子メール（や他の機能）を統合するようになった場合の簡単な構成図を見てみましょう。
登場するサーバーは冗長化のために用意された２台目のメールサーバーと電子メールやスケジュールなどの情報を統合して管理するためのグループウェアのサーバーが1台です。この構成で社内のPCは電子メールのみならず、予定表や連絡先、タスク（To-do）などをユーザー間で共有してコミュニケーションツールが稼働しているという状況の例です。
社内にMicrosoft Exchengeなどを配置している場合にはメールサーバーの後ろのイントラネットにもう1段サーバーが配置されていて、社内のクライアントPCはそれらのサーバーを参照することで電子メールを利用している、という構成だとします。
メールサーバーは最終的に自ホスト内のユーザー領域（MailBoxやMailDir）にローカル配送をしていたところを、グループウェアのユーザー領域に対して配送するようにしなくてはならないので、ここに設定変更を実施する必要性が出てきます。（メールリレーをするか、単純なユーザー別の転送で実現するか、といった細かなところを各々の仕様によって決定することになります。）
メールサーバーの冗長化は２台の同一メールサーバーでDNSラウンドロビンによって振り分けしてもいいですし、Active-Standbyのように正系＆副系で動作させてもいいと思います。
そうすると必然的に、電子メール自体は最終的にグループウェアのサーバーに集約されることになってきますが、メールサーバーは２台のメールサーバーで同時に受信＆送信が（設定によっては）ありえるので、この経路で２種類の経路が新設されることになり、片方が障害で停止してしまっても、もう片方で継続して電子メールの送受信ができるようになります。
そして、ここに電子メールのセキュリティアプライアンスのような機器（以下メールゲートウェイと表記）を導入するとします。最近よくある、自動的に社内から外部に送信する電子メールの添付ファイルをパスワード付きZIP化、ないしメールそのものを暗号化してくれるようなアプライアンス（ないしサービス）を導入したと仮定した簡単な構成図です。
電子メールを配送するために必要な経路が送信と受信で分かれる構成に変化してきました。
図ではメールの送信はメールサーバーとメールゲートウェイで２種類の流れが表記されていますが、これはユーザーの電子メールはメールゲートウェイに統合し、システムのアラートメールなどはメールサーバーから直接送信、という具合に、電子メールのトラフィックはメールデータによって分かれる傾向がありますので２種類の経路を記載しています。もちろん、仕様上問題なければメールゲートウェイにすべての外部向け送信メールを統合する、ということも可能です。
ここまでくるとPCがメールサーバーに電子メールの配送依頼をするシンプルな構成から電子メールの経路が複雑化し、かなり関与する機器が増えてきました。
社内メールサーバーからインターネット上にメールが出るまでの間で、メールゲートウェイが導入され、社内メールサーバーのメールがいったんメールゲートウェイを経由してインターネット上のメールホストに対して配送を実行するようにメールの流れが変わることになります。当然電子メールの出口となるメールゲートウェイでは必要なセキュリティ対策を電子メールに実施し、加工した状態の電子メールを外部に送信するようになります。
さらに、もう少し複雑にするために、ここによくある迷惑メール対策（迷惑メールをブロックしてくれる）サーバーを導入してみましょう。構成図はさらに複雑になります。
すべての外部から受信する電子メールは迷惑メールフィルタサーバーでいったん受信し、メールが選別されたあとで、安全な電子メール/スパムではない電子メールがメールサーバーにリレーされてくることになります。ですが、迷惑メールフィルタサーバー自体は外部への電子メール送信には関与しないため、メール送信の経路には影響を与えなくなります。
これだけの段階があると、単純にユーザーから「メールが届かない。」というトラブル報告を受けたとしてもどのサーバーの、どの処理のステップでメールが届かなくなっているか、ということを調べるために、どの機能が電子メール受信に関係しているか、とその順番を把握しておく必要があります。
具体的なサーバー設定によって電子メールの経路自体は変わってきてしまいますが、いかがでしょうか？
自インフラの電子メールはどのように流れて最終的にインターネットの向こう側に設置された相手のメールサーバーに到達するか、という点を把握しておくことは本記事のようにメールシステムの構成変更が発生するときに押さえておきたい重要なポイントとなります。もし作業に手落ちがあれば社内の電子メールがすべて停止してしまう、という重大な事態に発展しかねません。こういった「構成変更時の障害」を未然に防ぐためにも、平常時の構成図作成は管理者のためのドキュメント管理としてお勧めしておきたい業務の一つです。
