この章では、一般的な MTA サービスと設定について説明します。より具体的で詳細な説明については、ほかの章を参照してください。この章には、次の節があります。
imta.cnf、mappings、aliases、option.dat などの MTA 設定ファイルを変更した場合は、設定をコンパイルしなおす必要があります。これにより、設定ファイルが共有メモリ内の単一のイメージ (UNIX の場合)、またはダイナミックリンクライブラリ (NT の場合) にコンパイルされます。
コンパイルされた設定には、静的な部分と動的で再読み込み可能な部分があります。動的な部分が変更された場合に imsimta reload を実行すると、実行中のプログラムによって動的なデータが再読み込みされます。動的な部分とは、マッピングテーブル、エイリアス、検索テーブルです。
設定情報のコンパイルは、主にパフォーマンス向上のために行います。コンパイルされた設定を使用するもう 1 つの利点は、設定の変更を簡単にテストできることです。これは、コンパイルされた設定が使用されているときに設定ファイル自体は「実行中」ではないからです。
チャネルプログラムなどの MTA コンポーネントは、設定ファイルの読み込みが必要になるたびに、コンパイルされた設定が存在するかどうかをチェックします。存在する場合は、そのイメージが実行中のプログラムに添付されます。イメージの添付処理に失敗すると、MTA は代わりに古い方法であるテキストファイルの読み込みを実行します。
reverse、forward、または一般データベースを変更した場合は、imsimta reload コマンドを発行して変更を有効にしてください。job_controller に影響を及ぼさない imta.cnf、mappings ファイル、aliases、conversions、または option.dat ファイルを変更した場合は、imsimta cnbuild に続けて imsimta restart smtp を発行する必要があります。dispatcher.cnf を変更した場合は、imsimta restart dispatcher を実行する必要があります。変更する設定ファイルが、ジョブコントローラには影響を与えるが、SMTP サーバーには影響を与えないコンパイル済みの設定に含まれる場合には、大抵、コマンドimsimta cnbuild および imsimta restart job_controller を発行する必要があります。
変更する設定ファイルが、SMTP サーバーとジョブコントローラの両方に影響を与えるコンパイル済みの設定に含まれる場合は、次のコマンドを発行する必要があります。
imsimta cnbuild imsimta restart smtp imsimta restart job_controller |
これらのコマンドの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「MTA Commands」を参照してください。
ほかにも、次の場合にジョブコントローラを再起動する必要があります。
コントローラ設定ファイルである job_controller.cnf や job_controller.site、または job_controller.cnf にインクルードされるいずれかのファイルを変更した場合。
imta.cnf ファイル内で、チャネルキーワード pool、maxjobs、master、slave、single、single_sys、multiple を追加または使用変更した場合。imta.cnf 内の threaddepth チャネルキーワードの追加または変更は、imsimta cache -change -thread_depth=... を使って処理できます。
コントローラが既存のチャネルジョブをタイムアウトするまで待つのではなく、マスターチャネルジョブへの変更が即座に反映されるようにする場合は、MTA 設定またはチャネルオプションファイルへの関連する (事実上ほぼ) すべての変更が対象になります。mappings ファイルまたは MTA データベースを変更する場合、次の点が当てはまります。(1) 通常、外部へ送信されるチャネルジョブとは関係がありません。ただし、これらは conversion、process、reprocess などの「中間」チャネルでは重要な意味を持つ場合があります。また、(2) これらの中間チャネルが関係する場合、mappings ファイルまたはデータベースへの変更は、多くの場合、imsimta reload を使って処理することで、ジョブコントローラの再起動を避けることができます。変更を直ちに反映することの利点と、ジョブコントローラを再起動することで発生するダメージとのバランスを取る必要があります。また、特定の種類のジョブを何らかの方法で実行するのにかかる時間も考慮する必要があります。
MTA の設定には、imta.cnf およびそれがインクルードするすべてのファイル (internet.rules など)、alias ファイル、mappings ファイル、conversions ファイル、option.dat ファイル (および前記のファイルに含まれるすべてのファイル)、imta.filter、reverse、forward、一般データファイルが含まれます。また、一部の configutil パラメータが含まれることもあります。
imta.cnf に対する前記の変更 (チャネル定義のキーワードの追加/変更) すべてで、imsimta cnbuild を実行する必要があります。これは、ジョブコントローラを再起動する必要があるかどうかに関係のない、基本的な手順です。
上記の条件のいずれかで再起動が必要である場合を除き、特にキュー内に多数のメッセージが存在する場合に、ジョブコントローラの再起動の回避を試みてください。
本稼働システムで、imsimta refresh コマンドを使用することはお勧めしません。これは、多くの場合ジョブコントローラの再起動は不要であり、ジョブコントローラを再起動することでメッセージの再試行がリセットされ、通知メッセージや戻されるメッセージなどの遅延が発生するためです。
MTA の主要設定ファイルは imta.cnf です。デフォルトでは、このファイルは msg_svr_base/config/imta.cnf にあります。このファイルには、MTA チャネル定義およびチャネル書き換えルールが含まれています。書き換えられた宛先アドレスに関連付けられたチャネルが、宛先チャネルとなります。通常、デフォルトの imta.cnf を使用することでシステムは良好に機能します。
この節では、MTA 設定ファイルについて簡単に説明します。MTA 設定ファイルを構成する書き換えルールとチャネル定義の詳細については、第 11 章「書き換えルールの設定」、および第 12 章「チャネル定義を設定する」を参照してください。
MTA 設定ファイルを変更することにより、サイトで使用されるチャネルを確立し、書き換えルールを介して各チャネルが処理するアドレスの種類を決定することができます。設定ファイルは、使用可能な転送方法 (チャネル) および転送経路 (書き換えルール) を指定し、アドレスの種類を適切なチャネルに関連付けることにより電子メールシステムの設計を定めるファイルです。
設定ファイルは、ドメイン書き換えルールとチャネル定義の 2 つの部分から構成されます。ドメイン書き換えルールがファイルの最初に現れ、チャネル定義とは 1 つの空白行で区切られています。チャネル定義は集合的にチャネルテーブルと呼ばれます。個々のチャネル定義がチャネルブロックを構成します。
次の imta.cnf 設定ファイルの例は、書き換えルールを使って適切なチャネルにメッセージをルーティングする方法を示しています。わかりやすくするために、ドメイン名は使用していません。書き換えルールは設定ファイルの前半部分にあり、そのあとにチャネル定義が続いています。
! test.cnf - 設定ファイルの例。 (1)! ! これは、単に設定ファイルの例です。 ! システムで使用するためのものではありません。 ! ! パート I: 書き換えルール a $U@a-daemon (2) b $U@b-daemon c $U%c@b-daemon d $U%d@a-daemon (3) ! パート II: チャネル定義 l (4) local-host a_channel defragment charset7 usascii (5) a-daemon b_channel noreverse notices 1 2 3 b-daemon </opt/SUNWmsgsr/msg-tango/table/internet.rules (6) |
次に、上記設定ファイルの主な項目 (括弧に入っている太字の番号付き) について説明します。
コメント行を示すには、感嘆符 (!) を使用します。感嘆符は行頭に表示されていなければなりません。その他の場所にある感嘆符は、文字として解釈されます。
書き換えルールは設定ファイルの前半部分にあります。書き換えルールに空白行を入れることはできません。コメント行 (行頭に感嘆符が付いている) を入れることはできます。
設定ファイル内で最初に現れる空白行は、書き換えルールの終わりとチャネル定義の始まりを表します。これらの定義は「チャネルホストテーブル」と総称され、MTA が使用できるチャネルと、各チャネルに関連付けられた名前を定義します。
通常、最初のチャネルブロックはローカルチャネル (l チャネル) です。その後、チャネルブロック間が空白行で区切られます(例外は defaults チャネルであり、このチャネルは l チャネルの前に出現)。
典型的なチャネル定義は、チャネル名 (a_channel)、チャネルの設定を定義するキーワード (defragment charset7 usascii)、およびルーティングシステム (a-daemon) で構成されます。ルーティングシステムは「チャネルタグ」とも呼ばれます。
設定ファイルには、ほかのファイルの内容をインクルードすることができます。行の 1 桁目に「小なり」(<) の記号があると、その行の残りはファイル名として扱われます。ファイル名は絶対名でフルパスでなければなりません。指定されたファイルが開かれ、設定ファイルのその場所にほかのファイルの内容が入れられます。インクルードファイルは、3 階層までネストすることができます。設定ファイルに含めるファイルは、設定ファイルと同じようにだれでも読み取り可能でなければなりません。
表 10–1 に、上記の設定でアドレスをルーティングする方法の例を示します。
表 10–1 アドレスおよび関連チャネル
アドレス |
チャネルキュー |
---|---|
u@a |
a_channel |
u@b |
b_channel |
u@c |
c_channel |
u@d |
d_channel |
MTA 設定ファイルの詳細については、「書き換えルール」、「チャネル定義」、および第 11 章「書き換えルールの設定」を参照してください。
imta.cnf ファイルを変更した場合は、必ず MTA 設定をコンパイルしなおしてください。「MTA 設定をコンパイルする」を参照してください。
MTA コンポーネントの多くは、テーブル検索に基づいた情報を使用します。このタイプのテーブルは、入力文字列を出力文字列に変える (マップする) のに使用されます。このようなテーブルは「マッピングテーブル」と呼ばれ、通常 2 つのカラムで構成されます。最初 (左側) のカラムにはパターンを照合する入力文字列が、2 番目 (右側) のカラムにはその入力文字列がマップされた (テンプレート) 結果の出力文字列が並んでいます。
MTA データベースのほとんどは、このタイプのテーブルのインスタンスです。これ らのデータベースにはさまざまなタイプの MTA データが含まれています。マッピングテーブルとは混同しないでください。ただし、MTA データベースファイルには、ワイルドカード検索機能がありません。データベース全体でワイルドカードに一致するものを検索するのは非効率的だからです。
MTA mappings ファイルは、複数のマッピングテーブルをサポートします。ワイルドカード機能もあり、複数の手順や反復マッピング方法にも対応しています。このアプローチは、データベースを使用する場合に比べ、さらに多くの処理を必要とします。特に、エントリ数が多い場合などはなおさらです。ただし、それに付随して柔軟性が増すため、同等のデータベースにおけるエントリのほとんどを必要としなくなり、全体的にオーバーヘッドが少なくなります。
マッピングテーブルは、MTA mappings ファイルに保存されています。これは、MTA tailor ファイルの IMTA_MAPPING_FILE オプションで指定されているフォルダで、デフォルトは msg_svr_base/config/mappings です。mappings ファイルの内容は、再読み込み可能なセクションとしてコンパイルされた設定に取り込まれます (「MTA 設定をコンパイルする」を参照)。誰でも読み取り可能でアクセスできない場合は、誤作動をまねくことになります。mappings ファイルを変更した場合は、必ず MTA 設定をコンパイルしなおしてください。「MTA 設定をコンパイルする」を参照してください。
表 10–2 に、このマニュアルで使用するマッピングテーブルの一覧を示します。
表 10–2 Messaging Server のマッピングテーブル
マッピングテーブル |
ページ |
説明 |
---|---|---|
AUTH_REWRITE |
authrewrite キーワードとともに、認証操作 (SASL) で取得したアドレス情報によってヘッダーとエンベロープアドレスを変更するために使用されます。「TCP/IP 接続と DNS 検索のサポート」を参照してください |
|
CHARSET-CONVERSION |
チャネル間における文字セット変換やメッセージフォーマット変換の種類を指定するために使用されます。「文字セット変換とメッセージの再フォーマット」を参照してください |
|
COMMENT_STRINGS |
アドレスヘッダーのコメント (括弧で囲まれた文字列) を変更するために使用されます。「アドレスヘッダー行内のコメントを処理する」を参照してください |
|
CONVERSIONS |
変換チャネルのメッセージトラフィックを選択するために使用されます。「変換処理のトラフィックを選択する」を参照してください。 |
|
FORWARD |
エイリアスファイルまたはエイリアスデータベースを使用した場合と同様の転送を行います。「正引き検索テーブルと FORWARD アドレスのマッピング」を参照してください |
|
FROM_ACCESS |
エンベロープ From アドレスに基づいてメールをフィルタリングする場合に使用します。このテーブルは、To アドレスが不適切な場合に使用します。「アクセス制御マッピングテーブル — 操作」を参照してください |
|
INTERNAL_IP |
内部のシステムとサブネットを認識します。「SMTP リレーを追加するには」を参照してください |
|
MAIL_ACCESS |
SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて着信接続をブロックする場合に使用します。「アクセス制御マッピングテーブル — 操作」を参照してください |
|
NOTIFICATION_LANGUAGE |
通知メッセージをカスタマイズまたはローカライズします。「配信ステータス通知メッセージを制御する」を参照してください |
|
ORIG_MAIL_ACCESS |
ORIG_SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて着信接続をブロックする場合に使用します。「アクセス制御マッピングテーブル — 操作」を参照してください |
|
ORIG_SEND_ACCESS |
エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、着信接続をブロックする場合に使用します。「アクセス制御マッピングテーブル — 操作」を参照してください |
|
PERSONAL_NAMES |
個人名 (角括弧で区切られたアドレスの前にある文字列) を変更するために使用されます。「アドレスヘッダー行内の個人名を処理する」を参照してください |
|
PORT_ACCESS |
IP 番号に基づいて着信接続をブロックする場合に使用します。「アクセス制御マッピングテーブル — 操作」を参照してください |
|
REVERSE |
内部形式から公のアドバタイズ形式にアドレスを変換します。「内部形式から公的な形式にアドレスを変換するには」 |
|
SEND_ACCESS |
エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、着信接続をブロックする場合に使用します。「アクセス制御マッピングテーブル — 操作」を参照してください |
|
SMS_Channel_TEXT |
サイト定義のテキストの変換に使用されます。「サイト定義のテキスト変換」を参照してください |
|
X-ATT-NAMES |
マッピングテーブルからパラメータ値を検索するために使用されます。「変換エントリからマッピングテーブルに呼び出すには」を参照してください |
|
X-REWRITE-SMS-ADDRESS |
ローカル SMS アドレスの妥当性チェックに使用されます。「サイト定義のアドレス妥当性チェックと変換」を参照してください |
mappings ファイルは、一連のテーブルで構成されています。各テーブルはその名前で始まります。名前には常に、最初の列にアルファベット文字がきます。テーブル名の次には必ず空白行が続き、その後にテーブルのエントリが続きます。エントリは、ゼロまたはそれ以上のインデント行で構成されます。各エントリ行は、1 つ以上のスペースまたはタブで区切られた 2 つのカラムから成ります。エントリ内のスペースはすべて、$ 文字で囲む必要があります。各テーブル名の後およびテーブル間には空白行が必要ですが、1 つのテーブル内のエントリ間に空白行があってはなりません。コメントは、1 つめのカラムに記述され、感嘆符 (!) から始まります。
つまり、ファイルフォーマットは以下のようになります。
TABLE1_NAME pattern1-1 template1-1 pattern1-2 template1-2 pattern1-3 template1-3 . . . . . . pattern1-n template1-n TABLE2_NAME pattern2-1 template2-1 pattern2-2 template2-2 pattern2-3 template2-3 . . . . . . pattern2-n template2-n . . . TABLE3_NAME . . . |
TABLE2_NAME マッピングテーブルを使用するアプリケーションは、pattern2-2 文字列を template2-2 で指定された文字列にマップします。各パターン、またはテンプレートには、最高 252 文字までを含めることができます。マッピングテーブルに含まれるエントリの数に制限はありません (ただし、エントリが必要以上に多い場合は、大きな CPU 容量およびメモリ容量を要することになる)。252 バイト以上の長い行は、\ (円記号) を行の末尾に置くことで次の行に続けることができます。2 つのカラム間および 1 つめのカラムの前にある空白スペースを削除してはなりません。
mappings ファイルでマッピングテーブル名が重複することは許されていません。
mappings ファイルにほかのファイルをインクルードすることができます。次の形式の行を使用します。
<file-spec |
これによって、mappings ファイル内の file-spec の行が、その実際のファイルに置き換えられます。ファイル指定には、完全なファイルパス (ディレクトリ等) が必要です。この方法で含めるファイルは、誰でも読み取り可能でなければなりません。mappingsファイルに含めるファイルにはコメントを入れることもできます。インクルードファイルは、3 階層までネストできます。インクルードファイルは、mappings ファイルといっしょに読み込まれます。オンデマンドで読み込まれるのではないため、ファイルを含めることによってパフォーマンスまたはメモリを節約することはできません。
mappings ファイル内のマッピングはすべて一定の方法で適用されます。マッピングごとに異なるのは、入力文字列のソースとマッピング出力の使用目的のみです。
マッピングの動作は、常に入力文字列とマッピングテーブルから始まります。マッピングテーブルのエントリは、テーブルに表示される順に上から下へ 1 つずつスキャンされます。各エントリの左側の部分がパターンとして使用され、入力文字列は大文字/小文字の区別なくそのパターンと比較されます。
パターンには、ワイルドカード文字を含めることができます。たとえば、次のような一般的なワイルドカード文字を使用できます。アスタリスク (*) はゼロまたはそれ以上の文字と一致し、パーセント記号 (%) は 1 つの文字に一致します。ドル記号 ($) をアスタリスク、パーセント記号、スペース、およびタブの前に置くことによって、それらの記号を文字として使用できるようになります。アスタリスクまたはパーセント記号を文字として使用した場合は、それらの特殊な定義が無効になります。パターンやテンプレートを正しく認識させるために、その中のスペースやタブは文字として認識させる必要があります。ドル記号を文字として使用するには、2 重のドル記号 ($$) を使用します。この場合、1 つめのドル記号によって、2 つめのドル記号を文字として認識されるようになります。
表 10–3 マッピングパターンのワイルドカード
ワイルドカード |
説明 |
% |
1 つの文字に一致します。 |
* |
左から右への最大限の一致を使用して、ゼロ以上の文字を一致します |
後照合 |
説明 |
$ n* |
n 番めのワイルドカードまたはグロブに一致します。 |
修飾子 |
説明 |
$_ |
左から右への最低限の一致を使用します。 |
$@ |
後続のワイルドカード、またはグロブの「保存」をオフにします。 |
$^ |
後続のワイルドカードまたはグロブの「保存」をオンにします。デフォルト設定です。 |
グロブワイルドカード |
説明 |
$A% |
A 〜 Z および a 〜 z のアルファベットのうち、1 つの文字に一致します。 |
$A* |
A 〜 Z および a 〜 z のアルファベットが 0 個以上含まれた文字列に一致します。 |
$B% |
1 桁の 2 進数 (0 または 1) に一致します。 |
$B* |
0 またはそれ以上の桁数の 2 進数 (0 または 1) に一致します。 |
$D% |
1 桁の 10 進数 (0 〜 9) に一致します。 |
$D* |
0 またはそれ以上の桁数の 10 進数 (0 〜 9) に一致します。 |
$H% |
1 桁の 16 進数 (0 〜 9 または A 〜 F) に一致します。 |
$H* |
0 またはそれ以上の桁数の 16 進数 (0 〜 9 または A 〜 F) に一致します。 |
$O% |
1 桁の 8 進数 (0 〜 7) に一致します。 |
$O* |
0 またはそれ以上の桁数の 8 進数 (0 〜 7) に一致します。 |
$S% |
1 つの記号セット文字 (例: 0 〜 9、A 〜 Z、a 〜 z、_、$) に一致します。 |
$S* |
ゼロまたはそれ以上の記号セット文字、すなわち 0 〜 9、A 〜 Z、a 〜 z、_、$ に一致します。 |
$T% |
1 つのタブ、垂直タブ、またはスペース文字に一致します。 |
$T* |
ゼロまたはそれ以上のタブ、垂直タブ、またはスペース文字に一致します。 |
$X% |
$H% と同義です。 |
$X* |
$H* と同義です。 |
$[ c]% |
文字 c に一致します。 |
$[ c]* |
文字 c の不定発生に一致します。 |
$[ c1 c2 ... cn ]% |
文字 c1、c2、または cn の発生の 1 つに一致します。 |
$[ c1 c2 ... cn ]* |
文字 c1、c2、または cn の不定発生に一致します。 |
$[ c1 -cn ]% |
c1 から c n までの文字のいずれか 1 つに一致します。 |
$[ c1 -cn ]* |
c1 から cn までの文字の不定発生に一致します。 |
$< IPv4> |
ビットを無視して、IPv4 アドレスに一致します。 |
$(IPv4) |
プレフィックスビットを維持した状態で、IPv4 アドレスに一致します。 |
${IPv6} |
1 組の IPv6 アドレスに一致します。 |
グロブ内、つまり $[...] 内では、円記号 (\) は引用符となります。実際のハイフン (-) または右角括弧 (]) をグロブ内で表すには、ハイフンまたは右角括弧に円記号を付ける必要があります。
パターン内のその他の文字はすべて、文字として使用されます。特に、一重引用符や二重引用符、および括弧は、マッピングパターンやテンプレートにおいて特殊な意味を持たず、通常の文字とみなされます。このため、不正なアドレスや部分的なアドレスに対応するエントリの書き出しが簡単になります。
複数の修飾子、または修飾子および後照合を指定するには、構文にドル記号を 1 つだけ使用します。たとえば、最初のワイルドカードを、後照合そのものを保存せずに後照合するには、$@$0 ではなく $@0 を使用します。
マッピングパターンのテスト、特にパターン内のワイルドカードの動作のテストを行うには、imsimta test -match ユーティリティーを使用できます。
アスタリスクのワイルドカードは、入力文字列を左から右へスキャンすることにより、一致する対象を最大化します。たとえば、入力文字列 a/b/c をパターン */* と比較する場合、左のアスタリスクが a/b に一致し、右のアスタリスクが残りの c に一致します。
$_ 修飾子は、ワイルドカードによる照合を最小にするため、パターンの左から右に向かって、もっとも可能性の少ない一致がその一致とみなされます。たとえば、文字列 a/b/c をパターン $_*/$_* と比較した場合、左の $_* は a と、右の $_* は b/c と一致します。
IPv4 プレフィックスの照合では、IP アドレス、またはサブネットを指定し、そのあとにオプションとして、照合比較の際に有効となるスラッシュとプレフィックスのビット数を続けます。たとえば、次の例は 123.45.67.0 サブネット内にあるものに一致します。
$(123.45.67.0/24)
IPv4 照合でビットを無視する場合は、IP アドレスまたはサブネットを指定し、そのあとにオプションとしてスラッシュを付け、照合を確認する際に無視するビット数を続けます。たとえば、次の例は 123.45.67.0 サブネット内にあるものに一致します。
$<123.45.67.0/8>
次の例は、123.45.67.4 から 123.45.67.7 の範囲内にあるものに一致します。
$<123.45.67.4/2>
IPv6 照合は、IPv6 アドレスまたはサブネットを照合します。
指定したエントリのパターン比較に失敗した場合は、何の動作も行われず、次のエントリのスキャンへ移行します。比較が成功した場合は、エントリの右側の部分がテンプレートとして使用され、出力文字列が生成されます。このテンプレートによって、入力文字列がテンプレートの指示によって構成された出力文字列に置き換えられます。
テンプレート内のほとんどすべての文字が、そのまま出力文字列として生成されます。ただし、ドル記号 ($) は例外です。
ドル記号の後ろにドル記号、スペース、またはタブが続く場合は、出力文字列にドル記号、スペース、またはタブが生成されます。これらの文字を出力文字列に挿入するには、引用符を付ける必要があります。
ドル記号に数字 n が続いている場合は置換を呼び出します。ドル記号の後ろにアルファベット文字が続くものは「メタキャラクタ」と呼ばれます。メタキャラクタ自体はテンプレートで生成された出力文字列に出現しませんが、特殊な置換や処理で使われます。特殊な置換および標準処理のメタキャラクタの一覧は、表 10–4 を参照してください。その他のメタキャラクタはマッピング特有の用途に制限されています。
テンプレートの照合パターン内に $C、$E、$L または $R のいずれかのメタキャラクタがある場合、それらはマッピング処理に影響を及ぼし、処理の終了または続行を決定します。つまり、1 つのエントリの出力文字列が別のエントリの入力文字列となるような反復的なマッピングテーブルエントリを設定することができます。テンプレートの照合パターン内に $C、$E、$L、または $R のどのメタキャラクタも含まれていない場合は、$E (マッピング処理の即時終了) が行われます。
無限ループを避けるために、マッピングテーブル内のパス (文字列が渡されること) の反復回数には制限があります。前回のパスと同じか、それより長いパターンを使用してパスが反復されるたびに、カウンタは 1 増えます。文字列が直前のものより短い場合は、カウンタがゼロにリセットされます。カウンタが 10 に達すると、マッピングの反復要求は受け付けられません。
表 10–4 マッピングテンプレートの置換とメタキャラクタ
置換シーケンス |
置き換える内容 |
---|---|
$n |
左から右にゼロから数えて n 番めのワイルドカードのフィールド。 |
$#...# |
シーケンス番号の置換 |
$]...[ |
LDAP により URL 検索が行われます。結果として、置換が行われます。 |
$|...| |
指定されたマッピングテーブルを、与えられた文字列に適用します。 |
${...} |
一般データベースの置換。 |
$}domain,attribute{ |
ドメイン単位の属性にアクセスする機能を追加します。domain は該当するドメインであり、attribute はドメインに関連付けられた属性です。このドメインが存在して属性を有している場合、その初期値はマッピングの結果に代入されます。属性かドメインのどちらかが存在しない場合、マッピングエントリは失敗します。 attributes には、ドメイン LDAP 属性か、下記のように定義された特殊な属性を指定できます。 _base_dn_ - ドメインのユーザーエントリのベース DN _domain_dn_ - ドメインエントリ自体の DN _domain_name_ - ドメインの名前 (エイリアスではない) _canonical_name_ - ドメインに関連付けられた標準名 |
$[...] |
サイト提供のルーチンを起動し、結果の置換を行います。 |
メタキャラクタ |
説明 |
$C |
次のテーブルエントリからマッピング処理を続行し、このエントリの出力文字列をマッピング処理の新しい入力文字列として使用します。 |
$E |
マッピング処理をただちに終了し、このエントリの出力文字列をマッピング処理の最終結果とします。 |
$L |
次のテーブルエントリからマッピング処理を続行し、このエントリの出力文字列を新しい入力文字列として使用します。テーブル内のすべてのエントリを照合したら、もう一度最初のテーブルエントリから照合します。後続の照合エントリにメタキャラクタ $C、$E または $R がある場合には、それらのエントリが優先されます。 |
$R |
マッピングテーブルの最初のエントリからマッピング処理を続行し、このエントリの出力文字列をマッピング処理の新しい入力文字列として使用します。 |
$nA |
現在のアドレスの 0 の位置から左に n 番目の文字を挿入します。n を省略した場合、アドレス全体が挿入されます。 |
$nX |
メールホストの 0 から左に n 番目のコンポーネントを挿入します。n を省略した場合、メールホスト全体が挿入されます。 |
$?x? |
マッピングエントリが x パーセントの割合で成功します。 |
$\ |
後続のテキストを小文字にします。 |
$^ |
後続のテキストを大文字にします。 |
$_ |
後続のテキストを元々の状態で残します。 |
$= |
後続の置換文字が、LDAP 検索フィルタへの挿入に適した引用の対象となるようにして、その部分を大文字に変換します。 |
$:x |
指定したフラグが設定されている場合にのみ、一致します。 |
$;x |
指定したフラグがクリアの場合にのみ、一致します。 |
ドル記号に数字 n が続いている場合、これは、パターン内の n 番目のワイルドカードに一致するデータで置き換えられます。ワイルドカードには、0 から順に番号が付けられています。たとえば、次のエントリは入力文字列 PSI%A::B に一致し、その結果 b@a.psi.siroe.com という出力文字列を生成します。
PSI$%*::* $1@$0.psi.siroe.com |
また、入力文字列 PSI%1234::USER にも一致するので、出力文字列として USER@1234.psi.siroe.com が生成されます。入力文字列 PSIABC::DEF は、このエントリ内のパターンに一致しないため置換は行われません。つまり、このエントリから出力文字列は生成されません。
メタキャラクタ $\ は後続のテキストを小文字に変換し、メタキャラクタ $^ は後続のテキストを大文字に変換します。また、メタキャラクタ $_ は、後続のテキストを元の大文字または小文字の状態で残します。たとえば、これらのメタキャラクタは、マッピングを使って大文字または小文字の区別が有効なアドレスを変更する際に役立ちます。
メタキャラクタ $C、$L、$R、および $E は、マッピング処理を終了するかどうか、またいつ終了するかなど、マッピング処理に影響を与えます。これらのメタキャラクタには、次の効果があります。
$C は現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、次のエントリからマッピング処理を続行します。
$L は、現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、次のエントリからマッピング処理を続行します。一致するエントリが見つからない場合には、もう一度そのテーブルの最初のテーブルエントリから照合を開始します。後続の照合エントリにメタキャラクタ $C、$E または $R がある場合には、それらのエントリが優先されます。
$R は、現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、テーブルの最初のエントリからマッピング処理を続行します。
$E はマッピング処理を終了し、このエントリの出力文字列が最終結果となります。デフォルト設定は $E です。
マッピングテーブルのテンプレートは、左から右にスキャンされます。一般データベースの置換やランダム値で制御されるエントリなど、「成功」または「失敗」するエントリに $C、$L、または $R のフラグを設定するには、メタキャラクタ $C、$L、または $R をエントリの成功または失敗する部分の左側に配置します。これを行わないと、エントリの残りの部分が失敗した場合、フラグが表示されません。
マッピングプローブの中には、特殊なフラグセットを持つものがあります。これらは設定可能なフラグであり、それらが存在するかどうかは $: および $; テストの一般的なマッピングテーブル機能を使用して確認されます。$:x はフラグ x が設定されている場合のみ、エントリを一致させます。$:x はフラグ x がクリアの場合にのみ、エントリを一致させます。特定のマッピングテーブルに適用される特殊なフラグについては、各マッピングテーブルの説明を参照してください (表 17–2 の $A、$T、$S、$F、および $D を参照)。
フラグチェックが成功するとエントリが成功して終了するが、フラグチェックが失敗するとマッピング処理を続行する必要があるという場合、エントリはフラグチェックの左側に $C メタキャラクタを配置し、フラグチェックの右側に $E フラグを配置する必要があります。
マッピングテーブルのエントリにメタキャラクタ $?x? がある場合は、これによって、x パーセントの割合でエントリが「成功」します。残りの割合でエントリは「失敗」し、マッピングエントリの入力文字列は変更されずにそのまま出力文字列となります(マッピングによっては、エントリが失敗したこととエントリが一致しなかったこととは、必ずしも同義ではない)。x には、成功率を実数で指定します。
たとえば、IP アドレスが 123.45.6.78 であるシステムが、自分のサイトに大量の SMTP 電子メールを送信していて、このメールの量を少し減らしたいとします。この場合、PORT_ACCESS マッピングテーブルを次のように使用できます。たとえば、接続の 25 パーセントのみを許可し、残りの 75 パーセントを拒否するとします。次のマッピングテーブル PORT_ACCESS は、$?25? を使用し、$Y のあるエントリを 25 パーセントの割合で成功させます (すなわち、接続を許可)。エントリが失敗する残りの 75 パーセントの割合では、そのエントリの最初の $C によって MTA は次のエントリからマッピングを続行しますが、接続試行は拒否され、Try again later (あとでもう一度試行してください) という SMTP エラーメッセージが表示されます。
PORT_ACCESS TCP|*|25|123.45.6.78|* $C$?25?$Y TCP|*|25|123.45.6.78|* $N45s$ 4.40$ Try$ again$ later |
$#...# 置換は、MTA シーケンスファイルに保存されている値を増やし、その値をテンプレート内に入れます。たとえば、マッピングテーブルを使ってファイル名を生成するときなど、マッピングテーブルの出力に固有の修飾子があることが望ましい場合に、シーケンス番号付きの固有文字列を生成することができます。
次のいずれかの構文を使用できます。
$#seq-file-spec|radix|width|m# |
$#seq-file-spec|radix|width# |
$#seq-file-spec|radix# |
$#seq-file-spec# |
必須の引数 seq-file-spec は、既存の MTA シーケンスファイルの完全なファイル指定です。オプションの引数 radix で出力するシーケンス値の基数を、width で出力する桁数を指定します。デフォルトの基数は 10 ですが、-36 ~ 36 の範囲内の基数も使用できます。たとえば、基数 36 では 0 ~ 9、A ~ Z の文字からなる値を使用することができます。デフォルトでは、シーケンス値は自然幅で出力されますが、大きな桁数を指定すると、桁数に合わせるために数値の左側に 0 が追加されます。桁数を明示的に指定する場合は、基数も明示的に指定する必要があります。
オプションの引数 m はモジュラスです。この 4 番目の引数が指定されている場合、挿入される値はファイル mod m から取得されたシーケンス番号です。デフォルトでは、モジュラスの処理を行わないようになっています。
上記にあるように、マッピングで参照される MTA シーケンスファイルはすでに存在するものでなければなりません。MTA シーケンスファイルを作成するには、次のコマンドを使用します。
touch seq-file-spec |
または
cat >seq-file-spec |
マッピングテーブルを使ってアクセスされるシーケンス番号ファイルは、誰でも読み取り可能でないと正常に操作できません。また、このようなシーケンス番号ファイルを使用するには、MTA ユーザーアカウント (imta_tailor ファイルで nobody として設定) を持つことが必要です。
$]ldap-url[ の形式の置換は、特殊な方法で処理されます。ldap-url は LDAP クエリ URL として解釈され、LDAP クエリの結果が置換されます。ホストとポートが省略された標準の LDAP URL が使用されます。ホストとポートは、代わりに LDAP_HOST オプションと LDAP_PORT オプションで指定されます。LDAP URL は次のように指定する必要があります。
ldap:///dn[?attributes[?scope?filter]]
上記の角括弧 ([ と ]) は、URL のオプションの部分を示します。dn は検索ベースを指定する識別名で、この部分は必須です。URL の attributes、scope、および filter の各オプションを指定すると、より細かい情報が返されます。つまり、attributes では、この LDAP クエリに一致する LDAP ディレクトリエントリから返される属性を指定します。scope には、base (デフォルト)、one、または sub のいずれかを指定できます。filter には一致するエントリの特徴を記述します。
特定の LDAP URL 置換シーケンスは、LDAP クエリ URL 内で使用できます。
$|mapping;argument| 形式の置換は、特殊な方法で処理されます。MTA は、MTA mappings ファイル内の mapping で指定されている補足的なマッピングテーブルを探し、その補足的なマッピングテーブルへの入力文字列として argument を使用します。この補足的なマッピングテーブルは既存のものであり、置換が成功した場合にはその出力文字列に $Y フラグを設定しなければなりません。この補足的なマッピングテーブルが存在しなかったり、または $Y フラグを設定しなかった場合には、補足的なマッピングテーブルの置換は失敗し、元のマッピングエントリも失敗とみなされます。元の入力文字列が出力文字列として使用されます。
マッピングテーブルの置換を行うマッピングテーブルエントリで $C、$R、または $L などの処理制御メタキャラクタを使用する場合は、処理制御メタキャラクタをマッピングテーブルテンプレート内のマッピングテーブル置換の左側に配置します。そうしないと、マッピングテーブルの置換が「失敗」したときに、処理制御メタキャラクタが処理されません。
${text} 形式の置換は、特殊な方法で処理されます。text 部分は、一般検索テーブルやデータベースにアクセスするための鍵として使われます。データベースは、imsimta crdb ユーティリティーにより生成されます。text がテーブルで一致すると、テーブル内の対応するテンプレートがその文字列に置き換えられます。text がテーブル内のエントリに一致しない場合は、入力文字列がそのまま出力文字列として使用されます。
一般検索テーブルを使用している場合、MTA オプションの use_text_databases の下位ビットを設定する必要があります。つまり、奇数に設定する必要があります。general.txt を変更した場合は、imsimta cnbuild を使用してコンパイルし、imsimta reload を使用して再読み込み可能なデータを再読み込みすることで、MTA 設定にコンパイルする必要があります。
一般データベースを使用している場合、データベースが適切に動作するためには、データベースは誰にでも読み取り可能でなければなりません。
一般テーブルの置換を行うマッピングテーブルエントリで、$C、$R、または $L などの処理制御メタキャラクタを使用する場合は、処理制御メタキャラクタをマッピングテーブルテンプレート内の一般テーブル置換の左側に配置します。そうしないと、一般テーブルの置換が「失敗」したときに、処理制御メタキャラクタが処理されません。
$[image,routine,argument] 形式の置換は特殊な方法で処理されます。image、routine、argument の各部分は、カスタマ提供のルーチンを見つけて呼び出すために使用されます。UNIX では、MTA は dlopen および dlsym を使って共有ライブラリ image からルーチン routine をダイナミックにロードし、呼び出します。そのとき、ルーチン routine は、次の引数を伴った関数として呼び出されます。
status = routine (argument, arglength, result, reslength) |
argument および result は、252 バイトの文字列バッファーです。argument および result は、文字列へのポインタ (たとえば、C 言語での char* のように) として渡されます。arglength および reslength は、参照によって渡される符号付きの long 型整数です。入力時、argument にはマッピングテーブルテンプレートの argument 文字列が含まれ、arglength にはその文字列の長さが含まれます。値を返すときには、result に結果文字列が入り、reslength にその長さが入ります。この結果文字列が、マッピングテーブルテンプレート内の $[image,routine,argument] に置き換わります。routine は、マッピングテーブルの置換が失敗した場合には 0 を返し、成功した場合には -1 を返します。置換が失敗した場合は、通常、元の入力文字列がそのまま出力文字列として使用されます。
サイト提供ルーチンの置換を行うマッピングテーブルエントリで、$C、$R、または $L などの処理制御メタキャラクタを使用する場合は、処理制御メタキャラクタをマッピングテーブルテンプレート内のサイト提供ルーチン置換の左側に配置します。そうしないと、マッピングテーブルの置換が「失敗」したときには、処理制御メタキャラクタが処理されません。
サイト提供ルーチンの呼び出し機構によって、MTA のマッピング処理はさまざまな方法で拡張することができます。たとえば、マッピングテーブル PORT_ACCESS または ORIG_SEND_ACCESS 内で、ロード監視サービスへの呼び出しを行い、その結果を使って接続やメッセージを受け入れるかどうかを決定することができます。
image (サイト提供の共有ライブラリイメージ) は、誰でも読み取り可能でなければなりません。
一般的なマッピングテーブル機能で、Unicode 文字の値から UTF-8 文字列を生成できます。次の形式の Unicode メタキャラクタ列があるとします。
$&A0A0,20,A1A1&
この場合、A0A0、20 および A1A1 の位置にある文字を含む UTF-8 文字列が生成されます。
imta.cnf ファイルのほかにも、Messaging Server には MTA サービスの設定に役立ついくつかの設定ファイルがあります。表 10–5 にファイルの一覧を示します。
reverse、forward、または一般データベースを変更した場合は、imsimta reload コマンドを発行して変更を有効にしてください。job_controller に影響を及ぼさない imta.cnf、mappings ファイル、aliases、conversions、または option.dat ファイルを変更した場合は、imsimta cnbuild に続けて imsimta restart smtp を発行する必要があります。dispatcher.cnf を変更した場合は、imsimta restart dispatcher を実行する必要があります。変更する設定ファイルが、ジョブコントローラには影響を与えるが、SMTP サーバーには影響を与えないコンパイル済みの設定に含まれる場合には、大抵、コマンドimsimta cnbuild および imsimta restart job_controller を発行する必要があります。
これらのコマンドの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「MTA Commands」を参照してください。
表 10–5 MTA 設定ファイル
ファイル |
説明 |
---|---|
「エイリアスファイル」 (必須) |
ディレクトリにないエイリアスを実装します。msg_svr_base/config/aliases |
「TCP/IP (SMTP) チャネルオプションファイル」 (SMTP オプションファイル) |
チャネル固有のオプションを設定します。msg_svr_base/config/channel_option |
変換チャネルがメッセージ本体部分の変換を制御するのに使用します。msg_svr_base/config/conversions |
|
「ディスパッチャー設定ファイル」 (必須) |
ディスパッチャー用の設定ファイルです。msg_svr_base/config/dispatcher.cnf |
「ジョブコントローラファイル」 (必須) |
ジョブコントローラ が使用する設定ファイルです。/msg_svr_base/config/job_controller.cnf |
MTA 設定ファイル (必須) |
アドレスの書き換え、ルーティング、およびチャネル定義に使用します。/msg_svr_base/config/imta.cnf |
「マッピングファイル」 (必須) |
マッピングテーブルのリポジトリです。/msg_svr_base/config/mappings |
グローバル MTA オプションのファイルです。/msg_svr_base/config/option.dat |
|
「テイラーファイル」 (必須) |
場所といくつかの調整パラメータを指定するファイルです。/msg_svr_base/config/imta_tailor |
一般検索テーブル (オプション) |
一般検索機能は一般データベースと同等です。再読み込み可能なコンパイル済み設定の一部です。 場所といくつかの調整パラメータを指定するファイルです。/msg_svr_base/config/general.txt |
正引き検索テーブル (オプション) |
To: アドレスの検索機能です。正引きデータベースと同等です。再読み込み可能なコンパイル済み設定の一部です。 /msg_svr_base/config/forward.txt |
リバース検索テーブル (オプション) |
From: アドレスのアドレスの検索機能です。リバースデータベースと同等です。再読み込み可能なコンパイル済み設定の一部です。/msg_svr_base/config/reverse.txt |
エイリアスファイル aliases は、ディレクトリに設定されていないエイリアスを設定します。その例として、ルートのアドレスが挙げられます。このファイルで設定したエイリアスがディレクトリにもある場合は、ファイル内の設定が無視されます。エイリアスおよび aliases ファイルの詳細については、「エイリアス」を参照してください。
aliases ファイルの変更後は、MTA を再起動するか、imsimta reload コマンドを実行してください。
TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。チャネルオプションファイルは MTA 設定ディレクトリに保存し、x_option という名前を付けてください。x はチャネル名です。たとえば、msg_svr_base/config/imta/tcp_local_option のようになります。詳細は、「SMTP チャネルオプションを設定する」を参照してください。すべてのチャネルオプションキーワードおよび構文の詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
変換ファイル conversions は、MTA を介して送受信されるメッセージの変換チャネルにおける変換方法を指定します。変換には、MTA トラフィックの任意のサブセットを選択できます。また、変換処理を行うには、プログラムまたはコマンドの任意のセットを使用できます。MTA は変換ファイルに基づいて、それぞれのメッセージ本文に対する適切な変換を選択します。
このファイルの構文の詳細は、「変換チャネル」を参照してください。
ディスパッチャー設定ファイル dispatcher.cnf では、ディスパッチャーの設定情報を指定します。インストール時に作成されたデフォルトの設定ファイルをそのまま使用することができます。ただし、セキュリティーやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合は、dispatcher.cnf ファイルを編集することができます(概念の詳細は、「ディスパッチャー」を参照)。
ディスパッチャー設定ファイルのフォーマットは、ほかの MTA 設定ファイルのフォーマットに似ています。オプションを指定する行は、次の形式で記述されています。
option=value
option はオプション名で、value はオプションを設定する文字列または整数です。option が整数の値を受け入れる場合は、b%v の文字列表記ルールを使って基数を指定できます。この場合、b は底 10 で表す基数であり、v は底 b で表す実際の値です。これらのオプションの仕様は、次のオプション設定を適用するサービスに対応するセクションに、グループ分けされています。各行では、次の形式が使用されます。
[SERVICE=service-name]
The service-name はサービスの名前です。最初のオプション仕様、すなわちこのようなセクションタグよりも前に記述されているオプション仕様はすべてのセクションに適用されます。
次に、ディスパッチャー設定ファイル (dispatcher.cnf) の例を示します。
! オプションの最初のセットは [SERVICE=xxx] ヘッダーなしで ! 表示された、すべてのサービスに適用されるデフォルトオプション ! です。 ! MIN_PROCS=0 MAX_PROCS=5 MIN_CONNS=5 MAX_CONNS=20 MAX_LIFE_TIME=86400 MAX_LIFE_CONNS=100 MAX_SHUTDOWN=2 ! ! ディスパッチャーで使用できるサービスを定義する ! [SERVICE=SMTP] PORT=25 IMAGE=msg_svr_base/lib/tcp_smtp_server LOGFILE=msg_svr_base/log/tcp_smtp_server.log |
このファイルのパラメータの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
mappings ファイルでは、MTA が入力文字列を出力文字列にマップする方法を定義します。
MTA コンポーネントの多くは、テーブル検索に基づいた情報を使用します。一般に、このタイプのテーブルは、入力文字列を出力文字列に変える (マップする) のに使用されます。このようなテーブルは、マッピングテーブルと呼ばれ、通常 2 つのカラムで構成されます。1 つめ (左側) のカラムには入力文字列が、2 つめ (右側) のカラムにはその入力文字列に関連付けられた出力文字列が並んでいます。MTA データベースのほとんどは、このタイプのマッピングテーブルです。ただし、MTA データベースファイルには、ワイルドカード検索機能がありません。データベース全体でワイルドカードに一致するものを検索するのは非効率的だからです。
mappings ファイルによって、MTA は複数のマッピングテーブルをサポートできるようになります。さらに、完全なワイルドカード機能もあり、複数の手順や反復マッピング方法にも対応しています。このアプローチは、データベースを使用する場合に比べ、さらに多くの処理を必要とします。特に、エントリ数が多い場合などはなおさらです。ただし、それに付随して柔軟性が増すため、同等のデータベースにおけるエントリのほとんどを必要としなくなり、全体的にオーバーヘッドが少なくなります。
imsimta test -mapping コマンドを使ってマッピングテーブルをテストすることができます。mappings ファイルの構文および test -mapping コマンドの詳細は、「マッピングファイル」および『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
mappings ファイルの変更後は、MTA を再起動するか、imsimta reload コマンドを実行してください。
オプションファイル option.dat は、グローバル MTA オプションを指定します。これは、チャネル固有のオプションとは逆のオプションです。
オプションファイルを使って、MTA 全体に適用されるさまざまなパラメータのデフォルト値を無効にすることができます。特に、オプションファイルは、設定ファイルやエイリアスファイルが読み込まれるさまざまなテーブルのサイズを確立するのに使用されます。また、MTA が許可するメッセージのサイズを制御したり、MTA 設定で許可するチャネル数を指定したり、許可する書き換えルールの数を設定したりできます。
option.dat では、#、!、または ; で始まる行はコメント行として処理されます。先行する行の末尾に、続きがあることを示す \ がある場合でも同様です。配信オプションなど、これらの文字を含む長いオプションの場合には注意が必要です。
配信オプションの場合は、自然なレイアウトは # または ! で始まる継続行になりますが、確実で整然とした回避方法はあります。
オプションファイルの構文の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
テイラーファイル imta_tailor は、さまざまな MTA コンポーネントの場所を設定します。MTA が正常に機能するには、imta_tailor ファイルが常に msg_svr_base/config ディレクトリ内になければなりません。
このファイルを編集して特定の設定にその変更を反映させることはできますが、その際には注意が必要です。このファイルを変更した場合は、必ず MTA を再起動してください。MTA が停止しているときに変更を行うのが望ましい方法です。
特に必要でないかぎり、このファイルを変更することは避けてください。
このファイルの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。ジョブコントローラの概念とチャネルキーワードの設定については、「ジョブコントローラ」、「チャネル実行ジョブの処理プール」、および 「サービスジョブの制限」を参照してください。
ジョブコントローラファイル 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
一方、宛先システムで並行処理が可能な場合は、ジョブ範囲の値を増やすことができます。
例 10–1 に、ジョブコントローラ設定ファイルの例を示します。表 10–6 に、使用可能なオプションを示します。
! MTA ジョブコントローラ設定ファイル ! ! グローバルデフォルト tcp_port=27442 (1) secret=never mind slave_command=NULL (2) max_life_age=3600 (3) ! ! ! プールの定義 ! [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=l] (6) master_command=msg_svr_base/lib/l_master ! [CHANNEL=ims-ms] master_command=msg_svr_base/lib/ims_master ! [CHANNEL=tcp_*] (7) anon_host=0 master_command=msg_svr_base/lib/tcp_smtp_client |
以下に、上の例の主な項目 (太字の丸括弧付きの数字がある部分) について説明します。
このグルーバルオプションは、ジョブコントローラが要求を待機する TCP ポート番号を定義します。
そのあとの [CHANNEL] セクションのデフォルト MAX_LIFE_AGE を設定します。
この [POOL] セクションは、DEFAULT という名前のプールを定義します。
この [CHANNEL] セクションは、l という名前のチャネル (UNIX ローカルチャネル) に適用されます。このセクションに必要な定義は、ジョブコントローラがこの チャネルを実行するために発行する master_command だけです。このチャネル名にはワイルドカードが含まれていないため、チャネル名は完全に一致しなければなりません。
この [CHANNEL] セクションは、tcp_* で始まるすべてのチャネル名に適用されます。このチャネル名にはワイルドカードが含まれているため、tcp_ で始まるすべてのチャネルに一致します。
ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。ジョブ範囲は、job_controller にプールごとに設定されます。たとえば、SMTP_POOL の job_limit を 10 と定義すれば、このプールで実行できる tcp_smtp クライアントプロセスは常に 10 個だけです。
tcp_* チャネルを追加する必要があることもあります。たとえば、メール処理が非常に遅いサイト用の tcp チャネルなどです。このようなチャネルは別のプールで実行することをお勧めします。理由は、tcp_* チャネルを 10 個作成し、SMTP_POOL ですべてを実行する場合は、tcp_* チャネルごとに常に 1 つの tcp_smtp クライアントだけを実行することが可能であるからです (ただし、メールの宛先がすべて tcp_* チャネルであり、SMTP_POOL が 10 個の job_limit で定義されている場合)。システムに大きな負荷があり、どのキューにも複数の tcp_* チャネル宛の待機メッセージがある場合は、十分ではありません。スロットが競合しないように、新しい tcp_* チャネルに別のプールを定義することも考えられます。
たとえば、次の tcp_* チャネルを設定する場合を考えてみます。
tcp_yahoo smtp mx pool yahoo_pool keyword keyword keyword tcp-yahoo-daemon tcp_aol smtp mx keyword keyword keyword pool aol_pool tcp-aol-daemon tcp_hotmail smtp mx pool hotmail_pool keyword keyword keyword tcp-hotmail-daemon ... tcp_sun smtp mx pool sun_pool keyword keyword keyword tcp-sun-daemon |
新規チャネルごとに 10 個の tcp_smtp_client 処理を追加するには、job_controller.cnf ファイルに次のように追加します。
[POOL=yahoo_pool] job_limit=10 [POOL=aol_pool] job_limit=10 [POOL=hotmail_pool] job_limit=10 ... [POOL=sun_pool] job_limit=10 |
プールの詳細については、「チャネル実行ジョブの処理プール」を参照してください。『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
表 10–6 ジョブコントローラ設定ファイルのオプション
MTA には、ローカルシステムに関連付けられ、実際のユーザーと必ずしも対応しないメールボックス名をサポートする機能である「エイリアス」があります。エイリアスは、メーリングリストの作成、メールの転送、およびユーザーの別名の設定に役立ちます。エイリアス解決の処理方法については、「$V メタキャラクタ」を参照してください。
aliases ファイルまたはエイリアスデータベースで定義されている旧形式のメーリングリストは、非定位置パラメータ [capture] をとるようになりました。[capture] パラメータが使用されている場合、このパラメータで指定するのは、LDAP でユーザーまたはグループに適用される LDAP_CAPTURE 属性で指定される取得アドレスと同じセマンティクスの取得アドレスです。
エイリアスデータベースの使用はお勧めしません。代わりに aliases ファイルを使用してください。このファイルは imsimta reload コマンドを使用して動的に再読み込みできます。
MTA はディレクトリ内の情報を使用し、エイリアスデータベースを作成します。このエイリアスデータベースは、標準のエイリアスファイルが参照されるたびに参照されます。ただし、エイリアスデータベースのエントリが調べられるのは、標準のエイリアスファイルが使用される前です。すなわち、デーベースは、エイリアスファイルが使用される前に実行される、一種のアドレス書き換え機能として動作します。
データベースの形式は固有のものです。データベースを直接編集しないでください。必要な変更はすべてディレクトリで行なってください。
aliases ファイルは、ディレクトリで設定されていないエイリアスを設定するのに使用します。よい例として、Postmaster エイリアスが挙げられます。このファイルで設定したエイリアスがディレクトリにもある場合、このファイルの設定は無視されます。imsimta reload コマンドを発行するか MTA を再起動すると変更が有効になります。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。
Messaging Server には、アドレスリバースデータベースや特殊化されたマッピングテーブルなど、アドレス操作のためのその他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換えルールを使用するようにしてください。第 11 章「書き換えルールの設定」を参照してください。
このファイルでは、一行に入力できる文字数が 1024 バイトに制限されています。\ (円記号) を継続文字として使用すれば、1 つの論理行を複数の行に分割することができます。
ファイルフォーマットは以下のとおりです。
user@domain: address (ホストしているドメイン内のユーザー用) user@domain: address (ホストしていないドメイン内のユーザー用。例: デフォルトドメイン)
例:
! A /var/mail/ ユーザー inetmail@siroe.com: inetmail@native-daemon ! メッセージストアユーザー ms_testuser@siroe.com: mstestuser@ims-ms-daemon |
プライマリ aliases ファイルには、ほかのファイルを含めることができます。次の行は、MTA に file-spec ファイルを読み込むように指示するためのものです。
<file-spec
ファイル仕様は、完全なパスを指定したものでなければなりません。また、そのファイルには、プライマリ aliases ファイルと同じ保護が設定されている必要があります (たとえば、誰でも読み込み可能であることなど)。
インクルードファイルの内容は、aliases ファイル内の参照ポイントに挿入されます。インクルードファイルへの参照をそのファイルの実際の内容に置き換えることによっても、同様の効果が得られます。インクルードファイルの形式は、プライマリ aliases ファイルとまったく同じになります。さらに、インクルードファイルにほかのファイルを含めることも可能です。インクルードファイルは、3 階層までネストすることができます。
Messaging Server には、MTA に関する各種保守、テスト、管理などのタスクを実行するためのコマンド行ユーティリティーが備わっています。たとえば、MTA の設定、エイリアス、マッピング、セキュリティー、システム全体のフィルタファイル、およびオプションファイルをコンパイルするには、imsimta cnbuild コマンドを使用します。MTA コマンド行ユーティリティーの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。
SMTP セキュリティーとアクセス制御については、第 17 章「メールのフィルタリングとアクセス制御」を参照してください。
MTA 固有のログファイルはすべて、ログディレクトリ (msg_svr_base/log) に保存されます。このディレクトリには、MTA を介したメッセージトラフィックのログファイル、および特定のマスタープログラムまたはスレーブプログラムの情報を記述したログファイルがあります。
MTA ログファイルの詳細については、第 21 章「ログの管理」を参照してください。
アドレスは、アドレスリバースデータベース (リバースデータベースとも呼ばれる) と REVERSE マッピングテーブルを使って内部形式から公的なアドバタイズ形式に変換することができます。たとえば、uid@mailhost.siroe.com は、siroe.com ドメイン内では有効なアドレスであっても、外部に公開するには適切なアドレスではない場合があります。この場合は、firstname.lastname@siroe.com のような公式アドレスを使用することをお勧めします。
Messaging Server には、aliases ファイルや特殊化されたマッピングテーブルなど、アドレス操作のためのその他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換えルールを使用するようにしてください。第 11 章「書き換えルールの設定」を参照してください。
リバースデータベースでは、各ユーザーの公式アドレスはディレクトリ内のユーザーエン トリのmail 属性で指定されています。プライベートアドレスや内部アドレスは、mailAlternativeAddress 属性で指定されています。配布リストについても同様です。
リバースデータベースには、有効なアドレスと公式アドレスとの間のマッピングが含まれています。通常、リバースデータベースは MTA データベースディレクトリにあります。このデータベースは、msg_svr_base/config/imta_tailor ファイルの IMTA_REVERSE_DATABASE オプションで名前が指定されているファイルで構成されます。特に設定を変更しない限り、これらのファイルは msg_svr_base/data/db/reversedb.* です。
データベース内でアドレスが見つかった場合は、そのデータベースの対応する右側部分がアドレスとして置き換えられます。アドレスが見つからなかった場合は、mappings ファイルで REVERSE という名前のマッピングテーブルが検索されます。このマッピングテーブルが存在しない場合、またはマッピングテーブル内に一致するエントリがない場合には、置換は行われず、書き換えは通常どおりに終了します。
REVERSE マッピングテーブルが mappings ファイル内にあり、アドレスがマッピングエントリと一致し、そのエントリが $Y を指定している場合は、結果の文字列によってアドレスが置き換えられます。$N を指定している場合は、マッピングの結果が破棄されます。マッピングエントリが $Y のほかに $D を指定している場合は、結果の文字列を使ってもう一度リバースデータベースがスキャンされます。一致するエントリが見つかった場合は、データベースのテンプレートによってマッピングの結果 (つまりアドレス) が置き換えられます。一般的な REVERSE マッピングテーブルエントリ (すべてのチャネルに適用されるエントリ) の形式は、以下のとおりです。フラグは、新しいアドレスの前または後ろに指定できます。
REVERSE OldAddress $Y[Flags]NewAddress |
チャネル固有のエントリ (特定のチャネルから渡されるメッセージ上でのみ実行されるマッピング) の形式は、次のとおりです。チャネル固有のエントリを機能させるには、option.dat で use_reverse_database を 13 に設定する必要があります。
REVERSE source-channel|destination-channel|OldAddress $Y[Flags]NewAddresS |
REVERSE マッピングテーブルのフラグを表 10–7 に示します。
表 10–7 REVERSE マッピングテーブルのフラグ
フラグ |
説明 |
---|---|
$Y |
出力文字列を新規アドレスとして使用します。 |
$N |
アドレスは変更されません。 |
$D |
出力文字列を使ってリバースデータベースをスキャンします。 |
$A |
パターンをリバースデータベースエントリとして追加します。 |
$F |
パターンを正引きデータベースエントリとして追加します。 |
フラグの比較 |
説明 |
$:B |
ヘッダー (本文) のアドレスのみを照合します。 |
$:E |
エンベロープアドレスのみを照合します。 |
$:F |
前方を探すアドレスのみを照合します。 |
$:R |
後方を探すアドレスのみを照合します。 |
$:I |
メッセージ ID のみを照合します。 |
reverse チャネルキーワードと noreverse チャネルキーワード、および MTA の USE_REVERSE_DATABASE オプションと REVERSE_ENVELOPE オプションを使用して、アドレスリバースを適用する時期や方法などの指定を制御できます。デフォルトでは、アドレスリバース操作は、後方を探すアドレスだけではなく、すべてのアドレスに適用されます。
アドレスリバースは、REVERSE_ENVELOPE システムオプションの値を設定することによって (デフォルト: 1-on、0-off)、有効または無効にすることができます。
宛先チャネル上の noreverse は、アドレスリバースがメッセージ内のアドレスに適用されないことを指定します。reverse は、アドレスリバースが適用されることを指定します。詳細は、「チャネル固有のリバースデータベースの使用を有効にする」を参照してください。
USE_REVERSE_DATABASE は、MTA が置換アドレスとしてアドレスリバースデータベースとREVERSE マッピングを使用するかどうかを制御します。値 0 は、アドレスリバースがどのチャネルでも使われないことを示します。値 5 (デフォルト) は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけではなく、すべてのアドレスに適用されることを指定します。値 13 は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけでなく、reverse チャネルキーワードを含むアドレスに適用されることを意味します。また、USE_REVERSE_DATABASE オプションのビット値を設定して、アドレスリバース操作の単位を指定することもできます。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Option File Format and Available Options」を参照してください。
REVERSE_ENVELOPE オプションは、メッセージヘッダーアドレスとともにエンベロープ From アドレスにもアドレスリバースを適用するかどうか制御します。
これらの効果の詳細については、『Sun Java System Messaging Server Administration Reference』の各オプションおよびキーワードの説明を参照してください。
一般的な REVERSE マッピングの例を次に示します。この例では、siroe.com の内部アドレスの形式が user@mailhost.siroe.com であると仮定しています。ただし、ユーザーのネームスペースでは、user@host1.siroe.com と user@host2.siroe.com が siroe.com のすべてのホストで同じユーザーを指定しています。次の REVERSE マッピングは、アドレスリバースデータベースとともに使用できます。
REVERSE *@*.siroe.com $0@siroe.com$Y$D
この例では、name@anyhost.siroe.com という形式のアドレスが name@siroe.com に変換されています。$D メタキャラクタでは、アドレスリバースデータベースが参照されるようになります。アドレスリバースデータベースには、以下の形式のエントリが含まれています。
user@mailhost.siroe.com first.last@siroe.com
デフォルトでは、ルーティングの範囲がメールサーバードメインに設定されている場合に、アドレスリバースデータベースが使用されます。チャネル固有の REVERSE マッピングテーブルエントリの例を以下に示します。
REVERSE tcp_*|tcp_local|binky@macho.siroe.com $D$YRebecca.Woods@siroe.com
このエントリは、MTA に対して、ソースチャネル tcp_* から宛先チャネル tcp_local に送信されるすべてのメールのアドレス形式を、binky@macho.siroe.com から Rebecca.Woods@siroe.com に変更するように指示します。
チャネル固有のリバースマッピングを有効にするには、option.dat の USE_REVERSE_DATABASE オプションを 13 に設定する必要があります (デフォルト =5)。
アドレスリバースは、エンベロープ To: アドレスには適用されません。これは、エンベロープ To: アドレスは、メッセージがメールシステムで処理される過程で次々と書き換えられ、変更されるからです。ルーティングの目的は、エンベロープ To: アドレスをシステムまたはメールボックス固有のフォーマットに変換していくことです。アドレスリバースの正規化機能は、エンベロープ To: アドレスには不適切です。
MTA では豊富な機能が使用でき、エンベロープ To: アドレスの置換が実行できます。エイリアスファイル、エイリアスデータベース、および一般検索テーブルによって、この機能が提供されます。
MTA では、正引き検索テーブルや FORWARD マッピングも提供されており、パターンに基づく転送、ソース固有の転送、アドレスの自動登録などの特殊な転送に使用されます。ただし、正引き検索テーブルや FORWARD マッピングは、特殊なアドレス転送のための機能であることに注意してください。ほとんどのアドレス転送には、MTA のほかの転送機構を使用したほうがパフォーマンスは向上します。
エンベロープ To: アドレス用のさまざまな置換機構では、リバース検索テーブルと同等の機能が提供されますが、リバースマッピングと同等の機能は現時点ではありません。エンベロープ To: アドレス用のマッピング機能が必要とされる状況が発生することもあります。
FORWARD マッピングテーブルでは、パターンに基づいた転送を行うための機能が提供されます。また、ソース固有の転送を行うための機構も提供されます。マッピングファイル内に FORWARD マッピングテーブルがある場合、それは各エンベロープ To: アドレスに適用されます。このマッピングテーブルがない場合や一致するエントリがマッピングテーブルにない場合、変更は行われません。
アドレスに一致するマッピングエントリがある場合は、マッピングの結果がテストされます。エントリが $Y を指定している場合は、エンベロープ To: アドレスは結果の文字列で置き換えられ、エントリが $N を指定している場合は、マッピングの結果が破棄されます。このほかのフラグの一覧は、表 10–8 を参照してください。
表 10–8 FORWARD マッピングテーブルフラグの各フラグの説明
フラグ |
説明 |
---|---|
$D |
出力文字列を使って書き換えプロセスを再び実行します |
$G |
正引き検索テーブルの使用が有効になっている場合に、出力文字列を使って正引き検索テーブルをスキャンします |
$H |
正引き検索テーブルまたは FORWARD マッピングの検索続行を無効にします |
$I |
.HELD ファイルとしてメッセージを保留します |
$N |
アドレスは変更されません |
$Y |
出力文字列を新規アドレスとして使用します |
FORWARD マッピングが存在する場合は、正引き検索テーブルの検索が行われる前に参照されます。FORWARD マッピングが一致し、フラグ $G が付いていれば、FORWARD マッピングの結果は正引き検索テーブルに対してチェックされます。ただし、USE_FORWARD_DATABASE が適切に設定されていて正引き検索テーブルの使用が有効になっている必要があります。チャネル固有の正引き検索テーブルの使用が指定されている場合は、正引き検索テーブルの検索が行われる前に、ソースアドレスとソースチャネルが FORWARD マッピングの結果の前に付けられます。一致する FORWARD マッピングエントリが $D を指定している場合、FORWARD マッピング (およびオプションの正引き検索テーブルの検索) の結果を使用して MTA アドレス書き換えプロセスが再び実行されます。一致する FORWARD マッピングエントリが $H を指定している場合、それ以上の FORWARD マッピングまたはデータベースの検索は、$D を使用したことによる後続のアドレス書き換えプロセスの間に実行されません。
以下に、複雑な REVERSE マッピングおよび FORWARD マッピングの使用例を示します。mr_local チャネルに関連付けられている am.sigurd.innosoft.com というシステム (仮のドメイン) が、次の一般的な形式の RFC 822 アドレスを生成すると仮定します。
"lastname, firstname"@am.sigurd.example.com
または
"lastname,firstname"@am.sigurd.example.com
これらのアドレスは完全に正しいものですが、RFC 822 の構文ルールに完全準拠していないほかのメーラー (たとえば、引用符で囲まれたアドレスを適切に処理しないメーラー) では混乱が生じることがあります。そのため、引用を必要としないアドレス形式のほうが、多くのメーラーで機能する傾向があります。次はその一例です。
firstname.lastname@am.sigurd.example.com
複雑な FORWARD マッピングおよび REVERSE マッピングの例
REVERSE *|mr_local|"*,$ *"@am.sigurd.example.com $Y"$1,$ $2"@am.sigurd.example.com *|mr_local|"*,*"@am.sigurd.example.com $Y"$1,$ $2"@am.sigurd.example.com *|*|"*,$ *"@am.sigurd.example.com $Y$3.$2@am.sigurd.example.com *|*|"*,*"@am.sigurd.example.com $Y$3.$2@am.sigurd.example.com *|mr_local|*.*@am.sigurd.example.com $Y"$2,$ $1"@am.sigurd.example.com *|*|*.*@am.sigurd.example.com $Y$2.$3@am.sigurd.example.com FORWARD "*,$ *"@am.sigurd.example.com $Y"$0,$ $1"@am.sigurd.example.com "*,*"@am.sigurd.example.com $Y"$0,$ $1"@am.sigurd.example.com *.*@am.sigurd.example.com $Y"$1,$ $0"@am.sigurd.example.com
上記の例では、サンプルのマッピングテーブルの目的には 3 段階あります。(1) 上記の 3 種類のアドレス形式をすべて使用可能にする。(2) 必要に応じて形式を変換し、元の形式のアドレスのみを mr_local チャネルに提示する。(3) 必要に応じて形式を変換し、新しい引用府なしの形式のアドレスのみをほかのすべてのチャネルに提示する (例で示した REVERSE マッピングでは、MTA オプション USE_REVERSE_DATABASE のビット 3 が設定されていると仮定)。
アドレス転送を自動登録またはソース固有にする必要がある場合には、正引き検索テーブルを使用します。通常、単純なメッセージの転送に正引き検索テーブルを使用することは適切ではありません。このような転送には、aliases ファイルまたはエイリアス検索テーブルを使用するほうが効率的です。デフォルトでは、正引き検索テーブルは一切使用されません。使用するには、USE_FORWARD_DATABASE オプションを使用して明示的に有効にする必要があります。正引き検索テーブルの検索は、アドレス書き換えの後、エイリアス展開が実行され、FORWARD マッピングがチェックされた後で実行されます。正引き検索テーブルの検索が成功した場合、結果の置換済みアドレスを使用して MTA アドレス書き換えプロセスが初めからやり直されます。
正引き検索テーブルに使用できる機構には、メモリ内ハッシュテーブルと従来のデータベースの 2 つがあります。テーブルのサイズが極端に大きい場合を除いて、ハッシュテーブルを使用することをお勧めします (1,000 はそれほど大きいとされない。100,000 が目安)。ハッシュテーブルは、use_text_database オプションにビット 3 (値 34) を設定すること、および use_forward_database を設定することによって有効になります。ハッシュテーブルは、msg_svr_base/configure/forward.txt から読み込まれ、設定の再読み込み可能な部分にコンパイルされます。imsimta reload コマンドを使用すると、これをアクティブな MTA プロセスに再読み込みできます。
正引きデータベースは、crdb ユーティリティーを使用してソーステキストファイルから作成された MTA crdb データベースです。デフォルトでは、ソーステキストファイルは次のような形式になっています。
user1@domain1 changedmailbox1@changeddomain1 user2@domain2 changedmailbox@changeddomain2 |
ただし、USE_FORWARD_DATABASE オプションでビット 3 が設定されていてソース固有の正引きデータベースの使用が有効になっている場合は、ソーステキストファイルの形式は次のようになります。
source-channel|source-address|original-address changed-address
たとえば、次のようなエントリがあるとします。
tcp_limited|bob@blue.com|helen@red.com “helen of troy”@siroe.com |
この例では、To: アドレス helen@red.com が “helen of troy”@siroe.com にマッピングされます (メッセージの差出人が bob@blue.com で、キューに入れられるチャネルが tcp_limited であると仮定した場合)。
配信ステータス通知、すなわちステータス通知は、MTA が差出人に送信する電子メールステータスメッセージで、ポストマスターに送信することもできます。Messaging Server では、通知メッセージの内容や言語をカスタマイズすることができます。また、配信ステータス (たとえば、FAILED、BOUNCED、TIMEDOUT など) の種類ごとに異なるメッセージを作成することもできます。さらに、特定のチャネルから送信されたメッセージに関するステータス通知を作成することもできます。
デフォルトでは、ステータス通知は msg_svr_base/config/locale/C ディレクトリに保存されます (msg_svr_base/config/imta_tailor ファイルの IMTA_LANG 設定で指定)。次のような種類があります。
return_bounced.txt、return_delivered.txt、return_header.opt、return_timedout.txt、return_deferred.txt、return_failed.txt、return_prefix.txt、return_delayed.txt、return_forwarded.txt、return_suffix.txt
*.txt ファイルのメッセージテキストは、1 行につき 78 文字以内である必要があります。これらのファイルには直接変更を加えないてください。これらのファイルは、Messaging Server の現在のバージョンのアップグレード時に上書きされます。ファイルを変更して独自の通知メッセージテンプレートファイル (return_*.txt) として使用する場合は、新しいディレクトリにファイルをコピーし、そちらを編集してください。次に imta_tailor ファイルに IMTA_LANG オプションを設定し、このテンプレートがある新しいディレクトリを指定します。通知ファイルのセットを複数作成する場合は (言語別のセットを作成する場合など)、NOTIFICATION_LANGUAGE マッピングテーブルを設定する必要があります。
通知メッセージは、return_prefix.txt、return_ActionStatus.txt、return_suffix.txt の 3 ファイルのセットで構成されています。
通知をカスタマイズまたはローカライズするには、ロケールまたはカスタマイズ、あるいはその両方のそれぞれに return_*.txt ファイルの全セットを作成し、それを別々のディレクトリに保存します。たとえば、あるディレクトリにはフランス語の通知ファイル、もう 1 つのディレクトリにはスペイン語の通知ファイルを保存し、3 つ目のディレクトリには特殊な不特定多数宛メールに対する通知を保存することができます。
このリリースには、フランス語、ドイツ語、およびスペイン語のサンプルファイルが含まれています。これらのファイルは、ユーザーのそれぞれのニーズに合わせて変更することができます。
日本語などの 2 バイト文字の場合は、日本語でテキストを作成してから、そのテキストを ASCII 形式に変換してから、% 文字がないかどうかをチェックしてください。不測の % 文字が存在する場合は、%% で置き換えてください。
ステータス通知メッセージの形式と構造は次のとおりです。
return_prefix.txt には、該当するヘッダーテキストと本文の導入部分が含まれます。米国英語のロケールのデフォルトは以下のとおりです。
Content-type: text/plain; charset=us-asci Content-language: EN-US This report relates to a message you sent with the following header fields: %H |
US-ASCII 以外のステータス通知メッセージの場合は、charset パラメータと Content-Language ヘッダーを適切な値に変更する必要があります (たとえばフランス語用のファイルでは ISO-8859-1 と fr)。%H は、表 10–9 で定義されているヘッダー置換シーケンスです。
return_<ActionStatus>.txt にはステータス専用のテキストが含まれています。ActionStatus は、メッセージの MTA ステータスタイプです。たとえば、デフォルトでは return_failed.txt のテキストは次のようになります。
Your message cannot be delivered to the following recipients:%R
return_bounced.txt のデフォルトのテキストは次のようになります。
Your message is being returned. It was forced to return bythe postmaster.
The recipient list for this message was:%R
return_suffix.txt には結びのテキストが含まれます。デフォルトでは、このファイルは空白です。
置換 |
定義 |
---|---|
%H |
メッセージのヘッダーに展開します。 |
%C |
メッセージがキューに入っていた時間の単位1 に展開します。 |
%L |
返送されるまでメッセージがキューに置かれていた時間の単位1 に展開します。 |
%F |
メッセージがキュー内に留まることができる時間の単位 1 に展開します。 |
%S [%s] |
以前展開した数値が 1 以外の場合は、S または s に展開します。次に例を示します。「%C day%s」は、メッセージがキューに入っていた日数によって「1 day」または「2 days」などに展開できます。 |
%U [%u] |
使用する時間の単位 (時間または日) に展開します。次に例を示します。「%C %U%s」は、メッセージがキューに入っていた日数または時間数と MTA オプション RETURN_UNITS の値によって「2 日」や「1 時間」などに展開できます。RETURN_UNITS=1 (時間) を設定していて、ローカライズされた通知メッセージをサイトで使用している場合は、英語以外のすべての言語に関して、return_delayed.txt と return_timedout.txt を編集し、「日」に相当する単語を「時間」に相当する単語で置き換える必要があります。たとえば、フランス語では、jour(s) を heure(s) と置き換えます。ドイツ語では、Tag(e) を Stunde(n) と置き換えます。スペイン語では、día(s) を hora(s) と置き換えます。 |
%R |
メッセージの受取人のリストに展開します。 |
%% |
% (テキストの置換シーケンスは、文字セットに関係なくバイト単位でスキャンされる。2 バイトの文字セットを使用する場合は、意図しない % 記号を確認する必要がある。) |
1 単位は、時間または日 (デフォルト) で、MTA オプションファイルの RETURN_UNITS オプションで定義されます。 |
配信ステータス通知メッセージをローカライズして、言語別に異なるユーザーにメッセージを返すことができます。たとえば、フランス語を使用しているユーザーにフランス語の通知を返すことができます。
ステータス通知メッセージのローカライズまたはカスタマイズは、次の 2 つの手順で行います。
ローカライズまたはカスタマイズされた return_*.txt メッセージファイルのセットを作成し、別々のディレクトリに保存します。詳細は、「ステータス通知を作成および変更するには」を参照してください。
NOTIFICATION_LANGUAGE マッピングテーブルを設定します。
NOTIFICATION_LANGUAGE マッピングテーブル (msg_svr_base/config/mappings) では、送信元メッセージ (通知が送信される原因であるメッセージ) の属性 (言語、国、ドメイン、アドレスなど) に応じて使用される、ローカライズまたはカスタマイズされた通知メッセージファイルのセットを指定します。
元の差出人のメッセージがパースされ、ステータス通知の種類、ソースチャネル、優先言語、返信アドレス、および 1 人目の受取人が決定されます。テーブルの構築方法によって異なりますが、通知ファイルのセットは 1 つ以上の属性によって選択されます。
NOTIFICATION_LANGUAGE マッピングテーブルの形式は次のとおりです。サンプルのエントリ行は、紙面の都合で折り返されています。実際のエントリは、1 行で記述する必要があります。
NOTIFICATION_LANGUAGE dsn-type-list|source-channel|preferred-language|return-address \ |first-recipient $Idirectory-spec |
dsn-type-list は、配信ステータス通知の種類のコンマ区切りリストです。複数の種類を指定する場合はコンマで区切ります。スペースでは区切りません。スペースを使用すると、マッピングテーブルエントリのパターンが終了します。次のような種類があります。
failed - 一般的な、永続的配信不能を示すメッセージ (「そのようなユーザーはありません」など)。return_failed.txt ファイルが使用されます。
bounced - 手動で「バウンス」した場合に使用される通知メッセージ。ポストマスターを実行します。return_bounced.txt ファイルが使用されます。
timedout - MTA が、指定された配信期間内にメッセージを配信できなかったことを示します。メッセージは送り返されます。return_timedout.txt ファイルが使用されます。
delayed - MTA が、メッセージを配信できなかったが、引き続き配信を試みていることを示します。return_delayed.txt ファイルが使用されます。
deferred - 「delayed」に類似した配信不能通知。ただし、MTA が配信試行を続行する期間は表示されません。return_deferred.txt ファイルが使用されます。
forwarded - このメッセージに対して配信確認が要求されていたが、このメッセージは配信確認がサポートされていないシステムに転送されたことを示します。return_forwarded.txt ファイルが使用されます。
source-channel は通知メッセージを生成するチャネル、つまり現在メッセージがキューに入っているチャネルです。たとえば、メッセージストアの配信キューの ims-ms、送信用 SMTP キューの tcp_local などがあります。
preferred-language は、処理中のメッセージ (通知を生成中のメッセージ) で使用される言語です。この情報のソースは、第 1 に accept_language フィールドです。このフィールドにない場合は、Preferred-language: ヘッダーフィールドと X-Accept-Language: ヘッダーフィールドが使用されます。標準の言語コードの値のリストは、msg_svr_base/config/languages.txt ファイルを参照してください。
このフィールドには、空の場合を除き、メッセージの発信者が Preferred-language: ヘッダー行または X-Accept-language: ヘッダー行に指定した内容が入ります。このため、意味のない文字が使用されることもあります。
return-address は、送信元メッセージのエンベロープ From: アドレスです。これは、通知メッセージの送信先となるエンベロープアドレスであり、使用言語の手掛かりになることがあります。
first-recipient は、元のメッセージの宛先のエンベロープ To: アドレス (メッセージが複数の受取人に届かない場合は 1 人目の受取人アドレス) です。たとえば、「dan@siroe.com へのメッセージは配信されませんでした」という通知では、報告を受けるエンベロープ To: アドレスは dan@siroe.com です。
directory-spec は、マッピングテーブルのプローブに一致する場合に使用する return_*.txt ファイルを含むディレクトリです。$I の後ろにディレクトリの指定が続きます。
たとえば、フランス語の通知ファイル (return_*.txt) が /lc_messages/table/notify_french/ ディレクトリにあり、スペイン語の通知ファイル (return_*.txt) が /lc_messages/table/notify_spanish/ ディレクトリにあるサイトでは、次のようなテーブルを使用できます。各エントリは 1 つまたは複数のスペースで始まり、エントリ間には空白行はありません。
NOTIFICATION_LANGUAGE ! 優先言語: 指定されたヘッダー値 ! *|*|fr|*|* $I/lc_messages/table/notify_french/ *|*|es|*|* $IIMTA_TABLE/notify_spanish/ *|*|en|*|* $I/imta/lang/ ! ! 優先言語の値が指定されていない場合は、ドメイン名の国別コードに ! 基づいて通知を選択します。例: PF= フランス領ポリネシア、BO= ボリビア ! *|*|*|*.fr|* $I/imta/table/notify_french/ *|*|*|*.fx|* $I/imta/table/notify_french/ *|*|*|*.pf|* $I/imta/table/notify_french/ *|*|*|*.tf|* $I/imta/table/notify_french/ *|*|*|*.ar|* $I/imta/table/notify_spanish/ *|*|*|*.bo|* $I/imta/table/notify_spanish/ *|*|*|*.cl|* $I/imta/table/notify_spanish/ *|*|*|*.co|* $I/imta/table/notify_spanish/ *|*|*|*.cr|* $I/imta/table/notify_spanish/ *|*|*|*.cu|* $I/imta/table/notify_spanish/ *|*|*|*.ec|* $I/imta/table/notify_spanish/ *|*|*|*.es|* $I/imta/table/notify_spanish/ *|*|*|*.gp|* $I/imta/table/notify_spanish/ *|*|*|*.gt|* $I/imta/table/notify_spanish/ *|*|*|*.gy|* $I/imta/table/notify_spanish/ *|*|*|*.mx|* $I/imta/table/notify_spanish/ *|*|*|*.ni|* $I/imta/table/notify_spanish/ *|*|*|*.pa|* $I/imta/table/notify_spanish/ *|*|*|*.ve|* $I/imta/table/notify_spanish/ |
デフォルトの mappings.locale ファイルはインストールによって組み込まれます。これは、通知言語マッピングを有効にするために mappings ファイルに組み込まれます。通知言語マッピングを無効にするには、インクルード行を以下のようにコメントアウトします。
! <IMTA_TABLE:mappings.locale
ファイル内のコメントを読み、必要に応じて変更してください。
配信ステータス通知および MDN (message disposition notification) の両方に、2 つのオプションファイルが使用できます。これらは、生成された通知をより柔軟に国際化するためのものです。次の 2 種類があります。
IMTA_LANG:return_option.dat (DSN)IMTA_LANG:disposition_option.dat (MDN) |
これらのファイルに使用できるオプションを、表 10–10 に示します。
表 10–10 配信ステータス通知および MDN (message disposition notification) のオプション
オプション |
説明 |
---|---|
DAY (DSN) |
RETURN_UNITS=0 (デフォルト) が設定されている場合に、%U または %u と置き換えて挿入される文字です。%U と %u とは区別されません (デフォルトでは、英語の「Day」と「day」が区別して置換される)。 |
DSN の最初の受取人ごとのセクションの作成に使用した「Diagnostic code:」文字のオーバーライドです。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。 |
|
HOUR (DSN) |
RETURN_UNITS=1 が設定されている場合に、%U または %u と置き換えて挿入される文字です。%U と %u とは区別されません (デフォルトでは、英語の「Hour」と「hour」が区別して置換される)。 |
n.n.n (DSN) |
DSN の受取人ごとのセクションの作成時に、受取人単位のステータスの数字と一致するオプション名があるかどうかがチェックされます。一致するものがある場合、対応する文字が DSN に挿入されます。また、上で指定された REASON オプションの結果が長さ 0 の文字列である場合、REASON フィールドには文字は挿入されません。 |
DSN の最初の受取人ごとのセクションの作成に使用した「Original address:」文字のオーバーライドです。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。 |
|
REASON (DSN) |
DSN の最初の受取人ごとのセクションの作成に使用した「Reason::」文字のオーバーライドです。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。 |
DSN の最初の受取人ごとのセクションの作成に使用した「Recipient address:」文字のオーバーライドです。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。 |
|
From: フィールドと一緒に使用される個人名のフィールドのオーバーライドです。このフィールドは RFC 2047 エンコードされている必要があります。このオプションを指定しない場合、RETURN_PERSONAL MTA オプションで設定された値が使用されます。 |
|
SUBJECT (DSN および MDN) |
Subject: フィールドのオーバーライドです。この値は、通知に個々の件名のフィールドが含まれない場合にのみ使用されます。このフィールドは RFC 2047 エンコードされている必要があります。このオプションが使用されず、通知に件名が含まれない場合は、適切な件名が作成されます。 |
MDN の最初の部分および件名が変換されるべき文字セットです。デフォルトでは、変換を行わないようになっています。 |
ステータス通知メッセージの設定に必要な手順は、前の節で説明したとおりです。ここでは、追加機能について説明します。
通常、メッセージがバウンスまたはブロックされる場合は、差出人とローカルドメインのポストマスターに通知メッセージでメッセージの内容が戻されます。サイズの大きいメッセージが何通もそのまま戻されると、リソースに負担がかかります。一定のサイズを超えるメッセージの内容が戻るのをブロックするには、MTA オプションファイルで CONTENT_RETURN_BLOCK_LIMIT オプションを設定します。
インターネットメッセージヘッダーの本来の形式では US-ASCII 以外の文字は使用できません。メッセージヘッダーに使用されている US-ASCII 以外の文字は「MIME ヘッダーエンコーディング」でエンコードされたものです。MIME ヘッダーエンコーディングについては RFC 2047 に記述されています。したがって、電子メールメッセージの「件名」行は、実際には次のように表されています。
Subject: =?big5?Q?=A4j=AB=AC=A8=B1=AD=B1=B0=D3=F5=A5X=AF=B2?=
電子メールクライアントは、ヘッダーを表示する際にエンコーディングを削除する必要があります。
%H テンプレートは通知メッセージの本文にヘッダーをコピーするので、通常はエンコードされたヘッダーが表示されます。ただし、Messaging Server では、件名の文字セット (この場合は big5) が return_prefix.txt の Content-Type ヘッダー文字セットパラメータにある文字セットと一致する場合は、エンコーディングが削除されます。一致しない場合は、Messaging Server のエンコーディングはそのまま残ります。
キーワード: notices、nonurgentnotices、normalnotices、urgentnotices
配信不能メッセージは、指定したチャネルキューに一定期間保存したあとで差出人に戻されます。また、Messaging Server が配信を試みている期間に、一連のステータスメッセージや警告メッセージを差出人に戻すこともできます。その期間とメッセージの配信間隔は、notices、nonurgentnotices、normalnotices、urgentnotices のキーワードで指定できます。次に例を示します。
notices 1 2 3
この例では、すべてのメッセージについて、一時的な配信不能のステータス通知メッセージが 1 日目と 2 日目に送信されます。メッセージが 3 日たってもまだ配信されない場合は、差出人に返されます。
urgentnotices 2,4,6,8
この例では、優先度の高いメッセージについて、一時的な配信不能の通知が 2、4、6 日目に送信されます。メッセージが 8 日たってもまだ配信されない場合は、差出人に返されます。
MTA オプションファイルの RETURN_UNITS オプションでは、時間 (1) または日 (0) で単位を指定することができます。デフォルトは日 (0) です。RETURN_UNITS=1 に設定した場合は、通知を 1 時間おきに受信するには、返送ジョブが 1 時間おきに実行されるようにスケジュールする必要もあります。返送ジョブが 1 時間ごとに実行されると、このジョブによって mail.log* ファイルも 1 時間ごとにロールオーバーされます。mail.log ファイルが 1 時間ごとにロールオーバーされないようにするには、imta.tailor ファイルの IMTA_RETURN_SPLIT_PERIOD テイラーファイルオプションを 24 に設定します。返送ジョブのスケジュールは、local.schedule.return_job configutil パラメータで制御します。
notices キーワードが指定されていない場合は、デフォルトでは、ローカルの l チャネル用の notices 設定が使用されます。ローカルチャネル用の設定がない場合は、デフォルトでは、notices 3, 6, 9, 12 が使用されます。
キーワード: includefinal、suppressfinal、useintermediate
MTA が通知メッセージ (バウンスメッセージ、配信確認メッセージなど) を生成するとき、元の形式の受取人アドレスと、変更された最終的な形式の受取人アドレスの両方が MTA に提示される場合があります。元の形式の方が通知メッセージの受取人 (通知メッセージの場合は元のメッセージの差出人) によって認識される可能性が高いため、MTA は、常に元の形式を通知メッセージに含めます。
includefinal および suppressfinal チャネルキーワードは、MTA が最終的な形式のアドレスを含めるかどうかを制御するためのものです。外部に対して内部のメールボックス名を隠しているサイトでは、最終的な形式のアドレスを含めないことをお勧めします。このようなサイトでは、元の形式の外部用アドレスのみをステータス通知メッセージに含めるほうが適しています。デフォルトは includefinal であり、最終的な形式の受取人アドレスが含められます。suppressfinal を使用すると、元の形式のアドレスが存在する場合、MTA は最終的な形式のアドレスをステータス通知メッセージに含めません。
useintermediate キーワードでは、リストの展開後、ユーザーメールボックス名を生成するまでの間に作成された中間形式のアドレスを使用します。この情報を入手できない場合は、最終形式が使用されます。
デフォルトでは、Errors-to: ヘッダー行やエンベロープ From: アドレスが空白であるためにエラーが返されるか、警告をまったく送信できない場合を除いて、障害および警告のステータス通知メッセージのコピーがポストマスターに送信されます。ポストマスターへの通知メッセージの配信の詳細については、以後の節および表 10–11 で説明する多数のチャネルキーワードで制御できます。
キーワード: sendpost、nosendpost、copysendpost、errsendpost
長期間にわたってサービスが支障をきたしている場合や、アドレスが不正確な場合は、チャネルプログラムがメッセージを配信できないことがあります。このような場合、MTA チャネルプログラムは、配信不能の理由を説明する文と一緒にメッセージを差出人に返送します。さらに、配信できないメッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります (表 10–11 を参照)。
キーワード: warnpost、nowarnpost、copywarnpost、errwarnpost
メッセージの返送に加えて、MTA では、配信できないメッセージに関する詳細な情報を記載した警告を送信することができます。通常、この警告メッセージは notices チャネルキーワードが指定するタイムアウトに基づいて送られますが、配信試行に失敗したときに送られることもあります。警告には、問題点の説明と配信試行を継続する時間枠が記載されます。また、多くの場合、該当するメッセージのヘッダーと最初の数行も含まれます。
さらに、警告メッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります。warnpost、copywarnpost、errwarnpost、nowarnpost キーワードは、警告メッセージを postmaster に送ることを制御するために使用されます (表 10–11 を参照)。
returnenvelope キーワードは 1 つの整数値をとり、これはビットフラグのセットとして解釈されます。ビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープアドレスを空白にするか、あるいはローカルポストマスターのアドレスを入れるかを制御します。このビットを設定した場合は、ローカルポストマスターのアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになります。
RFC 1123 では空白アドレスの使用が義務付けられています。ただし、一部のシステムでは空白エンべロープ From: アドレスを適切に処理できないため、このオプションが必要な場合があります。
ビット 1 (値 = 2) は、MTA がすべての空白エンベロープアドレスをローカルポストマスターのアドレスに置き換えるかどうかを制御します。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用されます。
ビット 2 (値 = 4) は構文的に不正な返信アドレスを禁止します。
ビット 3 (値 = 8) は mailfromdnsverify キーワードと同じです。
キーワード: postheadonly、postheadbody
チャネルプログラムまたは定期的なメッセージ返送ジョブがメッセージをポストマスターと差出人の両方に返送する場合は、ポストマスターへのコピーには、メッセージ全体を含めることも、ヘッダーだけを含めることもできます。ポストマスターへのコピーをヘッダーに限定することで、ユーザーメールのプライバシーのレベルを高めることができます。ただし、ポストマスターやシステム管理者は一般に root システム権限を使用してメッセージの内容を読むことができるため、このキーワードを使用してもメッセージのセキュリティーを完全に保証することにはなりません (表 10–11 を参照)。
キーワード: aliaspostmaster、returnaddress、noreturnaddress、returnpersonal、noreturnpersonal
デフォルトでは、MTA がバウンスメッセージやステータス通知メッセージを作成する際に使用されるポストマスターの返信アドレスは、postmaster@local-host です。この local-host の部分は、ローカルホストの正式な名前 (ローカルチャネルの名前) で、ポストマスターの個人名は「MTA e-Mail Interconnect」です。この場合、ポストマスターのアドレスの選択には注意してください。不正なアドレスを選択すると、高速のメッセージループが発生し、非常に多数のエラーメッセージが返されることになります。
RETURN_ADDRESS オプションと RETURN_PERSONAL オプションを使用すると、MTA システムでポストマスターのアドレスと個人名をデフォルトに設定できます。また、チャネルごとに制御する必要がある場合は、returnaddress および returnpersonal の各チャネルキーワードを使用できます。returnaddress と returnpersonal は、それぞれポストマスターのアドレスと個人名を指定する引数をとります。noreturnaddress と noreturnpersonal はデフォルトであり、デフォルト値が使用されます。このようなオプションが設定されていない場合は、RETURN_ADDRESS オプションと RETURN_PERSONAL オプションでデフォルトを設定します。これらのオプションが設定されていない場合は、通常のデフォルト値が使用されます。
aliaspostmaster キーワードがチャネルに指定されている場合は、正式なチャネル名におけるユーザー名 postmaster (大文字のみ、小文字のみ、またはその両方) 宛のすべてのメッセージは、postmaster@local-host にリダイレクトされます。local-host には、正式なローカルホスト名 (ローカルチャネルの名前) が入ります。インターネット標準規格では、メールを受け付ける DNS のすべてのドメインに、メールを受信する有効なポストマスターアカウントを設定する必要があります。このため、各ドメインに個別のポストマスターアカウントを設定するのではなく、ポストマスターの責務を一元化する場合はこのキーワードが便利です。つまり、returnaddress は、MTA がポストマスターからの通知メッセージを生成する際に使用するポストマスターの返信アドレスを制御し、aliaspostmaster は、MTA がポストマスター宛のメッセージを処理する方法を制御します。
表 10–11 ポストマスターと差出人に送信される通知メッセージのキーワード
MDN (Message Disposition Notifications) は、MTA によって差出人またはポストマスター (あるいはその両方) に送信される電子メールレポートであり、メッセージの配信状態を報告します。たとえば、メッセージが Sieve フィルタによって拒否された場合、差出人に MDN が送信されます。MDN は、開封確認、確認通知、受信通知、配信確認とも呼ばれます。Sieve スクリプト言語は一般に、メッセージフィルタリングおよび不在返信メッセージに使用されます。
MDN の変更とローカライズについての手順は、わずかな相違を除いて、配信ステータス通知メッセージのカスタマイズとローカライズで説明されている手順と同様です。「配信ステータス通知メッセージをカスタマイズおよびローカライズするには」および 「生成された通知の国際化」を参照してください。
マッピング (DISPOSITION_LANGUAGE マッピングと呼ばれる) は、ステータス通知を国際化するために使用される notification_language マッピングテーブル (「配信ステータス通知メッセージをカスタマイズおよびローカライズするには」を参照) と同等です。
ただし、このマッピングに対する MDN のプローブは、次の形式をとります。
type|modifiers|source-channel|header-language|return|recipient
説明:
type はディスポジションタイプで、displayed、dispatched、processed、deleted、denied、failed のいずれかを指定できます。
modifiers は、ディスポジション修飾子をコンマで区切って示したリストです。現在指定できるのは、error、warning、superseded、および expired です。
source-channel は、MDN を生成するソースチャネルです。
header-language は言語で、accept-language、preferred-language、x-accept-language のいずれかのオプションで指定します (これらオプションのうち最初に指定されているものが MTA で使用される)。
return は、通知の返信先アドレスです。
recipient は、ディスポジションの対象のアドレスです。
ディスポジションマッピングの結果には、2 〜 3 個の情報が含まれます。各情報は縦棒 (|) で区切られています。最初の情報は、開封通知のテンプレートファイルが置かれているディレクトリです。2 番目の情報は、ディスポジションテキストだけに適用される文字セットです。一部のディスポジション (特に自動返信エコーまたは不在時の Sieve 処理に対する :mime パラメータの使用によって生成されたディスポジション) では、テンプレートファイルが使用されず、その結果、テンプレートファイルから文字セットを継承することができないため、この情報は必要です。3 番目の情報は、通知の件名行のオーバーライドです。この情報は、マッピングによって $T フラグも設定されている場合にのみ使用されます。
次の追加テンプレートファイルは、MDN を構築するときに使用されます。
disposition_deleted.txt disposition_failed.txtdisposition_denied.txt disposition_prefix.txtdisposition_dispatched.txt disposition_processed.txtdisposition_displayed.txt disposition_suffix.txtdisposition_option.opt
これらのテンプレートファイルの使用は、ステータス通知メッセージの場合のさまざまな return_*.txt ファイルの使用に相当します。*.txt ファイルのメッセージテキストは、1 行につき 78 文字以内である必要があります。