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

第 6 章 MTA サービスと設定について


この章では、サーバにおける MTA サービスの設定に関する概念を説明します。この章には、以下の項目があります。


メッセージ転送エージェント (MTA)

Messaging Server の MTA は、インターネット標準に基づいた保存および転送用メッセージングシステムです。メッセージ転送エージェント (MTA) は、メッセージが適切な受取人に配信されるように、メッセージのルーティング方法を決定します。図 6-1に示すように、MTA は以下の操作を行います。

図 6-1 MTA のルーティングと配信


チャネル


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

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

メッセージは、MTA に入るときにチャネルによってキュー内に配置され、MTA から出るときに取り出されます。通常、メッセージは 1 つのチャネルを介して入り、別のチャネルを介して送り出されます。チャネルは、メッセージを取り出して処理したり、または別の MTA チャネルのキューに配置したりします。

チャネルは、プライマリ MTA 設定ファイル imta.cnf で定義します。また、MTA オプションファイル option.dat でチャネルのグローバルオプションを設定したり、チャネルオプションファイルで特定のチャネルを設定することもできます。

MTA 設定ファイルの詳細については、「MTA 設定ファイル」を参照してください。オプションファイルの詳細については、「オプションファイル」および「TCP/IP チャネルオプションファイル」を参照してください。チャネルの設定の詳細については、第 8 章「チャネル定義を設定する」を参照してください。


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

通常、チャネルには 2 つのプログラムがあります。マスターおよびスレーブと呼ばれるプログラムです。リモートシステムへの送信を開始するチャネルプログラムが「マスタープログラム」で、リモートシステムから開始された送信を受け取るプログラムが「スレーブプログラム」です。

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

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

スレーブプログラムは、メッセージをそのチャネル内のメッセージキューに、または別のチャネルのメッセージキューに入れることができます。マスタープログラムは、キュー内で待機しているメッセージを取り出し、メッセージのネットワーク転送を開始します。ただし、マスタープログラムは、その独自のチャネルキュー内にあるメッセージしか取り出せません。

図 6-2 マスタープログラムとスレーブプログラム

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

図 6-3 ims-ms チャネル


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

すべてのチャネルには、関連付けられたメッセージキューがあります。メッセージがメッセージングシステムに入ると、スレーブプログラムによってメッセージを入れるキューが決められます。キューに入れられたメッセージは、チャネルキューディレクトリのメッセージファイル内に保存されます。これらのディレクトリは、デフォルトで以下の場所に保存されます : /サーバ-インスタンス/imta/queue/チャネル/*


書き換え規則


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

各書き換え規則には、それぞれパターンとテンプレートがあります。パターンは、アドレスのドメイン名を検索する文字列であり、テンプレートは一致したパターンに基づいてアドレスを書き換える方法を示すものです。アドレスが書き換えられた後、メッセージはその受取人に配信するために、宛先チャネルに入れられます。

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


ジョブコントローラ


ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。

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

ジョブコントローラは、起動時に設定ファイルを読み込みます。設定ファイルには、一般的なパラメータ、返信ジョブスケジューリング、パージジョブスケジューリング、プール定義、およびチャネル処理情報が指定されています。この設定情報は、サーバ_ルート/msg-インスタンス/imta/config/ ディレクトリの job_controller.cnf に保存されています。

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

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

imsimta start job_controller

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

imsimta stop job_controller

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

imsimta restart job_controller

ジョブコントローラを再起動すると、動作中のジョブコントローラが終了し、新規のジョブコントローラが起動します。


ディスパッチャ


ディスパッチャとは、指定のサービスにおける責任を共有するための複数のマルチスレッドサーバを許可するマルチスレッド接続ディスパッチエージェントのことです。ディスパッチャを使用すると、複数のマルチスレッド SMTP サーバを同時実行できるようになります。また、それぞれのサーバで複数のアクティブな接続が可能になります。

ディスパッチャは、その設定に一覧されている 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 は使用しないでください。無効になったコマンドを実行しようとすると、警告メッセージが表示されます。

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

imsimta stop dispatcher

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

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

imsimta restart dispatcher

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


MTA 設定ファイル


最も重要な MTA 設定ファイル名は、imta.cnf です。デフォルトにより、このファイルは次の場所に保存されています。サーバ-インスタンス/imta/config/imta.cnf。このファイルには、サーバのすべてのチャネル定義、およびルーティング用でアドレスを書き換える際の書き換え規則が含まれています。書き換えられた宛先アドレスに関連付けられたチャネルが、宛先チャネルとなります。

この節では、MTA 設定ファイルについて簡単に説明します。MTA 設定ファイルに含まれている書き換え規則およびチャネル定義の設定については、第 7 章「書き換え規則を設定する」および第 8 章「チャネル定義を設定する」を参照してください。

MTA 設定ファイルを変更することにより、サイトで使用されるチャネルを確立し、書き換え規則を介してどのチャネルがどのようなアドレスを処理するかを決定することができます。設定ファイルは、送信方法 (チャネル) およびトランスポートルート (書き換え規則) を指定し、アドレスのタイプを適切なチャネルに関連付けることにより電子メールシステムの体系を確立するためのファイルです。

次の imta.cnf 設定ファイルの例は、書き換え規則を使って適切なチャネルにメッセージをルーティングする方法を示しています。わかりやすくするために、ドメイン名は使用していません。書き換え規則は設定ファイルの前半部分にあり、その後にチャネル定義が続いています。

図 6-4 簡単な MTA 設定ファイルの例
! test.cnf - An example configuration file. (1)
!
! This is only an example of a configuration file. It serves
! no useful purpose and should not be used in a real system.
!
a $U@a-daemon (2)
b $U@b-daemon
c $U%c@b-daemon
d $U%d@a-daemon
(3)
l (4)
local-host

a_channel defragment charset7 usascii (5)
a-daemon

b_channel noreverse notices 1 2 3
b-daemon


以下に、上記設定ファイルの主な項目 (カッコで括られた番号付き) について説明します。

  1. 感嘆符 (!) は、コメント行を表します。感嘆符は最初のカラムに表示されていなければなりません。その他の場所で表示される感嘆符は、文字として解釈されます。

  2. 書き換え規則は設定ファイルの前半部分にあります。書き換え規則に空白行を入れることはできません。コメント行 (最初のカラムに感嘆符が付いている) を入れることはできます。

  3. 設定ファイル内で最初に現れる空白行は、書き換え規則の終わりとチャネル定義の始まりを表します。

  4. UNIX の場合、最初のチャネル定義ブロックは常に l チャネル (「L」の小文字で指定された UNIX ローカルチャネル) です。各チャネル定義ブロックは、空白行で区切られています (defaults チャネルは例外。このチャネルは l チャネルより先に表示されます)。

表 6-1 に、上記設定ファイルによるメッセージのルーティングおよびキュー処理を示します。

表 6-1 アドレスと関連チャネル


アドレス

チャネル(キュー)

u@a

a_channel

u@b

b_channel

u@c

b_channel

u@d

a_channel


その他の MTA 設定ファイル


imta.cnf ファイルの他にも、iPlanet Messaging Server にはMTA サービスを設定するのに役立ついくつかの設定ファイルがあります。表 6-2に、これらの設定ファイルの要約を示します。

表 6-2 MTA 設定ファイル


ファイル

説明

自動返信オプションファイル

autoreply プログラムによって使用されるオプション。
/サーバ-インスタンス/imta/config/autoreply_option

エイリアスファイル (必須)

ディレクトリにないエイリアスを実行します。
/サーバ-インスタンス/imta/config/aliases

TCP/IP チャネルオプションファイル

チャネル固有のオプションを設定します。
/サーバ-インスタンス/imta/config/チャネル_option

変換ファイル

変換チャネルがメッセージ本体部分の変換を制御するのに使用します。
/サーバ-インスタンス/imta/config/conversions

Dirsync オプションファイル (必須)

dirsync プログラムによって使用されるオプション。
/サーバ-インスタンス/imta/config/dirsync.opt

ディスパッチャ設定ファイル (必須)

ディスパッチャ用の設定ファイル。
/サーバ-インスタンス/imta/config/dispatcher.cnf

MTA 設定ファイル (必須)

アドレスの書き換え、ルーティング、およびチャネル定義に使用します。
/サーバ-インスタンス/imta/config/imta.cnf

マッピングファイル (必須)

マッピングテーブルのリポジトリ。
/サーバ-インスタンス/imta/config/mappings

オプションファイル

グローバルな MTA オプションのファイル。
/サーバ-インスタンス/imta/config/option.dat

テイラーファイル (必須)

場所といくつかの調整パラメータを指定するファイル。
/サーバ-インスタンス/imta/config/imta_tailor

ジョブコントローラファイル (必須)

ジョブコントローラによって使用する設定ファイル。
/サーバ-インスタンス/imta/config/job_controller.cnf


自動返信オプションファイル

自動返信ファイル autoreply_option は、自動返信または Vacation プログラムのオプションを設定します。このファイルの構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


エイリアスファイル

エイリアスファイル aliases は、ディレクトリにないエイリアスを設定します。その例として、ルートのアドレスが挙げられます。このファイルで設定したエイリアスがディレクトリにもある場合は、ファイル内の設定が無視されます。エイリアスおよび aliases ファイルの詳細については、「エイリアス」を参照してください。

aliases ファイルに変更を加えた場合は、必ず MTA を再起動してください。


TCP/IP チャネルオプションファイル

TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。チャネルオプションファイルは、MTA 設定ディレクトリに保存する必要があります。ファイルには x_option という名前を付けてください。ファイル名の x はチャネル名となります。たとえば、次のようになります。/サーバ-インスタンス/config/imta/tcp_local_option

オプションファイルは、1 つまたは複数のキーワードと 1 つの関連する値により構成されています。たとえば、DISABLE_EXPAND キーワードをオプションファイルに入れ、値を 1 に設定すると、サーバの SMTP EXPN コマンドを無効にすることができます。

その他のオプションファイルキーワードを使って、以下の設定を行うことができます。

すべてのチャネルオプションキーワードおよび構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


変換ファイル

変換ファイル conversions は、MTA を介して送受信されるメッセージの変換チャネルにおける変換方法を指定します。変換には、いずれの MTA 通信のサブセットでも選択することができます。また、変換処理を行うには、いずれのプログラムまたはコマンドのセットでも使用することができます。MTA は変換ファイルに基づいて、それぞれのメッセージ本文に対する適切な変換を選択します。

このファイルの構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


Dirsync オプションファイル

Dirsync オプションファイル dirsync.opt は、コマンドラインで設定できない dirsync プログラムのオプションを設定します。

このファイルの構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


ディスパッチャ設定ファイル

ディスパッチャ設定ファイル dispatcher.cnf は、ディスパッチャの設定情報を指定します。インスール時に作成されたデフォルトの設定ファイルをそのまま使用することができます。ただし、セキュリティやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合には、dispatcher.cnf ファイルを変更します。

ディスパッチャ設定ファイルのフォーマットは、その他の MTA 設定ファイルに似ています。オプションを指定する行は、次の形式に従います。

option=value

option はオプション名で、value はオプションを設定する文字列または整数となります。option が整数の value を認める場合は、b%v という形式の記数法を使って基数を指定できます。b は基数 10 で表される基数となり、v は基数 b が表している実際の値となります。このようなオプション仕様は、下記のオプション設定が適用されるサービスに応じてセクション別にグループ分けされます。これには、次の形式の行を使用します。

[SERVICE=service-name]

service-name はサービス名です。このようなセクションタグの前に記述されている最初のオプション仕様は、すべてのセクションに適用されます。

以下に、ディスパッチャ設定ファイル (dispatcher.cnf) の例を示します。
! The first set of options, listed without a [SERVICE=xxx]
! header, are the default options that will be applied to all
! services.
!
MIN_PROCS=0
MAX_PROCS=5
MIN_CONNS=5
MAX_CONNS=20
MAX_LIFE_TIME=86400
MAX_LIFE_CONNS=100
MAX_SHUTDOWN=2
!
! Define the services available to Dispatcher
!
[SERVICE=SMTP]
PORT=25
IMAGE=サーバ-ルート/msg-インスタンス/imta/lib/tcp_smtp_server
LOGFILE=サーバ-ルート/msg-インスタンス/imta/log/tcp_smtp_server.log

このファイルのパラメータの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


マッピングファイル

マッピングファイル mappings は、MTA が入力文字列を出力文字列にマップする方法を定義します。

MTA コンポーネントの多くは、テーブル検索に基づいた情報を使用します。一般に、このタイプのテーブルは、入力文字列を出力文字列に変える (マップする) のに使用されます。このようなテーブルは、マッピングテーブルと呼ばれ、通常 2 つのカラムで構成されます。1 つ目 (左側) のカラムには入力文字列が、2 つ目 (右側) のカラムにはその入力文字列に関連付けられた出力文字列が並んでいます。MTA データベースのほとんどは、このタイプのマッピングテーブルです。ただし、MTA データベースファイルには、ワイルドカード検索機能はありません。データベース全体でワイルドカードに一致するものを検索するのは非効率的だからです。

マッピングファイルによって、MTA が複数のマッピングテーブルをサポートできるようになります。さらに、完全なワイルドカード機能もあり、複数の手順や反復マッピング方法にも対応しています。このアプローチは、データベースを使用する場合に比べてさらに多くの処理を必要とします。特に、エントリ数が多い場合などはなおさらです。ただし、それに付随して柔軟性が増すため、同等のデータベースにおけるエントリのほとんどを必要としなくなり、全体的にオーバーヘッドが少なくなります。

imsimta test -mapping コマンドを使ってマッピングテーブルをテストすることができます。マッピングファイルの構文および test -mapping コマンドの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


オプションファイル

オプションファイル option.dat は、チャネル オプションとは逆に、グローバルな MTA オプションを指定します。

オプションファイルを使って、MTA 全体に適用されるさまざまなパラメータのデフォルト値を無効にすることができます。特に、設定ファイルやエイリアスファイルが読み込まれるさまざまなテーブルのサイズを確立するのに使用できます。また、MTA が受信するメッセージのサイズを制御したり、MTA 設定で許可するチャネル数を指定したり、許可する書き換え規則の数を設定するなどの操作を行うことができます。

オプションファイルの構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


テイラーファイル

テイラーファイル imta_tailor は、さまざまな MTA コンポーネントの場所を設定します。MTA が正常に機能するには、imta_tailor ファイルが常にサーバ-インスタンス/imta/config ディレクトリ内になければなりません。

このファイルを編集して特定のインストールにその変更を反映させることはできますが、その際には注意が必要です。このファイルを変更した場合は、必ず MTA を再起動してください。MTA が停止しているときに変更を行うのが望ましい方法です。

注 特に必要でない限り、このファイルを変更することは避けてください。


このファイルの構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


ジョブコントローラファイル

ジョブコントローラファイル job_controller.cnf は、チャネル処理の情報を指定します。このファイルには、以下の目的があります。

imta.cnf ファイルで、pool キーワードを使ってプロセスプール (job_controller.cnf で定義) の名前を指定できます。たとえば、次のサンプルファイル job_controller.cnf の要素は、プール MY_POOL を定義します。

[POOL=MY_POOL]
job_limit = 12

次のサンプルファイル imta.cnf の要素は、チャネル定義ブロック内でプール MY_POOL を指定します。

channel_x pool MY_POOL
channel_x-daemon

デフォルトのプール設定に関連付けられたパラメータを変更したり、プールを追加する場合には、job_controller.cnf ファイルを編集してから、ジョブコントローラを終了して再起動してください。

新しい設定を使用して新規のジョブコントローラプロセスが作成され、それ以降のリクエストを受信するようになります。古いジョブコントローラプロセスは、キューに入っているリクエストをすべて処理し終了します。

ジョブコントローラ設定ファイルの最初のプールは、プール名が指定されていないリクエストのすべてに使用されます。MTA 設定 (imta.cnf) で定義されている MTA チャネルは、後にプール名が続く pool チャネルキーワードを使って、特定のプールに処理リクエストを送ることができます。このプール名は、ジョブコントローラ設定のプールの名前と一致しなければなりません。ジョブコントローラがリクエストされたプール名を認識できない場合、そのリクエストは無視されます。

最初の設定には、DEFAULT、LOCAL_POOL、IMS_POOL、SMTP_POOL のプールが定義されています。


使用例

通常、特定のチャネルの処理を別のチャネルの処理と区別したい場合には、ジョブコントローラ設定に付加的なプール定義を追加します。また、異なる特性を持つプールを使用することもできます。たとえば、チャネルが処理できる同時リクエスト数を制御する必要があるとします。これを行うには、ジョブ制限を持つ新規プールを作成し、pool チャネルキーワードを使ってチャネルをより適切なプールに割り当てます。

プール定義に加え、ジョブコントローラ設定ファイルには、各チャネルのリクエストを処理するのに必要な MTA チャネルとコマンドのテーブルが含まれています。リクエストには「マスター」と「スレーブ」と呼ばれる 2 つのタイプがあります。通常、チャネルの MTA メッセージキューにメッセージが入れられると、チャネルマスタープログラムが起動します。マスタープログラムは、メッセージをキューから取り出します。

スレーブプログラムは起動すると、チャネルをポーリングし、そのチャンネル内の受信メッセージを受け取ります。マスタープログラムはほぼすべての MTA チャネルにありますが、スレーブプログラムは MTA チャネルにはほとんどなく、すなわち必要とされません。たとえば、TCP/IP を使用した SMTP を処理するチャネルではスレーブプログラムを使用しません。すべてのSMTP サーバからのリクエストに対して、ネットワークサービスである SMTP サーバが受信 SMTP メッセージを受け取るためです。SMTP チャネルのマスタープログラムは、MTA の SMTP クライアントです。

チャネルに関連付けられた宛先のシステムが一度に複数のメッセージを処理できない場合は、ジョブ制限が 1 である新しいタイプのプールを作成する必要があります。

[POOL=single_job]
job_limit=1

一方、宛先のシステムが十分に並行処理できる場合は、ジョブ制限の値の設定を増やすことができます。

図 6-5 に、ジョブコントローラ設定ファイルの例を示します。

図 6-5 UNIX のジョブコントローラ設定ファイルの例
!MTA Job Controller configuration file
!
!Global defaults
tcp_port=27442(1)
secret=never mind
return_job=サーバ_ルート/bin/msg/imta/bin/return.sh
return_time=00:30/24:00
purge_job=サーバ_ルート/bin/msg/imta/bin/purge
purge_argv=-num=5
slave_command=NULL(2)
max_life_age=3600(3)
!
!
!Pool definitions
!
[POOL=DEFAULT](4)
job_limit=10(5)
!
[POOL=LOCAL_POOL]
job_limit=10
!
[POOL=IMS_POOL]
job_limit=1
!
[POOL=SMTP_POOL]
job_limit=1
!
!Channel definitions
!
!
[CHANNEL=l](6)
master_command=サーバ_ルート/bin/msg/imta/bin/l_master
!
[CHANNEL=ims-ms]
master_command=サーバ_ルート/bin/msg/imta/bin/ims_master
!
[CHANNEL=tcp_*](7)
anon_host=0
master_command=サーバ_ルート/bin/msg/imta/bin/tcp_smtp_client

以下に、上記例の主な項目 (丸括弧付き表示された) について説明します。

  1. このグルーバルオプションは、ジョブコントローラがリクエストをリッスンする TCP ポート番号を定義します。

  2. 後続の [CHANNEL] セクションのデフォルト SLAVE_COMMAND を設定します。

  3. 後続の [CHANNEL] セクションのデフォルト MAX_LIFE_AGE を設定します。

  4. この [POOL] セクションは、DEFAULT という名前のプールを定義します。

  5. このプールの JOB_LIMIT を 10 に設定します。

  6. この [CHANNEL] セクションは、l という名前のチャネル (UNIX ローカルチャネル) に適用されます。このセクションに必要な定義は、ジョブコントローラがこのチャネルを実行するのに発行する master_command のみです。このチャネル名にはワイルドカードが含まれていないため、チャネル名は完全に一致しなければなりません。

  7. この [CHANNEL] セクションは、tcp_* で始まるすべてのチャネル名に適用されます。このチャネル名にはワイルドカードが含まれているため、tcp_ で始まるすべてのチャネルに一致します。

ジョブコントローラファイルの構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


エイリアス


MTA には、必ずしも実際のユーザに対応するとは限らない、ローカルシステムに関連付けられたメールボックス名をサポートする機能である「エイリアス」があります。エイリアスは、メーリングリストの作成、メールの転送、およびユーザの別名の設定に役立ちます。

エイリアスを適用できるのは、l チャネルまたは aliaslocal キーワードの付いたすべてのチャネルに一致するアドレスだけです。MTA のメッセージ送信ロジックが l チャネルまたは aliaslocal キーワードの付いたすべてのチャネルに一致するアドレスを識別するたびに、アドレスに指定されているメールボックス (たとえば、ユーザ名) がエイリアスデータベースまたはエイリアスファイル内の各エントリと照合されます。一致するエントリが見つかると、エイリアスアドレスは変換値またはエイリアスで指定された値に置き換えられます。エイリアスは、追加エイリアスまたは実際のアドレスによる任意の組み合わせに変換できます。実際のアドレスが l チャネルや aliaslocal キーワードの付いたすべてのチャネルに一致する必要はありません。したがって、エイリアスは、リモートシステムにメールを転送するのに使用することができます。

本当にチャネルに一致すると見なされるアドレスは Envelope To アドレスのみであるため、エイリアスは Envelope To アドレスにしか適用されません。MTA は、アドレスの書き換えが完了した後にのみエイリアスの変換および拡張を行います。エイリアスによって生成された変換値は、完全に新しいアドレスとして扱われ、最初から処理されます。


エイリアスデータベース

MTA はディレクトリ内の情報を使用し、エイリアスデータベースを作成します。このエイリアスデータベースは、標準のエイリアスファイルが参照されるたびに参照されます。ただし、エイリアスデータベースのエントリが調べられるのは、標準のエイリアスファイルが使用される前です。すなわち、デーベースは、エイリアスファイルが使用される前に実行される、一種のアドレス書き換え機能として動作します。エイリアスデータベースにユーザおよび配信リストのエントリを作成するためのディレクトリ属性については、『iPlanet Messaging Server 5.1 Provisioning Guide』を参照してください。

注 データベースには固有のフォーマットがあるので、データベースを直接編集することは避け、必要な変更はディレクトリ内で行うようにしてください。



エイリアスファイル

aliases ファイルは、ディレクトリで設定されていないエイリアスを設定するのに使用します。よい例として、Postmaster エイリアスが挙げられます。このファイルで設定したエイリアスがディレクトリにもある場合、このファイルの設定は無視されます。変更を有効にするには、MTA を再起動する必要があります。感嘆符で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。

このファイルでは、一行に入力できる文字数が 252 文字に制限されています。バックスラッシュ (\) を継続文字として使用すれば、1 つの論理行を複数の行に分割することができます。

ファイルフォーマットは以下のとおりです。
user@domain: <address> (ホストドメインのユーザ用)

user@domain: <address> (非ホストドメインのユーザ用。例 ： default-domain)

以下に例を示します。
! A /var/mail/ user
inetmail@siroe.com: inetmail@native-daemon

! A message store user
ms_testuser@siroe.com: mstestuser@ims-ms-daemon


エイリアスファイルに他のファイルを含める

プライマリ aliases ファイルには、他のファイルを含めることができます。次の行は、MTA にfile-spec ファイルを読み込むように指示するためのものです。

<file-spec

ファイル仕様は、完全なパスを指定したものでなければなりません。また、そのファイルには、プライマリ aliases ファイルと同じ保護が設定されている必要があります (たとえば誰でも読み込み可能であることなど)。

含まれているファイルの内容は、aliases ファイル内の参照ポイントに挿入されます。含めたファイルへのリファレンスをそのファイルの実際の内容に置き換えることによっても、同様の効果が得られます。含まれたファイルのフォーマットは、プライマリ aliases ファイルとまったく同じになります。さらに、含まれたファイルに他のファイルを含めることも可能です。ファイルには3段階までの入れ子レベルが許可されています。


コマンドラインユーティリティ


iPlanet Messaging Server には、MTA のさまざまなメンテナンス、テスト、管理タスクを行うためのコマンドラインユーティリティが備わっています。たとえば、MTA の設定、エイリアス、マッピング、セキュリティ、システム全体のフィルタ、およびオプションファイルをコンパイルするには、imsimta cnbuild コマンドを使用します。また、MTA ディレクトリキャッシュを再作成または更新するには、imsimta dirsync コマンドを使用します。MTA コマンドラインユーティリティの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


MTA ディレクトリキャッシュ


MTA は、処理する各メッセージに対し、サポートするユーザ、グループ (メーリングリスト、ファミリアカウント、組織)、およびドメインに関する情報にアクセスする必要があります。この情報は、LDAP ディレクトリサービスに保存されています。MTA は、メッセージを処理するごとにディレクトリサービスのクエリを行うのではなく、ディレクトリ情報をキャッシュに保存します。つまり、ディレクトリ情報のスナップショットを保存するのです。その後、MTA はこのキャッシュ内のディレクトリ情報にアクセスします。

ディレクトリサービスに保存されたディレクトリ情報は、常に更新されます。このため、MTA のディレクトリキャッシュもディレクトリサービス内のディレクトリ情報に合わせて定期的に更新 (つまり、同期) する必要があります。Messaging Server では、2 種類の同期方法を利用できます。

デフォルトでは、毎日午前 2 時に完全同期が行われ、また 10 分ごとにインクリメンタル同期が行われます。

表 6-3 に、完全同期またはインクリメンタル同期が行われるディレクトリエントリを示します。

表 6-3 MTA ディレクトリキャッシュの更新


MTA ディレクトリキャッシュの更新

完全同期

インクリメンタル同期

追加した新規のユーザエントリ

○

○

修正したユーザエントリの更新

○

○

*削除したユーザエントリの破棄

○

X

既存の配信リストに追加した新規メンバー

○

○

既存の配信リストから削除したメンバーの破棄

○

○

追加した新規の配信リスト

○

○

*削除した配信リストの破棄

○

X

*削除したエントリに対してインクリメンタル同期を実行するには、そのエントリのステータスに削除済みのマークが付いている必要があります。インクリメンタル同期の実行後、MTA はそのユーザまたはグループが存在しないと見なします。実際にディレクトリを削除する作業は、インクリメンタル同期の後に行ってください。

通常、ディレクトリの同期は自動的に行われます。ただし、必要に応じて、imsimta dirsync コマンドを使って MTA ディレクトリキャッシュを再作成または更新することができます。imsimta dirsync コマンドの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。


同期設定パラメータ

表 6-4 に、ディレクトリ同期設定のパラメータを示します。

表 6-4 ディレクトリ同期設定のパラメータ


パラメータ

説明

local.imta.
ldsearchtimeout

ユーザおよびメーリングリストの情報を検索する際の LDAP 検索のタイムアウトを指定します。デフォルトでは、タイムアウトはありません。

local.imta.
hostnamealiase

LDAP エントリがローカルであるかどうかを確認する目的でそのエントリの mailhost または mailRoutingHosts 属性をチェックする際に、dirsync プロセスは local.hostname パラメータを使って比較を行います。さらに、local.imta.hostnamealiases パラメータにより、カンマで区切られたホスト名エイリアスのリストが提供されます。dirsync プロセスは、これらの 2 つのパラメータで提供されるすべてのホスト名を使って、エントリがローカルであるかどうかを調べます。

local.imta.
mailaliases

デフォルトでは、mail および mailAlternateAdress という LDAP 属性しかルーティング可能なメールアドレスとして見なされません。その代わり、local.imta.mailaliases パラメータにより、カンマで区切られた LDAP 属性のリストが提供されます。このリストはデフォルトの属性を上書きします。たとえば、メッセージをルーティングする際に、MTA は次の 4 つの属性を考慮します。

local.imta.mailaliases=mail,mailAlternateAdres,
rfc822mailbox,rfc822mailalias

local.imta.
ugfilter

このパラメータは、ユーザやメーリングリストの情報を検索する際に、dirsync が使用する LDAP 検索フィルタを設定します。

デフォルトのフィルタは次のとおりです。(objectClass=inetLocalMailRecipient)

たとえば、inetLocalMailRecipient および myispSubscriber オブジェクトクラスの LDAP エントリだけを考慮する場合には、このパラメータを次のように設定します。

local.imta.ugfilter=
(&(objectClass=inetLocalMailRecipient)
(objectClass=myispSubscriber))

注意 : インクリメンタル同期の場合は、このフィルタにタイムスタンプフィルタが追加されます。このため、カスタムフィルタを ( ) で括る必要があります。

local.imta.
statssamplesize

このパラメータを設定すると、標準出力として、最初からのユーザ/メーリングリストエントリおよび平均率 (エントリ数/秒) を要約して印刷するように dirsync に指示が出されます。ユーザおよびメーリングリストは、同期が完了したかどうかに関わらず数えられます。

local.imta.
reverseenabled

リバースデータベースの生成をトリガします。デフォルト値は、Yes です。実際にリバースデータベースが使用される方法は、USE_REVERSE_DATABASE オプションで制御されます。

local.imta.
ssrenabled

SSR (Server Side Rule) データベースの生成をトリガします。デフォルト値は、Yes です。SSR データベースが使用される方法は、ssr チャネルキーワードで制御されます。

local.imta.
vanityenabled

バニティドメイン (msgVanityDomain ユーザ LDAP 属性) が有効であるかどうかを制御します。デフォルト値は Yes です。

local.imta.
catchallenabled

キャッチオールアドレス (@domain 形式の mail または mailAlternateAddress) が有効であるかどうかを制御します。デフォルト値は Yes です。

local.imta.
scope

このパラメータは、どのエントリを同期するかを dirsync に知らせます。

mailhost 属性がローカルホストであるユーザおよびメーリングリストのエントリだけをキャッシュする場合 : 値 = "local"。

mailhost 属性に関わらず、ユーザおよびメーリングリストのエントリをキャッシュする場合 : 値 = "domains"。これはパラメータがない場合のデフォルト値です。

ドメイン、ユーザ、またはメーリングリストをキャッシュしない場合 : 値 = "nobody"。


SMTP セキュリティとアクセス制御


SMTP セキュリティとアクセス制御の詳細については、第 9 章「メールのフィルタリングとアクセス制御」および第 11 章「セキュリティとアクセス制御を設定する」を参照してください。


ログファイル


MTA 専用のログファイルはすべて、MTA ログディレクトリ (サーバ-インスタンス/log/imta/) に保存されます。このディレクトリには、MTA を介したメッセージ通信のログファイル、および特定のマスタープログラムまたはスレーブプログラムの情報を記述したログファイルがあります。

MTA ログファイルの詳細については、第 12 章「ログ記録とログ解析」を参照してください。


前へ    目次    索引    次へ
Copyright (c) 2001 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2001 Netscape Communications Corp. All rights reserved.

最終更新日 2001 年 5 月 24 日