メッセージングトポロジ要素の理解

この節では、メッセージングトポロジにおける最も一般的な要素について説明します。基本的な要素について理解を深めることで、独自のトポロジの設計が容易になります。

この節の内容は次のとおりです。

• 「メッセージングトポロジのコンポーネント」

• 「MTA によるメッセージングシステムの保護」

• 「MMP の使用」

• 「ゲートウェイの使用」

メッセージングトポロジのコンポーネント

「メッセージングトポロジの設計」で、メッセージングトポロジのコンポーネントである Messaging Server、Directory Server、およびクライアントの 3 つについて簡単に説明しました。この節では、基本的なメッセージングトポロジにおけるそのほかのコンポーネントについて説明します。

Messaging Server: ユーザーのメールボックスを収容して管理します。また、「インターネット接続 MTA」と「MTA リレー」で説明されているように、Messaging Server の MTA 部分だけを含むサーバーとしても機能します。

クライアント: 多くの場合 Messaging マルチプレクサを通じて、Messaging Server からメッセージングサービスにアクセスします。

Directory Server:Messaging Server により名前とエイリアスの検索に使用されます。ダイレクト LDAP 検索によりメッセージがどこにルーティングされるかが決められます。

Messaging マルチプレクサ: メッセージ取得のために適切なメッセージングサービスにクライアントを接続します。

インターネット接続 MTA: インターネットからのメッセージをルーティングし、ファイアウォールを越えてリレーします。通常、Messaging Server ホストはこの機能を実行するように設定されます。

MTA リレー: インバウンド MTA は、着信メッセージを適切な Messaging Server 内の有効なアドレスにルーティングします。発信 MTA はクライアントからの発信メッセージを受け取り、LDAP にクエリーを行なって送信先を検索し、メッセージを適切なサーバーに送信するか、ファイアウォールを越えてインターネットに向けて送信します。通常、Messaging Server ホストはこの機能を実行するように設定されます。

DNS サーバー: サーバー名を IP アドレスに解決し、ネットワーク内の適切なアドレスにメッセージが届くようにします。

ファイアウォール: 内部サイトのインターネットアクセスを制限します。組織内の部門間にもファイアウォールを設置することが考えられます。

MTA によるメッセージングシステムの保護

MTA を使えば、Messaging Server 配備を保護できるほか、サイトに出入りするメッセージトラフィックのフローを制御することができます。

インターネット接続 MTA は組織外のサイトからのメッセージを受信する単一窓口です。インターネット接続 MTA は、ファイアウォールを越えて受信 MTA、通常は別の Messaging Server に着信メッセージを送信します。

次に、インバウンド MTA はディレクトリのクエリーを行なって、組織内のメッセージの送信先を判断します。インターネット接続 MTA は、ファイアウォールの外部ウォールと内部ウォールの間に位置するファイアウォールの非武装地帯 (DMZ) に配置され、インバウンド MTA 以外のサーバーについての情報にはアクセスしません。

送信 MTA は、クライアントから送信されたメッセージを受け取ります。アウトバウンド MTA は LDAP のクエリーを行なって送信先を検索し、メッセージを適切なサーバーに送信するか、ファイアウォールを越えてインターネットに向けて送信します。これにより、ユーザーのためにメッセージを取得するというメッセージングサーバーとしての機能から MTA が解放されます。図 12–5 にこの概念を示します。

図 12–5 メッセージングトポロジ内の MTA

MMP の使用

MMP により、Messaging Server ホストのレイアウトをエンドユーザーから隠すことができます。その結果、メールボックスが配置されているサーバーを特定することなく、ユーザーに汎用的な MMP またはロードバランサを割り当てることができます。メッセージアクセスクライアントは、受信メッセージを取得するときに MMP を指定します。

そのようなクライアント接続と認証の際に、MMP はディレクトリ内のユーザー情報の検索を行い、ユーザーのメッセージがどこにあるかを判断します。次に、MMP はクライアントを特定のサーバーに接続します。次の図は、Messaging Server に対する IMAP4 と POP3 接続のプロキシとして MMP が機能する仕組みを示します。図 12–6 は、Messaging Server 環境においてマルチプレクサがどのように機能するかを示します。

図 12–6 MMP の概要

複数の MMP の手前にロードバランサを配置します。MMP は通常、複数個存在します。

MMP SMTP プロキシの使用

MMP には、メッセージを受け取るが転送はしないように設計された SMTP プロキシが含まれています。この設計のため、MMP SMTP プロキシを DNS MX レコードのターゲットとして使用したり、そのほかの方法でインターネット上の任意の発信元から着信するメールを受信するために使用したりしてはいけません。Messaging Server では、メッセージ転送機能に MMP SMTP プロキシを使用できません。

Messaging Server では、エンドユーザークライアントからのメッセージの送信に MMP SMTP プロキシを使用できません。ただし、MMP の多重化機能は、POP 接続や IMAP 接続を正しいバックエンドストアに割り当てるために必要ですが、SMTP 送信には必要ありません。標準に従うメールクライアントに対しては MX レコードにより、また、標準に従わないメールクライアントに対しては単純なロードバランサによって、SMTP 送信を分散できます。

MMP SMTP プロキシは次の場合にのみ使用してください。

1. MTA が SSL/TLS 処理によって妨げられている場合で、MMP SMTP プロキシでそのメッセージ送信プロセスのオフロードを行いながら、標準の SMTP STARTTLS を引き続きサポートできるとき。

2. MMP で POP や IMAP に SSL ハードウェアアクセラレータを使用している場合で、それを SMTP 送信にも利用すると効果が期待できるとき。

3. 「POP before SMTP」メカニズムを使用する必要があるため、MMP SMTP プロキシが必須になる場合。

4. 必要な機能が MMP SMTP プロキシにはあり、バックエンド MTA にはない場合。

5. 配備にプロキシが必要な場合。この場合は、MMP SMTP プロキシを使用してください。このプロキシは、MTA が持っているセキュリティー機能と SMTP 拡張機能を保持するように特別に設計されており、それを安全に行うためにカスタム SMTP 拡張機能 (XPEHLO) を使用します。

MMP SMTP プロキシは、バックエンドとしての Messaging Server の SMTP サーバーでのみ動作します。

ゲートウェイの使用

組織には、旧バージョンのメッセージングシステムがメッセージング処理の専用メソッドとして存在する場合があります。ユーザーを移行させるまで、両方のメッセージング戦略を残しておかなければなりません。これらの旧バージョンのシステムにアクセスする場合には、SMTP ゲートウェイを使用できます。これは、新規のシステムと旧バージョンのシステム間で SMTP 接続を有効にするものです。通常、旧バージョンのシステムは、受信 MTA がメッセージをルーティングできるように、SMTP 接続をサポートしています。