第 6 章 MTA の概念

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

MTA の機能

MTA (図 6-2) は以下の機能を実行する Messaging Server (図 6-1) の構成要素です。

メッセージのルーティング - メッセージを受け取り、A) 別の SMTP ホスト、B) ローカルメッセージストア、または C) 処理プログラム (ウィルスチェックなど) にルーティングする

メッセージのブロッキング - 特定のソースや宛先の IP アドレス、メールアドレス、ポート、チャネル、ヘッダー文字列などに基づいて、メッセージをブロックまたは許可する

アドレスの書き換え - 受信したアドレスの From: や To: を必要な形式に書き換える

メッセージの処理 - さまざまな種類のメッセージを処理する

例 :

エイリアスのエクスパンド

SMTP コマンドおよびプロトコルサポートの管理

SASL サポートの提供

指定したアドレス数を超過した場合のメッセージの保留

ウィルスチェックやメールファイリングプログラムなど、サイト提供プログラムへのメッセージの配信

メッセージ部分ごとのメッセージ変換の実行

配信状況通知メッセージのカスタマイズ

図 6-1 Messaging Server, 簡易コンポーネント表示 (Messenger Express では表示されない)
図は、Messaging Server の簡易コンポーネント表示を示しています。

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

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

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

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

メッセージのブロッキング - 特定の IP アドレス、メールアドレス、ポート、チャネル、ヘッダー文字列などを含むメッセージをブロックする (第 14 章「メールのフィルタリングとアクセス制御」)

アドレスの変更 - 受信したアドレスの 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 tcpauth
tcpintranet-daemon

この場合、最初の単語 tcp_intranet はチャネル名です。最後の単語はチャネルタグです。チャネル名とチャネルタグの間にある単語はチャネルキーワードで、メッセージの処理方法を表します。さまざまなキーワードを使って、さまざまな方法でメッセージを処理できます。チャネルキーワードの詳しい説明は、『Sun ONE Messaging Server Reference Guide』と第 10 章「チャネル定義を設定する」にあります。

メッセージの配信

メッセージが処理されると、マスタープログラムはメッセージの配信パスに沿って次の送信先にメッセージを送ります。次の送信先が予定した受取人のメールボックスであることもあれば、別の MTA や別のチャネルであることもあります。この図では別のチャネルへの転送は表示されていませんが、そのようなケースもよくあります。

ディスパッチャ

ディスパッチャは、複数のマルチスレッドサーバー処理が 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 コマンドによってサーバープロセスが突然終了した場合、ディスパッチャは新しい接続ごとに新規サーバープロセスを作成します。

ディスパッチャを起動および停止するには

ディスパッチャを起動するには、次のコマンドを実行します。

このコマンドには、ディスパッチャが管理するように設定された MTA のコンポーネントを起動するために以前使用していた、ほかのすべての start-msg コマンドが組み込まれています。以前のコマンドはすべて無効になっています。特に、imsimta start smtp は使用しないでください。無効になったコマンドを実行しようとすると、MTA によって警告メッセージが表示されます。

ディスパッチャを終了するには、次のコマンドを実行します。

ディスパッチャの終了時にサーバープロセスがどのように処理されるかは、その基礎となっている TCP/IP パッケージによって決まります。ディスパッチャに適用される MTA の設定やオプションを変更した場合は、ディスパッチャを必ず再起動して新しい設定やオプションを有効にします。

ディスパッチャを再起動するには、次のコマンドを実行します。

ディスパッチャを再起動すると、実行中のディスパッチャが終了し、新しいディスパッチャが起動します。

書き換えルール

アドレスのドメイン部分を適切な形式や希望の形式に書き換える方法を指定する

アドレスを書き換えたあとにメッセージをキューに入れるためのチャネルを決定する

書き換えルールにはそれぞれパターンとテンプレートがあります。パターンは、アドレスのドメイン部分と照合する文字列です。テンプレートは、ドメイン部分がパターンと一致した場合に実行するアクションを指定します。これは、次の 2 つから構成されます。1) アドレスを書き換える方法を指定する指示のセット (一連の制御文字) と、2) メッセージの送信先のチャネル名。アドレスの書き換え後、メッセージは予定された受取人に配信するために宛先チャネルに入れられます。

siroe.com はドメインパターンです。アドレスに siroe.com を含むメッセージはテンプレートの指示 ($U%$D) に基づいて書き換えられます。$U は、書き換えられたアドレスでも同じユーザー名を使うように指定します。% は、書き換えられたアドレスでも同じドメイン区切り文字を使用するように指定します。$D は、パターンと一致したドメイン名を使うように指定します。@tcp_siroe-daemon は、書き換えられたアドレスのメッセージがチャネル tcp_siroe-daemon に送信されるように指定します。詳細は、第 9 章「書き換えルールを設定する」を参照してください。

チャネル

チャネルは、メッセージを処理するための基本的な MTA コンポーネントです。チャネルは、別のコンピュータシステムまたはシステムグループとの接続を表します。実際のハードウェア接続やソフトウェア転送は、チャネルによって大きく異なることがあります。

メッセージをリモートシステムに送信し、その後メッセージをキューから削除する

リモートシステムからメッセージを受信し、適切なチャネルキューに保存する

メッセージをローカルのメッセージストアに配信する

メッセージを特殊処理プログラムに配信する

メッセージは、MTA に入るときにチャネルを介してキューに入れられ、MTA から出るときにキューから取り出されます。通常、メッセージは 1 つのチャネルを介して入り、別のチャネルを介して送り出されます。チャネルは、キューからのメッセージの取り出し、メッセージの処理、別の MTA チャネルのキューへのメッセージの保存などを行います。

マスタープログラムとスレーブプログラム

通常、各チャネルにはマスターとスレーブの 2 つのプログラムがあります。スレーブプログラムは、ほかのシステムからのメッセージを受け取り、そのメッセージをチャネルのメッセージキューに追加します。マスタープログラムは、チャネルからほかのシステムにメッセージを転送します。

たとえば、SMTP チャネルには、メッセージを送信するマスタープログラムと、メッセージを受信するスレーブプログラムがあります。これらは、それぞれ SMTP クライアントおよびサーバーに相当します。

通常、マスタープログラムは、MTA が発した送信接続を管理します。マスターチャネルプログラムには、以下のような機能があります。

ローカルの処理要求に応えて起動する

チャネルメッセージキューからメッセージを取り出す

宛先の形式が、キューにあるメッセージの形式と異なる場合は、必要に応じて、アドレス、ヘッダー、および内容の変換を行う

メッセージのネットワーク転送を開始する

通常、スレーブプログラムは、MTA が外部要求に応答するための受信接続を受け入れます。スレーブチャネルプログラムには、以下のような機能があります。

外部イベントまたはローカル要求に応えて起動する

メッセージをチャネルキューに入れる。宛先チャネルは、書き換えルールでエンベロープアドレスを渡すと決定される

たとえば、図 6-3 では、チャネル 1 とチャネル 2 の 2 つのチャネルプログラムが示されています。チャネル 1 のスレーブプログラムは、リモートシステムからメッセージを受信します。スレーブプログラムは、アドレスを確認して必要な書き換えルールを適用し、書き換えられたアドレスに基づいてメッセージを適切なチャネルメッセージキューに入れます。

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

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

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

すべてのチャネルに、メッセージキューが関連付けられています。メッセージがメッセージングシステムに入ると、スレーブプログラムがメッセージを入れるキューを決定します。キューに入れられたメッセージは、チャネルキューディレクトリのメッセージファイル内に保存されます。デフォルトでは、これらのディレクトリは msg_svr_base/data/queue/channel/* に保存されます。.



警告	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 - 設定ファイルの例。
!
! ! 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 tcpauth
tcpintranet-daemon

この例の最初の単語 tcp_intranet はチャネル名です。また、最後の単語 tcpintranet-daemon はチャネルタグです。チャネルタグは、書き換えルールでメッセージを送信するために使用する名前です。チャネル名とチャネルタグの間にある単語はチャネルキーワードで、メッセージの処理方法を表します。さまざまなキーワードを使って、さまざまな方法でメッセージを処理できます。チャネルキーワードの一覧と説明は、『Sun ONE Messaging Server Reference Guide』と第 10 章「チャネル定義を設定する」にあります。

チャネルホストテーブルは、Messaging Server で使用できるチャネルと、各チャネルに関連付けられているシステム名を定義します。

UNIX システムでは、常にファイルの最初のチャネルブロックでローカルチャネル (l) が示されます (例外は defaults チャネルであり、このチャネルはローカルチャネルの前に出現)。ローカルチャネルを使ってルーティングを決定し、UNIX メールツールでメールを送信します。

MTA ディレクトリ情報

MTA は、処理する各メッセージに関して、サポートするユーザー、グループ、およびドメインに関するディレクトリ情報にアクセスする必要があります。この情報は、LDAP ディレクトリサービスに保存されています。MTA は LDAP ディレクトリに直接アクセスします。詳細は、第 7 章「ダイレクト LDAP を使用したアドレスの変換とルーティング」を参照してください。

ジョブコントローラ

メッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。チャネルまたはプールのジョブ数が制限に達したためにジョブを開始できない場合は、ジョブコントローラは別のジョブが終了するまで待機します。ジョブ数の超過が解消されると、ジョブコントローラは別のジョブを開始します。

チャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。プールの詳細については、「ジョブコントローラファイル」および「チャネル実行ジョブのプールを処理する」を参照してください。

チャネルのジョブ範囲は maxjobs チャネルキーワードで決定します。プールのジョブ範囲は、プールの JOB_LIMIT オプションで決定します。

通常 Messaging Server は、すべてのメッセージの配信を即座に試行します。最初の試行でメッセージを配信できない場合、メッセージの配信は backoff キーワードに指定した時間だけ遅れることになります。メッセージは、backoff キーワードに指定した時間が経過するとすぐに配信できる状態になり、必要に応じてチャネルジョブがメッセージの処理を開始します。

ジョブコントローラのメモリ内における処理中メッセージおよび処理待ちメッセージのデータ構造は、ディスクの MTA キュー領域に保存されているすべてのメッセージファイルを反映しています。ただし、ディスク上のメッセージファイルのバックログが大きくなり、ジョブコントローラのメモリ内データ構造のサイズ限界値を超えると、ジョブコントローラはメモリ内でディスク上のメッセージファイルの一部だけをトラッキングします。ジョブコントローラはメモリ内でトラッキング中のメッセージだけを処理します。メモリ内ストレージを開放できるだけの大量のメッセージが配信されると、ジョブコントローラは MTA キュー領域をスキャンしてメッセージリストを更新し、メモリ内ストアを自動的に更新します。その後、ジョブコントローラはディスクから取り出したばかりの新しいメッセージファイルの処理を開始します。ジョブコントローラは、MTA キュー領域のスキャンを自動的に行います。

サイトに大量のメッセージバックログが頻繁にたまる場合は、MAX_MESSAGES オプションを使ってジョブコントローラをチューニングすることもできます。MAX_MESSAGES オプションの値を大きくすると、ジョブコントローラが使用するメモリが増え、メッセージのバックログがジョブコントローラのメモリ内キャッシュでオーバーフローする回数が減ります。これにより、ジョブコントローラが MTA キューディレクトリをスキャンするための負荷が低減されます。ただし、ジョブコントローラでメモり内キャッシュを再構築する必要がある場合は、キャッシュが大きくなるので処理時間も長くなる点に注意してください。ジョブコントローラの起動時または再起動時には必ず MTA キューディレクトリをスキャンする必要があります。このため、メッセージのバックログが大量にある場合は、そのようなバックログがない場合に比べて、ジョブコントローラの起動や再起動に大きな負荷がかかります。

ジョブコントローラを起動および停止するには

ジョブコントローラを起動するには、次のコマンドを実行します。

ジョブコントローラを停止するには、次のコマンドを実行します

ジョブコントローラを再起動するには、次のコマンドを実行します。

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