ホップ数とメールシステムの関係

sendmailの生みの親が「皆メールを使い過ぎ」

という記事を拝見しましたが、そうは言っても日本の企業では、今や電子メールは無くてはならない基幹サービスと言って間違いないでしょう。良し悪しは別として隣の席の同僚にさえメールで要件を伝えることも珍しくなく、企業が送受信するメール通数は日々増加の一途です。

しかし、最近のメールシステムの構築（または更改）はとっても大変です。ISMS や新会社法などの法的面への対応も理由の一つですが、なんと言っても構成設計段階が最も大変ではないでしょうか。メールサーバ間のメール・リレーは昔と変わらずバケツリレーであるにも関わらず、メールに求められる機能が年々増加傾向にありますから、設計・構築担当者の方は大変です。増加した機能では以下をざっと思いつきます。

• 送信者認証
• アンチウィルス（Anti-Virus）
• アンチスパム（Anti-Spam）
• アーカイブ（メールの全文保存）
• コンテンツ監査
• LDAPなどのDBとの連携認証やメールルーティング
• フィルタリング
• Proxy Switch
• 暗号化（ゲートウェイでの暗号化）

などなど。

増加した機能別にサーバを構築していく・・・という方法が最も安易ですが、ここに落とし穴があります。「ホップ数」です。

メール一通一通には、本文や添付ファイルデータ部分とは別に「ヘッダー」というデータ部分が存在しています。ヘッダーには送信者・受信者アドレス、件名や送信日付など、様々な情報が記録されていますが、この中にある「Received」という情報を参照することにより、「このメールがどのメールサーバを経由してリレーされたか」が、真偽はともかく判断できます。
しかし、この「Received」の最大行数（ホップ数）が、経由途中のメールサーバの設定値を超えた場合（大体のメールサーバが26ホップでしょう）、そのメールはエラー処理となり、メールのあて先人のメールボックスに到着することはありません。
※経由したメールサーバの構成にもよりますが、基本的には「１メールサーバ」で「１Received行」と考えます。

このホップ数の存在目的は、経由したメールサーバの記録のほかに、メールルーティング中のループを防ぐという重要な役割もあるため、メールサーバ側のホップ制限値を「無制限」にすることはお勧めできません。

稀なケースとなりますが、沢山のメールサーバを経由する必要のある企業同士間で、メールが到着しないといった現象がホップ数が原因で発生します。このため、メールサーバの台数が無闇に多くならないように考慮する必要がありますが、これでも数年前まで問題がほとんど無かったのは、サーバ台数の決定要素が「メール・ルーティング」と「サイジング」、「Anti-Virus」くらいだったからと考えられます。

しかし、冒頭に書きましたとおり、メールに求められる機能が年々増加傾向にありますから、機能ごとにメールサーバを構築していった場合、望まないホップ数も増加することとなります。極端な例ですが以下のような inbound 経路のメールシステムも存在するかも知れません。
※MTAは Message Transfer Agent の略ですが、中継メールサーバ、リレーサーバ、単にメールサーバなどとも呼ばれます。

インターネット → ?ゲートウェイ(送信者認証等)MTA → ?Anti-Virus(A社製) MTA → ?Anti-Virus(B社製) MTA → ?Anti-Spam(Scan)MTA → ?Anti-Spam(Spool)MTA → ?ポリシー・フィルタリングMTA → ?コンテンツ監査MTA → ?アーカイブMTA → ?ローカル振分けMTA → ?MLサーバ(MTA) → ?ローカル振分けMTA → ?スプール・サーバ(メールボックス)

上記経路だけでも、一メールサーバ一ホップとしても、12ホップがヘッダーに記録され、あて先の受信者に到着することとなります。Anti-Virus メールサーバなどの場合、構成によっては1リレーで2ホップ/台になる可能性があり、さらにアーカイブ・サーバなどは3ホップ/台にもなる可能性があります。上記経路の場合、最高で計16ホップになるかも知れません。
もし、16ホップだとすると、既に10ホップが記録されたメールが?のゲートウェイMTAに届いた場合、?のスプールサーバの到着時点でエラー処理となり、スプールサーバ内のあて先メールボックスにメールが配送されない可能性がかなり高いでしょう。

前置きが非常に長かったのですが、「最近のメールシステムの構成はホップ数に留意して検討しましょう」ということを申し上げたかった次第です。

かと言って、必要な機能は全てメールシステムに入れなければならない・・・といった回避不可能な機能要件が、管理者の目の前に登場するかも知れません。
そこで、具体的なホップ数対策として、以下を検討されることをお勧めいたします。

1.inbound と outbound 経路を物理的に分離する

ホップ数が多くなる可能性は一般的に inbound（外部→内部）の経路が高いでしょう。ですが、まずは外部の相手方に配慮して、outbound（内部→外部）の経路を単純化します。例えばアンチスパム機能が内部から送信されるメールにも本当に必要か検討することは重要です。必要ないと判断できれば経路から外します。

また、MLはその機能的にホップ数を増加させる傾向にあります。MLソフトウェアによってはホップ数を実際より減らすことが可能な設定も存在しますので、これも検討・対策します。

そして、ロギング面などの管理性と耐障害性の観点からも言えることですが、可能な限り outbound は物理的に独立したメールサーバが経路となるように設計することをお勧めします。ただ、Anti-Virus や Anti-Spam などは、メーカーによってはサーバ台数によってライセンスを要求される可能性があります。できればサイト・ライセンスなど、サーバ台数に左右されないライセンス体系の製品を選定し、outbound 経路用に配置することを検討します。

2.アプライアンス製品でまとめる

最近の商用メールサーバ製品は、「アンチ・スパムとアンチ・ウィルス」「アーカイブとコンテンツ監査」など、ロジック的に近い機能を「一まとめ・一メールサーバ」になるようになっています。
これらの製品は「メール中継サーバ（MTA）」の形態をとっていることが殆どですが、変わったアプローチとしては、ネットワーク・スイッチなどにアンチウィルスやアンチスパム機能などを実装し、透過的にパケットの中身をチェックするというインテリジェントな製品もあります。
※書いていて思いましたが、このネットワーク・スイッチ同居型ってホップ数軽減の目的としては効果ありですね。

そして、一まとめにするにあたって、ついでに単機能サーバ化（アプライアンス・サーバ化）しようという発想は自然の流れかと思います。メールサーバの分野では（特にゲートウェイ・タイプのMTA）、かなりのアプライアンス製品が市場に出回っている思いますが、この手のアプライアンス製品を導入することにより、ホップ数の軽減と管理コスト削減を狙うことも可能です。

メールサーバに限らずアプライアンス製品の選定留意点を過去に投稿していますので、よろしければご参照ください。

アプライアンス製品導入前に

しかし、まとめ過ぎるのも・・・

Microsoft 社製の Exchange2007 では、エッジ・トランスポートという名称でメール・ゲートウェイ機能を強化してきました。アンチウィルス、アンチスパム、フィルタリング、コンテンツ監査、アーカイブ、送信者認証など、およそ今のメールシステムに必要であろうと考えられる機能をこれでもかと詰め込んでいます。
さらに OWA（Outlook Web Access）、OMA（Outlook Mobile Access）などの、リモート・アクセス向けのウェブ・インターフェースも持っています。
AD とシームレスな連携によるアカウント認証もばっちりです。OS も自社製ですから、ハードウェア云々の狭義の捉え方をしなければ、Exchange と OS だけでもアプライアンス製品と言えるのかも知れません。

これならば1台または2台程度のメールサーバ台数で、全ての要件を達成したうえに、ホップ数も激減させることができそうですが、難点もあります。

それは、何らかの原因でどこかの一機能に障害が発生した場合に、原因究明や代替策実施は非常に難しいということです。何といっても物理的に同一のサーバ内での話ですから、障害が発生している機能部分だけを見つけるための切り分けや、障害箇所をスキップさせるための方法が限られてしまいます。

物理的に分離しているメールシステム構成であれば、とりあえず障害が発生しているサーバを迂回させるという縮退運用もとっさにとれます。

機能まとめはやり過ぎず、かと言って台数を増やし過ぎず・・・が肝要と言えるかと思います。