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

この章では、一般的な MTA サービスと設定について説明します。より具体的で詳細な説明については、ほかの章を参照してください。この章には、以下の節があります。

MTA 設定をコンパイルする

imta.cnf、mappings、aliases、option.dat などの MTA 設定ファイルを変更した場合は、imsimta refresh コマンドを使って必ず設定をコンパイルしなおす必要があります (『Sun Java System Messaging Server Administration Reference』を参照)。このコマンドによって、設定ファイルが共有メモリ内の単一のイメージ (UNIX の場合)、またはダイナミックリンクライブラリ (NT の場合) にコンパイルされます。

コンパイルされた設定には、静的な部分と動的で再読み込み可能な部分があります。動的な部分が変更された場合に imsimta reload を実行すると、実行中のプログラムによって動的なデータが再読み込みされます。動的な部分とは、マッピングテーブル、エイリアス、検索テーブルです。

設定情報のコンパイルは、主にパフォーマンス向上のために行います。コンパイルされた設定を使用するもう 1 つの利点は、設定の変更を簡単にテストできることです。これは、コンパイルされた設定が使用されているときに設定ファイル自体は「実行中」ではないからです。

チャネルプログラムなどの MTA コンポーネントは、設定ファイルの読み込みが必要になるたびに、コンパイルされた設定が存在するかどうかをチェックします。存在する場合は、そのイメージが実行中のプログラムに添付されます。イメージの添付処理に失敗すると、MTA は代わりに古い方法であるテキストファイルの読み込みを実行します。

MTA 設定ファイル

MTA の主要設定ファイルは imta.cnf です。デフォルトでは、このファイルは msg_svr_base/config/imta.cnf にあります。このファイルには、MTA チャネル定義およびチャネル書き換えルールが含まれています。書き換えられた宛先アドレスに関連付けられたチャネルが、宛先チャネルとなります。通常、デフォルトの imta.cnf を使用することでシステムは良好に機能します。

MTA 設定ファイルを変更することにより、サイトで使用されるチャネルを確立し、書き換えルールを介して各チャネルが処理するアドレスの種類を決定することができます。設定ファイルは、使用可能な転送方法 (チャネル) および転送経路 (書き換えルール) を指定し、アドレスの種類を適切なチャネルに関連付けることにより電子メールシステムの設計を定めるファイルです。

設定ファイルは、ドメイン書き換えルールとチャネル定義の 2 つの部分から構成されます。ドメイン書き換えルールがファイルの最初に現れ、チャネル定義とは 1 つの空白行で区切られています。チャネル定義は集合的にチャネルテーブルと呼ばれます。個々のチャネル定義がチャネルブロックを構成します。

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

以下に、上記設定ファイルの主な項目 (括弧に入っている太字の番号付き) について説明します。

コメント行を示すには、感嘆符 (!) を使用します。感嘆符は行頭に表示されていなければなりません。その他の場所にある感嘆符は、文字として解釈されます。

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

設定ファイル内で最初に現れる空白行は、書き換えルールの終わりとチャネル定義の始まりを表します。これらの定義は「チャネルホストテーブル」と総称され、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	b_channel
u@d	a_channel


注	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 ファイルは、誰でも読み取り可能でなければなりません。誰でも読み取り可能でアクセスできない場合は、誤作動をまねくことになります。mappings ファイルを変更した場合は、必ず MTA 設定をコンパイルしなおしてください。「MTA 設定をコンパイルする」を参照してください。

表 10-2 に、このマニュアルで説明するマッピングテーブルの一覧を示します。

表 10-2 Messaging Server のマッピングテーブル
マッピングテーブル	ページ	説明
AUTH_REWRITE	367	authrewrite キーワードとともに、認証操作 (SASL) で取得したアドレス情報によってヘッダーとエンベロープアドレスを変更するために使用されます。
CHARSET-CONVERSION	448	チャネル間における文字セット変換やメッセージフォーマット変換の種類を指定するために使用されます。
COMMENT_STRINGS	390	アドレスヘッダーのコメント (括弧で囲まれた文字列) を変更するために使用されます。
CONVERSIONS	430	変換チャネルのメッセージトラフィックを選択するために使用されます。
FORWARD	271	エイリアスファイルまたはエイリアスデータベースを使用した場合と同様の転送を行います。
FROM_ACCESS	533	エンベロープの From アドレスに基づいてメールをフィルタリングする場合に使用します。このテーブルは、To アドレスが不適切な場合に使用します。
INTERNAL_IP	550	内部のシステムとサブネットを認識します。
MAIL_ACCESS	533	SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて着信接続をブロックする場合に使用します。
NOTIFICATION_LANGUAGE	275	通知メッセージをカスタマイズまたはローカライズします。
ORIG_MAIL_ACCESS	533	ORIG_SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて着信接続をブロックする場合に使用します
ORIG_SEND_ACCESS	533	エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、着信接続をブロックします。
PERSONAL_NAMES	391	個人名 (角括弧で区切られたアドレスの前にある文字列) を変更するために使用されます。
PORT_ACCESS	533	IP 番号に基づいて着信接続をブロックする場合に使用します。
REVERSE	267	内部形式から公のアドバタイズ形式にアドレスを変換します。
SEND_ACCESS	533	エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、着信接続をブロックします。
SMS_Channel_TEXT	918	サイト定義のテキストの変換に使用されます。
X-ATT-NAMES	439	マッピングテーブルからパラメータ値を検索するために使用されます。
X-REWRITE-SMS-ADDRESS	917	ローカル SMS アドレスの妥当性チェックに使用されます。

マッピングファイルのファイルフォーマット

mappings ファイルは、一連のテーブルで構成されています。各テーブルはその名前で始まります。名前には常に、最初の列にアルファベット文字がきます。テーブル名の次には必ず空白行が続き、その後にテーブルのエントリが続きます。エントリは、ゼロまたはそれ以上のインデント行で構成されます。各エントリ行は、1 つ以上のスペースまたはタブで区切られた 2 つのカラムから成ります。エントリ内のスペースはすべて、$ 文字で囲む必要があります。各テーブル名の後およびテーブル間には空白行が必要ですが、1 つのテーブル内のエントリ間に空白行があってはなりません。コメントは、1 つめのカラムに記述され、感嘆符 (!) から始まります。

TABLE2_NAME マッピングテーブルを使用するアプリケーションは、pattern2-2 文字列を template2-2 で指定された文字列にマップします。各パターン、またはテンプレートには、最高 252 文字までを含めることができます。マッピングテーブルに含まれるエントリの数に制限はありません (ただし、エントリが必要以上に多い場合は、大きな CPU 容量およびメモリ容量を要することになる)。252 バイト以上の長い行は、¥ (円記号) を行の末尾に置くことで次の行に続けることができます。2 つのカラム間および 1 つめのカラムの前にある空白スペースを削除してはなりません。

mappings ファイルでマッピングテーブル名が重複することは許されていません。

マッピングファイルにほかのファイルを含める

mappings ファイルにほかのファイルをインクルードすることができます。次の形式の行を使用します。

これによって、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 の不定発生に一致します。
$[ c₁ c₂ ... c_n ]%	文字 c₁、c₂、または c_n の発生の 1 つに一致します。
$[ c₁ c₂ ... c_n ]*	文字 c₁、c₂、または c_n の不定発生に一致します。
$[ c₁ -c_n ]%	c₁ から c_n までの文字のいずれか 1 つに一致します。
$[ c₁ -c_n ]*	c₁ から c_n までの文字の不定発生に一致します。
$< IPv4>	ビットを無視して、IPv4 アドレスに一致します。
$(IPv4)	プレフィックスビットを維持した状態で、IPv4 アドレスに一致します。
${IPv6}	1 組の IPv6 アドレスに一致します。

グロブ内、つまり $[...] 内では、円記号 (¥) は引用符となります。実際のハイフン (-) または右角括弧 (]) をグロブ内で表すには、ハイフンまたは右角括弧に円記号を付ける必要があります。

パターン内のその他の文字はすべて、文字として使用されます。特に、一重引用符や二重引用符、および括弧は、マッピングパターンやテンプレートにおいて特殊な意味を持たず、通常の文字とみなされます。このため、不正なアドレスや部分的なアドレスに対応するエントリの書き出しが簡単になります。

複数の修飾子、または修飾子および後照合を指定するには、構文にドル記号を 1 つだけ使用します。たとえば、最初のワイルドカードを、後照合そのものを保存せずに後照合するには、$@$0 ではなく $@0 を使用します。

マッピングパターンのテスト、特にパターン内のワイルドカードの動作のテストを行うには、imsimta test -mapping ユーティリティを使用できます。

アスタリスクのワイルドカードは、パターンを左から右へスキャンすることにより、一致する対象を最大化します。たとえば、文字列 a/b/c をパターン */* と比較する場合、左のアスタリスクがa/bに一致し、右のアスタリスクが残りの c に一致します。

$_ 修飾子は、ワイルドカードによる照合を最小にするため、パターンの左から右に向かって、もっとも可能性の少ない一致がその一致とみなされます。たとえば、文字列 a/b/c をパターン $_*/$_* と比較した場合、左の $_* は a と、右の $_* は b/c と一致します。

IP の照合

IPv4 プレフィックスの照合では、IP アドレス、またはサブネットを指定し、そのあとにオプションとして、照合比較の際に有効となるスラッシュとプレフィックスのビット数を続けます。たとえば、次の例は 123.45.67.0 サブネット内にあるものに一致します。

IPv4 照合でビットを無視する場合は、IP アドレスまたはサブネットを指定し、そのあとにオプションとしてスラッシュを付け、照合を確認する際に無視するビット数を続けます。たとえば、次の例は 123.45.67.0 サブネット内にあるものに一致します。

次の例は、123.45.67.4 から 123.45.67.7 の範囲内にあるものに一致します。

マッピングエントリのテンプレート

指定したエントリのパターン比較に失敗した場合は、何の動作も行われず、次のエントリのスキャンへ移行します。比較が成功した場合は、エントリの右側の部分がテンプレートとして使用され、出力文字列が生成されます。このテンプレートによって、入力文字列がテンプレートの指示によって構成された出力文字列に置き換えられます。

テンプレート内のほとんどすべての文字が、そのまま出力文字列として生成されますが、ドル記号 ($) は例外です。

ドル記号の後ろにドル記号、スペース、またはタブが続く場合は、出力文字列にドル記号、スペース、またはタブが生成されます。これらの文字を出力文字列に挿入するには、引用符を付ける必要があります。

ドル記号に数字 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 はドメインに関連付けられた属性です。このドメインが存在して属性を有している場合、その初期値はマッピングの結果に代入されます。属性かドメインのどちらかが存在しない場合、マッピングエントリは失敗します。 attribute には、ドメイン 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 が続いている場合、これは、パターン内の n 番目のワイルドカードに一致するデータで置き換えられます。ワイルドカードには、0 から順に番号が付けられています。たとえば、次のエントリは入力文字列 PSI%A::B に一致し、その結果 b@a.psi.siroe.com という出力文字列を生成します。

また、入力文字列 PSI%1234::USER にも一致するので、出力文字列として USER@1234.psi.siroe.com が生成されます。入力文字列 PSIABC::DEF は、このエントリ内のパターンに一致しないため置換は行われません。つまり、このエントリから出力文字列は生成されません。

テキストの大文字小文字の制御 ($¥、$^、$_)

メタキャラクタ $¥ は後続のテキストを小文字に変換し、メタキャラクタ $^ は後続のテキストを大文字に変換します。また、メタキャラクタ $_ は、後続のテキストを元の大文字または小文字の状態で残します。たとえば、これらのメタキャラクタは、マッピングを使って大文字または小文字の区別が有効なアドレスを変更する際に役立ちます。

処理制御 ($C、$L、$R、$E)

メタキャラクタ $C、$L、$R、および $E は、マッピング処理を終了するかどうか、またいつ終了するかなど、マッピング処理に影響を与えます。これらのメタキャラクタには、次の効果があります。

マッピングテーブルのテンプレートは、左から右にスキャンされます。一般データベースの置換やランダム値で制御されるエントリなど、「成功」または「失敗」するエントリに $C、$L、または $R のフラグを設定するには、メタキャラクタ $C、$L、または $R をエントリの成功または失敗する部分の左側に配置します。これを行わないと、エントリの残りの部分が失敗した場合、フラグが表示されません。

特殊なフラグの確認

マッピングプローブの中には、特殊なフラグセットを持つものがあります。これらは設定可能なフラグであり、それらが存在するかどうかは $: および $; テストの一般的なマッピングテーブル機能を使用して確認されます。$:x はフラグ x が設定されている場合のみ、エントリを一致させます。$:x はフラグ x がクリアの場合にのみ、エントリを一致させます。特定のマッピングテーブルに適用される特殊なフラグについては、各マッピングテーブルの説明を参照してください (表 17-2 の $A、$T、$S、$F、および $D を参照)。

フラグチェックが成功するとエントリが成功して終了するが、フラグチェックが失敗するとマッピング処理を続行する必要があるという場合、エントリはフラグチェックの左側に $C メタキャラクタを配置し、フラグチェックの右側に $E フラグを配置する必要があります。

ランダムに成功または失敗するエントリ ($?x?)

マッピングテーブルのエントリにメタキャラクタ $?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 エラーメッセージが表示されます。

シーケンス番号の置換 ($#...#)

$#...# 置換は、MTA シーケンスファイルに保存されている値を増やし、その値をテンプレート内に入れます。たとえば、マッピングテーブルを使ってファイル名を生成するときなど、マッピングテーブルの出力に固有の修飾子があることが望ましい場合に、シーケンス番号付きの固有文字列を生成することができます。

必須の引数 seq-file-spec は、既存の MTA シーケンスファイルの完全なファイル指定です。オプションの引数 radix で出力するシーケンス値の基数を、width で出力する桁数を指定します。デフォルトの基数は 10 ですが、-36 ～ 36 の範囲内の基数も使用できます。たとえば、基数 36 では 0 ～ 9、A ～ Z の文字からなる値を使用することができます。デフォルトでは、シーケンス値は自然幅で出力されますが、大きな桁数を指定すると、桁数に合わせるために数値の左側に 0 が追加されます。桁数を明示的に指定する場合は、基数も明示的に指定する必要があります。

オプションの引数 m はモジュラスです。この 4 番目の引数が指定されている場合、挿入される値はファイル mod m から取得されたシーケンス番号です。デフォルトでは、モジュラスの処理を行わないようになっています。

上記にあるように、マッピングで参照される MTA シーケンスファイルはすでに存在するものでなければなりません。MTA シーケンスファイルを作成するには、以下のコマンドを使用します。

マッピングテーブルを使ってアクセスされるシーケンス番号ファイルは、誰でも読み取り可能でないと正常に操作できません。また、このようなシーケンス番号ファイルを使用するには、MTA ユーザーアカウント (imta_tailor ファイルで nobody として設定) を持つことが必要です。

LDAP クエリ URL の置換 $]...[

$]ldap-url[ の形式の置換は、特殊な方法で処理されます。ldap-url は LDAP クエリ URL として解釈され、LDAP クエリの結果が置換されます。ホストとポートが省略された標準の LDAP URL が使用されます。ホストとポートは、代わりに LDAP_HOST オプションと LDAP_PORT オプションで指定されます。LDAP URL は次のように指定する必要があります。

上記の角括弧 ([ と ]) は、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 は、以下の引数を伴った関数として呼び出されます。

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 (サイト提供の共有ライブラリイメージ) は、誰でも読み取り可能でなければなりません。

UTF-8 文字列の生成

一般的なマッピングテーブル機能で、Unicode 文字の値から UTF-8 文字列を生成できます。次の形式の Unicode メタキャラクタ列があるとします。

この場合、A0A0、20 および A1A1 の位置にある文字を含む UTF-8 文字列が生成されます。

その他の MTA 設定ファイル

imta.cnf ファイルのほかにも、Messaging Server には MTA サービスの設定に役立ついくつかの設定ファイルがあります。表 10-5 にファイルの一覧を示します。imta.cnf、mappings、aliases、option.dat などの MTA 設定ファイルを変更した場合は、必ず設定をコンパイルしなおす必要があります (『Sun Java System Messaging Server Administration Reference』の imsimta refresh コマンドを参照)。

表 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 (SMTP) チャネルオプションファイル

TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。チャネルオプションファイルは MTA 設定ディレクトリに保存し、x_option という名前を付けてください。x はチャネル名です。たとえば、msg_svr_base/config/imta/tcp_local_option のようになります。詳細については、「SMTP チャネルオプションを設定する」を参照してください。すべてのチャネルオプションキーワードおよび構文の詳細については、『Messaging Server Reference Manual』を参照してください。

変換ファイル

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

このファイルの構文の詳細については、「変換チャネル」を参照してください。

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

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

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

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

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

以下に、ディスパッチャ設定ファイル (dispatcher.cnf) の例を示します。

このファイルのパラメータの詳細については、『Messaging Server Reference Manual』を参照してください。

マッピングファイル

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

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

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

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

mappings ファイルの変更後は、MTA を再起動するか、imsimta reload コマンドを実行してください。

オプションファイル

オプションファイル option.dat はグローバル MTA オプションを指定します。これはチャネル固有のオプションとは逆のオプションです。

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

option.dat では、#、!、または ; で始まる行はコメント行として処理されます。先行する行の末尾に、続きがあることを示す ¥ がある場合でも同様です。配信オプションなど、これらの文字を含む長いオプションの場合には注意が必要です。

配信オプションの場合は、自然なレイアウトは # または ! で始まる継続行になりますが、確実で整然とした回避方法はあります。

オプションファイルの構文の詳細については、『Messaging Server Reference Manual』を参照してください。

テイラーファイル

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

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

このファイルの詳細については、『Messaging Server Reference Manual』を参照してください。

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


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

ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。ジョブコントローラの概念とチャネルキーワードの設定については、「ジョブコントローラ」、「チャネル実行ジョブの処理プール」、および「サービスジョブの制限」を参照してください。

ジョブコントローラファイル job_controller.cnf では、次のチャネル処理情報を指定します。

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

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

デフォルトのプール設定に関連付けられたパラメータを変更したり、プールを追加する場合は、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 である新しいタイプのプールを作成する必要があります。

一方、宛先システムで並行処理が可能な場合は、ジョブ範囲の値を増やすことができます。

コード例 10-1 に、ジョブコントローラ設定ファイルの例を示します。表 10-6 に、使用可能なオプションを示します。

以下に、上の例の主な項目 (太字の丸括弧付きの数字がある部分) について説明します。

追加プールの例

ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。ジョブ範囲は、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_* チャネルを設定する場合を考えてみます。

新規チャネルごとに 10 個の tcp_smtp_client 処理を追加するには、job_controller.cnf ファイルに次のように追加します。

プールの詳細については、「チャネル実行ジョブの処理プール」を参照してください。ジョブコントローラファイルの構文の詳細については、『Messaging Server Reference Manual』を参照してください。

表 10-6 ジョブコントローラ設定ファイルのオプション
オプション	説明
一般的なオプション	説明
INTERFACE_ADDRESS=adapter	ジョブコントローラがバインドする IP アドレスインタフェースを指定します。値 (アダプタ) には、ANY、ALL、LOCALHOST、または IP アドレスのいずれかを指定できます。デフォルトで、ジョブコントローラはすべてのアドレスにバインドします (ALL または ANY の指定に相当)。INTERFACE_ADDRESS=LOCALHOST を指定すると、ジョブコントローラは、ローカルマシンからの接続しか受け付けられません。これは、ジョブコントローラではマシン間の操作はサポートされていないため、通常の操作には影響がありません。ただし、HA エージェントがジョブコントローラの応答をチェックする HA 環境では、不適切かもしれません。Messaging Server の実行しているマシンが HA 環境にあり、「内部ネットワーク」アダプタと「外部ネットワーク」アダプタを持っている場合で、大きなポート番号への接続をブロックするファイアウォール機能の信頼性が低い場合は、「内部ネットワーク」アダプタの IP アドレスを指定することをお勧めします。
MAX_MESSAGES=integer	ジョブコントローラは、メモリ内構造でメッセージに関する情報を保持します。バックログが大きくなった場合は、この構造のサイズを制限する必要があります。バックログのメッセージ数がこのパラメータ値を超えると、その後のメッセージに関する情報はメモリに保存されません。メールメッセージは常にディスクに書き込まれるため、失われることはありませんが、ジョブコントローラが認識するメッセージ数がこの値の半分になるまで配信されません。この時点では、ジョブコントローラが imsimta cache -sync コマンドを模倣してプールディレクトリをスキャンします。デフォルトは 100000 です。
SECRET=file_spec	ジョブコントローラに送信される要求を保護するための共有の秘密情報。
SYNCH_TIME=time_spec	ジョブコントローラは定期的にディスク上のプールファイルをスキャンしてファイルが不足していないかどうかをチェックします。デフォルトでは 4 時間ごとにスキャンされます (ジョブコントローラが起動してから 4 時間ごと)。time_spec のフォーマットは、HH:MM/hh:mm または /hh:mm。hh.mm 変数は、イベントの間隔を時間数 (h) と分数 (m) で示します。HH:MM 変数は、1 日の中でイベントが最初に発生する時間です。たとえば 15:45/7:15 と指定すると、15:45 にイベントが開始し、その後 7 時間 15 分ごとにイベントが実行されます。
TCP_PORT=integer	ジョブコントローラが要求パケットをリッスンする TCP ポートを指定します。このオプションは、デフォルト値がシステム内の別の TCP アプリケーションと競合しないかぎり変更しないでください。このオプションを変更する必要がある場合は、対応する MTA テイラーファイル (msg_svr_base/config/imta_tailor) の IMTA_JBC_SERVICE オプションも同じように変更する必要があります。TCP_PORT オプションはグローバルに適用され、[CHANNEL] セクションまたは [POOL] セクション内にある場合は無視されます。
プールオプション	説明
JOB_LIMIT=integer	プールが同時に使用できるプロセスの最大数を指定します。JOB_LIMIT は各プールに個別に適用されます。ジョブの最大合計数は、すべてのプールの JOB_LIMIT パラメータの合計数です。この値をセクションの外に設定すると、JOB_LIMIT が指定されていない [POOL] セクションにより、デフォルトとして使用されます。このオプションは、[CHANNEL] セクション内では無視されます。
チャネルオプション	説明
MASTER_COMMAND=file_spec	チャネルを実行し、そのチャネルからメッセージを取り出すために、ジョブコントローラによって作成された UNIX システムプロセスが実行するコマンドのフルパスを指定します。この値をセクションの外に設定すると、MASTER_COMMAND が指定されていない [CHANNEL] セクションにより、デフォルトとして使用されます。[POOL] セクション内では、このオプションが無視されます。
MAX_LIFE_AGE=integer	チャネルマスタージョブに対する最大のライフタイムを秒数で指定します。このパラメータがチャネルに指定されていない場合は、グローバルなデフォルト値が使用されます。デフォルト値が指定されていない場合は、1800 (30 分) が使用されます。
MAX_LIFE_CONNS=integer	マスターチャネルの寿命は、最長使用期間パラメータのほか、メッセージがあるかどうかをジョブコントローラに確認する回数によっても制限されます。このパラメータがチャネルに指定されていない場合は、グローバルなデフォルト値が使用されます。デフォルト値が指定されていない場合は 300 が使用されます。
SLAVE_COMMAND=file_spec	チャネルを実行し、そのチャネルに入れるメッセージをポーリングするために、ジョブコントローラによって作成された UNIX システムプロセスが実行するコマンドのフルパスを指定します。ほとんどの場合、MTA チャネルには SLAVE_COMMAND がありません。その場合は、予約値である NULL を指定します。この値をセクションの外に設定すると、SLAVE_COMMAND が指定されていない [CHANNEL] セクションにより、デフォルトとして使用されます。[POOL] セクション内では、このオプションが無視されます。

エイリアス

MTA には、ローカルシステムに関連付けられ、実際のユーザーと必ずしも対応しないメールボックス名をサポートする機能である「エイリアス」があります。エイリアスは、メーリングリストの作成、メールの転送、およびユーザーの別名の設定に役立ちます。エイリアス解決の処理方法については、「$V メタキャラクタ」を参照してください。

aliases ファイルまたはエイリアスデータベースで定義されている旧形式のメーリングリストは、非定位置パラメータ [capture] をとるようになりました。[capture] パラメータが使用されている場合、このパラメータで指定するのは、LDAP でユーザーまたはグループに適用される LDAP_CAPTURE 属性で指定される取得アドレスと同じセマンティクスの取得アドレスです。

エイリアスデータベース

エイリアスデータベースの使用はお勧めしません。代わりに aliases ファイルを使用してください。このファイルは imsimta reload コマンドを使用して動的に再読み込みできます。

MTA はディレクトリ内の情報を使用し、エイリアスデータベースを作成します。このエイリアスデータベースは、標準のエイリアスファイルが参照されるたびに参照されます。ただし、エイリアスデータベースのエントリが調べられるのは、標準のエイリアスファイルが使用される前です。すなわち、デーベースは、エイリアスファイルが使用される前に実行される、一種のアドレス書き換え機能として動作します。

エイリアスファイル


注	データベースの形式は固有のものです。データベースを直接編集しないでください。必要な変更はすべてディレクトリで行なってください。

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

このファイルでは、一行に入力できる文字数が 1024 バイトに制限されています。¥ (円記号) を継続文字として使用すれば、1 つの論理行を複数の行に分割することができます。

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


注	Messaging Server には、アドレスリバースデータベースや特殊化されたマッピングテーブルなど、アドレス操作のためのその他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換えルールを使用するようにしてください。第 11 章「書き換えルールの設定」を参照してください。

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

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

インクルードファイルの内容は、aliases ファイル内の参照ポイントに挿入されます。インクルードファイルへの参照をそのファイルの実際の内容に置き換えることによっても、同様の効果が得られます。インクルードファイルの形式は、プライマリ aliases ファイルとまったく同じになります。さらに、インクルードファイルにほかのファイルを含めることも可能です。インクルードファイルは、3 階層までネストすることができます。

コマンド行ユーティリティ

Messaging Server には、MTA に関する各種保守、テスト、管理などのタスクを実行するためのコマンド行ユーティリティが備わっています。たとえば、MTA の設定、エイリアス、マッピング、セキュリティ、システム全体のフィルタファイル、およびオプションファイルをコンパイルするには、imsimta cnbuild コマンドを使用します。MTA コマンド行ユーティリティの詳細については、『Messaging Server Reference Manual』を参照してください。

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

ログファイル

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

内部形式から公的な形式にアドレスを変換するには

アドレスは、アドレスリバースデータベース (「リバースデータベース」とも呼ばれる) と 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 マッピングテーブルエントリ (すべてのチャネルに適用されるエントリ) の形式は、以下のとおりです。フラグは、新しいアドレスの前または後ろに指定できます。

チャネル固有のエントリ (特定のチャネルから渡されるメッセージ上でのみ実行されるマッピング) の形式は、次のとおりです。チャネル固有のエントリを機能させるには、option.dat で use_reverse_database を 13 に設定する必要があります。

表 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 は、アドレスリバースが適用されることを指定します。詳細は、『Sun Java System Messaging Server Administration Reference』を参照してください。

USE_REVERSE_DATABASE は、MTA が置換アドレスとしてアドレスリバースデータベースと REVERSE マッピングを使用するかどうかを制御します。値 0 は、アドレスリバースがどのチャネルでも使われないことを示します。値 5 (デフォルト) は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけではなく、すべてのアドレスに適用されることを指定します。値 13 は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけではなく、reverse チャネルキーワードを含むアドレスに適用されることを指定します。また、USE_REVERSE_DATABASE オプションのビット値を設定して、アドレスリバース操作の単位を指定することもできます。詳細は、『Sun Java System Messaging Server Administration Reference』を参照してください。

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 マッピングは、アドレスリバースデータベースとともに使用できます。

この例では、name@anyhost.siroe.com という形式のアドレスが name@siroe.com に変更されています。$D メタキャラクタでは、アドレスリバースデータベースが参照されるようになります。アドレスリバースデータベースには、以下の形式のエントリが含まれています。

チャネル固有のリバースマッピングの例

デフォルトでは、ルーティングの範囲がメールサーバードメインに設定されている場合に、アドレスリバースデータベースが使用されます。チャネル固有の REVERSE マッピングテーブルエントリの例を以下に示します。

このエントリは、MTA に対して、ソースチャネル tcp_* から宛先チャネル tcp_local に送信されるすべてのメールのアドレス形式を、binky@macho.siroe.com から Rebecca.Woods@siroe.com に変更するように指示します。

正引き検索テーブルと FORWARD アドレスのマッピング

アドレスリバースは、エンベロープ To: アドレスには適用されません。これは、エンベロープ To: アドレスは、メッセージがメールシステムで処理される過程で次々と書き換えられ、変更されるからです。ルーティングの目的は、エンベロープ To: アドレスをシステムまたはメールボックス固有のフォーマットに変換していくことです。アドレスリバースの正規化機能は、エンベロープ To: アドレスには不適切です。

MTA では豊富な機能が使用でき、エンベロープ To: アドレスの置換が実行できます。エイリアスファイル、エイリアスデータベース、および一般検索テーブルによって、この機能が提供されます。

MTA では、正引き検索テーブルや FORWARD マッピングも提供されており、パターンに基づく転送、ソース固有の転送、アドレスの自動登録などの特殊な転送に使用されます。ただし、正引き検索テーブルや FORWARD マッピングは、特殊なアドレス転送のための機能であることに注意してください。ほとんどのアドレス転送には、MTA のほかの転送機構を使用したほうがパフォーマンスは向上します。

エンベロープ To: アドレス用のさまざまな置換機構では、リバース検索テーブルと同等の機能が提供されますが、リバースマッピングと同等の機能は現時点ではありません。エンベロープ To: アドレス用のマッピング機能が必要とされる状況が発生することもあります。

FORWARD マッピングテーブル

FORWARD マッピングテーブルでは、パターンに基づいた転送を行うための機能が提供されます。また、ソース固有の転送を行うための機構も提供されます。マッピングファイル内に FORWARD マッピングテーブルがある場合、それは各エンベロープ To: アドレスに適用されます。このマッピングテーブルがない場合や一致するエントリがマッピングテーブルにない場合、変更は行われません。

アドレスに一致するマッピングエントリがある場合は、マッピングの結果がテストされます。エントリが $Y を指定している場合は、エンベロープ To: アドレスは結果の文字列で置き換えられ、エントリが $N を指定している場合は、マッピングの結果が破棄されます。このほかのフラグの一覧は、表 10-8 を参照してください。

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 アドレスを生成すると仮定します。

これらのアドレスは完全に正しいものですが、RFC 822 の構文ルールに完全準拠していないほかのメーラー (たとえば、引用符で囲まれたアドレスを適切に処理しないメーラー) では混乱が生じることがあります。そのため、引用を必要としないアドレス形式のほうが、多くのメーラーで機能する傾向があります。次はその一例です。

上記の例では、サンプルのマッピングテーブルの目的には 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 relaod コマンドを使用すると、これをアクティブな MTA プロセスに再読み込みできます。

正引きデータベースは、crdb ユーティリティを使用してソーステキストファイルから作成された MTA crdb データベースです。デフォルトでは、ソーステキストファイルは次のような形式になっています。

user1@domain1 changedmailbox1@changeddomain1
user2@domain2 changedmailbox@changeddomain2

ただし、USE_FORWARD_DATABASE オプションでビット 3 が設定されていてソース固有の正引きデータベースの使用が有効になっている場合は、ソーステキストファイルの形式は次のようになります。

この例では To: アドレス helen@red.com が "helen of troy"@siore.com にマッピングされます (メッセージの差出人が bob@blue.com で、キューに入れられるチャネルが tcp_limted であると仮定した場合)。

配信ステータス通知メッセージを制御する

配信ステータス通知、すなわちステータス通知は、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 つ目のディレクトリには特殊な不特定多数宛メールに対する通知を保存することができます。

ステータス通知メッセージの形式と構造は次のとおりです。

表 10-9 通知メッセージの置換シーケンス
置換	定義
%H	メッセージのヘッダーに展開します。
%C	メッセージがキューに入っていた時間の単位¹に展開します。
%L	返送されるまでメッセージがキューに置かれていた時間の単位¹に展開します。
%F	メッセージがキュー内に留まることができる時間の単位¹に展開します。
%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 バイトの文字セットを使用する場合は、意図しない % 記号を確認する必要がある)。
¹単位は、時間または日 (デフォルト) で、MTA オプションファイルの RETURN_UNITS オプションで定義されます。

配信ステータス通知メッセージをカスタマイズおよびローカライズするには

配信ステータス通知メッセージをローカライズして、言語別に異なるユーザーにメッセージを返すことができます。たとえば、フランス語を使用しているユーザーにフランス語の通知を返すことができます。

ステータス通知メッセージのローカライズまたはカスタマイズは、次の 2 つの手順で行います。

NOTIFICATION_LANGUAGE マッピングテーブル (msg_svr_base/config/mappings) では、送信元メッセージ (通知が送信される原因であるメッセージ) の属性 (言語、国、ドメイン、アドレスなど) に応じて使用される、ローカライズまたはカスタマイズされた通知メッセージファイルのセットを指定します。

元の差出人のメッセージがパースされ、ステータス通知の種類、ソースチャネル、優先言語、返信アドレス、および 1 人目の受取人が決定されます。テーブルの構築方法によって異なりますが、通知ファイルのセットは 1 つ以上の属性によって選択されます。

NOTIFICATION_LANGUAGE マッピングテーブルの形式は次のとおりです。

dsn-type-list は、配信ステータス通知の種類のコンマ区切りリストです。複数の種類を指定する場合はコンマで区切ります。スペースでは区切りません。スペースを使用すると、マッピングテーブルエントリのパターンが終了します。次のような種類があります。

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 つまたは複数のスペースで始まり、エントリ間には空白行はありません。

生成された通知の国際化

配信ステータス通知および MDN (message disposition notification) の両方に、2 つのオプションファイルが使用できます。これらは、生成された通知をより柔軟に国際化するためのものです。次の 2 種類があります。

これらのファイルに使用できるオプションを、表 10-10 に示します。

表 10-10 配信ステータス通知および MDN (message disposition notification) のオプション
オプション	説明
DAY (DSN)	RETURN_UNITS=0 (デフォルト) が設定されている場合に、%U または %u と置き換えて挿入される文字。%U と %u とは区別されません (デフォルトでは、英語の「Day」と「day」が区別して置換される)。
DIAGNOSTIC_CODE (DSN)	DSN の最初の受取人ごとのセクションの作成に使用した「Diagnostic code:」文字のオーバーライド。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。
HOUR (DSN)	RETURN_UNITS=1 が設定されている場合に、%U または %u と置き換えて挿入される文字。%U と %u とは区別されません (デフォルトでは、英語の「Hour」と「hour」が区別して置換される)。
n.n.n (DSN)	DSN の受取人ごとのセクションの作成時に、受取人単位のステータスの数字と一致するオプション名があるかどうかがチェックされます。一致するものがある場合、対応する文字が DSN に挿入されます。また、上で指定された REASON オプションの結果が長さ 0 の文字列である場合、REASON フィールドには文字は挿入されません。
ORIGINAL_ADDRESS (DSN)	DSN の最初の受取人ごとのセクションの作成に使用した「Original address:」文字のオーバーライド。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。
REASON (DSN)	DSN の最初の受取人ごとのセクションの作成に使用した「Reason:」文字のオーバーライド。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。
RECIPIENT_ADDRESS (DSN)	DSN の最初の受取人ごとのセクションの作成に使用した「Recipient address:」文字のオーバーライド。このフィールドには、DSN の最初の部分で使用したのと同じ文字セットを指定する必要があります。
RETURN_PERSONAL (DSN および MDN)	From: フィールドと一緒に使用される個人名のフィールドのオーバーライド。このフィールドは RFC 2047 エンコードされている必要があります。このオプションを指定しない場合、RETURN_PERSONAL MTA オプションで設定された値が使用されます。
SUBJECT (DSN および MDN)	Subject: フィールドのオーバーライド。この値は、通知に個々の件名のフィールドが含まれない場合にのみ使用されます。このフィールドは RFC 2047 エンコードされている必要があります。このオプションが使用されず、通知に件名が含まれない場合は、適切な件名が作成されます。
TEXT_CHARSET (MDN)	MDN の最初の部分および件名が変換されるべき文字セット。デフォルトでは、変換を行わないようになっています。

ステータス通知メッセージの追加機能

ステータス通知メッセージの設定に必要な手順は前の節で説明したとおりです。ここでは、追加機能について説明します。

サイズの大きいメッセージの内容が戻るのをブロックするには

通常、メッセージがバウンスまたはブロックされる場合は、差出人とローカルドメインのポストマスターに通知メッセージでメッセージの内容が戻されます。サイズの大きいメッセージが何通もそのまま戻されると、リソースに負担がかかります。一定のサイズを超えるメッセージの内容が戻るのをブロックするには、MTA オプションファイルで CONTENT_RETURN_BLOCK_LIMIT オプションを設定します。

ステータス通知メッセージのヘッダーから US-ASCII 以外の文字を削除するには

インターネットメッセージヘッダーの本来の形式では US-ASCII 以外の文字は使用できません。メッセージヘッダーに使用されている US-ASCII 以外の文字は「MIME ヘッダーエンコーディング」でエンコードされたものです。MIME ヘッダーエンコーディングについては RFC 2047 に記述されています。したがって、電子メールメッセージの「件名」行は、実際には次のように表されています。

電子メールクライアントは、ヘッダーを表示する際にエンコーディングを削除する必要があります。

%H テンプレートは通知メッセージの本文にヘッダーをコピーするので、通常はエンコードされたヘッダーが表示されます。ただし、Messaging Server では、件名の文字セット (この場合は big5) が return_prefix.txt の Content-Type ヘッダー文字セットパラメータにある文字セットと一致する場合は、エンコーディングが削除されます。一致しない場合は、Messaging Server のエンコーディングはそのまま残ります。

通知メッセージの配信間隔を設定するには

配信不能メッセージは、指定したチャネルキューに一定期間保存したあとで差出人に戻されます。また、Messaging Server が配信を試みている期間に、一連のステータスメッセージや警告メッセージを差出人に戻すこともできます。その期間とメッセージの配信間隔は、notices、nonurgentnotices、normalnotices、urgentnotices のキーワードで指定できます。

この例では、すべてのメッセージについて、一時的な配信不能のステータス通知メッセージが 1 日目と 2 日目に送信されます。メッセージが 3 日たってもまだ配信されない場合は、差出人に返されます。

この例では、優先度の高いメッセージについて、一時的な配信不能の通知が 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 が使用されます。

ステータス通知メッセージに代替アドレスを含めるには

MTA が通知メッセージ (バウンスメッセージ、配信確認メッセージなど) を生成するとき、元の形式の受取人アドレスと、変更された最終的な形式の受取人アドレスの両方が MTA に提示される場合があります。元の形式の方が通知メッセージの受取人 (通知メッセージの場合は元のメッセージの差出人) によって認識される可能性が高いため、MTA は、常に元の形式を通知メッセージに含めます。

includefinal および suppressfinal チャネルキーワードは、MTA が最終的な形式のアドレスを含めるかどうかを制御するためのものです。外部に対して内部のメールボックス名を隠しているサイトでは、最終的な形式のアドレスを含めないことをお勧めします。このようなサイトでは、元の形式の外部用アドレスのみをステータス通知メッセージに含めるほうが適しています。デフォルトは includefinal であり、最終的な形式の受取人アドレスが含められます。suppressfinal を使用すると、元の形式のアドレスが存在する場合、MTA は最終的な形式のアドレスをステータス通知メッセージに含めません。

useintermediate キーワードでは、リストの展開後、ユーザーメールボックス名を生成するまでの間に作成された中間形式のアドレスを使用します。この情報を入手できない場合は、最終形式が使用されます。

ポストマスターへのステータス通知メッセージを送信、ブロック、指定するには

デフォルトでは、Errors-to: ヘッダー行やエンベロープ From: アドレスが空白であるために警告をまったく送信できない場合を除いて、警告のステータス通知メッセージのコピーがポストマスターに送信されます。ポストマスターへの通知メッセージの配信の詳細については、以後の節および表 10-11 で説明する多数のチャネルキーワードで制御できます。

返送された配信不能メッセージ

長期間にわたってサービスが支障をきたしている場合や、アドレスが不正確な場合は、チャネルプログラムがメッセージを配信できないことがあります。このような場合、MTA チャネルプログラムは、配信不能の理由を説明する文と一緒にメッセージを差出人に返送します。さらに、配信できないメッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります (表 10-11 を参照)。

警告メッセージ

メッセージの返送に加えて、MTA では、配信できないメッセージに関する詳細な情報を記載した警告を送信することができます。通常、この警告メッセージは notices チャネルキーワードが指定するタイムアウトに基づいて送られますが、配信試行に失敗したときに送られることもあります。警告には、問題点の説明と配信試行を継続する時間枠が記載されます。また、多くの場合、該当するメッセージのヘッダーと最初の数行も含まれます。

さらに、警告メッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります。キーワード: warnpost、copywarnpost、errwarnpost、nowarnpost キーワードは、警告メッセージを postmaster に送ることを制御するために使用されます (表 10-11 を参照)。

空白のエンベロープ返信アドレス

returnenvelope キーワードは 1 つの整数値をとり、これはビットフラグのセットとして解釈されます。ビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープアドレスを空白にするか、あるいはローカルポストマスターのアドレスを入れるかを制御します。このビットを設定した場合は、ローカルポストマスターのアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになります。

ビット 1 (値 = 2) は、MTA がすべての空白エンベロープアドレスをローカルポストマスターのアドレスに置き換えるかどうかを制御します。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用されます。

ビット 2 (値 = 4) は構文的に不正な返信アドレスを禁止します。

ポストマスター返送メッセージの内容

チャネルプログラムまたは定期的なメッセージ返送ジョブがメッセージをポストマスターと差出人の両方に返送する場合は、ポストマスターへのコピーには、メッセージ全体を含めることも、ヘッダーだけを含めることもできます。ポストマスターへのコピーをヘッダーに限定することで、ユーザーメールのプライバシーのレベルを高めることができます。ただし、ポストマスターやシステム管理者は一般に 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 ポストマスターと差出人に送信される通知メッセージのキーワード
キーワード	説明
返送メッセージの内容	通知のアドレスの指定
notices	通知の送信とメッセージの返送を行うまでの時間を指定します。
nonurgentnotices	優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
normalnotices	優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
urgentnotices	優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
返送メッセージ	配信不能な返送メッセージの処理方法。
sendpost	配信不能メッセージのコピーをすべてポストマスターに送信します。
copysendpost	配信不能メッセージの差出人アドレスが空白の場合を除き、配信不能通知のコピーをポストマスターに送信します。この場合、ポストマスターは、バウンスメッセージや通知メッセージ以外のすべての配信不能メッセージのコピーを受け取ります。
errsendpost	通知を差出人に返すことができない場合に、配信不能通知のコピーをポストマスターに送信します。nosendpost が指定されている場合は、配信不能メッセージがポストマスターに送信されることはありません。
nosendpost	配信不能メッセージのコピーをポストマスターには一切送信しません。
警告メッセージ	警告メッセージの処理方法。
warnpost	警告メッセージのコピーをすべてポストマスターに送信します。デフォルトでは、Warnings-to: ヘッダーやエンベロープ From: アドレスが空白であるために警告をまったく送信できない場合を除いて、警告のコピーがポストマスターに送信されます。
copywarnpost	未配信メッセージの差出人アドレスが空白になっている場合を除き、警告メッセージのコピーがポストマスターに送信されます。
errwarnpost	通知を差出人に返すことができない場合に、警告メッセージのコピーをポストマスターに送信します。
nowarnpost	警告メッセージのコピーをポストマスターには一切送信しません。
返送メッセージの内容	ポストマスターにメッセージの内容をすべて送信するか、ヘッダーだけを送信するかの指定。
postheadonly	ポストマスターにヘッダーだけを返送します。ポストマスターへのコピーをヘッダーに限定することで、ユーザーメールのプライバシーのレベルを高めることができます。ただし、ポストマスターやシステム管理者は root システム権限を使用してメッセージの内容を読むことができるため、このキーワードを選択してもメッセージのセキュリティを完全に保証することにはなりません。
postheadbody	ヘッダーとメッセージの内容の両方を返送します。
返送メッセージの内容	通知のアドレスの指定
includefinal	配信通知の中に最終的な形式のアドレス (受取人アドレス) を含めます。
returnenvelope	空白のエンベロープ返信アドレスの使用を制御します。returnenvelope キーワードは 1 つの整数値をとり、これはビットフラグのセットとして解釈されます。ビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープアドレスを空白にするか、あるいはローカルポストマスターのアドレスを入れるかを制御します。このビットを設定した場合は、ローカルポストマスターのアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになります。ビット 1 (値 = 2) は、MTA がすべての空白エンベロープアドレスをローカルポストマスターのアドレスに置き換えるかどうかを制御します。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用されます。ビット 2 (値 = 4) は構文的に不正な返信アドレスを禁止します。ビット 3 (値 = 8) は mailfromdnsverify キーワードと同じです。
suppressfinal	オリジナルの形式のアドレスが存在する場合に、通知メッセージに最終アドレス形式を表示しないようにします。
useintermediate	リストの展開後、ユーザーメールボックス名を生成するまでの間に作成された中間形式のアドレスを使用します。この情報を入手できない場合は、最終形式が使用されます。
返送メッセージの内容	通知のアドレスの指定
aliaspostmaster	正式なチャネル名でのユーザー名ポストマスター宛のメッセージは postmaster@local-host にリダイレクトされます。local-host には、ローカルホスト名 (ローカルチャネルの名前) が入ります。
returnaddress	ローカルポストマスターの返信アドレスを設定します。
noreturnaddress	ポストマスターアドレス名に RETURN_ADDRESS オプション値を使用します。
returnpersonal	ローカルのポストマスターに対する個人名を設定します。
noreturnpersonal	ポストマスター個人名に RETURN_PERSONAL オプション値を使用します。

MDN (Message Disposition Notifications) を制御する

MDN (Message Disposition Notification) は、MTA によって差出人またはポストマスター (あるいはその両方) に送信される電子メールレポートであり、メッセージの配信状態を報告します。たとえば、メッセージが Sieve フィルタによって拒否された場合、差出人に MDN が送信されます。MDN は、開封確認、確認通知、受信通知、配信確認とも呼ばれます。Sieve スクリプト言語は一般に、メッセージフィルタリングおよび不在返信メッセージに使用されます。

MDN メッセージをカスタマイズおよびローカライズするには

マッピング (DISPOSITION_LANGUAGE マッピングと呼ばれる) は、ステータス通知を国際化するために使用される notification_language マッピングテーブル (コード例 10-2) と同等です。

ただし、このマッピングに対する MDN のプローブは、次の形式をとります。

type はディスポジションタイプで、次のいずれかを指定できます。displayed、dispatched、processed、deleted、denied、または failed。

modifiers は、ディスポジション修飾子をコンマで区切って示したリストです。現在指定できるのは次のとおりです。error、warning、superseded、および expired。

header-language は言語で、次のいずれかのオプションで指定します。accept-language、preferred-language、または x-accept-language (これらオプションのうち最初に指定されているものが MTA で使用される)。

ディスポジションマッピングの結果には、2 ～ 3 個の情報が含まれます。各情報は縦棒 (|) で区切られています。最初の情報は、開封通知のテンプレートファイルが置かれているディレクトリです。2 番目の情報は、ディスポジションテキストだけに適用される文字セットです。一部のディスポジション (特に自動返信エコーまたは不在時の Sieve 処理に対する :mime パラメータの使用によって生成されたディスポジション) では、テンプレートファイルが使用されず、その結果、テンプレートファイルから文字セットを継承することができないため、この情報は必要です。3 番目の情報は、通知の件名行のオーバーライドです。この情報は、マッピングによって $T フラグも設定されている場合にのみ使用されます。

以下の追加テンプレートファイルは、MDN を構築するときに使用されます。

disposition_deleted.txt disposition_failed.txt
disposition_denied.txt disposition_prefix.txt
disposition_dispatched.txt disposition_processed.txt
disposition_displayed.txt disposition_suffix.txt
disposition_option.opt

これらのテンプレートファイルの使用は、ステータス通知メッセージの場合のさまざまな return_*.txt ファイルの使用に相当します。*.txt ファイルのメッセージテキストは、1 行につき 78 文字以内である必要があります。

前へ目次索引次へ
Sun Java System Messaging Server 6 2005Q1 管理ガイド


注	チャネル固有のリバースマッピングを有効にするは、option.dat の USE_REVERSE_DATABASE オプションを 13 に設定する必要があります (デフォルト =5)。

フラグ	説明
$D	出力文字列を使って書き換えプロセスを再び実行します
$G	正引き検索テーブルの使用が有効になっている場合に、出力文字列を使って正引き検索テーブルをスキャンします
$H	正引き検索テーブルまたは FORWARD マッピングの検索続行を無効にします
$I	.HELD ファイルとしてメッセージを保留します
$N	アドレスは変更されません
$Y	出力文字列を新規アドレスとして使用します


注	このリリースには、フランス語、ドイツ語、およびスペイン語のサンプルファイルが含まれています。これらのファイルは、ユーザーのそれぞれのニーズに合わせて変更することができます。日本語などの 2 バイト文字の場合は、日本語でテキストを作成してから、そのテキストを ASCII 形式に変換してから、% 文字がないかどうかをチェックしてください。不測の % 文字が存在する場合は、%% で置き換えてください。


注	デフォルトの mappings.locale ファイルはインストールによって組み込まれます。これは、通知言語マッピングを有効にするために mappings ファイルに組み込まれます。通知言語マッピングを無効にするには、インクルード行を以下のようにコメントアウトします。 ! <IMTA_TABLE: mappings.locale ファイル内のコメントを読み、必要に応じて変更してください。


注	RFC 1123 では空白アドレスの使用が義務付けられています。ただし、一部のシステムでは空白エンベロープ From: アドレスを適切に処理できないため、このオプションが必要な場合があります。