MTA は、Messaging Server に宛てられたインターネットメールメッセージのルーティング、転送、および配信を行います。メールは、「チャネル」と呼ばれるインタフェース内を通過します。各チャネルは、1 つまたは 1 組のエージェントプログラムと一連の設定情報とで構成されます。エージェントプログラムには、チャネルに入ってきたメールを処理する「スレーブプログラム」と、チャネルを出ていくメールを処理する「マスタープログラム」があります。任意のチャネルに関連付けられた 1 つ以上のインタフェースに送られるメッセージを格納するためのメッセージキューがあります。Messaging Server には、次のような数多くのチャネルがデフォルトで用意されています。
SMTP チャネル: TCP/IP ベースのメッセージ配信と受信を有効にします。マスターチャネルとスレーブチャネルが用意されます。
LMTP チャネル: 2 層構成における MTA から メッセージストアへのメッセージの直接ルーティングを有効にします。これらのチャネルは、SMTP ではなく LMTP を使用して別のシステム上のメッセージストアと通信を行います。マスターチャネルとスレーブチャネルが用意されます。
パイプチャネル: 代替メッセージ配信プログラムで使用します。メッセージをユーザーの受信箱に直接送るのではなく、メールソーターのようなプログラムへの配信を行います。マスターチャネルが用意されます。
ローカルチャネル:メールを /var/mail に配信します。古い UNIX メールクライアントとの互換性を提供します。マスターチャネルが用意されます。
再組立チャネル: 不完全なメッセージを再度組み立て、MIME の Message/Partial Content-type をサポートする元の完全なメッセージにします。マスターチャネルが用意されます。
変換チャネル: メッセージを本文ごとに変換します。アドレスの再書き込みまたはメッセージの再フォーマットに役立ちます。マスターチャネルが用意されます。
メッセージストアチャネル: メッセージストアへのローカル配信を行います。
図 9–2 は、このプロセスを示したものです。チャネルを個別に設定し、アドレスに基づいてメールを特定のチャネルに送ることもできます。
チャネルプログラムは、次の 2 つの機能の 1 つを実行します。
SMTP スレーブプログラムは、メッセージをメッセージキューに入れて MTA による次の処理に備えるか、システムに受け入れることのできないメッセージを拒否し、ほかのインタフェースからのメッセージを受け入れます。
マスタープログラムは、キュー領域からのメッセージを処理し、それを同じシステムのキューに入れて、別のチャネルによる処理に備えます。または、ほかのインタフェースに送信し、送信後にキューから削除します。あるいは、そのメッセージをメッセージストアのようなシステム上の最終送信先に配信します。
チャネルの設定は、imta.cnf 設定テキストファイルを使用して行います。チャネル設定を通じて、さまざまな「チャネルキーワード」を設定してメッセージの処理方法を制御できます。チャネルキーワードは、パフォーマンスの調整とシステムのレポーティング面に影響を与えます。たとえば、複数のチャネルを定義してトラフィックを送信先別に分類し、メッセージサイズを制限してトラフィックを制限し、業務のニーズに応じて配信状態通知規則を定義します。診断属性もチャネル単位で設定可能です。かなりの数の設定パラメータが、チャネルベースで設定可能です。
MTA の概念の詳細については、『Sun Java System Messaging Server 6.3 管理ガイド』の第 8 章「MTA の概念」を参照してください。
MTA は、情報の検索を LDAP サーバーに対して直接行います。直接検索により、MTA と LDAP サーバーとの関係がスケーラブルで高速かつ設定可能になります。LDAP クエリーの結果は設定可能なサイズと時間でプロセスにキャッシュされるため、パフォーマンスの調整が可能です。詳細については、『Sun Java System Messaging Server 6.3 管理ガイド』を参照してください。
メールは、「ドメイン書き換え規則」(略して「書き換え規則」) が適用された送信先アドレスの実行結果に基づいて、チャネルにルーティングされます。書き換え規則は、アドレスを真のドメインアドレスに変換し、それに対応するチャネルを決定するために使用されます。これらの規則は、「トランスポート層」と「メッセージヘッダー」の両方に表示されるアドレスを書き換えるために使用されます。トランスポート層は、メッセージのエンベロープです。ルーティング情報はユーザーには見えない形で含まれていますが、実際の情報はメッセージを適切な受信者に配信するのに使用されます。
書き換え規則とチャネルのテーブルは、協力してそれぞれのアドレスの処置を決定します。書き換えプロセスの結果により、アドレスとルーティングシステム、すなわちメッセージが送信またはキューイングされるシステム (チャネル) が書き換えられます。ネットワークのトポロジ次第で、ルーティングシステムはメッセージが送信先までにたどるパスの最初のステップである場合もあれば、最終の送信先システムである場合もあります。
書き換えプロセスが終了すると、imta.cnf ファイルのチャネル部分に対してルーティングシステムの検索が行われます。それぞれのチャネルには、チャネルに関連付けられた 1 つ以上のホスト名があります。ルーティングシステム名がそれぞれのホスト名と比較されて、メッセージがどのチャネルのキューに入れられるかが決定されます。次に簡単な書き換え規則を示します。
example.com $U%example.com@tcp_siroe-daemon
この規則は、ドメイン example.com のアドレスだけを検索します。一致したアドレスは、次に示すテンプレート$U%$D を使用して書き換えられます。
アドレスのユーザーの部分またはアドレスの左側 (@ の前) を示します
@ 符号を示します
アドレスのドメインの部分またはアドレスの右側 (@ の後ろ) を示します
このように、wallaby@thor.example.com の形式のメッセージが wallaby@example.com に書き換えられ、tcp_siroe-daemon をチャネルホスト名に持つチャネルに送信されます。
書き換え規則は、マッピングテーブル、LDAP ディレクトリ検索、およびデータベース参照に基づいて、高度な置換を行うこともできます。暗号のようなわかりにくいものになる場合もありますが、書き換え規則が低レベルで動作し、処理サイクルへの直接のオーバーヘッドがほとんどない点が便利です。書き換え規則の詳細と書き換えプロセスで利用できる機能については、『Sun Java System Messaging Server 6.3 管理ガイド』の第 11 章「書き換えルールの設定」を参照してください。
マスターチャネルプログラムは、ジョブコントローラの制御下で実行されます。ジョブコントローラは、メッセージキューを制御し、実際のメッセージ配信を行うチャネルプログラムを呼び出すプログラムです。ジョブコントローラはマルチスレッドプロセスであり、Messaging Server システムに常駐している数少ないプロセスの 1 つです。チャネル処理ジョブ自体は、ジョブコントローラにより作成されますが、一時的なジョブで、実行する作業がない場合は存在しなくなります。
ジョブコントローラの設定により、チャネル処理プログラムのインスタンスが常に少なくとも 1 つ存在するかどうかが決まります。多くの場合は、すぐに実行する作業がなくてもサービスプログラムのインスタンスが少なくとも 1 つは常に存在するように設定されます。それ以外の場合は、現在行うべき作業がなくなってから一定期間の間インスタンスが存在することになります。
外部メッセージを受け入れたスレーブチャネルは、メッセージをキューイングすることにより、新しいメッセージファイルが作成されたことをジョブコントローラに通知します。ジョブコントローラは、この情報を内部データ構造に入力し、必要に応じてそのキュー内のメッセージを処理するマスターチャネルジョブを作成します。ジョブコントローラで、既存のチャネルジョブが新しくキューイングされたメッセージファイルを処理できるように設定されている場合は、このジョブを作成する必要はありません。マスターチャネルジョブは、ジョブが開始されると、ジョブコントローラからメッセージ割り当てを取得します。メッセージの処理を終了すると、マスターチャネルはその処理のステータスに応じてジョブコントローラを更新します。そのステータスは、メッセージが正常にキューから削除されたか、メッセージの再配信スケジュールが組まれたかのいずれかになります。
ジョブコントローラは、メッセージの優先度と失敗した配信に関する情報を維持し、チャネルジョブに優先的なスケジュールを許可します。ジョブコントローラは、各ジョブの状態の追跡も行います。ジョブの状態は、アイドル、アイドルの時間、ジョブがビジーであるかどうかです。状態の追跡により、ジョブコントローラはチャネルジョブの最適なプールを維持できます。
現時点で存在しているスレーブチャネルは、SMTP スレーブと LMTP スレーブの 2 つだけです。次に、これらのプログラムを制御するディスパッチャーについて説明します。
ディスパッチャーは、Messaging Server システムに常駐しているもう 1 つのプロセスです。これはマルチスレッドのトラフィックディスパッチャーであり、着信した SMTP 接続または LMTP 接続を、プロトコル固有の処理が行えるように SMTP サーバースレッドまたは LMTP サーバースレッドのプールへと振り分けます。SMTP サーバープログラムと LMTP サーバープログラムは、ディスパッチャーによって制御されるワークスレッドのプールを提供します。メッセージ処理 (メッセージの拒否または送信先チャネルへのメッセージのキューイング) が完了すると、ワークスレッドは、ディスパッチャーから別の作業を受け入れられる状態になります。
ディスパッチャーは IP アドレスに基づいて着信トラフィックをブロックできるため、サービス拒否攻撃を回避することができます。また、ディスパッチャーは、負荷と設定に基づく SMTP サーバープロセスまたは LMTP サーバープロセスの作成およびシャットダウンも行います。このように、SMTP または LMTP のスレーブチャネルプログラムは、ジョブコントローラの制御下ではなく、ディスパッチャーの制御下にあります。
Messaging Server 6.0 リリースでは、複数階層配備におけるメッセージストアに配信を行う LMTP 設定が可能になりました。インバウンドリレーとバックエンドメッセージストアが使用されるこのような環境では、アドレス拡張、自動返信や転送などの配信方法、およびメーリングリストの拡張などに関してリレーが重要な役割を果たします。
バックエンドストアへの配信はこれまで SMTP 上で行われてきました。SMTP では、バックエンドシステムで LDAP ディレクトリの受取人アドレスを再度調べる必要があるため、MTA の全機能が使用されます。速度と効率性を向上するために、MTA では SMTP ではなく LMTP を使用してバックエンドストアにメッセージを配信できます。詳細については、『Sun Java System Messaging Server 6.3 管理ガイド』の第 16 章「LMTP 配信」を参照してください。
LMTP は、複数階層配備で使用されるように設計されています。LMTP を単一システム配備で使用することはできません。Messaging Server に実装されている LMTP サービスは、ほかの LMTP サーバーまたは LMTP クライアントと連携して動作するように設計されていません。