まず思いつくことは「アーカイブしたメールは、個人情報や社内機密情報を含んでいる可能性がある」ということである。それゆえ、よりインターネットから遠くLANに近いセグメントに設置が望まれるだろう（図2）。
図2：アーカイブデータはより内側に設置
ところが、電子署名を付与するメールゲートウェイがすでに設置されている場合は逆の考え方になる。電子署名ゲートウェイよりアーカイブゲートウェイを手前（LAN寄り）に設置すると、アーカイブ処理をした後にメールが改変（署名付与）されることになり、アーカイブの完全性を保持できない。よってアーカイブゲートウェイとの順序が逆になる（図3）。
図3：電子署名を付与するゲートウェイがある場合
同様の理由でアンチウイルスゲートウェイも、メールの改変（ウイルスの除去）を伴うので、アーカイブとの順序が問題になる。
またアンチウイルスゲートウェイならではの問題として、アーカイブゲートウェイをアンチウイルスの内側に置いてしまうと、「ウイルス感染させられた」という社外からの疑惑に対する反証の手段としては意味をなさないともいえる。
図4：アンチウイルスゲートウェイがある場合（コンプライアンスを重視）
このようにアーカイブゲートウェイをより内側に置きたいという要請と、逆にインターネットに出て行く直前に置きたいという要請とが真っ向から対立する。
とはいえ、必ずしもアーカイブゲートウェイをファイアウォールの手前に置かなければならないということではないし、署名やアンチウイルスのゲートウェイの後でアーカイブをすることが絶対というわけでもない。
コンプライアンスよりセキュリティを重視するのであれば、アーカイブゲートウェイの後にアンチウイルスゲートウェイを置くという判断は十分にあり得る。
図5：アンチウイルスゲートウェイがある場合（セキュリティを重視）
セキュリティ上あるいはコンプライアンス上、何にプライオリティを置くかによって、個々のケースにあわせて最適な結論を導き出す必要がある。
さらに厄介なことに、これら多数のゲートウェイやメールハブを経由すると、「Received:」ヘッダがたくさん付与され、その結果一部のプロバイダでは以下のようなエラーを返してきてメールが到達しないこともある。
Your message was rejected by [***.***.***.***] for the following reason:
Error: too many hops
「Received:」ヘッダについては「社内のメールサーバのホスト名を社外に公開しない」というセキュリティポリシーにも関連するケースがあるため、これまた総合的な判断が必要となる。
|
