test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

第 8 章 MTA の概念

この章では、MTA の概念について説明します。この章には、次の節があります。

MTA の機能

MTA (Message Transfer Agent) は、Messaging Server (図 8–1) の構成要素です。もっとも基本的なレベルにおいては、MTA はメッセージルーターです。MTA はほかのサーバーからメッセージを受信してアドレスを読み取り、最終的な宛先 (通常はユーザーのメールボックス) に向けて次のサーバーにルーティングします。

長年にわたって、MTA には多くの機能が追加され、サイズ、能力、および複雑さも増してきました。これらの MTA 機能は重複していますが、通常は次のように分類できます。

これらの機能は、図 8–2 に示される多数のサブコンポーネントおよびプロセスでサポートされています。この章では、これらのサブコンポーネントとプロセスについて説明します。また、システム管理者は多数のツールを使用して、これらの機能を有効化および設定することができます。このようなツールには、MTA オプション、configutil パラメータ、マッピングテーブル、キーワード、チャネル、書き換えルールなどがあります。これらのツールについては、後に MTA の章で説明します。

図 8–1 Messaging Server の簡易コンポーネント表示 (Communications Express は表示されていない)

図は、Messaging Server の簡易表示を示しています。

図 8–2 MTA のアーキテクチャー

図は、MTA の簡易アーキテクチャーとデータフローを示しています。

MTA アーキテクチャーとメッセージフローの概要

ここでは、MTA のアーキテクチャーとメッセージフローの概要を簡単に説明します (図 8–2)。MTA は非常に複雑なコンポーネントであり、この図はシステムを通じて配信されるメッセージの簡略図であることに注意してください。実際、この図は、システムを通じて配信されるすべてのメッセージを厳密に示しているわけではありません。ただし、概念を説明するという目的は十分に果たしています。

ディスパッチャーと SMTP サーバー (スレーブプログラム)

SMTP セッションを介して、インターネットまたはイントラネットから MTA にメッセージが届きます。MTA が SMTP 接続要求を受信すると、MTA ディスパッチャー (マルチスレッド接続ディスパッチエージェント) はスレーブプログラム (tcp_smtp_server) を実行して SMTP セッションを処理します。ディスパッチャーは、各サービスのマルチスレッドプロセスのプールを管理します。さらにセッションが要求されると、ディスパッチャーは SMTP サーバープログラムを起動して、それぞれのセッションを処理します。ディスパッチャーのプロセスプール内のプロセスは、複数の接続を同時に処理することもあります。ディスパッチャーとスレーブプログラムにより、着信メッセージごとにさまざまな機能が実行されます。次の 3 つの基本機能があります。

詳細は、「ディスパッチャー」を参照してください。

ルーティングとアドレス書き換え

メッセージは 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 のスレーブプログラムは、リモートシステムからメッセージを受信します。スレーブプログラムは、アドレスを確認して必要な書き換えルールを適用し、書き換えられたアドレスに基づいてメッセージを適切なチャネルメッセージキューに入れます。

マスタープログラムは、キューからメッセージを取り出し、メッセージのネットワーク転送を開始します。ただし、マスタープログラムは、自分のチャネルキューにあるメッセージしか取り出せません。

図 8–3 マスタープログラムとスレーブプログラム

図は、マスタープログラムとスレーブプログラムの相互作用を示しています。

通常、1 つのチャネルにはマスタープログラムとスレーブプログラムの両方がありますが、スレーブプログラムまたはマスタープログラムしかないチャネルもあります。たとえば、Messaging Server で提供される ims-ms チャネルには、マスタープログラムしかありません。このチャネルでは、図 8–4 に示すように、キューからのメッセージの取り出しとローカルメッセージストアへの送信だけを行います。

図 8–4 ims-ms チャネル

図は、ims-ms チャネルを示しています。

チャネルメッセージキュー

すベてのチャネルに、メッセージキューが関連付けられています。メッセージがメッセージングシステムに入ると、スレーブプログラムがメッセージを入れるキューを決定します。キューに入れられたメッセージは、チャネルキューディレクトリのメッセージファイル内に保存されます。デフォルトでは、これらのディレクトリは 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 ディレクトリ情報

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

ジョブコントローラを再起動すると、実行中のジョブコントローラが終了し、その後すぐに新しいジョブコントローラが起動します。