前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



第 5 章   MTA の概念


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



MTA の機能

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

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

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

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

  • メッセージの処理 - さまざまな種類のメッセージを処理する。たとえば、以下のような処理を行う

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

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

    • SASL サポートの提供

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

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

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

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

図 5-1    iPlanet Messaging Server の簡易コンポーネント表示 (Messenger Express では表示されない)

図 5-2    MTA のアーキテクチャ



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


ここでは、MTA のアーキテクチャとメッセージフローの概要を簡単に説明します (図 5-2)。


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

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

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

  • チャネルのエンキュー処理 - アドレスに書き換え規則を適用し、メッセージを送信するチャネルを決定する

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


エンキュー
配信のこの段階ではさまざまなタスクが実行されますが、主なタスクは以下のとおりです。

  • エイリアスをエクスパンドする

  • アドレスに書き換え規則を適用してメッセージをキューに入れるチャネルを決定し、アドレスのドメイン部分を正しい形式または必要な形式に書き換える

  • チャネルキーワードを処理する

  • メッセージを該当するチャネルキューに送信する


チャネル
チャネルは、メッセージを処理するための基本的な 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 はチャネル名です。最後の単語はチャネルタグです。チャネル名とチャネルタグの間にある単語はチャネルキーワードで、メッセージの処理方法を表します。さまざまなキーワードを使って、さまざまな方法でメッセージを処理できます。チャネルキーワードの詳しい説明は、『iPlanet Messaging Server リファレンスマニュアル』と第 8 章「チャネル定義を設定する」にあります。


メッセージの配信
メッセージが処理されると、マスタープログラムはメッセージの配信パスに沿って次の送信先にメッセージを送ります。次の送信先が予定した受取人のメールボックスであることもあれば、別の 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 コマンドによってサーバプロセスが突然終了した場合、ディスパッチャは新しい接続ごとに新規サーバプロセスを作成します。

ディスパッチャの設定の詳細については、「ディスパッチャ設定ファイル」を参照してください。


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

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

imsimta start dispatcher

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

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

imsimta stop dispatcher

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

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

imsimta restart dispatcher

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



書き換え規則


書き換え規則には、以下の目的があります。

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

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

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

書き換え規則の例を次に示します。

siroe.com             $U%$D@tcp_siroe-daemon

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

書き換え規則の設定の詳細については、「MTA 設定ファイル」および第 7 章「書き換え規則を設定する」を参照してください。



チャネル


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

チャネルには、以下のような機能があります。

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

図 5-3    マスタープログラムとスレーブプログラム

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

図 5-4    ims-ms チャネル


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

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


チャネル定義

チャネル定義は MTA 設定ファイル (imta.cnf) の後半で、書き換え規則のあとに記載されています (「MTA 設定ファイル」 を参照)。設定ファイル内で最初に現れる空白行は、書き換え規則の終了とチャネル定義の開始を表します。

チャネル定義には、チャネル名、チャネルの設定を定義するキーワードのオプションリスト、および一意のチャネルタグが含まれています。チャネルタグは書き換え規則で使用され、メッセージをチャネルにルーティングします。チャネル定義は 1 行の空白行によって区切られています。1 つのチャネル定義の中にコメント行を含めることはできますが、空白行を含めることはできません。
[blank line]
! sample channel definition
Channel_Name keyword1 keyword2
Channel_Tag
[blank line]

チャネル定義を総称してチャネルホストテーブルと呼びます。個々のチャネル定義はチャネルブロックと呼ばれます。たとえば、図 5-5 のチャネルホストテーブルには、チャネル定義つまりチャネルブロックが 3 つあります。

図 5-5    簡単な設定ファイル - チャネル定義
! 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 はチャネルタグです。チャネルタグは、書き換え規則でメッセージを送信するために使用する名前です。チャネル名とチャネルタグの間にある単語はチャネルキーワードで、メッセージの処理方法を表します。さまざまなキーワードを使って、さまざまな方法でメッセージを処理できます。チャネルキーワードの一覧と説明は、『iPlanet Messaging Server リファレンスマニュアル』と第 8 章「チャネル定義を設定する」にあります。

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

UNIX システムでは、ファイルにある最初のチャネルブロックは必ずローカルチャネル l を表します(ただし defaults チャネルは例外で、ローカルチャネルより先に表示されます)。ローカルチャネルを使ってルーティングを決定し、UNIX メールツールでメールを送信します。

MTA オプションファイル (option.dat) でも、チャネルのグローバルオプションを設定したり、チャネルオプションファイルで特定チャネルのオプションを設定したりできます。オプションファイルの詳細については、「オプションファイル」および 「TCP/IP (SMTP) チャネルオプションファイル」を参照してください。チャネル設定の詳細については、第 8 章「チャネル定義を設定する」を参照してください。MTA チャネル作成の詳細については、「MTA 設定ファイル」を参照してください。



MTA ディレクトリ情報


MTA は、処理する各メッセージに関して、サポートするユーザ、グループ、およびドメインに関するディレクトリ情報にアクセスする必要があります。この情報は、LDAP ディレクトリサービスに保存されています。MTA からは、2 つの方法でこの情報にアクセスできます。1 つは LDAP ディレクトリに直接アクセスする方法です。これはダイレクト LDAP モードと呼ばれます。詳細は付録 B「MTA ダイレクト LDAP 操作」に記載されています。もう 1 つはデフォルトの方法で、ディレクトリキャッシュを介してディレクトリ情報にアクセスします。これは dirsync モードと呼ばれます。

dirsync モードでは、MTA が使用するユーザとグループに関するディレクトリ情報には、多数のファイルおよびデータベース (総称してディレクトリキャッシュと呼ぶ) を介してアクセスします。データ自体は LDAP ディレクトリに格納されていますが、実際の情報にはキャッシュを介してアクセスします。キャッシュのデータは dirsync プログラムを使って更新します。このプログラムでは LDAP ディレクトリへの変更を監視し、変更されたファイルやデータベースがあれば更新します。

dirsync の操作と設定の詳細については、「dirsync の設定」を参照してください。



ジョブコントローラ


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

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

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

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

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

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

ジョブコントローラは、数多くの定期的なジョブも実行します。これらのジョブは、cron などの一般的な機能を使用せず、ジョブコントローラ設定で設定されるため、ジョブのスケジュールは実行中のジョブコントローラに依存します。これは、フェイルオーバーが考慮される高可用性の設定では、重要なポイントとなります。

ジョブコントローラの設定とプールの詳細については、「ジョブコントローラファイル」および 「メッセージの処理と配信を設定する」を参照してください。


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

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

imsimta start job_controller

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

imsimta stop job_controller

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

imsimta restart job_controller

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


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日