この章では、MTA の概念について説明します。この章には、次の節があります。
MTA (Message Transfer Agent) は、Messaging Server (図 8–1) の構成要素です。もっとも基本的なレベルにおいては、MTA はメッセージルーターです。MTA はほかのサーバーからメッセージを受信してアドレスを読み取り、最終的な宛先 (通常はユーザーのメールボックス) に向けて次のサーバーにルーティングします。
長年にわたって、MTA には多くの機能が追加され、サイズ、能力、および複雑さも増してきました。これらの MTA 機能は重複していますが、通常は次のように分類できます。
ルーティング: メッセージを受け取り、エイリアスである場合などは必要に応じて展開または変換して、次のサーバー、チャネル、プログラム、ファイルなどにルーティングします。ルーティング機能が拡張され、管理者がメッセージのルーティングについての内部的および外部的な方法を指定できるようになりました。たとえば、SMTP 認証、各種 SMTP コマンドおよびプロトコルの使用、TCP/IP または DNS 検索のサポート、ジョブの送信、プロセス制御やメッセージキューイングなどを指定できます。
アドレス書き換え: 通常、エンベロープアドレスはルーティングプロセスの一環として書き換えられますが、エンベロープまたはヘッダーアドレスを、より希望に沿った適切な形式に書き換えることができます。
フィルタ: MTA は、アドレス、ドメイン、感染のおそれのあるウィルスやスパムの内容、サイズ、IP アドレス、ヘッダーの内容などに基づいて、メッセージをフィルタ処理できます。フィルタ処理されたメッセージは、破棄、拒否、変更、ファイルやプログラムに送信、またはユーザーのメールボックスに向けて送信する途中に次のサーバーに送信することができます。
コンテンツの変更: メッセージのヘッダーまたはコンテンツを変更することができます。次に例を示します。特定のクライアントから読み取り可能なメッセージや、特定の文字セットをサポートするメッセージを作成したり、スパムやウィルスのチェックを行います。
監査: だれが、いつ、どこから、どのようなメッセージを送信したかを追跡します。
これらの機能は、図 8–2 に示される多数のサブコンポーネントおよびプロセスでサポートされています。この章では、これらのサブコンポーネントとプロセスについて説明します。また、システム管理者は多数のツールを使用して、これらの機能を有効化および設定することができます。このようなツールには、MTA オプション、configutil パラメータ、マッピングテーブル、キーワード、チャネル、書き換えルールなどがあります。これらのツールについては、後に MTA の章で説明します。
ここでは、MTA のアーキテクチャーとメッセージフローの概要を簡単に説明します (図 8–2)。MTA は非常に複雑なコンポーネントであり、この図はシステムを通じて配信されるメッセージの簡略図であることに注意してください。実際、この図は、システムを通じて配信されるすべてのメッセージを厳密に示しているわけではありません。ただし、概念を説明するという目的は十分に果たしています。
SMTP セッションを介して、インターネットまたはイントラネットから MTA にメッセージが届きます。MTA が SMTP 接続要求を受信すると、MTA ディスパッチャー (マルチスレッド接続ディスパッチエージェント) はスレーブプログラム (tcp_smtp_server) を実行して SMTP セッションを処理します。ディスパッチャーは、各サービスのマルチスレッドプロセスのプールを管理します。さらにセッションが要求されると、ディスパッチャーは SMTP サーバープログラムを起動して、それぞれのセッションを処理します。ディスパッチャーのプロセスプール内のプロセスは、複数の接続を同時に処理することもあります。ディスパッチャーとスレーブプログラムにより、着信メッセージごとにさまざまな機能が実行されます。次の 3 つの基本機能があります。
メッセージのブロッキング - 特定の IP アドレス、メールアドレス、ポート、チャネル、ヘッダー文字列などを含むメッセージをブロックする (第 17 章「メールのフィルタリングとアクセス制御」)。
アドレスの変更。着信したアドレスの From: や To: を必要な形式に書き換える。
チャネルへのキューイング。アドレスに書き換えルールを適用し、メッセージを送信するチャネルを決定する。
詳細は、「ディスパッチャー」を参照してください。
メッセージは SMTP サーバーによってキューに入れられますが、変換チャネルや再処理チャネルなど、いくつかのほかのチャネルによってもキューに入れられることがあります。配信のこの段階ではさまざまなタスクが実行されますが、主なタスクは以下のとおりです。
チャネルは、メッセージを処理するための基本的な MTA コンポーネントです。チャネルは、ほかのシステム (ほかの MTA、ほかのチャネル、ローカルメッセージストアなど) とのメッセージ接続を表します。メールが届くと、メッセージのソースや宛先によってルーティングや処理方法が異なります。たとえば、ローカルメッセージストアに配信されるメールと、インターネットに配信されるメールと、メールシステムの別の MTA に配信されるメールは、それぞれ別の方法で処理されます。チャネルは、各接続に必要な処理とルーティングをカスタマイズするしくみを提供します。デフォルトの設定では、メッセージの大半はインターネット、イントラネット、およびローカルのメッセージを扱う 1 本のチャネルに入ります。
特定の状況のための特殊なチャネルを作成することもできます。たとえば、メールの処理が非常に遅いインターネットドメインがあり、このドメイン宛のメールがあると MTA の処理が停滞するとします。このような場合は、処理が遅いドメイン宛のすべてのメッセージを処理する特別なチャネルを作成すると、このドメインのボトルネックが解消されます。
アドレスのドメイン部分は、メッセージがどのチャネルのキューに入れられるのかを決定します。ドメインを読み取って適切なチャネルを決定するしくみを、書き換えルールと呼びます (「書き換えルール」を参照)。
チャネルは通常、マスタープログラムというチャネル処理プログラムとチャネルキューで構成されています。スレーブプログラムが該当するチャネルキューにメッセージを配信すると、マスタープログラムが必要な処理とルーティングを行います。チャネルの指定と設定は、書き換えルールと同様、imta.cnf ファイルで行います。チャネルエントリの例を次に示します。
tcp_intranet smtp mx single_sys subdirs 20 noreverse maxjobs 7 SMTP_POOL maytlsserver allowswitchchannel saslswitchchannel tcp_auth tcp_intranet-daemon |
この場合、最初の単語 tcp_intranet はチャネル名です。最後の単語はチャネルタグです。チャネル名とチャネルタグの間にある単語はチャネルキーワードで、メッセージの処理方法を表します。さまざまなキーワードを使って、さまざまな方法でメッセージを処理できます。チャネルキーワードの詳しい説明は、第 12 章「チャネル定義を設定する」を参照してください。
メッセージが処理されると、マスタープログラムはメッセージの配信パスに沿って次の送信先にメッセージを送ります。次の送信先が予定した受取人のメールボックスであることもあれば、別の MTA や別のチャネルであることもあります。この図では別のチャネルへの転送は表示されていませんが、そのようなケースもよくあります。
アドレスのローカル部分と受信フィールドは通常は 7 ビット文字なので注意してください。MTA がこれらのフィールドで 8 ビット文字を読み取った場合、8 ビットそれぞれをアスタリスクに変換します。
ディスパッチャーは、複数のマルチスレッドサーバープロセスが SMTP 接続サービスを分担できるようにする、マルチスレッドディスパッチエージェントです。ディスパッチャーを使用すると、複数のマルチスレッド SMTP サーバープロセスを同時に実行し、同じポートへの接続を処理できるようになります。さらに、それぞれのサーバーで 1 つ以上のアクティブな接続が可能になります。
ディスパッチャーは、その設定に指定されている TCP ポートの中心的なレシーバとして機能します。定義された各サービスに対して、ディスパッチャーは 1 つまたは複数の SMTP サーバープロセスを作成し、確立後の接続を処理します。
通常、ディスパッチャーは、定義された TCP ポートの接続を受信すると、そのポートにおけるサービスのワーカープロセスのプールを確認し、その接続用に最適なワーカープロセスを選択します。適当なワーカープロセスがない場合、ディスパッチャーはこの接続と後続の接続を処理するための新しいワーカープロセスを作成します。また、ディスパッチャーは、今後の着信接続を予測して、新しいワーカープロセスを作成することもできます。ディスパッチャーのさまざまなサービスを制御するための設定オプションがいくつかあります。これらの設定オプションは特に、ワーカープロセス数、および各ワーカープロセスが処理できる接続の数を制御するのに使用されます。
詳細は、「ディスパッチャー設定ファイル」を参照してください。
ディスパッチャーの自動ハウスキーピング機能により、新規サーバープロセスの作成や、アイドル状態の古いサーバープロセスの有効期限を制御することができます。ディスパッチャーの動作を制御する基本的なオプションは、MIN_PROCS と MAX_PROCS です。MIN_PROCS は、着信接続用に一定のサーバープロセス数を待機させることにより、一定レベルのサービスを確実に提供します。一方、MAX_PROCS は、指定したサービスに対して同時にアクティブにできるサーバープロセス数の上限を設定します。
すでに処理可能な最大数の接続を処理しているため、またはプロセスの終了がスケジュールされているために、動作中のサーバープロセスが接続を受け入れられないことがあります。ディスパッチャーは、今後の接続に役立つよう追加のプロセスを作成することができます。
MIN_CONNS および MAX_CONNS オプションを使うと、サーバープロセス間で接続を分散できます。MIN_CONNS はサーバープロセスが「十分にビジー」であることを示す接続数を指定し、MAX_CONNS はサーバープロセスが「最高にビジー」な状態となる場合の接続数を指定するものです。
通常、現在のサーバープロセス数が MIN_PROCS 未満である場合、または既存のサーバープロセスがすべて「十分にビジー」(各サーバープロセスに対し、現在アクティブな接続の数が MIN_CONNS 以上) である場合、ディスパッチャーは新しいサーバープロセスを作成します。
たとえば UNIX システムの kill コマンドによってサーバープロセスが突然終了した場合、ディスパッチャーは新しい接続ごとに新規サーバープロセスを作成します。
ディスパッチャーの設定の詳細については、「ディスパッチャー設定ファイル」を参照してください。
start-msg dispatcher
このコマンドには、ディスパッチャーが管理するように設定された MTA のコンポーネントを起動するために以前使用していた、ほかのすべての start-msg コマンドが組み込まれています。そのため、組み込まれたコマンドはすべて無効になっています。特に、imsimta start smtp は使用しないでください。無効になったコマンドを実行しようとすると、MTA によって警告メッセージが表示されます。
stop-msg dispatcher
ディスパッチャーの終了時にサーバープロセスがどのように処理されるかは、その基礎となっている TCP/IP パッケージによって決まります。ディスパッチャーに適用される MTA の設定やオプションを変更した場合は、ディスパッチャーを必ず再起動して新しい設定やオプションを有効にします。
ディスパッチャーを再起動するには、次のコマンドを実行します。
imsimta restart dispatcher
ディスパッチャーを再起動すると、実行中のディスパッチャーが終了し、新しいディスパッチャーが起動します。
アドレスのドメイン部分を適切な形式や希望の形式に書き換える方法を指定する。
アドレスを書き換えたあとにメッセージをキューに入れるためのチャネルを決定する。
書き換えルールにはそれぞれパターンとテンプレートがあります。パターンは、アドレスのドメイン部分と照合する文字列です。テンプレートは、ドメイン部分がパターンと一致した場合に実行するアクションを指定します。これは、次の 2 つから構成されます。1) アドレスを書き換える方法を指定する指示のセット (一連の制御文字) と、2) メッセージの送信先のチャネル名。アドレスの書き換え後、メッセージは予定された受取人に配信するために宛先チャネルに入れられます。
書き換えルールの例を次に示します。
siroe.com $U%$D@tcp_siroe-daemon
siroe.com はドメインパターンです。アドレスに siroe.com を含むメッセージはテンプレートの指示 ($U%$D) に基づいて書き換えられます。$U は、書き換えられたアドレスでも同じユーザー名を使うように指定します。% は、書き換えられたアドレスでも同じドメイン区切り文字を使用するように指定します。$D は、パターンと一致したドメイン名を使うように指定します。@tcp_siroe-daemon は、書き換えられたアドレスのメッセージがチャネル tcp_siroe-daemon に送信されるように指定します。詳細は、第 11 章「書き換えルールの設定」 を参照してください。
書き換えルールの設定の詳細は、「MTA 設定ファイル」および第 11 章「書き換えルールの設定」を参照してください。
チャネルは、メッセージを処理するための基本的な MTA コンポーネントです。チャネルは、別のコンピュータシステムまたはシステムグループとの接続を表します。実際のハードウェア接続やソフトウェア転送は、チャネルによって大きく異なることがあります。
チャネルには、次のような機能があります。
メッセージをリモートシステムに送信し、その後メッセージをキューから削除する。
リモートシステムからメッセージを受信し、適切なチャネルキューに保存する。
メッセージをローカルのメッセージストアに配信する。
メッセージを特殊処理プログラムに配信する。
メッセージは、MTA に入るときにチャネルを介してキューに入れられ、MTA から出るときにキューから取り出されます。通常、メッセージは 1 つのチャネルを介して入り、別のチャネルを介して送り出されます。チャネルは、キューからのメッセージの取り出し、メッセージの処理、別の MTA チャネルのキューへのメッセージの保存などを行います。
通常 (常にそうというわけではない)、チャネルにはマスターとスレーブの 2 つのプログラムがあります。スレーブプログラムは、ほかのシステムからのメッセージを受け取り、そのメッセージをチャネルのメッセージキューに追加します。マスタープログラムは、チャネルからほかのシステムにメッセージを転送します。
たとえば、SMTP チャネルには、メッセージを送信するマスタープログラムと、メッセージを受信するスレーブプログラムがあります。これらは、それぞれ SMTP クライアントおよびサーバーに相当します。
通常、マスタープログラムは、MTA が発した送信接続を管理します。マスターチャネルプログラムには、以下のような機能があります。
ローカルの処理要求に応えて起動する。
チャネルメッセージキューからメッセージを取り出す。
宛先の形式が、キューにあるメッセージの形式と異なる場合は、必要に応じて、アドレス、ヘッダー、および内容の変換を行う。
メッセージのネットワーク転送を開始する。
通常、スレーブプログラムは、MTA が外部要求に応答するための着信接続を受け入れます。スレーブチャネルプログラムには、以下のような機能があります。
外部イベントまたはローカル要求に応えて起動する。
メッセージをチャネルキューに入れる。宛先チャネルは、書き換えルールでエンベロープアドレスを渡すと決定される。
たとえば、図 8–3 では、チャネル 1 とチャネル 2 の 2 つのチャネルプログラムが示されています。チャネル 1 のスレーブプログラムは、リモートシステムからメッセージを受信します。スレーブプログラムは、アドレスを確認して必要な書き換えルールを適用し、書き換えられたアドレスに基づいてメッセージを適切なチャネルメッセージキューに入れます。
マスタープログラムは、キューからメッセージを取り出し、メッセージのネットワーク転送を開始します。ただし、マスタープログラムは、自分のチャネルキューにあるメッセージしか取り出せません。
通常、1 つのチャネルにはマスタープログラムとスレーブプログラムの両方がありますが、スレーブプログラムまたはマスタープログラムしかないチャネルもあります。たとえば、Messaging Server で提供される ims-ms チャネルには、マスタープログラムしかありません。このチャネルでは、図 8–4 に示すように、キューからのメッセージの取り出しとローカルメッセージストアへの送信だけを行います。
すベてのチャネルに、メッセージキューが関連付けられています。メッセージがメッセージングシステムに入ると、スレーブプログラムがメッセージを入れるキューを決定します。キューに入れられたメッセージは、チャネルキューディレクトリのメッセージファイル内に保存されます。デフォルトでは、これらのディレクトリは msg_svr_base/data/queue/channel/* に配置されます。メッセージキューのサイズ設定については、『Sun Java System Communications Services 6 2005Q4 配備計画ガイド』の「MTA メッセージキューのディスクサイズ決定」を参照してください。
MTA キューディレクトリ (imta_tailor ファイル内の IMTA_QUEUE の値) に、ファイルまたはディレクトリを追加しないでください。これを行うと問題が発生します。MTA キューディレクトリに個別のファイルシステムを使用するときは、マウントポイントの下にサブディレクトリを作成し、そのサブディレクトリを IMTA_QUEUE の値として指定してください。
チャネル定義は MTA 設定ファイル (imta.cnf) の後半で、書き換えルールのあとに記載されています (「MTA 設定ファイル」を参照)。設定ファイル内で最初に現れる空白行は、書き換えルールの終了とチャネル定義の開始を表します。
チャネル定義には、チャネル名、チャネルの設定を定義するキーワードのオプションリスト、および一意のチャネルタグが含まれています。チャネルタグは書き換えルールで使用され、メッセージをチャネルにルーティングします。チャネル定義は 1 行の空白行によって区切られています。1 つのチャネル定義の中にコメント行を含めることはできますが、空白行を含めることはできません。
[blank line] ! sample channel definition Channel_Name keyword1 keyword2 Channel_Tag [blank line] |
チャネル定義を総称してチャネルホストテーブルと呼びます。個々のチャネル定義はチャネルブロックと呼ばれます。たとえば、次の例のチャネルホストテーブルには、チャネル定義つまりチャネルブロックが 3 つあります。
! test.cnf - An example configuration file. ! ! Rewrite Rules . . . ! BEGIN CHANNEL DEFINITIONS ! FIRST CHANNEL BLOCK l local-host ! SECOND CHANNEL BLOCK a_channel defragment charset7 usascii a-daemon ! THIRD CHANNEL BLOCK b_channel noreverse notices 1 2 3 b-daemon |
典型的なチャネルエントリは次のようなものです。
tcp_intranet smtp mx single_sys subdirs 20 noreverse maxjobs 7 SMTP_POOL maytlsserver allowswitchchannel saslswitchchannel tcp_auth tcp_intranet-daemon |
この例の最初の単語 tcp_intranet はチャネル名です。また、最後の単語 tcp_intranet-daemon はチャネルタグです。チャネルタグは、書き換えルールでメッセージを送信するために使用する名前です。チャネル名とチャネルタグの間にある単語はチャネルキーワードで、メッセージの処理方法を表します。さまざまなキーワードを使って、さまざまな方法でメッセージを処理できます。チャネルキーワードの一覧と説明は、第 12 章「チャネル定義を設定する」にあります。
チャネルホストテーブルは、Messaging Server で使用できるチャネルと、各チャネルに関連付けられているシステム名を定義します。
UNIX システムでは、常にファイルの最初のチャネルブロックでローカルチャネル l が示されます(例外はdefaults チャネルであり、このチャネルはローカルチャネルの前に出現)。ローカルチャネルを使ってルーティングを決定し、UNIX メールツールでメールを送信します。
MTA オプションファイル (option.dat) でも、チャネルのグローバルオプションを設定したり、チャネルオプションファイルで特定チャネルのオプションを設定したりできます。オプションファイルの詳細は、「オプションファイル」および 「TCP/IP (SMTP) チャネルオプションファイル」を参照してください。設定チャネルの詳細は、第 12 章「チャネル定義を設定する」を参照してください。MTA チャネルの作成の詳細は、「MTA 設定ファイル」を参照してください。
MTA は、処理する各メッセージに関して、サポートするユーザー、グループ、およびドメインに関するディレクトリ情報にアクセスする必要があります。この情報は、LDAP ディレクトリサービスに保存されています。MTA は LDAP ディレクトリに直接アクセスします。詳細は、第 9 章「MTA のアドレス変換とルーティング」を参照してください。
メッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。チャネルまたはプールのジョブ数が制限に達したためにジョブを開始できない場合は、ジョブコントローラは別のジョブが終了するまで待機します。ジョブ数の超過が解消されると、ジョブコントローラは別のジョブを開始します。
チャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。プールの詳細は、「ジョブコントローラファイル」および 「チャネル実行ジョブの処理プール」を参照してください。
チャネルのジョブ範囲は、maxjobs チャネルキーワードで決定します。プールのジョブ範囲は、プールの JOB_LIMIT オプションで決定します。
通常 Messaging Server は、すべてのメッセージの配信を即座に試行します。最初の試行でメッセージを配信できない場合、メッセージの配信は backoff キーワードに指定した時間だけ遅れることになります。メッセージは、backoff キーワードに指定した時間が経過するとすぐに配信できる状態になり、必要に応じてチャネルジョブがメッセージの処理を開始します。
ジョブコントローラのメモリ内における処理中メッセージおよび処理待ちメッセージのデータ構造は、ディスクの MTA キュー領域に保存されているすべてのメッセージファイルを反映しています。ただし、ディスク上のメッセージファイルのバックログが大きくなり、ジョブコントローラのメモリ内データ構造のサイズ限界値を超えると、ジョブコントローラはメモリ内でディスク上のメッセージファイルの一部だけをトラッキングします。ジョブコントローラはメモリ内でトラッキング中のメッセージだけを処理します。メモリ内ストレージを解放するのに十分な数のメッセージが配信されると、ジョブコントローラは MTA キュー領域をスキャンしてメッセージリストを更新し、メモリ内ストアを自動的に更新します。その後、ジョブコントローラはディスクから取り出したばかりの新しいメッセージファイルの処理を開始します。ジョブコントローラは、MTA キュー領域のスキャンを自動的に行います。
サイトに大量のメッセージバックログが頻繁にたまる場合は、MAX_MESSAGES オプションを使ってジョブコントローラをチューニングすることもできます。MAX_MESSAGESオプションの値を大きくすると、ジョブコントローラが使用するメモリが増え、メッセージのバックログがジョブコントローラのメモリ内キャッシュでオーバーフローする回数が減ります。これにより、ジョブコントローラが MTA キューディレクトリをスキャンするための負荷が低減されます。ただし、ジョブコントローラでメモリ内キャッシュを再構築する必要がある場合は、キャッシュが大きくなるので処理時間も長くなる点に注意してください。ジョブコントローラの起動時または再起動時には必ず MTA キューディレクトリをスキャンする必要があります。このため、メッセージのバックログが大量にある場合は、そのようなバックログがない場合に比べて、ジョブコントローラの起動や再起動に大きな負荷がかかります。
ジョブコントローラの設定とプールの詳細は、「ジョブコントローラファイル」および 「メッセージの処理と配信を設定する」を参照してください。
ジョブコントローラを起動するには、次のコマンドを実行します。
start-msg job_controller
ジョブコントローラを停止するには、次のコマンドを実行します。
stop-msg job_controller
ジョブコントローラを再起動するには、次のコマンドを実行します。
imsimta restart job_controller
ジョブコントローラを再起動すると、実行中のジョブコントローラが終了し、その後すぐに新しいジョブコントローラが起動します。