| 前へ 目次 索引 次へ | |
| iPlanet Messaging Server 5.0 リファレンス マニュアル | |
第 5 章 MTA の設定
この章には、以下の項目があります。
imta.cnf ファイル
MTA 設定ファイル
このセクションでは、MTA 設定ファイルの構造とレイアウトについて説明します。設定の変更の中には、第 2 章 「Message Transfer Agent のコマンド ライン ユーティリティ」で説明しているように、コマンド ラインのインターフェイスを使って行うことができるものもあります。コマンド ラインで変更できないものは、設定ファイルを編集して行うことができます。設定ファイルの編集は経験のある管理者以外の方にはお勧めしません。設定ファイルはすべて ASCII テキスト ファイルで、どのようなテキスト エディタでも生成、変更が可能です。設定ファイルの権限は、誰でも読み取り可能に設定しなければなりません。設定ファイルを誰でも読み取り可能にしないと、予期しない MTA 障害の原因になることもあります。ほとんどのファイルの物理行は 252 バイトに制限されており、バックスラッシュ (\) の継続文字を使って論理行を複数の物理行に分けることができます。
表 5-1 に、MTA 設定ファイルとその簡単な説明を一覧します。
ファイル
説明
autoreply プログラムが使うオプションです。サーバ_ルート/msg-インスタンス/imta/config/autoreply.opt
エイリアス ファイル (必須)
ディレクトリに存在しないエイリアスを実装します。サーバ_ルート/msg-インスタンス/imta/config/aliases
チャネルの多くは、チャネル固有のオプションを設定するために、チャネル オプション ファイルを使用します。サーバ_ルート/msg-インスタンス/imta/config/channel_option
メッセージ本体部分の変換を制御するために変換チャネルによって使われます。サーバ_ルート/msg-インスタンス/imta/config/conversions
Dirsync オプション ファイル (必須)
dirsync プログラムが使用するオプションです。サーバ_ルート/msg-インスタンス/imta/config/dirsync.opt
ディスパッチャ設定ファイル (必須)
サービス ディスパッチャの設定ファイルです。サーバ_ルート/msg-インスタンス/imta/config/dispatcher.cnf
imta.cnf ファイル (必須)
チャネル定義のほかに、アドレスの書き換えとルーティングのために使用されます。サーバ_ルート/msg-インスタンス/imta/config/imta.cnf
マッピング ファイル (必須)
グローバル MTA オプションのファイルです。サーバ_ルート/msg-インスタンス/imta/config/option.dat
テイラー ファイル (必須)
ジョブ コントローラ設定ファイル (必須)
ジョブ コントローラによって使用される設定ファイルです。サーバ_ルート/msg-インスタンス/imta/config/job_controller.cnf
表 5-2 に、MTA データベース ファイルとその簡単な説明を一覧します。
imta.cnf ファイル
imta.cnf ファイルには、ルーティングとアドレス書き換えの設定が含まれています。このファイルは、すべてのチャネルとそれらの特性、それらのチャネルにメールを転送するための規則、そして MTA によってアドレスが書き換えられる方法を定義したものです。
imta.cnf ファイルの構造
設定ファイルは次の 2 つの部分から構成されます。ドメイン書き換えとチャネル定義です。ドメイン書き換え規則がファイルの最初に現れ、チャネル定義とは 1 つの空白行で区切られています。チャネル定義は集合的にチャネル テーブルと呼ばれます。個々のチャネル定義がチャネル ブロックを構成します。
ファイル内のコメント
コメントは設定ファイルのどの位置に書いてもかまいません。コメント行は、1 桁目に感嘆符 (!) を書きます。コメントを豊富に書いて、ファイルの動作を説明することをお勧めします。次の imta.cnf ファイルの一部分は、コメント行の使い方を表示したものです。
! パート I: 書き換え規則
!
ims-ms.my_server.siroe.com $E$U@ims-ms-daemon
!
! パートII: チャネル定義空白行とコメント行を区別することが重要です。空白行は、設定ファイルのセクションを区切る重要な役割を果たしています。コメント行は設定ファイルを読み込むルーチンに無視されます。つまり、コメント行はないものとみなされ、空白行として数えられることはありません。
他のファイルを含める
他のファイルの内容を設定ファイルに含めることもできます。行の 1 桁目に「小なり」 (<) の記号があると、その行の残りはファイル名として扱われます。ファイル名は絶対名でフルパスでなければなりません。指定されたファイルが開かれ、設定ファイルのその場所に他のファイルの内容が入れられます。ファイルの包含は、3 階層までネストすることができます。次の imta.cnf ファイルの一部には、/usr/iplanet/server5/msg-tango/table/internet.rules ファイルが含められています。
</usr/iplanet/server5/msg-tango/table/internet.rules
注 設定ファイルに含めるファイルは、設定ファイルと同じように誰でも読み取り可能でなければなりません。
チャネル定義
MTA 設定ファイルの 2 つめの部分には、チャネルそのものの定義が含まれています。これらの定義は集合的に「チャネル、あるいはホスト テーブル」と呼ばれます。個々のチャネル定義は、MTA が使用できるチャネルを定義し、各チャネルに付けられた名前からなる「チャネルブロック」を形成します。それぞれのチャネル ブロックの間は 1 行の空白行によって区切られています。そのため、1 つのチャネル定義の中にコメント行を含めることはできますが、空白行を含めることはできません。1 つのチャネルブロックには、そのチャネルの構成を定義するキーワードのリストがあります。これらのキーワードは「チャネル キーワード」と呼ばれます。詳細については 、表 5-3 を参照してください。次の imta.cnf ファイルの一部分はサンプルのチャネル ブロックを表しています。
[空白行}
! チャネル ブロックの例
channelname keyword1 keyword2
routing_system
[空白行]routing_systemは、書き換え規則内でこのチャネルを参照するために使用される抽象ラベルです。
チャネル定義とチャネル テーブル キーワードの詳細については、「チャネル設定キーワード」および表 5-3 を参照してください。
チャネル設定キーワード
各チャネルブロックの最初の行にはチャネル名があり、次に特定のチャネルの設定を定義するキーワードが続きます。次節では、キーワードと、それらのキーワードがアドレス (チャネルがサポートするタイプのアドレス) を制御する方法について説明します。転送レイヤ (メッセージ エンベロープ) に使われるアドレスとメッセージ ヘッダーに使われるアドレスとは区別されます。チャネル名の次にあるキーワードは、チャネルにさまざまな属性を割り当てるために使用されます。キーワードは大文字と小文字を区別し、32 バイトまで有効で、それ以上の文字は無視されます。サポートされているキーワードを 表 5-3 に示します。太字 のキーワードはデフォルトです。
このリストにないキーワードを指定しても (正しくないかもしれませんが) エラーにはなりません。 UNIX システムの場合、未定義のキーワードは、チャネルのキューにメールを入れるためにプロセスが必要とするグループ ID として解釈されます。imsimta test -rewrite ユーティリティを使うと、権限リストの識別子に合致しない設定ファイル内のキーワードを見つけることができます。
アドレスの解釈 (bangoverpercent、 nobangoverpercent)
アドレスは常に RFC 822 と RFC 976 に準拠して解釈されます。ただし、これらの規格で扱われていない複合アドレスをどう処理するかについては、あいまいな部分があります。特に、A!B%C という形式のアドレスは次のどちらにも解釈できます。
A がルーティング ホストで、C が最終的な宛先ホスト。
あるいは
C がルーティング ホストで、A が最終的な宛先ホスト。
RFC 976 では、メール プログラムが後者の規則を使ってアドレスを解釈できるという旨が示唆されていますが、そのような解釈が要求されるとは書かれていません。状況によっては、前者の解釈方法を使ったほうがよい場合があるかもしれません。bangoverpercent キーワードを使うと、前者のA!(B%C) のように解釈されます。nobangoverpercent キーワードを使うと、後者の (A!B)%C のように解釈されます。nobangoverpercent がデフォルトです。
注 このキーワードが、A!B@Cという形式のアドレスの処理方法に影響を与えることはありません。これらのアドレスは常に(A!B)@C として扱われます。このように処理することが RFC 822 と RFC 976 の両方で義務付けられています。
アドレス内のルーティング情報 (exproute、 noexproute、 improute、 noimproute)
MTA が扱うアドレス モデルは、すべてのシステムが他のすべてのシステムのアドレスを知っていて、それらのアドレスにどのように到達するかを知っているものと想定しています。しかし、このような理想は、世界に知られていない 1 つ以上のシステムにチャネルが接続する (たとえば、プライベートな TCP/IP ネットワーク内にあるマシン) 場合など、どのような場合にも当てはまるとは限りません。このチャネルにあるシステムのアドレスは、サイトの外にあるリモートのシステムからは見ることができないようになっているのかもしれません。このようなアドレスに応答したい場合は、ローカル マシンを通ってメッセージをルーティングするようリモートのシステムに指示するソース ルートを含んでいなければなりません。そうすれば、ローカル マシンは (自動的に) これらのマシンにルーティングすることができます。exproute キーワード (explicit routing の略) は、アドレスがリモートのシステムに渡されるときに、関連するチャネルが明示的なルーティングを要するということを MTA に指示するものです。このキーワードがチャネルに指定されている場合、MTA は、ローカルシステムの名前 (あるいは、ローカルシステムの現在のエイリアス) を含むルーティング情報を、チャネルに合致するすべてのヘッダーのアドレスとすべてのエンベロープ From: アドレスに付け加えます。デフォルトの noexproute を指定すると、ルーティング情報は付け加えられません。
EXPROUTE_FORWARD オプションは、後方を探すアドレスに対する exproute の動作を制限するために使用できます。MTA が適切なルーティングを独自に実行することができないチャネルを通して相手システムに接続する場合には、別の状況が発生します。この場合、他のチャネルに関連するアドレスはすべて、能力のないシステムに接続するチャネルに送られたメール内で使用されるときに、ルーティング指定を必要とします。
この状況を処理するには、黙示的なルーティングと improute キーワードが使用されます。MTA は、他のチャネルに合致するすべてのアドレスが improute マークの付いたチャネルに送られたメールの中で使用されるときにルーティングを必要とすることを知っています。デフォルトの noimproute は、指定されたチャネルに送られるメッセージのアドレスにルーティングの情報を加えないことを指定するものです。IMPROUTE_FORWARD オプションは、後方を探すアドレスに対する improute の動作を制限するために使用できます。
exproute と improute キーワードは慎重に使用するようにしてください。これらのキーワードは、アドレスを長く、より複雑にし、相手側のシステムで使用されているインテリジェントなルーティング機能を妨害する可能性があります。明示的ルーティングと黙示的ルーティングを、指定ルートと混同しないようにしてください。指定ルートは、書き換え規則からアドレスにルーティング情報を挿入するときに使用されます。これは、特殊な A@B@C 書き換え規則テンプレートによってアクティブになります。
指定ルートは、アクティブになったときに、ヘッダーとエンベロープ内のすべてのアドレスに適用されます。指定ルートは特定の書き換え規則によってアクティブになるもので、通常、現在使用中のチャネルとは関係がありません。一方、明示的ルーティングと黙示的ルーティングはチャネルごとに制御され、挿入されるルート アドレスは常にローカルシステムのものです。
メッセージがキューから取り出されるときのアドレス書き換え (connectalias、 connectcanonical)
MTA は通常、チャネルのキューにメッセージを入れるときにアドレスを書き換えます。メッセージがキューから取り出されるときに、さらに書き換えが行われることはありません。したがって、ホスト名が変更されたときにチャネルのキュー内に元のホスト名宛てのメッセージがまだ残っていても、問題は生じません。
connectalias キーワードは、受取人のアドレスに書かれているホストに配信するように、MTA に指示するものです。デフォルト設定では、このキーワードが使用されます。キーワード connectcanonical は、結果のホスト名を使用して、もう一度書き換え規則を適用するためのものです。
チャネルの方向性 (master、 slave、 bidirectional)
チャネルを処理するプログラムは、マスター プログラム (master)、スレーブ プログラム (slave)、あるいは両方のプログラム (bidirectional) という 3 つのキーワードで指定されます。これらのどのキーワードも指定されていない場合のデフォルトは bidirectional です。これらのキーワードによって、チャネルのキューにメッセージが入れられたときに MTA が配信活動を開始するかどうかが決まります。これらのキーワードを使用すると、対応するチャネル プログラムの特徴が反映されるようになります。これらのキーワードをいつ、どこで使用すべきかについては、MTA がサポートする各種チャネルの説明を参照してください。
チャネル サービスの定期性 (immnonurgent)
チャネルがマスター モードの操作を実行できる場合 (master キーワードで指定)、その操作は定期的なサービス ジョブによって、あるいは配信の必要に応じてオンデマンドで開始されます。immnonurgent は、優先度が高、標準、低のメッセージの配信を可能にします。
優先度に影響するメッセージ サイズ (urgentblocklimit、 normalblocklimit、 nonurgentblocklimit)
urgentblocklimit、normalblocklimit、および nonurgentblocklimit キーワードは、サイズに基づいてメッセージの優先度を下げるように指定するためのものです。この優先度は、メッセージを即時に処理するかどうか、あるいは次の定期ジョブが実行される時まで処理を待つかどうかに影響します。urgentblocklimit キーワードは、normal (標準) 優先度に対して指定されたサイズより大きいメッセージの優先度を下げるように MTA に指示します。normalblocklimit キーワードは、nonurgent (低) 優先度に対して指定されたサイズより大きいメッセージの優先度を下げるように MTA に指示します。nonurgentblocklimit キーワードは、nonurgent 優先度 (2 級優先度)、つまり次の定期的なジョブが実行されるまで処理を待つ優先度に対して指定されたサイズより大きいメッセージの優先度を下げるように MTA に指示します。
チャネル接続情報のキャッシング (cacheeverything、 cachesuccesses、 cachefailures、 nocache)
SMTP チャネルは、以前の接続試行の履歴を含むキャッシュを管理します。このキャッシュは、アクセスできないホストに繰り返し接続しようとして時間を浪費し、他のメッセージの配信が遅延されることを回避するために使用されます。通常、キャッシュには、成功した接続試行と失敗した接続試行の両方に関する情報が記録されます成功した試行は、その後失敗する試行を相殺するために記録されます。すなわち、一度接続に成功したホストがその後失敗しても、初めて試行する接続や以前失敗した接続ほど次の接続試行が遅れることはありません。ただし、このキャッシングの方法がすべての状況に適しているというわけではありません。たとえば、1 つの不安定なホストに接続するために使用されるSMTP チャネルはキャッシングをしても利点がありません。そこで、チャネル キーワードを使用して MTA キャッシュを調整します。
cacheeverything キーワードは、すべての形式のキャッシングを有効にします (デフォルト)。nocache はすべてのキャッシングを無効にします。 cachefailures は、失敗した接続をキャッシュしますが、成功した接続はキャッシュしません。cachesuccesses は成功した接続だけをキャッシュします。この最後のキーワードは、チャネルの nocache キーワードと同等のものです。
サービス ジョブまたはファイルごとに処理するアドレス/メッセージ ファイルの数 (addrsperjob、 filesperjob、 maxjobs)
メッセージがチャネルのキューに入れられると、ジョブ コントローラが 1 つのチャネルにつき 1 つのマスター プロセスを開始します。チャネルが定期的に処理される場合は、1 つのチャネルにつき 1 つのマスター プロセスが開始されます。しかし、1 つのサービス ジョブではすべてのメッセージを手際よく配信できない場合もあります。
addrsperjob と filesperjob キーワードは、追加のマスター プロセスを作成するために使用することができます。これらのキーワードには、正の整数を 1 つパラメータとして設定する必要があります。この整数は、チャネルへ送られるべきアドレスまたはキュー エントリ (ファイル) の数を指定するもので、その後それらのアドレスまたはファイルを処理するために複数のマスター プロセスが作成されます。パラメータに 0 またはそれ以下の値を指定した場合は、1 つのサービス ジョブだけがキューに入れられます。キーワードを指定しないと、デフォルトで値は 0 に指定されます。これらのキーワードの影響は最大化されます。すなわち、算出された大きな方の数値が実際に作成されるサービス ジョブの数となります。
addrsperjob キーワードは、すべてのエントリ内のTo: アドレスの合計数を与えられた値で割って開始すべきサービス ジョブの数を計算します。filesperjob キーワードは、実際のキュー エントリ (ファイル) 数を与えられた値で割って作成するジョブ数を算出します。各メッセージのキュー エントリ数は、single や single_sys キーワード、メーリング リストのヘッダー修正アクション、そのほかさまざまな要素によって決定されます。
maxjobs キーワードは、作成可能なサービス ジョブの合計数を制限します。maxjobs キーワードの後ろには、整数値を指定する必要があります。算出されたサービス ジョブ数がこの値より大きい場合には、maxjobs で指定されたプロセスだけが作成されます。maxjobs が指定されていない場合のデフォルト値は 100 です。通常、maxjobs には、チャネルが使用するサービス キューで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を指定します。
たとえば、4 つの受取人アドレスを持つメッセージが addrsperjob 2 および maxjobs 5 でマークされたチャネルのキューに入れられた場合は、合計 2 つのサービス ジョブが作成されます。しかし、同じチャネルのキューに 23 個の受取人アドレスを持つメッセージが入れられた場合には、maxjobs 制限により、5つのジョブしか作成されません。
注 これらのキーワードは、定期的なサービス ジョブと即時のサービス ジョブのどちらにも影響を与えます。定期的なジョブの場合、作成されるジョブの数はチャネルのキュー内にあるメッセージの合計数から算出されます。即時のサービス ジョブの場合、計算はそのときにキューに入れられたメッセージに基づいてのみ計算されます。
一般に、addrsperjob キーワードはアドレスごとのサービスを行うチャネルにしか効果がありません。現在のところ、iPlanet Messaging Server 5.0 では、そのようなチャネルは提供されていません。この機能は、そのような細かいサービスを提供する能力のあるサードパーティやサイト独自に供給されるチャネルのために提供されているものです。
複数のアドレス (multiple、 addrsperfile、 single、 single_sys)
MTA では、キューに入れられたそれぞれのメッセージに複数の宛先アドレスを使用できるようになっています。チャネル プログラムの中には、1 つの受取人を持つメッセージ、限定された数の受取人を持つメッセージ、あるいは 1 つのメッセージ コピーにつき 1 つの宛先システムを持つメッセージしか処理できないものもあります。たとえば、SMTP チャネルのマスター プログラムは、(1 つのチャネルがすべての SMTP トラフィックのために使用されるのにも関わらず) 1 つのトランザクションで 1 つのリモート ホストとの接続を確立するため、そのホストへのアドレスのみが処理されます。もう 1 つの例として、SMTP サーバの中には、1 度に処理できる受取人の数を制限し、このタイプのエラーを処理できないものもあります。
キーワード multiple、addrsperfile、single、single_sys は、複数のアドレスを処理する方法を制御するために使用できます。single キーワードは、各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。キーワード single_sys は、使用されている宛先システムごとにメッセージのコピーを 1 つ作成します。デフォルトの multiple キーワードは、チャネル全体に対してメッセージのコピーを 1 つ作成します。
注 どちらのキーワードを使用しても、メッセージがキューに入れられる各チャネルごとに最低 1 つずつメッセージのコピーが作成されることに注意してください。
addrsperfile キーワードは、チャネルのキューにある1つのメッセージ ファイルに関連付けられる受取人の最大数に制限を付けるために使用されます。これによって、1つの操作で処理される受取人の数が制限されます。このキーワードは、1 つのメッセージ ファイルで許される受取人アドレスの最大数を指定する 1 つの整数引数を必要とします。この数に達すると MTA は自動的にそれらを処理するために追加のメッセージ ファイルを作成します。デフォルトの multiple キーワードは、メッセージ ファイル内の受取人の数に制限を課さないことを意味しています。
複数アドレスの拡張 (expandlimit)
大部分のチャネルは複数の宛先アドレスを持つメッセージを受け入れますが、1 つのメッセージに複数の宛先アドレスが指定されていると、配信処理に遅延 (オンライン遅延) が生じます。遅延時間が長いとネットワークのタイムアウトが発生し、メッセージの重複送信やその他の問題が発生する可能性があります。MTA は、1 つのメッセージに特定数以上のアドレスが指定されている場合に配信を遅らせて処理 (オフライン処理) することができます。この据え置き処理によって、オンライン遅延を大きく軽減することが可能です。処理のオーバーヘッドを遅らせることはできますが、遅延を完全に回避することはできません。
この特別な機能は、汎用の再処理チャネルと expandlimit キーワードとの組み合わせを使用して開始されます。expandlimit キーワードには、オフライン処理を開始するまでにチャネルから受け入れることのできるメッセージのアドレス数の上限を示す整数の引数をとります。expandlimit キーワードが設定されていない場合のデフォルトは無限大です。引数の値を 0 にすると、そのチャネルで受信したすべてのメッセージがオフラインで処理されます。
expandlimit キーワードは、ローカル チャネルおよび reprocessing チャネルには使用できません。使用すると、予測できない事態が発生する可能性があります。再処理チャネルは据え置き処理を実行するために使用され、expandlimit キーワードが効果を発揮するように設定ファイルに追加する必要があります。ただし、MTA 設定ユーティリティによって生成された設定ファイルを使用しているのであれば、その必要はありません。
複数のサブディレクトリ (subdirs)
デフォルトでは、チャネルのキューに入れられたすべてのメッセージは、ディレクトリ /imta/queue/チャネル名にあるファイルとして格納されます。この「チャネル名」はチャネルの名前です。ただし、TCP/IP チャネルのように、たくさんのメッセージを処理し、処理を待つメッセージ ファイルをたくさん格納しがちなチャネルの場合は、それらのメッセージ ファイルを複数のサブディレクトリに拡散するようなファイル システムを使った方が処理能力が向上する可能性があります。この機能を提供するのが subdirs チャネル キーワードです。チャネルのメッセージを拡散するサブディレクトリの数を指定する整数を、このキーワードの後に付けます。tcp_local single_sys smtp subdirs 10
サービス ジョブ キューの使用とジョブの延期 (pool)
MTA は、メッセージを配信するためにサービス ジョブ (チャネルマスター プログラム) を作成します。これらのジョブを起動するジョブ コントローラによって、これらのジョブがプールと関連付けられます。プールのタイプは job_controller.cnf ファイルに定義されています。それぞれのチャネルのマスター プログラムが、pool キーワードを使って、関連するプールをチャネルごとに選択することができます。pool キーワードの後には、現在のチャネルの配信ジョブのプール先となるプール名を指定する必要があります。プール名の長さの上限は 12 バイトです。pool キーワードが省略されている場合、使用されるプールは、ジョブ コントローラの設定ファイルで最初に指定されているデフォルトのキューとなります。
指定配信日 (deferred、 nodeferred)
deferred チャネル キーワードは、Deferred-delivery: ヘッダー行の認識と処理を行います。未来の deferred 指定配信日が付いているメッセージは、有効期限が切れて返されるか、あるいは指定配信日がくるまでチャネルのキューに保管されます。 Deferred-delivery: ヘッダー行の形式と操作の詳細については、RFC 1327 を参照してください。デフォルトのキーワードは nodeferred です。RFC 1327 では配信日指定によるメッセージ処理のサポートが義務付けられていますが、実際にそれを効果的に行えば、人々がディスク制限容量の拡張手段としてメール システムを使用できるようになります。
配信不能メッセージに対する通知発行のタイミング (notices)
notices キーワードは、配信不能メッセージを指定のチャネルのキューに保管する時間を制御するものです。 MTA は、差出人に一連の警告メッセージを送ることができ、メッセージが配信不能のままであれば、MTA は最終的にそのメッセージを差出人に戻します。キーワードの後には、同じ間隔で増加する最高 5 つの整数値を指定できます。これらの値はメッセージが受信されてから警告メッセージが発行されるまでの時間を示すものです。 RETURN_UNITS オプションが 0、あるいはオプション ファイルに指定されていなければ、時間の単位は日数です。または、RETURN_UNITS オプションが 1 であれば単位は時間です。配信不能のメッセージがリストの最後に指定された時間に達したりそれを超えたりすれば、そのメッセージは返されます (バウンスされます)。
それまでは、キーワードで指定した時間になる度に警告メッセージが送られます。 notices キーワードが与えられていなければ、ローカル チャネル用の notices 設定が使用されます (デフォルト)。ローカル チャネル用の notices 設定もない場合は、メッセージを受信してから 3 日後 (または 3 時間後)、6 日後 (または 6 時間後)、9 日後 (または 9 時間後)、12 日目（または 12 時間後）に警告メッセージが送られ、その後もメッセージキューに残っているメッセージが差出人に返送されます。
注 notices キーワードのシンタックスには、ドット文字やカンマを使用しません。たとえば、デフォルトの返送ポリシーは notices 3 6 9 12 というように表現されます。
次に示す行は、メッセージが tcp_local チャネルのキューに入れられ、後日処理されるように設定された場合、トランジエント失敗の配信ステータス通知は 1 日後と 2 日後に生成されることを指定しています。メッセージが 5 日たってもまだ配信されない場合は、差出人に返されます。
tcp_local charset7 us-ascii charset8 iso-8853-1 notices 1 2 3 mail.alpha.com defaults チャネルは、設定ファイル内の最初の空白行のすぐ後にあります。 defaults notices... 行の前と後には必ず空白行が必要です。
返送メッセージ (sendpost、 nosendpost、 copysendpost、 errsendpost)
長期間にわたってサービスが支障を来たしている場合や、アドレスが不正確な場合には、チャネル プログラムがメッセージを配信できないことがあります。その場合、MTA チャネル プログラムは、配信不能の理由を説明する文章と共に、メッセージを差出人に返送します。さらに、配信できないメッセージのコピーをすべてローカル postmaster に送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、postmaster にとっては大量のメールを処理しなければならないことにもなります。sendpost、copysendpost、errsendpost、および nosendpost キーワードは、配信不能のメッセージを postmaster に送ることを制御するために使用されます。sendpost キーワードは、すべての配信不能メッセージのコピーを無条件に postmaster に送るように MTA に指示します。copysendpost は、差出人のアドレスが空白である場合を除いて、配信不能通知のコピーを postmaster に送るように MTA に指示します。差出人のアドレスが空白である場合、postmaster は、バウンスや通知以外のすべての配信不能メッセージのコピーを受け取ります。
errsendpost キーワードは、通知を差出人に返すことができない場合に、配信不能通知のコピーを postmaster のみに送るように MTA に指示します。nosendpost が指定されている場合は、配信不能メッセージが postmaster に送られることはありません。これらのキーワードがどれも指定されていない場合は、デフォルトにより、Errors-to: ヘッダー行またはエンベロープ From: アドレスが空白になっている場合を除いて、配信不能のメッセージのコピーが postmaster に送られます。このデフォルトの動作は、どのキーワードの設定にも対応していません。
警告メッセージ (warnpost、 nowarnpost、 copywarnpost、 errwarnpost)
メッセージの返送に加えて、MTA は配信できないメッセージに関する詳細な情報を記載した警告メッセージを送ることがあります。通常、この警告メッセージは notices チャネル キーワードが指定するタイムアウトに基づいて送られますが、配信試行に失敗したときに送られることもあります。警告には、問題点の説明と配信試行を継続する時間枠が記載されます。また、多くの場合、該当するメッセージのヘッダーと最初の数行も含まれます。さらに、警告メッセージのコピーをすべてローカル postmaster に送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、postmaster にとっては大量のメールを処理しなければならないことにもなります。warnpost、copywarnpost、errwarnpost、nowarnpost キーワードは、警告メッセージを postmaster に送ることを制御するために使用されます。
warnpost は、すべての警告メッセージを無条件に postmaster に送るように MTA に指示します。
nowarnpost が指定されている場合は、警告メッセージが postmaster に送られることはありません。キーワードが設定されていない場合は、警告メッセージが postmaster に送られるようにデフォルト設定されています。ただし、Warningsto: ヘッダー行やエンベロープの From: アドレスが完全に空白になっている場合は送られません。このデフォルトの動作は、どのキーワードの設定にも対応していません。copywarnpost は、差出人のアドレスが空白である場合を除いて、警告を postmaster に送るように MTA に指示します。
errwarnpost は、通知を差出人に返すことができない場合に、警告のコピーを postmaster に送るように MTA に指示します。
- この場合、postmaster は、バウンスや通知以外のすべての配信不能メッセージの警告を受け取ることになります。
Postmaster 返送メッセージの内容 (postheadonly、 postheadbody)
チャネル プログラムまたは定期的なメッセージ返送ジョブがメッセージを postmster と差出人の両方に返送するとき、postmaster へのコピーはメッセージ全体にすることも、あるいはヘッダーのみにすることもできます。メッセージ全体を送らないことで、ユーザのプライバシーを尊重できます。ただし、postmaster やシステム管理者は一般に root システム権限を使用してメッセージの内容を読むことができるため、このキーワードを使用してもメッセージのセキュリティを完全に保証することにはなりません。postheadonly および postheadbody キーワードは、何を postmaster に送るかを制御するために使用されます。postheadbody キーワードは、ヘッダーとメッセージの内容の両方を返します。これがデフォルトです。postheadonly キーワードを指定した場合は、postmaster にヘッダーのみが送られます。
通知メッセージに変更されたアドレスを含める (includefinal、 suppressfinal)
MTA が通知メッセージ (バウンス、配信確認メッセージ、その他) を生成する場合、オリジナルの形式の受取人アドレスと変更された「最終」形式の受取人アドレスを使用できることがあります。オリジナルの形式の方が通知メッセージの受取人 (通知メッセージに関していえば、元のメッセージの差出人) によって認識される可能性が高いため、MTA は、常にオリジナルの形式を通知メッセージに含めますincludefinal と suppressfinal チャネル キーワードは、MTA が最終的な形式のアドレスを含めるかどうかを制御するためのものです。内部のメールボックス名を外から隠しているサイトでは、最終的な形式のアドレスを含めずに、元の外部用アドレスだけを通知メッセージに含めるようにした方がよいかもしれません。includefinal はデフォルトで、最終的な形式の受取人のアドレスを含めます。suppressfinal は、オリジナルの形式のアドレスが存在する場合に、通知メッセージに最終的な形式のアドレスを含めないようにします。
マルチスレッド チャネルで新しいスレッドをトリガする (threaddepth)
マルチスレッドの SMTP クライアントは、メッセージを宛先ごとにそれぞれ異なるスレッドに割り当てるために、送信メッセージを並べ替えます。threaddepth キーワードは、マルチスレッドの SMTP クライアントが 1 つのスレッドに割り当てられるメッセージの数を制限し、それ以上のメッセージがある場合には別のスレッドに割り当てるよう指定します。通常、同じ宛先へのメッセージはすべて 1 つのスレッドによって処理されますが、このキーワードを指定すると、それらのメッセージが複数のスレッドによって処理されるようになります。
チャネル プロトコルの選択 (smtp、 nosmtp)
これらのオプションは、チャネルが STMP プロトコルをサポートするかどうか、また、MTA がそのプロトコルの一部としてどのタイプの SMTP 改行記号を期待するのかを指定します。nosmtp キーワードは、そのチャネルが SMTP をサポートしないことを意味します。残りのキーワードはすべて、SMTP をサポートすることを意味します。SMTP プロトコルを使用するかどうかの選択は、ほとんどのチャネルに対して暗黙的に行われます。適切なチャネル プログラムを使って正しいプロトコルが選択されます。ゲートウェイ システムのいくつかは、メッセージ エンベロープとして RFC 821 に記述されている Simple Mail Transfer Protocol (SMTP) を使用しますが、エンベロープ形式を使用しないシステムもあります。その結果、すべてのエンベロープ情報は RFC 822 メッセージ ヘッダーから派生し、これがすべての場合に使用されます。smtp キーワードは、バッチの SMTP ヘッダーをメッセージに付けるようにチャネルのマスター プログラムに指示するために使用されます。nosmtp キーワードは、バッチ SMTP ヘッダーを生成しないようにするために使用されます。デフォルトのキーワードは nosmtp です。
smtp はすべての SMTP チャネルに必須のキーワードです smtp_cr、smtp_crlf、smtp_lf キーワードは、改行記号として受け入れる文字シーケンスを指定するために SMTP チャネルにおいて使用できます。smtp_crlf キーワードを使用すると、キャリッジ リターン (CR) + ライン フィーダ (LF) のシーケンスのみが改行記号として認識されます。smtp_lf または smtp キーワードを使用すると、LF のみのターミネータが受け入れられます。また、smtp_cr を使用すると、CR のみのターミネータが受け入れられます。通常は SMTP 改行記号として CRLF が使用され、したがって、MTA は常に CRLF を生成します。このオプションは、受信メールの処理のみに影響します。
SMTP EHLO コマンド (ehlo、 checkehlo、 noehlo)
RFC 1651 は、追加のコマンドのネゴシエーションを可能にするために SMTP を拡張します。これを利用するには、RFC 821 規定の HELO コマンドの代わりに、新しい EHLO コマンドを使用します。EHLO コマンドを受け取った 拡張 SMTP サーバはサポートする拡張内容のリストを返します。拡張をサポートしないサーバにこのコマンドを発行した場合は、不明なコマンドエラーのメッセージが返され、エラー メッセージを受け取ったクライアントは折り返し HELO コマンドを送ります。このフォールバックは、サーバが拡張されているかどうかに関わらず機能します。ただし、サーバが RFC 821 に準拠した SMTP を実装していない場合は、問題が発生する可能性があります。特に、認識できないコマンドを受け取ると接続を遮断してしまうサーバもあります。
EHLO コマンドを受け取ったサーバが接続を遮断した場合、SMTP クライアントは HELO コマンドを発行して再接続を試みます。ただし、EHLO を受け取ったリモート サーバが接続を遮断するだけでなく、その他の問題を併発する場合は、クライアントが再接続できないこともあります。
ehlo、noehlo、および checkehlo チャネル キーワードは、このような状況に対処するためのキーワードです。EHLO は、1 回目の接続試行に ehlo コマンドを使用するよう MTA に指示を出します。noehlo キーワードは EHLO コマンドの使用をすべて無効にします。checkehlo キーワードは、リモート SMTP サーバによって返された見出しに「ESMTP」文字列が含まれているかどうかを確認し、含まれている場合には EHLO を使用し、含まれていない場合には HELO を使用するように指示します。デフォルトでは、見出し行に「fire away」という文字列が含まれている場合を除き、EHLO をすべての1 回目の接続試行に使用します。「fire away」が含まれている場合には、HELO が使用されます。
注 このデフォルトの動作に対応するキーワードはありません。このデフォルトの動作は、ehlo キーワードと checkehlo キーワードによる中間的な結果であると言えます。
SMTP ETRN コマンドを受信する (allowetrn、 blocketrn、 domainetrn、 silentetrn)
allowetrn、blocketrn、domainetrn、silentetrn キーワードは、送信側の SMTP クライアントがSMTP ETRN コマンドを出して MTA のキューにメッセージを配信することを MTA に要求した場合に MTA の応答を制御するために使用されます。allowetrn がデフォルトで、MTA はすべての ETRN コマンドを実行しようとします。silentetrn は、ドメインが一致し、かつ MTA が実行しようとするチャネルの名前をエコーせずに、すべての ETRN コマンドを実行するように MTA に指示します。blocketrn は、ETRN コマンドを実行しないように MTA に指示します。domainetrn は、ドメインを指定する ETRN コマンドのみを実行するように MTA に指示します。またこれは、ドメインが一致し、かつMTA が実行しようとするチャネルの名前をエコーしないように MTA に指示します。
SMTP ETRN コマンドを送信する (sendetrn、 nosendetrn)
拡張された SMTP コマンド ETRN (RFC 1985) によって、SMTP クライアントは、リモート SMTP サーバが差出側の SMTP クライアントに送信することになるリモート側のメッセージ キューを開始するよう要求することができます。つまり、SMTP クライアントと SMTP サーバが、元々差出人であるサイドが受取人になり、元々受取人であったサイドが差出人になるというように、役割を交換できるようになります。言い換えると、ETRN は、自分のシステムに入ってくるメッセージのためにリモート SMTP システムをポーリングする方法を提供します。これは、ダイヤルアップ回線などのように、互いにトランジエントな接続のみを持つシステムで使用するのに便利です。接続が確立され、ETRN コマンドを使用して一方がもう一方に送信するとき、SMTP クライアントは、リモート側に、逆の方向に配信されるべきメッセージがあればそれらを配信するように指示します。SMTP クライアントは、SMTP ETRN コマンド行でメッセージの送信先となるシステム名 (通常、その SMTP クライアント システムの名前) を指定します。リモート SMTP サーバが ETRN コマンドをサポートする場合、サーバは指定のシステムに別途接続し、そのシステム宛てのメッセージの配信を開始するためのプロセスがトリガされます。
sendetrn および nosendetrn チャネル キーワードは、MTA が SMTP 接続開始時に ETRN コマンドを送るかどうかを指定するためのものです。デフォルト設定では nosendetrn が有効になっているため、MTA は ETRN コマンドを送りません。リモート SMTP サーバが ETRN コマンドをサポートする場合にのみ MTA が ETRN を発行するように指定するには、sendetrn キーワードを使用します。sendetrn キーワードの後には、メッセージの配信先となるシステムの名前を記述する必要があります。
SMTP VRFY コマンド (domainvrfy、 localvrfy、 novrfy)
これらのキーワードは、MTA の SMTP クライアントにおける VRFY コマンドの使用を制御します。通常の環境では、SMTP ダイアログの一部として VRFY コマンドを発行する必要はありません。SMTP MAIL TO コマンドに VRFY コマンドと同じ効果があり、必要に応じて適切なエラーを返すためです。ただし、サーバの中には、MAIL TO コマンドを受け取った場合にはコマンドが指定するアドレスをいったん受理してから返送し、VRFY コマンドを受け取った場合はより広範なチェックを実行するものもあります。MTA は、SMTP VRFY コマンドを出すように設定することができます。domainvrfy キーワードを使用すると、完全なアドレス (user@host) を引数とする VRFY コマンドが発行されます。localvrfy キーワードを使用すると、アドレスのローカル部分 (user) だけを引数とする VRFY コマンドが発行されます。デフォルトは、novrfy です。
SMTP VRFY コマンドに応答する (vrfyallow、 vrfydefault、 vrfyhide)
これらのキーワードは、送信側の SMTP クライアントが SMTP VRFY コマンドを出したときの MTA SMTP サーバの応答を制御します。MTA が詳細な情報を含む応答を返すように指定するには、vrfyallow キーワードを使用します。HIDE_VERIFY=1 チャネル オプションが指定されていない限り、MTA が詳細な情報を含む応答を返すよう指定するには、vrfydefault キーワードを使用します。MTA があいまいな応答を返すよう指定するには、vrfyhide キーワードを使用します。これらのキーワードを使用すると、VRFY コマンドに対する応答をチャネルごとに制御できます。一方、HIDE_VERIFY オプションは、1 つの SMTP サーバを介して処理されるすべての受信 TCP/IP チャネルに適用されます。
TCP/IP ポート番号 (port)
通常、SMTP 実装 TCP/IP チャネルは、ポート 25 に接続してメッセージを送信します。SMTP 実装 TCP/IP チャネルがその他のポートを使用するように指定するには、port キーワードを使用します。
TCP/IP MX レコードのサポート (mx、 nomx、 defaultmx、 randommx、 nonrandommx)
TCP/IP ネットワークには、MX (メールの転送) レコードの使用をサポートするものとしないものとがあります。MTA システムの接続先であるネットワークから提供される MX レコードだけを使用するように設定できる TCP/IP チャネル プログラムもあります。randommx キーワードは、MX 検索を実行し、同等の優先順位を持つ MX レコード値を順不同で処理するように指定するものです。また、nonrandommx キーワードは、MX 検索を実行し、同等の優先順位を持つ MX レコード値を受信した通りの順番で処理するように指定するものです。現在のところ、mx キーワードは nonrandommx キーワードと同じものですが、将来のリリースでは randommx と同じになるように変更される可能性もあります。nomx キーワードは MX 検索を無効にします。defaultmx キーワードは、ネットワークが MX レコードをサポートする場合に mx を使用するように指定します。MX 検索をサポートするチャネルではすべて defaultmx キーワードがデフォルトとして設定されています。
最後のホストを指定する (lastresort)
lastresort キーワードは、「最後のホスト」つまり他のホストへの接続試行がすべて失敗した場合に最終的な接続先となるホストを指定します。このキーワードは、事実上の最終手段的 MX レコードとして動作します。このキーワードは、SMTP チャネルに対してのみ効果があります。
受信 SMTP 接続における DNS リバース検索と IDENT 検索 (identtcp、 identtcplimited、 identtcpnumeric、 identtcpsymbolic、 identnone、 identnonelimited、 identnonenumeric、 identnonesymbolic、 forwardchecknone、 forwardchecktag、 forwardcheckdelete)
identtcp キーワードは、IDENT プロトコル (RFC 1413) を使用して接続と検索を実行するように MTA に指示します。 IDENT プロトコルから得られた情報 (通常、SMTP 接続をしているユーザのアイデンティティ) は次に、DNS リバース検索と IP 番号そのものから報告される、受信 IP 番号に対応するホスト名といっしょに、メッセージの Received: ヘッダー行に挿入されます。identtcpsymbolic キーワードは、IDENT プロトコル (RFC 1413) を使用して、接続と検索を実行するように MTA に指示します。 IDENT プロトコルから得られた情報 (通常、SMTP 接続をしているユーザのアイデンティティ) は次に、DNS リバース検索から報告された実際の受信 IP 番号といっしょに、Received: ヘッダー行に挿入されます。IP 番号そのものは Received: ヘッダーに挿入されません。
identtcpnumeric キーワードは、IDENT プロトコル (RFC 1413) を使用して接続と検索を実行するように、MTA に指示します。 IDENT プロトコルから得られた情報 (通常、SMTP 接続をしているユーザのアイデンティティ) は次に、実際の IP アドレスといっしょにメッセージの Received:ヘッダー行に挿入されます。IP 番号に対する DNS リバース検索は実行されません。
注 identtcp または identtcpnumeric による IDENT 検索が役に立つのは、リモート システムで IDENT サーバが稼動している場合です。
IDENT クエリーの試行でパフォーマンス ヒットが発生する場合があります。ルータは、徐々に認識しないポートへの接続試行を「ブラック ホール」に集めるようになります。これが IDENT クエリーに発生すると、MTA は接続がタイムアウトするまで (TCP/IP パッケージによって制御されるタイムアウトで、たいていは 1 分か 2 分) 応答をもらえません。
それほど重大ではないパフォーマンスの問題が identtcp あるいは identtcpsymbolic を identtcpnumeric と比較するときにも発生します。identtcp または identtcpsymbolic によって DNS リバース検索が実行された場合、よりユーザ フレンドリーなホスト名を返すにはより長い時間が必要になります。
identnone キーワードはIDENT 検索を無効にしますが、IP からホスト名への変換は行われます。メッセージの Received: ヘッダー行には IP 番号とホスト名の両方が含まれます。identnonesymbolic キーワードは IDENT 検索を無効にしますが、IP からホスト名への変換は行われます。メッセージの Received: ヘッダー行にはホスト名だけが含まれます。identnonenumeric キーワードは IDENT 検索を無効にし、DNS リバース検索の IP 番号からホスト名への変換を禁止します。また、Received: ヘッダーにユーザ フレンドリーでないホスト名を使用するため、パフォーマンスの向上につながる可能性もあります。identnone がデフォルトです。
identtcplimited および identnonelimited キーワードは、IDENT 検索、DNS リバース検索、Received: ヘッダーに表示する情報などに関し、identtcp および identnone と同様の効果をもたらします。ただし、異なる点として、identtcplimited および identnonelimited の場合は、switchchannel キーワードの影響で、DNS リバース検索によってホスト名が検出されたかどうかに関わらず常に IP リテラル アドレスがチャネル スイッチのベースとして使用されます。
forwardchecknone、forwardchecktag、および forwardcheckdelete チャネル キーワードは、DNS リバース検索を使用して見つかった IP 名の正引き検索を MTA にさせるか、正引き検索が要求されたときに、IP 名の正引き検索がオリジナルの接続の IP 番号に一致しない場合、MTA に何をさせるかを制御することによって、リバース検索の実施による影響を変更することができます。デフォルト設定では forwardchecknone キーワードが有効になっているため、正引き検索は実行されません。forwardchecktag キーワードは、リバース検索が行われる度に正引き検索を実行し、検出された番号が最初の接続の番号と一致しない場合は IP 名にアスタリスク (*) を付けるように指定します。forwardcheckdelete キーワードは、リバース検索の後に正引き検索を行い、リバース検索で返された名前の正引き検索がオリジナルの接続の IP アドレスに一致しない場合は、リバース検索で返された名前を無視 (削除) するように、MTA に指示します。代わりにオリジナルの IP アドレスを使います。
注 複数の IP アドレスに「一般的な」IP 名が使用されているサイトの場合、正引きの結果が最初の IP アドレスと一致しないのは比較的頻繁に見られる現象です。
これらのキーワードは、TCP/IP 上で稼動する SMTP チャネルでのみ使用できます。
受信メール用の代替チャネルを選択する (switchchannel、 allowswitchchannel、 noswitchchannel)
SMTP サーバがリモート システムから受信接続を受け付ける場合、SMTP サーバはその接続に関連付けるチャネルを選ぶ必要があります。通常、使用するチャネルは転送形式に基づいて決定されます。たとえば、受信 TCP/IP 接続は、自動的に tcp_local チャネルに関連付けられます。ただし、異なる性質を持つ複数の送信チャネルが複数のシステムに対して同時に使用される場合は、受信と送信がそれぞれ異なるチャネルで行われるため、対応するチャネルの性質がリモート システムに関連付けられません。
この問題は、switchchannel キーワードを使用することにより解決できます。switchchannel がサーバの初期チャネル(tcp_local) 上に指定されている場合は、送信元のホスト名がチャネル テーブルにあるかどうかが調べられ、一致するエントリがあれば、それに合わせてソースチャネルが変わります。ソース チャネルは switchchannel または allowswitchchannel にマークされているチャネルに切り替えられます (デフォルト)。noswitchchannel キーワードは、チャネルの切り替えを行わないように指定するためのものです。
デフォルトでは、サーバが関連付けられているチャネル以外のチャネルに switchchannel を使用しても効果はありません。現在のところ、switchchannel を使用できるのは SMTP チャネルに対してのみですが、いずれにしても SMTP チャネル以外に switchchannel を使用すべきではありません。
注 switchchannel が指定されている場合、送信元のホスト名は IP アドレスからホスト名への DNS リバース検索変換によって得られます。したがって、このキーワードはスパミング防止策を設定するときに便利ですが、パフォーマンスに影響をきたすこともあります。
不完全なアドレスを修正する際に使用するホスト名 (remotehost、 noremotehost)
MTA は、間違って設定された、あるいは標準に準拠しないメーラーや SMTP クライアントからメッセージを受け取ることがよくあります。MTA は、そのようなメッセージを通過させる前に、アドレスを有効な形式にしようと試みます。MTA は、アドレスにドメイン名を付け加える (たとえば、@siroe.com を mrochek に付け加える) ことによってそれを行います。しかし、SMTP サーバの場合は、論理的なドメイン名の選択肢は次の 2 つです。これらの 2 つの選択肢のどちらも、かなりの頻度で発生する場合が多いので、どちらも正しい可能性があります。不適切に構成された SMTP クライアントを扱う場合には、リモート ホストのドメイン名を使用することが適切です。メッセージを掲示するために SMTP を使う POP や IMAP クライアントのように軽量級のリモート メール クライアントを扱う場合には、ローカル ホストのドメイン名を使用することが適切です。
MTA がとれる最善の策は、チャネルごとに選択できるようにすることです。remotehost チャネル キーワードはリモート ホストの名前が使用されるように指定するもので、noremotehost チャネル キーワードはローカル ホストの名前が使用されるように指定するものです。デフォルトのキーワードは noremotehost です。
switchchannel キーワードは、前のセクション「受信メール用の代替チャネルを選択する (switchchannel、 allowswitchchannel、 noswitchchannel)」 で説明されているとおり、受信 SMTP 接続を特定のチャネルに関連付けるために使用することができます。この機能は、リモートのメール クライアントを、適切な処理を受けることができるチャネルにグループ化するために使用することができます。代わりの方法として、(標準に準拠しないクライアントが多数に使用されていたとしても) 標準に準拠するリモート メール クライアントを配備するほうが、MTA ホストでネットワーク全体の問題を解決しようとするより簡単です。
Recipient ヘッダー行がないメッセージを有効にする (missingrecipientpolicy)
RFC 822 (Internet) メッセージは、To:、Cc:、あるいは Bcc: の受取人ヘッダー行を含むことが要求されています。そのようなヘッダー行がないメッセージは無効になります。しかし、うまく稼動していないユーザ エージェントやメーラー (たとえば、古いバージョンの sendmail) は、無効なメッセージを受け入れます。missingrecipientpolicy キーワードは、そのようなメッセージを扱うときに使用すべきアプローチを指定する整数値をとります。このキーワードが明示的に表現されていない場合は、デフォルト値の 0 が使用され、エンベロープ To: アドレスが To:ヘッダーに入れられます。
表 5-4 missingrecipientpolicy の値
値
動作
MISSING_RECIPIENT_POLICY オプションは、MTA システムがデフォルトでこの動作をするように設定するためのものであることに注意してください。
8 ビット処理能力 (eightbit、 eightnegotiate、 eightstrict、 sevenbit)
127 (10進) 以上の序数値を持つ文字の使用は制限される場合があります。特に、SMTP サーバの中には、高ビットを切り捨てるために 8 ビット領域の文字を含むメッセージの文字化けの原因となるものもあります。MTA は、そのようなメッセージを自動的にエンコードし、8 ビット データがメッセージに直接表示されないようにする機能を備えています。特定のチャネルのキューに入れられるすべてのメッセージにエンコードを適用するには、sevenbit キーワードを指定します。そのような制約がない場合は、eightbit を使用します。拡張 SMTP など、転送形式によっては、8 ビットの文字を転送できるかどうかを判断するためのネゴシエーションの形式をサポートするものもあります。ネゴシエーションが失敗したときにメッセージをエンコードするようにチャネルに指示するためには、eightnegotiate キーワードを使用します。デフォルト設定ではすべてのチャネルに対してこのキーワードが有効になっているため、ネゴシエーションをサポートしないチャネルは 8 ビット データの転送が可能であるという仮定のもとに動作します。MTA がネゴシエートされていない 8 ビット データを含むメッセージをすべて拒否するように設定するには、eightstrict キーワードを使用します。
自動文字セット ラベル機能 (charset7、 charset8、 charsetesc)
MIME 仕様は、プレーン テキストのメッセージで使用される文字セットにラベルを付ける仕組みを提供します。 Content-type: ヘッダー行の一部としてcharset= 引数を指定することができます。MIME には、US-ASCII (デフォルト)、ISO-8859-1、ISO-8859-2 などのようにさまざまな文字セット名が定義されています。既存のシステムやユーザ エージェントの中には、これらの文字セット ラベルを生成する仕組みを提供しないものもあり、その結果、プレーンテキスト メッセージの中には適切にラベル付けされていないものもあります。charset7、charset8、および charsetesc チャネル キーワードは、メッセージ ヘッダーに文字セット名を挿入するメカニズムをチャネルごとに提供するキーワードです。これらのキーワードを使用する場合は、単一の文字セット名を引数として指定する必要があります。文字セット名が正しいかどうかの確認は行われません。
注 文字セットの変換は、MTA テーブル ディレクトリ内の文字セット定義ファイル charsets.txt で定義されている文字セットに対してのみ可能であることに注意してください。できるだけ、このファイルに定義されている名前を使うようにしてください。
メッセージに含まれるのが 7 ビット データのみの場合は charset7 を、8 ビット データが含まれる場合は charset8 を使用します。charsetesc は、7 ビット データが含まれているメッセージにエスケープ文字が含まれている場合に使用します。適切なキーワードが指定されていない場合は、Content-type: ヘッダー行に文字セット名が挿入されません。
これらの文字セット指定が既存のラベルより優先されることはありません。メッセージにすでに文字セット ラベルが含まれている場合やメッセージがテキストでない場合、これらのキーワードは効果をもたらしません。通常、MTA のローカル チャネルは次のようにラベル付けされます。
l ... charset7 US-ASCII charset8 ISO-8859-1 ...
hostnameContent-type ヘッダーがメッセージにない場合には、それが追加されます。また、このキーワードは、MIME-version: ヘッダー行も追加します (そのヘッダーがない場合)。
メッセージ行の長さに関する制限 (linelength)
SMTP 仕様では、1000 バイトまでのテキスト行が許されています。しかし、転送形式の中には、行長に制限を課すものもあります。linelength キーワードは、チャネルごとに許される最大のメッセージ行の長さを制限する仕組みを提供します。特定のチャネルのキューに入れられたメッセージの中で、そのチャネルに指定された行長を超えるメッセージは自動的にエンコードされます。MTA にはさまざまなエンコーディング方式が提供されており、エンコーディングの結果、行長は常に 80 バイト以下になります。エンコーディングが行われた元のメッセージは、適切なデコーディングのフィルタを通すことによって元の状態に戻すことができます。
注 エンコーディングは、行長を 80 バイトより短くするだけです。行長に 80 バイトより短い値を指定しても、指定された制限より短い行にできるとは限りません。
チャネル固有のリバース データベースの使用 (reverse、 noreverse)
reverse キーワードは、チャネルのキューに入れられたメッセージ内のアドレスを、アドレス リバース データベースまたは REVERSE マッピング (存在する場合) のいずれかに対して照合し、必要に応じて変更するように指示するものです。また、noreverse は、チャネルのキューに入れられたメッセージのアドレスを、アドレス リバース処理から外すことを指定するものです。デフォルトのキーワードは reverse です。
内部ヘッダーの書き換え (noinner、 inner)
ヘッダー行の内容は必要なときにだけ解釈されます。ただし、メッセージの中にメッセージを埋め込むことができる能力(メッセージ/RFC822) があるために、MIME メッセージには複数のメッセージ ヘッダーが含まれていることもあります。通常、MTA は一番外側のメッセージ ヘッダーだけを解釈し、書き換えます。オプションとして、メッセージの内部ヘッダーに書き換え規則を適用するように指示することも可能です。この動作は、noinner と inner キーワードを使用して制御できます。キーワード noinner は、内部ヘッダー行を書き換えないように MTA に指示するものです。デフォルトでは、このキーワードが使用されます。キーワード inner は、メッセージをパースして、内部ヘッダーを書き換えるように MTA に指示します。これらのキーワードは任意のチャネルに適用することができます。
制限されたメールボックスのエンコーディング (restricted、 unrestricted)
メール システムの中には、RFC 822 で許されるアドレスのすべての形式を扱うことができないものもあります。もっとも一般的に見られる例は、設定ファイルが不適切に設定された senmail ベースのメーラーです。引用されたローカルパート (あるいはメールボックス仕様) が頻繁に見られる問題の原因です。これは大きな問題なので、この問題を処理するための方策が RFC 1137 に記載されています。基本的なアプローチは、アドレスから引用を取り除き、引用を要する文字を、アトムとして許可されている文字にマップする変換規則を適用することです (ここで使われているアトムという語の定義については RFC 822 を参照)。たとえば、前のアドレスは次のようになります。
restricted チャネル キーワードは、そのチャネルがこのエンコーディングを必要とするメール システムに接続するということを MTA に知らせます。すると MTA は、メッセージがチャネルに書かれるときに、ヘッダーとエンベロープ アドレスの両方において引用されたローカルパートをエンコードします。そのチャネルの受信メールのアドレスは自動的にデコードされます。unrestricted キーワードは、RFC 1137 エンコーディングとデコーディングを実行するように MTA に指示します。デフォルトは unrestricted キーワードです。
注 restricted キーワードは、引用されたローカルパートを受け入れることができないシステムに接続するチャネルに対して適用します。引用されたローカルパートを実際に生成するチャネルには適用しないでください。(そのようなアドレスを生成することができるチャネルは、そのようなアドレスを処理することができると想定されるからです。)
メッセージ ヘッダー行をトリミングする (headertrim、 noheadertrim、 headerread、 noheaderread、 innertrim、 noinnertrim)
MTA には、メッセージから特定のメッセージ ヘッダー行をトリミング (取り除く) する、チャネル単位の機能があります。これは、チャネル キーワードと関連する 1 つまたは 2 つのヘッダー オプション ファイルの組み合わせによって行われます。headertrim キーワードは、チャネルに関連するヘッダー オプション ファイルを作成し、メッセージが処理された後、チャネルのキューに入れられたメッセージのヘッダーをそれに基づいてトリムするよう MTA に指示します。noheadertrim キーワードは、ヘッダー トリミングを行いません。デフォルトは noheadertrim キーワードです。innertrim キーワードは、たとえば埋め込まれた MESSAGE/RFC822 パートのような、内部メッセージ部分にヘッダー トリミングを実行するよう MTA に指示します。noinnertrim キーワードはデフォルトで、内部メッセージ部分のどのヘッダーにもトリミングを実行しないよう MTA に指示します。
headerread キーワードは、そのチャネルのキューに入っているメッセージが処理される前に、そのチャネルに関連しているヘッダー オプション ファイルを参照してヘッダーをトリムするようMTA に指示します。反対に、headertrim によるヘッダー トリミングは、メッセージが処理された後に適用されることに注意してください。noheaderread キーワードは、キューに入っているメッセージのヘッダー トリミングを行いません。noheaderread がデフォルトです。
重要なヘッダー情報をメッセージから取り除くと、MTA が正常に動作しなくなることもあります。取り除くヘッダーまたは制限するヘッダーを選ぶ際には、十分な配慮が必要です。この機能があるのは、特定のヘッダー行を取り除いたり、あるいは制限しなければならないような状況が発生することがあるからです。ヘッダー行を取り除く前に、そのヘッダー行の用途を十分に理解し、それを取り除いた場合の結果を考慮してください。
headertrim および innertrim キーワードのヘッダー オプション ファイルには、チャネル_headers.opt (「チャネル」はヘッダー オプション ファイルが関連付けられているチャネルの名前) という形式の名前がついています。同様に、headerread キーワードのヘッダー オプション ファイルには、channel_read_headers.opt という形式の名前がついています。これらのファイルは、MTA 設定ディレクトリ (サーバ_ルート/msg-インスタンス/imta/config/) に保存されています。
Encoding： ヘッダー行 (ignoreencoding、 interpretencoding)
MTA は、Yes CHARSET-CONVERSION を使用して、さまざまな非標準のメッセージ形式を MIME に変更することができます。特に、RFC 1154 形式は非標準の Encoding: ヘッダー行を使用します。しかし、ゲートウェイの中には、ヘッダー行に対して誤った情報を出すものもあり、その結果、このヘッダー行を無視したほうがいい場合もあります。 ignoreencoding キーワードは、Encoding: ヘッダー行をすべて無視するよう MTA に指示するものです。
注 MTA の CHARSET-CONVERSION が有効になっていない限り、このようなヘッダーはいずれにしても無視されます。 interpretencoding キーワードは、すべてのEncoding: ヘッダー行に注意を払うよう MTA に指示します。このキーワードがデフォルトです。
X-Envelope-to: ヘッダー行の生成 (x_env_to、 nox_env_to)
x_env_to と nox_env_to キーワードは、特定のチャネルのキューに入れられたメッセージのコピーにX-Envelope-to ヘッダー行を生成するかしないかを制御します。x_env_to キーワードを指定するとこれらのヘッダー行が生成され、nox_env_to を指定するとそのようなヘッダーがキュー内のメッセージから取り除かれます。デフォルトは nox_env_to です。
Received: ヘッダー行内の Envelope to アドレス (receivedfor、 noreceivedfor、 receivedfrom、 noreceivedfrom)
receivedfor キーワードは、メッセージが 1 つのエンベロープ受取人に宛てられている場合に、それが作成する Received: ヘッダー行にそのエンベロープを含めるよう MTA に指示します。デフォルトのキーワードは receivedfor です。noreceivedfor キーワードは、エンベロープ アドレスの情報なしに、Received ヘッダー行を作成するよう MTA に指示します。receivedfrom キーワードは、たとえばメーリング リストの拡張などのために MTA がエンベロープ From:アドレスを変更した場合、受信メッセージの Received: ヘッダー行を作成するときに元のエンベロープ From: アドレスを含めるように MTA に指示します。receivedfrom がデフォルトです。noreceivedfrom キーワードは、元のエンベロープ From: アドレスを含めずにReceived: ヘッダー行を作成するよう MTA に指示します。
空白のエンベロープ Return アドレス (returnenvelope)
returnenvelope キーワードは 1 つの整数値をとり、これはビット フラグのセットして解釈されます。ビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープ アドレスを空白にするか、あるいはローカルの postmaster のアドレスを入れるかを指定するものです。このビットを設定した場合は、ローカルの postmaster のアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになります。
注 RFC 1123 では空白のアドレスを使用することが義務付けられています。しかし、システムによっては空白のエンベロープ From: アドレスをうまく処理しないので、このオプションを使用することが必要になる場合があります。
ビット 1 (値 = 2) は、MTA がすべての空白エンベロープ アドレスをローカルの postmaster のアドレスに置き換えるかどうかを指定するものです。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用されます。
Reply-to: ヘッダー行をマップする (usereplyto)
usereplyto キーワードは Reply-to: ヘッダー行のマッピングを制御します。デフォルトは usereplyto 0 で、そのチャネルのデフォルトの動作を使用することです。チャネルの動作はチャネルごとに異なります。表 5-5 に、Reply-to: ヘッダー行のマッピング仕様を示します。
表 5-5 Reply-to: ヘッダーのマッピング オプション
値
動作
Reply-to: アドレスのデフォルトのマッピング (チャネルによって異なる) を使用します。デフォルトでは、このキーワードが使用されます。
利用できる Reply-to: アドレスがある場合に、それを From: にマップし、それ以外の場合は From: アドレスにフォールバックします。
非 RFC 822 環境へのゲートウェイを使って Resent- ヘッダー行をマップする (useresent)
useresent キーワードは、RFC 822 ヘッダー行をサポートしない環境へのゲートウェイを使用するときに、Resent- ヘッダー行の使用を制御するものです。このキーワードは 1 つの整数値の引数をとります。表 5-6 に、Resent- ヘッダーをマップするときに使用される値を示します。
表 5-6 Resent- ヘッダー行のマッピングオプション
値
動作
Resent-From ヘッダー行のみを使用してアドレス情報を生成します。その他の Resent- ヘッダー行はすべて無視されます。
アドレス ヘッダー行内のコメント (commentinc、 commentomit、 commentstrip、 commenttotal)
MTA は必要なときだけヘッダー行の内容を解釈します。ただし、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべての登録されたヘッダー行をパースしなければなりません。この処理の途中では、コメント (括弧で囲まれた文字列) が抽出され、ヘッダー行が再構成されるときに変更されるか、あるいは除外されることがあります。この動作は、commentinc、commentomit、commentstrip、commenttotal キーワードを使用して制御されます。commentinc キーワードは、ヘッダー行内のコメントを残すように MTA に指示します。デフォルトでは、このキーワードが使用されます。commentomit キーワードは、アドレス ヘッダー、たとえばTo、From、あるいは Cc ヘッダー行からコメントを取り除くよう MTA に指示します。
キーワード commenttotal は、Received: ヘッダー行を含め、すべてのヘッダー行からコメントを取り除くよう MTA に指示します。このキーワードは、通常、便利ではなく推薦もされません。commentstrip は、すべてのコメント フィールドから非アトムの文字を取り除くよう MTA に指示します。これらのキーワードはどのチャネルにも適用できます。
アドレス ヘッダー行内の個人名 (personalinc、 personalomit、 personalstrip)
書き換えプロセスの際には、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべてのヘッダー行をパースしなければなりません。このプロセスの際に、個人名 (角括弧で区切られたアドレスの前にある文字列) が抽出されますが、これはヘッダー行を再構築するときに変更したり除外することもできます。この動作は、personalinc、personalomit、personalstrip キーワードの使用によって制御されます。キーワード personalinc は、ヘッダー内の個人名を残すよう MTA に指示します。デフォルトでは、このキーワードが使用されます。キーワード personalomit は、個人名を取り除くよう MTA に指示します。キーワード personalstrip は、非アトムの文字をすべての個人名フィールドから取り除くよう MTA に指示します。これらのキーワードはどのチャネルにも適用できます。
2 桁または 4 桁の日付の変換 (datefour、 datetwo)
オリジナルの RFC 822 仕様では、メッセージ ヘッダーの日付フィールドに 2 桁の年表示を使用することが規定されています。これは後で RFC 1123 により 4 桁 に変更されました。しかし、古いメール システムの中には、4 桁の日付を受け入れないものもあります。また、新しいメール システムの中には、2 桁の日付を受け入れなくなったものもあります。
注 両方の形式を扱うことができないシステムは規格に違反しています。
datefour および datetwo キーワードは、MTA によるメッセージ ヘッダー内の日付フィールド処理を制御するものです。datefour キーワードがデフォルトで、すべての年表示フィールドを 4 桁に展開するように MTA に指示します。値が 50 以下の 2 桁の日付表示には 2000 が加えられ、50 より大きいものには 1900 が付け加えられます。
datetwo キーワードは、4 桁の日付表示から先頭の 2 桁を取り去るように MTA に指示します。これは、2 桁の日付表示を要求する、標準に準拠していないメール システムとの互換性を提供する目的で行われます。その他の目的のために使用してはなりません。
日付表示内の曜日仕様 (dayofweek、 nodayofweek)
RFC 822 仕様では、メッセージ ヘッダー内の日付フィールドにおいて、日付の前に曜日を付けることが許されています。しかし、システムの中には曜日情報を受け入れられないものもあります。そのため、ヘッダーに含めると便利な情報であるにもかかわらず、曜日情報を含めないシステムもあります。dayofweek および nodayofweek キーワードは、MTA による曜日情報処理を制御するものです。dayofweek キーワードがデフォルトで、これは曜日情報を残し、曜日情報がない場合にはその情報を月日/時間ヘッダーに追加するよう MTA に指示します。
nodayofweek キーワードは、月日/時間ヘッダーから先頭の曜日情報を取り除くよう MTA に指示します。これは、この情報を適切に処理することができない、標準に準拠していないメール システムとの互換性を提供する目的で行われます。その他の目的のために使用してはなりません。
長いヘッダー行の自動分割 (maxheaderaddrs、 maxheaderchars)
メッセージ転送形式、特に sendmail のインプリメンテーションの中には、長いヘッダー行を適切に処理できないものがあります。これは、ヘッダーが破壊されるだけでなく、誤ったメッセージ拒否の原因になりがちです。これは重大な規格違反ですが、一般的に起こりがちな問題です。MTA には、長いヘッダー行を複数の独立したヘッダー行に分割するチャネルごとの機能があります。maxheaderaddrs キーワードは 1 つの行にいくつのアドレスを含められるかを制御し、maxheaderchars キーワードは 1 行に何バイト分の文字を含められるかを制御します。どちらのキーワードにも、限度を指定する 1 つの整数引数が必要です。デフォルトでは、ヘッダー行の長さもアドレスの数も制限されていません。
ヘッダーの配置と折り返し (headerlabelalign、 headerlinelength)
headerlabelalign キーワードは、このチャネルのキューに入れられたメッセージ ヘッダーの配置ポイントを制御するものです。整数値の引数をとります。配置ポイントとは、ヘッダーの内容を揃えるためのマージンです。たとえば、配置ポイントが 10 のヘッダー行は次のようになります。
To: joe@siroe.com
From: mary@siroe.com
Subject: 配置テストデフォルトの headerlabelalign は 0 で、ヘッダーは揃えられません。headerlinelength キーワードは、このチャネルのキューに入れられたメッセージ ヘッダー行の長さを制御します。これよりも長い行は、RFC 822 の折り返し規則に基づいて折り返されます。
これらのキーワードは、メッセージ キュー内にあるメッセージのヘッダー形式を制御するだけのものです。実際のヘッダーの表示は、通常、ユーザ エージェントによって制御されます。さらに、ヘッダーはインターネットを転送されるときに何度もリフォーマットされるため、メッセージ ヘッダーをフォーマットしない単純なユーザ エージェントといっしょに使用された場合には、これらのキーワードの効果が見られないこともあります。
メッセージ/部分メッセージの自動再組立 (defragment、 nodefragment)
MIME 規格には、メッセージをより小さな部分に分割するための message/partial コンテンツ タイプがあります。これは、サイズ制限があるネットワークをメッセージが通過しなければならないときに便利です。メッセージが宛先に到着したときに自動的に再組み立てが行われるように、それぞれの部分に情報が含まれています。MTA では、defragment チャネル キーワードと再組立チャネルを使うことによって、メッセージの再組み立てを行うことができます。チャネルが defragment でマークされていれば、このチャネルのキューに入れられるメッセージまたは部分メッセージはすべて、代わりに再組立チャネルのキューに入れられます。すべての部分が到着したら、メッセージは再構築されて本来の宛先に送られます。nodefragment は、このような特別な処理を無効にするものです。デフォルトのキーワードは nodefragment です。
defragment キーワードが効果を発揮するためには、再組立チャネルを MTA 設定ファイルに追加する必要があります。ただし、MTA 設定ユーティリティによって作成された設定を使用しているのであれば、その必要はありません。
大きなメッセージの自動断片化 (maxblocks、 maxlines)
電子メール システムまたはネットワーク転送形式の中には、特定のサイズを超えるメッセージを処理できないものがあります。MTA には、チャネルごとにそのような制限を課す機能があります。設定されたサイズよりも大きなメッセージは自動的に複数の、より小さなメッセージに分割 (断片化) されます。このような断片に使用されるコンテンツ タイプは message/partial で、同じメッセージの各部分が互いに関連付けられ、受信先のメーラーによって自動的に再組立されるように固有 ID の引数が付け加えられます。maxblocks と maxlines キーワードは、自動断片化の対象となるサイズ制限枠を課すために使用されます。これらのキーワードの後には 1 つの整数値が続きます。maxblocks キーワードは、1 つのメッセージに許されるブロックの最大数を指定します。1 つの MTA ブロックは通常 1024 バイトで、これは MTA オプション ファイルの BLOCK_SIZE オプションで変更することができます。maxlines キーワードは、1 つのメッセージに許される行の最大数を指定します。これらの 2 つの制限は、必要に応じて同時に課すことができます。
メッセージ ヘッダーは、ある程度メッセージのサイズに含まれています。メッセージ ヘッダーを複数のメッセージに分割することはできないにもかかわらず、それ自体が指定されたサイズ制限を越えてしまうこともあるので、メッセージ ヘッダーのサイズを管理するためにかなり複雑な仕組みが使われます。この論理は、MTA オプション ファイルにある MAX_HEADER_BLOCK_USE と MAX_HEADER_LINE_USE オプションによって制御されます。
MAX_HEADER_BLOCK_USE は、0 から 1 までの間の実数を指定するために使用されます。デフォルト値は 0.5 です。この場合、メッセージのヘッダーは、(maxblocks キーワードで指定された) 1つのメッセージが占めることができる合計のブロック数の半分を占めることができます。メッセージ ヘッダーがそれより大きい場合、MTA は MAX_HEADER_BLOCK_USE と maxblocks の積を、ヘッダーのサイズ (ヘッダー サイズは、実際のヘッダー サイズと maxblocks より小さいものとみなされる) としてとります。
たとえば、maxblocks が 10 で MAX_HEADER_BLOCK_USE がデフォルトの 0.5 である場合、5 ブロックより大きいメッセージ ヘッダーは 5 ブロックのヘッダーとして取り扱われ、メッセージのサイズが 5 あるいはそれ以下のブロックの場合、断片化されません。0 を指定すると、メッセージのサイズ制限をあてはめる場合にヘッダーは無視されます。
1 を指定すると、利用可能なサイズのすべてをヘッダーに使うことができます。それぞれの断片は、サイズ制限を超えたかどうかにかかわらず、常に最低 1 行のメッセージ行を含みます。MAX_HEADER_LINE_USE と maxlines キーワードも、同様に動作します。
絶対的なメッセージ サイズ制限 (blocklimit、 linelimit)
メッセージは断片化によって自動的に小さな部分に分割されますた、場合によっては、管理者が指定した制限より大きいメッセージを拒否しなければならないこともあります (たとえば、サービス拒否のアタックを回避するためなど)。blocklimit および linelimit キーワードは、絶対的なサイズ制限を実施するために使用されます。これらのキーワードの後には、それぞれ 1 つの整数値が必要です。blocklimit キーワードは、1 つのメッセージに許されるブロックの最大数を指定します。 MTA は、これよりも多いブロックを含むメッセージがチャネルのキューに入れられるのを拒否します。1 つのMTA ブロックは通常 1024 バイトで、これは MTA オプション ファイルにあるBLOCK_SIZE オプションを使用して変更することができます。
linelimit キーワードは、1 つのメッセージに許される行の最大数を指定します。 MTA は、この数以上の行を含むメッセージがチャネルのキューに入れられるのを拒否します。これらの 2 つのキーワード (blocklimit と linelimit) は、必要に応じて同時に指定することができます。
同じ制限をすべてのチャネルに課すためには、LINE_LIMIT と BLOCK_LIMIT オプションを使用します。これらの制限は、すべてのチャネルに適用できるという利点があります。したがって、MTA サーバは、メッセージ受信情報を得る前に、それをメール クライアントに知らせることができます。この効果によって、メッセージ拒否の処理を簡略化できるプロトコルもあります。
ヘッダーの最大長を指定する (maxprocchars)
たくさんのアドレスを含む長いヘッダー行の処理には、多くのシステム リソースを費やすことがあります。maxprocchars キーワードは、MTA が処理して書き換えることができるヘッダーの最大長を指定するために使用されます。これよりも長いヘッダーを持つメッセージも受け入れられて配信されますが、異なる点は、長いヘッダー行は書き換えられないということです。このキーワードには、1 つの整数引数がともないます。デフォルトでは、どのような長さのヘッダーも処理されます。
メッセージのログ (logging、 nologging)
MTA は、メッセージがキューに出し入れされる度にログを作成することができます。ログ エントリはすべて、ログ ディレクトリ (サーバ_ルート/msg-インスタンス/log/imta/mail.log_current) にある mail.log_current ファイルに記録されます。ログは、チャネルごとに制御されます。logging キーワードは特定のチャネルのログ機能を有効にするもので、nologging キーワードはそれを無効にします。
チャネルのマスター/スレーブ プログラムのデバッギング (master_debug、 nomaster_debug、 slave_debug、 noslave_debug)
チャネル プログラムによっては、デバッグ目的のためにより詳細な診断出力を生成するオプション コードがあるものもあります。このチャネルごとのデバッグとの出力の生成機能を有効にするためのチャネル キーワードには 2 種類あります。master_debug キーワードはマスター プログラムのデバッグ出力を有効にし、slave_debug キーワードはスレーブ プログラムのデバッグ出力を有効にします。デフォルトでは nomaster_debug および noslave_debug が有効になっているため、デバッグ出力は生成されません。デバッグを有効にすると、デバッグ出力は各チャネル プログラムに関連付けられているログ ファイルに記述されます。ログ ファイルの場所はプログラムによって異なりますが、通常は MTA のログ ディレクトリにあります。通常、マスター プログラムには x_master.log という名前 (x はチャネルの名前) のログ ファイルがあり、スレーブ プログラムにはx_slave.log という名前のログファイルがあります。また、チャネル プログラムの中には (特に TCP/IP やファックス チャネル プログラム)、以下の名前の付いたログ ファイルが作成されることもあります。
ローカル チャネルの場合、master_debug はローカル チャネルから送信するときにデバッグ出力を有効にし、slave_debug はローカル チャネルにメッセージが配信されるときにデバッグ出力を有効にします。通常、出力は サーバ_ルート/msg-インスタンス/log/imta/l_master.log 内に記録されます。
配信日指定メッセージの配信 (serviceall、 noserviceall)
マスター プログラムは通常、そのチャネルのキューに入れられたメッセージのサブセットのみを処理します。その他にも、以前チャネルのキューに入れられ、この先処理されないメッセージがあることがあります。ただし、チャネルの中には (特に単一のメール コンポーネントへのリンクを提供するチャネル)、このような操作が適さないものもあります。即時配信ジョブがメール コンポーネントに接続した場合、そのジョブはキュー内のすべてのメッセージを容易に処理することができます。serviceall と noserviceall キーワードはこの動作を制御します。デフォルトの noserviceall を指定すると、マスター プログラムはキューに入っていたメッセージを処理するだけとなります。serviceall を指定すると、マスター プログラムは、メッセージがチャネルのキューに入れられるたびに処理を試行します。
serviceall をほとんど、あるいはすべてのチャネルに使用したいと思うかもしれません。ただし、serviceall の使用は、複数のリモート システムに接続するほとんどのチャネル、あるいはメッセージごとのオーバーヘッドが高いチャネルには適していないことに注意してください。serviceall がそのようなチャネルに使用されると、ネットワークとメッセージ処理のオーバーヘッドが急激に増加し、全体としてのメッセージ処理が遅くなるかもしれません。
これらのキーワードを指定しても、メッセージ処理が行われる順番は変わりません。即時ジョブは常に、処理するために作成されたメッセージを先に処理してから、チャネルのキュー内にある他のメッセージへ移ろうとします。
機密度チェック (sensitivitynormal、 sensitivitypersonal、 sensitivityprivate、 sensitivitycompanyconfidential)
機密度チェックのキーワードは、チャネルが受け入れられる機密度の上限を設定するものです。デフォルトは sensitivitycompanyconfidential で、どの機密度レベルのメッセージも通過を許されます。 Sensitivity: ヘッダーがないメッセージは標準、つまり、機密度が最も低いとみなされます。このようなキーワードで指定された機密度よりも高い機密度が指定されたメッセージは、チャネルのキューに入れられたときに、次のようなエラー メッセージが出され、拒否されます。message too sensitive for one or more paths used (使用されている 1 つ以上の パスに対してメッセージの機密度が高すぎます。)
MTA は、受取人レベルではなくメッセージ レベルでこのような機密度チェックを行うことに注意してください。1 人の受取人の宛先チャネルが機密度チェックに失敗した場合は、そのチャネルに関連する受取人だけでなく、すべての受取人のメッセージが返されます。
SMTP AUTH (maysaslserver、 mustsaslserver、 nosasl、 nosaslserver、 saslswitchchannel)
maysaslserver、mustsaslserver、nosasl、nosaslserver、および saslswitchchannel チャネル キーワードは、SMTP プロトコルが使用される際に、TCP/IP チャネルなどの SMTP チャネルによって SASL (SMTP AUTH) が使用されるように設定するためのものです。デフォルト設定では nosasl が有効になっているため、SASL 認証は許可または試行されません。このキーワードは nosaslserver を包括するため、SASL 認証の使用はすべて禁止されます。 maysaslserver を指定すると、SMTP サーバは、クライアントが SASL 認証の使用を試行することを許可します。 mustsaslserver を指定すると、SMTP サーバは、クライアントが SASL 認証を使用することを要求します。SMTP サーバは、リモート クライアントが認証に成功しない限り、メッセージを受け付けません。
クライアントが SASL の使用に成功したときに受信接続を指定のチャネルに切り替えるには、saslswitchchannel を使います。このキーワードには、切り替え先のチャネルを指定する必要があります。
MAIL FROM: のドメインが DNS 内にあることを確認する (mailfromdnsverify、 nomailfromdnsverify)
mailfromdnsverify を受信 TCP/IP チャネルに対して設定すると、MTA は SMTP の MAIL FROM コマンドで指定されているドメインに DNS 内のエントリが存在するかどうかを確認し、エントリが存在しない場合にはメッセージを拒否します。nonmailfromdnsverify はデフォルトで、そのような確認は行いません。ただし、返信用アドレスに対して DNS 確認を行うと、許可されるべきメッセージも拒否されてしまう可能性があることに注意してください (たとえば、正規のサイトでもそのドメイン名がまだ登録されていない場合や、DNS が適切に動作していない場合など)。これは、RFC 1123 の「Requirements for Internet Hosts (インターネット ホストの必要条件)」で規定されている電子メール受信の心得に反する行為です。ただし、存在しないドメインから偽りの電子メール アドレス宛ての電子メール (SPAM) が送られる場合は、このような確認を行った方がよい場合もあります。
チャネル動作のタイプ (submit)
チャネルを送信専用に設定するには、submit キーワードを使用します。これは通常、特別なポートで実行され、メッセージを送信する目的だけに使用される SMTP サーバなどの TCP/IP チャネルに便利です。
フィルタ ファイルの場所 (filter、 nofilter、 destinationfilter、 nodestinationfilter、 sourcefilter、 nosourcefilter、 fileinto、 nofileinto)
filter キーワードは、そのチャネル用のユーザ フィルタ ファイルの場所を指定するために、l と ims-ms チャネルに対して使用するものです。このキーワードは、フィルタ ファイルの場所を示す URL を引数としてとります。nofilter がデフォルトで、ユーザ メールボックス フィルタがそのチャネルに対して有効にならないことを示します。一般的な MTA チャネルにチャネルレベルのフィルタを指定するには、受信と送信のメッセージに対してそれぞれ sourcefilter と destinationfilter キーワードを使用します。これらのキーワードは、チャネル フィルタ ファイルの場所を示す URL を引数としてとります。nosourcefilter と nodestinationfilter がデフォルトで、チャネルのどちらの方向にもチャネル メールボックス フィルタが無効になります。
fileinto キーワードは、現在、メッセージ ストアに配信する際の ims-ms チャネルに対してのみサポートされており、メールボックス フィルタの fileinto オペレータが適用されるときにどのようにアドレスを変更するかを指定するものです。ims-ms チャネルの場合、通常の使用方法は以下のとおりです。
はじめにあったサブアドレスの代わりに、フォルダ名をサブアドレスとして元のアドレスに挿入します。
ヘッダー内の SMTP AUTH から認証済みアドレスを使用する (authrewrite)
MTA が認証された差出人の情報をヘッダーに含めるようにするために、authrewrite チャネル キーワードをソース チャネルに使用することもできます。FROM_ACCESS マッピングによって無視されることもありますが、通常はSMTP AUTH 情報が使用されます。
TLS (Transport Layer Security) (maytls、 maytlsclient、 maytlsserver、 musttls、 musttlsclient、 musttlsserver、 notlsclient、 notlsserver、 tlsswitchchannel)
maytls、maytlsclient、maytlsserver、musttls、musttlsclient、musttlsserver、notls、notlsclient、notlsserver、および tlsswitchchannel チャネル キーワードは、TCP/IP チャネルなどの SMTP ベースのチャネルが SMTP プロトコルを使用するときに TLS をどのように処理するかを設定するためのキーワードです。notls がデフォルトで、TLS は許可または試行されません。このキーワードは notlsclient キーワード (MTA SMTP クライアントが送信接続に TLS を使用しない) および notlsserver キーワード (MTA SMTP サーバが受信接続に TLS の使用を許可しない) を包括しています。maytls を指定すると、MTA は受信接続に TLS を提供し、送信接続時に TLS を試行します。このキーワードは、maytlsclient (MTA SMTP クライアントは、TLS をサポートする SMTP サーバに送信メッセージを送信するときに TLS の使用を試行する) および maytlsserver (MTA SMTP サーバが STARTTLS 拡張をサポートすることをアドバタイズし、メッセージを受信するときに TLS の使用を許可する) を包括しています。musttls キーワードを指定すると、MTA は送受信接続に必ず TLS を使用します。TLS の使用をネゴシエーションを行うことができなかったリモート システムとの電子メールの交換は許可されません。このキーワードは、musttlsclient (MTA SMTP クライアントはメッセージを送信するときに TLS の使用を要求し、TLS の使用をうまくネゴシエートできない SMTP サーバには送信しない。MTA は STARTTLS コマンドを出し、コマンドは成功しなければならない)、および musttlsserver (MTA SMTP サーバは STARTTLS 拡張をサポートすることをアドバタイズし、メッセージを受信するときに TLS の使用を要求し、TLS の使用のネゴシエートに成功しないクライアントからはメッセージを受け付けない) を包括しています。tlsswitchchannel キーワードは、クライアントが TSL 使用のネゴシエートに成功した場合、受信した接続を指定のチャネルに切り替えるためのキーワードです。このキーワードには、切り替え先のチャネルを指定する必要があります。
エイリアス ファイル
エイリアス ファイルは、ディレクトリで設定されていないエイリアスを設定するのに使用します。よい例として、Postmaster エイリアスが挙げられます。このファイルで設定したエイリアスがディレクトリにもある場合は、ファイル内の設定が無視されます。変更を有効にするには、MTA を再起動する必要があります。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。このファイルでは、一行に入力できる文字数が 252 文字に制限されています。バックスラッシュ (\) を継続文字として使用すれば、1 つの論理行を複数の行に分割することができます。
ファイル フォーマットは以下のとおりです。
ユーザ@domain: <アドレス>
ユーザ@domain: <アドレス>以下に、エイリアス ファイルの例を示します。
! A /var/mail user
mailsrv@siroe.com: mailsrv@native-daemon
!メッセージ ストア ユーザ
ms_testuser@siroe.com: mstestuser@ims-ms-daemon
エイリアス ファイルに他のファイルを含める
プライマリ エイリアス ファイルには、他のファイルを含めることができます。次の行は、MTA に file-spec ファイルを読み込むように指示するためのものです。
<file-spec ファイル仕様は、完全なパスを指定したものでなければなりません。また、そのファイルには、プライマリ エイリアス ファイル ファイルと同じ保護が設定されている必要があります (たとえば、誰でも読み取り可能でなければなりません)。
含めたファイルの内容は、エイリアス ファイル内のリファレンス ポイントに挿入されます。含めたファイルへのリファレンスをそのファイルの実際の内容に置き換えることによっても、同様の効果が得られます。含めたファイルのフォーマットは、プライマリ エイリアス ファイルとまったく同じになります。さらに、含めたファイルに他のファイルを含めることも可能です。ファイルを 3 段階まで含めたネスティングが許可されています。
/var/mail チャネル オプション ファイル
オプション ファイルは、ネイティブ チャネルのさまざまな特徴を制御するために使用されます。このローカル チャネルのオプション ファイルは MTA の設定ディレクトリに保存し、native_option という名前を付けなければなりません (例、サーバ_ルート/msg-インスタンス/imta/config/native_option)。オプション ファイルには複数の行があります。各行には 1 つのオプション設定が含まれています。オプション設定は、以下の形式で記述されます。
オプション=値 「値」は、オプションの要件によって文字列の場合もあれば整数の場合もあります。
SMTP チャネル オプション ファイル
オプション ファイルは、TCP/IP チャネルのさまざまな特徴を制御するために使用されます。このようなオプション ファイルは、MTA 設定ディレクトリ (サーバ_ルート/msg-インスタンス/imta/config) に保存し、x_option という名前を付けなければなりません。この「x」はチャネルの名前です。
ファイルの形式
オプション ファイルには複数の行があります。各行には、1 つのオプション設定が含まれています。オプション設定は、次の形式で記述されています。
オプション=値 「値」は、オプションの要件によって、文字列の場合もあれば整数の場合もありませす。オプションが整数値を受け入れる場合、基数は b%v という記法を用いて指定することができます。この場合、b は底 10 および vb で表される基数です。
使用可能な SMTP チャネル オプション
表 5-8 に、使用可能なオプションを示します。
変換
MTA が行う変換には大きく分けて 2 つのカテゴリがあり、各カテゴリはそれぞれ対応するマッピング テーブルおよび MTA の変換ファイルによって制御されます。最初のカテゴリは MTA が内部で実行する文字セット、フォーマット、およびラベルの変換です。この種の変換は CHARSET-CONVERSION マッピング テーブルによって制御されます。
もう 1 つのカテゴリは、外部サードパーティ プログラムおよびドキュメント コンバータなどのサイトのプロシージャに基づいて行うメッセージ添付ファイルの変換です。この種の変換は CONVERSIONS マッピング テーブルによって制御されます。変換を必要とするメッセージは MTA の変換チャネルに送られその変換チャネルによってサイト指定の外部変換プロシージャが実行されます。
MTA の変換ファイルは、CONVERSION テーブルによってトリガされる外部変換の詳細、および CHARSET-CONVERSION テーブルによってトリガされる内部変換の詳細を指定するために使用されます。
文字セット変換とメッセージ フォーマット変換のマッピング
MTA の基本的なマッピング テーブルの 1 つに、文字セット変換テーブルがあります。CHARSET-CONVERSION という名のこのテーブルは、チャネル間における文字セット変換やメッセージ フォーマット変換の種類を指定するために使用されます。多くのシステムでは、文字セットおよびメッセージ フォーマットの変換は不必要なため、このテーブルが使われることはありません。しかし、文字セット変換の必要性が生じる場合もあります。
CHARSET-CONVERSION マッピング テーブルは、メッセージ フォーマットを変換するためにも使用され、多数の非 MIME フォーマットを MIME に変換することができます。MIME エンコードおよび構造に変更を加えることもできます。これらのオプションは、MIME または MIME のサブセットだけをサポートするシステムにメッセージを送る際に使用されます。また、場合によっては、MIME フォーマットから非 MIME フォーマットへの変換も可能です。
MTA は 2 通りの方法によって CHARSET-CONVERSION マッピング テーブルをプローブします。1 回目のプローブは、MTA がメッセージ フォーマットを変換すべきか、また変換する場合はどのフォーマット オプションを使用すべきかを決定するために実行されます (フォーマット変換が指定されていない場合、特定の文字セットへの変換に関するチェックは行われません)。このプローブには、以下のような形式の入力文字列が使用されます。
IN-CHAN=チャネル (入力);OUT-CHAN=チャネル (出力);CONVERT チャネル (入力)はソース チャネル (メッセージの送信元)、チャネル (出力)は宛先チャネル (メッセージの送信先) を示します。一致するソース チャネルおよび宛先チャネルがある場合は、その結果がカンマで区切られたキーワード リストの文字列として表示されます。表 5-9に、それらのキーワードを一覧します。
文字セット変換およびメッセージ フォーマット変換のマッピングの詳細については、『iPlanet Messaging Server 5.0 管理者ガイド』を参照してください。
変換ファイル
MTA 設定ファイル (imta.cnf) 内 の変換チャネルの設定は、デフォルトで実行されるようになっています。「user@conversion.ローカルホスト名」または user@conversion という形式のアドレスは、CONVERSIONS マッピングの内容に関わらず、すべて変換チャネルを通してルーティングされます。変換チャネルが実行する変換は、MTA の変換ファイル内で定義されている規則によって制御されます。このファイルは、MTA テイラー ファイル内の IMTA_CONVERSION_FILE オプションによって指定されているものであり、デフォルト設定では サーバ_ルート/msg-インスタンス/imta/conversions です。
MTAの変換ファイルは MIME Content-Type パラメータに準拠する形式のエントリを含むテキスト ファイルです。各エントリは 1 つまたは複数のグループ化された行から構成され、各行には 1 つまたは複数の name=値; パラメータ句が含まれています。引用規則は Content-Type ヘッダー行のパラメータに関する MIME の様式に準拠します。最終行以外のすべての行は、セミコロン (;) で終了する必要があります。このファイルでは、一行に入力できる文字数が 252 バイトに制限されています。バックスラッシュ (\) を継続文字として使用すれば、1 つの論理行を複数の行に分割することができます。エントリは、セミコロンで終了していない行や空白行が 1 行以上挿入されているところで終了します。
現在提供されている規則パラメータを 表 5-10に示します。表内にないパラメータは無視されます。
定義済みの環境変数
表 5-11 に、変換コマンドで使用できる基本的な環境変数を示します。
環境変数
説明
コンバータが、封入する MESSAGE/RFC822 部分のヘッダーを保存するファイルの名前です。コンバータはこのファイルの作成/書き込みを行います。
表 5-12 に、変換チャネルで使用できる他のオプションを示します。コンバータ プロシージャは、これらのオプションを使って、変換チャネルに情報を渡すことができます。これらのオプションを設定するには、任意の変換エントリに OVERRIDE-OPTION-FILE=1 を設定し、コンバータ プロシージャによって OUTPUT_OPTIONS ファイル内の目的のオプションが設定されるようにします。
オプション
説明
変換チャネルが出力メッセージ部分を書き出す際に使用するモードで、受取人が出力メッセージ部分を読む取る際に使用するモードです。
必要に応じて、PARAMETER-SYMBOL-n 機能を使い、Content-Type 情報を含む環境変数をさらに作成することができます。
マッピング ファイル
MTA コンポーネントの多くは、テーブル検索に基づいた情報を使用します。一般に、このタイプのテーブルは、入力文字列を出力文字列に変える (マップする) のに使用されます。このようなテーブルは、マッピング テーブルと呼ばれ、通常 2 つのカラムで構成されます。1 つめ (左側) のカラムには入力文字列が、2 つめ (右側) のカラムにはその入力文字列に関連付けられた出力文字列が並んでいます。MTA データベースのほとんどは、このタイプのマッピング テーブルのインスタンスです。ただし、MTA データベース ファイルには、ワイルドカード検索機能がありません。データベース全体でワイルドカードに一致するものを検索するのは非効率的だからです。マッピング ファイルによって、MTA が複数のマッピング テーブルをサポートできるようになります。さらに、完全なワイルドカード機能もあり、複数の手順や反復マッピング方法にも対応しています。このアプローチは、データベースを使用する場合に比べ、さらに多くの処理を必要とします。特に、エントリ数が多い場合などはなおさらです。ただし、それに付随して柔軟性が増すため、同等のデータベースにおけるエントリのほとんどを必要としなくなり、全体的にオーバーヘッドが少なくなります。
マッピング ファイルを検索する/読み込む
マッピングはすべて MTA マッピング ファイルに保存されています (MTA テイラー ファイルの IMTA_MAPPING_FILE オプションで指定されているファイルで、デフォルトは サーバ_ルート/msg-インスタンス/imta/config/mappings です)。マッピング ファイルの内容は、コンパイルされた設定に組み込まれます。マッピング ファイルは、誰でも読み取り可能でなければなりません。誰でも読み取り可能でアクセスできない場合は、誤作動をまねくことになります。
マッピング ファイルのファイル フォーマット
マッピング ファイルは、一連のテーブルで構成されています。各テーブルはその名前で始まり、名前は常に 1 つめのカラムにあり、アルファベット文字を含んでいます。テーブル名の次には必ず空白行が続き、その後にテーブルのエントリが続きます。エントリは、ゼロまたはそれ以上のインデント行で構成されます。各エントリ行は、1 つ以上のスペースまたはタブで区切られた 2 つのカラムから成ります。エントリ内のスペースはすべて文字として認識させる必要があります。各テーブル名の後およびテーブル間には空白行が必要ですが、1 つのテーブル内のエントリ間に空白行があってはなりません。コメントは、1 つめのカラムに記述され、感嘆符 (!) から始まります。つまり、ファイル フォーマットは以下のようになります。
マッピング テーブル「テーブル-2-名前」が使われると、「パターン2-2」という文字列が「テンプレート2-2」で指定されたものにマップされます。各パターンまたはテンプレートには、最高 252 バイトまでの文字まで含めることができます。マッピング テーブルに含まれるエントリの数に制限はありません (ただし、エントリが必要以上に多い場合は、大きな CPU 容量およびメモリ容量を要することになります)。 252 バイト以上の長い行は、バックスラッシュ (\) を行の末尾に置くことで次の行に続けることができます。2 つのカラム間および 1 つめのカラムの前にある空白スペースを削除してはなりません。
マッピング ファイルでマッピング テーブル名が重複することは許されていません。
マッピング ファイルに他のファイルを含める
マッピング ファイルに他のファイルを含めることができます。次の形式の行を使用します。
<file-spec これによって、マッピング ファイル内の file-spec の行が、その実際のファイルに置き換えられます。ファイル指定には、完全なファイル パス (ディレクトリ等) が必要です。この方法で含めるファイルは、誰でも読み取り可能でなければなりません。マッピング ファイルに含めるファイルにはコメントを入れることもできます。含めるファイルは 3 段階までネスティングすることができます。含められたファイルは、マッピング ファイルといっしょに読み込まれます。オンデマンドで読み込まれるのではないため、ファイルを含めることによってパフォーマンスまたはメモリを節約することはできません。
マッピングの動作
マッピング ファイル内のマッピングはすべて一定の方法で適用されます。マッピングごとに異なるのは、入力文字列のソースとマッピング出力の使用目的のみです。マッピングの動作は、常に入力文字列とマッピング テーブルから始まります。マッピング テーブルのエントリは、テーブルに表示される順に上から下へ 1 つずつスキャンされます。各エントリの左側の部分がパターンとして使用され、入力文字列は大文字/小文字の区別なくそのパターンと比較されます。
マッピング エントリのパターン
パターンには、ワイルドカード文字を含めることができます。たとえば、次のような一般的なワイルドカード文字を使用できます。アスタリスク (*) はゼロまたはそれ以上の文字と一致し、パーセント記号 (%) は 1 つの文字に一致します。ドル記号 ($) をアスタリスク、パーセント記号、スペース、およびタブの前に置くことによって、それらの記号を文字として使用できるようになります。アスタリスクまたはパーセント記号を文字として使用した場合は、それらの特殊な定義が無効なります。パターンやテンプレートを正しく認識させるために、その中のスペースやタブは文字として認識させる必要があります。ドル記号を文字として使用するには、2 重のドル記号 ($$) を使用します。この場合、1 つめのドル記号によって、2 つめのドル記号を文字として認識されるようになります。
ワイルドカード
説明
後照合
説明
グローバル ワイルドカード
説明
グロブ内、つまり $[...] 内では、バックスラッシュ文字 (\) は引用符となります。実際のハイフン (-) または右角括弧 (]) をグロブ内で表すには、ハイフンまたは右角括弧にバックスラッシュを付ける必要があります。
パターン内のその他の文字はすべて、文字として使用されます。特に、一重引用符や二重引用符、および括弧は、マッピング パターンやテンプレートにおいて特殊な意味を持たず、通常の文字と見なされます。このため、不正なアドレスや部分的なアドレスに対応するエントリの書き出しが簡単になります。
複数の修飾子、または修飾子および後照合を指定するには、シンタックスにドル記号を 1 つだけ使用します。たとえば、最初のワイルドカードを、後照合そのものを保存せずに後照合するには、$@$0 ではなく $@0 を使用します。
マッピング パターンのテスト、特にパターン内のワイルドカードの動作のテストを行うには、imsimta test -mapping ユーティリティを使用できます。
アスタリスクのワイルドカードは、パターンを左から右へスキャンすることにより、一致する対象を最大化します。たとえば、文字列 a/b/c をパターン */* と比較する場合、左のアスタリスクが「a/b」に一致し、右のアスタリスクが残りの c に一致します。
IPv4 照合
IPv4 照合では、IP アドレスまたはサブネットを指定し、その後にオプションとして照合する際に無視するスラッシュおよびビット数を続けます。以下に例を示します。上の例は、123.45.67.0 サブネットのすべてに一致します。次に、別の例を示します。
これは、123.45.67.4 ～ 123.45.67.7 の範囲のすべてに一致します。
マッピング エントリのテンプレート
指定したエントリのパターン比較に失敗した場合は、何の動作も行われず、次のエントリのスキャンへ移行します。比較が成功した場合には、エントリの右側の部分がテンプレートして使用され、出力文字列が生成されます。このテンプレートによって、入力文字列がテンプレートの指示によって構成された出力文字列に置き換えられます。テンプレート内のほとんどすべての文字が、そのまま出力文字列として生成されますが、ドル記号 ($) は例外です。
ドル記号の後にドル記号、スペース、またはタブが続く場合は、出力文字列内にドル記号、スペース、またはタブが生成されます。これらの文字を出力文字列に挿入するには、引用符を付ける必要があります。
ドル記号の後に数字 n が続く場合は、代替が呼び出されます。ドル記号の後にアルファベット文字が続くものは、「メタ文字」と呼ばれます。メタ文字自体は、テンプレートによって生成される出力文字列に表示されません。特殊代替および標準処理のメタ文字の一覧については、表 5-14 を参照してください。その他のメタ文字はマッピング特有の用途に制限されています。
テンプレートの照合パターン内に $C、$E、$L または $R のいずれかのメタ文字がある場合、それらはマッピング処理に影響を及ぼし、処理の終了または続行を決定します。つまり、1 つのエントリの出力文字列が別のエントリの入力文字列となるような反復的なマッピング テーブル エントリを設定することができます。テンプレートの照合パターン内に $C、$E、$L または $R のどのメタ文字も含まれていない場合は、$E (マッピング処理の即時終了) が行われます。
無限の繰り返しループを避けるために、マッピング テーブル内の反復文字列の回数には制限があります。直前の文字列と同じ長さ、またはそれより長いパターンで「パス (文字列が渡されること)」が行われるたびに、カウンタにおける回数が増加します。文字列が直前のものより短い場合は、カウンタがゼロにリセットされます。カウンタが 10 に達すると、マッピングの反復リクエストは許可されません。
ワイルドカード フィールドの代替 ($n)
ドル記号の後に数字 n が続いている場合、これは、パターン内の n 番めのワイルドカードに一致するデータに置き換えられます。ワイルドカードには、0 から順に番号が付けられています。たとえば、次のエントリは入力文字列 PSI%A::B に一致し、その結果 b@a.psi.network.org という出力文字列を生成します。
PSI$%*::* $1@$0.psi.network.org また、入力文字列 PSI%1234::USER は、出力として生成される USER@1234.psi.network.org と照合されます。入力文字列 PSIABC::DEF は、このエントリ内のパターンに一致しないため、アクションは起こりません。つまり、このエントリから出力文字列は生成されません。
テキストの大文字/小文字を制御する ($\、 $^、 $_)
メタ文字 $\ は後続のテキストを小文字に変換し、メタ文字 $^ は後続のテキストを大文字に変換するものです。また、メタ文字 $_ は、後続のテキストを元々の大文字/小文字の状態で残します。たとえば、これらのメタ文字は、マッピングを使って大文字/小文字の区別が重要なアドレスを変更する際に役立ちます。
制御の処理 ($C、 $L、 $R、 $E)
メタ文字 $C、$L、$R、および $E は、マッピング処理を終了するかどうか、またいつ終了するかなど、マッピング 処理に影響を与えます。これらのメタ文字には、以下の効果があります。
$C は現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、次のエントリからマッピング処理を続行します。
マッピング テーブルのテンプレートは、左から右にスキャンされます。「成功」または「失敗」するエントリ (たとえば、一般データベースの代替またはランダム値で制御されるエントリ) に $C、$L または $R のフラグを設定するには、メタ文字 $C、$L または $R を成功または失敗するエントリ部分の左側に配置します。エントリのそれ以外の部分が失敗しても、フラグは表示されません。$L は、現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、次のエントリからマッピング処理を続行します。一致するエントリが見つからない場合には、もう一度そのテーブルの最初のテーブル エントリから照合を開始します。後続の照合エントリにメタ文字 $C、$E または $R がある場合には、それらのエントリが優先されます。
$R は、現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、テーブルの最初のエントリからマッピング処理を続行します。
エントリがランダムに成功または失敗する ($?x?)
マッピング テーブルのエントリに $?x? というメタ文字がある場合は、これによって、x パーセントの割合でエントリが「成功」します。それ以外の場合、エントリは「失敗」し、マッピング エントリの入力文字列が変更されずにそのまま出力文字列となります (マッピングによっては、エントリが失敗したこととエントリが一致しなかったこととは、必ずしも同義ではありません)。x は、成功率を指定するための実数値です。たとえば、IP アドレスが 123.45.6.78 であるシステムから自分のサイトに送られる電子メールの数が多すぎるため、その数を減らしたいとします。その際、マルチスレッドの TCP 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|* $NTry$ again$ later
シーケンス番号の代替 ($#...#)
$#...# 代替は、MTA シーケンス ファイルに保存されている値を増やし、その値をテンプレート内に入れます。たとえば、マッピング テーブルを使ってファイル名を生成するときなど、マッピング テーブルの出力に固有の修飾子があることが望ましい場合に、シーケンス番号付きの固有文字列を生成することができます。以下のいずれかのシンタックスを使用できます。
$#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 が追加されます。
桁数を明示的に指定する場合は、基数も明示的に指定する必要があります。
上記にあるように、マッピングで参照される MTA シーケンス ファイルは既に存在するものでなければなりません。MTA シーケンス ファイルを作成するには、以下のコマンドを使用します。
touch シーケンスファイル仕様 マッピング テーブルを使ってアクセスされるシーケンス番号ファイルは、誰でも読み取り可能でないと正常に操作できません。また、そのようなシーケンス番号ファイルを使用するには、MTA ユーザ アカウントを持っていなければなりません。
マッピング テーブルの代替 ($|...|)
$|マッピング,引数| 形式の代替は、特殊な方法で処理されます。MTA は、MTA マッピング ファイル内の引数で指定されている補足的なマッピング テーブルを探し、その補足的なマッピング テーブルで引数を入力文字列として使用します。この補足的なマッピング テーブルは既存のものであり、代替が成功した場合にはその出力文字列に $Y フラグを設定しなければなりません。この補足的なマッピング テーブルが存在しなかったり、または $Y フラグを設定しなかった場合には、補足的なマッピング テーブルの代替は失敗し、元のマッピング エントリも失敗と見なされます。この場合は、元の入力文字列が出力文字列として使用されます。マッピング テーブルの代替を行うマッピング テーブル エントリで $C、$R、または $L などの処理制御メタ文字を使用する場合には、処理制御メタ文字をマッピング テーブル テンプレート内のマッピング テーブル代替の左側に配置します。そうしないと、マッピング テーブル代替が「失敗」したときに、処理制御メタ文字が処理されないことになります。
一般データベースの代替 (${...})
${テキスト} 形式の代替は、特殊な方法で処理されます。テキスト部分は、一般データベースにアクセスするためのキーとして使われます。このデータベースは imsimta crdb ユーティリティにより生成されます。テキストがデータベース内のエントリに一致すると、データベース内の対応するテンプレートがその文字列に置き換えられます。テキストがデータベース内のエントリに一致しない場合は、入力文字列がそのまま出力文字列として使用されます。一般データベースは、正しい操作が行われるように誰でも読み取り可能でなければなりません。
一般データベースの代替を行うマッピング テーブル エントリで、$C、$R または $L などの処理制御メタ文字を使用する場合には、処理制御メタ文字をマッピング テーブル テンプレート内の一般データベース代替の左側に配置します。そうしないと、一般データベースの代替が「失敗」したときに、処理制御メタ文字が処理されないことになります。
サイト提供ルーチンの代替 ($[...])
$[イメージ,ルーチン,引数] 形式の代替は、特殊な方法で処理されます。「イメージ,ルーチン,引数」の部分は、カスタマ提供のルーチンを探し、呼び出すために使用されます。実行時に、MTA は dlopen および dlsym を使って、共有ライブラリ「イメージ」から「ルーチン」を動的に読み込み、呼び出します。そのとき、そのルーチンは、以下の引数をともなった関数として呼び出されます。
status = routine (引数, 引数の長さ, 結果, 結果の長さ) 引数および結果 は、252 バイトの文字列バッファです。引数および結果は、文字列のポインタ (たとえば、char* へのポインタ C) として渡されます。引数の長さおよび結果の長さ は、参照によって渡される符号付きの long 型整数です。入力時、引数 にはマッピング テーブル テンプレートからの引数文字列が含まれ、引数の長さにはその文字列の長さが含まれます。値を返すときには、結果に結果文字列が入り、結果の長さにその長さが入ります。この結果文字列が、マッピング テーブル テンプレート内の $[イメージ,ルーチン,引数] に置き換わります。「ルーチン」は、マッピング テーブルの代替が失敗した場合には 0 を返し、成功した場合には -1 を返します。代替が失敗した場合には、通常、元の入力文字列がそのまま出力文字列として使用されます。
サイト提供ルーチンの代替を行うマッピング テーブル エントリで、$C、$R、または $L などの処理制御メタ文字を使用する場合には、処理制御メタ文字をマッピング テーブル テンプレート内のサイト提供ルーチン代替の左側に配置します。そうしないと、マッピング テーブルの代替が「失敗」したときには、処理制御メタ文字が処理されないことになります。
サイト提供ルーチンの呼び出し機構によって、MTA のマッピング処理はさまざまな方法で拡張することができます。たとえば、マッピング テーブル PORT_ACCESS または ORIG_SEND_ACCESS 内で、ロード モニタ サービスへの呼び出しを行い、その結果を使って接続やメッセージを受け入れるかどうかを決定することができます。
「image」(サイト指定の共有ライブラリ イメージ) は、誰でも読み取り可能でなければなりません。
アドレス リバース データベース、REVERSE マッピング、および FORWARD マッピング
アドレス リバースとは、内部形式から公のアドバタイズ形式にアドレスを変換する操作のことです。たとえば、 uid@mailhost.alpha.com はドメイン alpha.com 内では有効なアドレスであっても、ドメイン外から見ると適切なアドレスでない場合があり、first.last@alpha.com がより公式なアドレスとなります。アドレス リバース操作は、デフォルトにより エンベロープ From: をはじめ、すべてのヘッダー アドレスに適用されます。これは、REVERSE_ENVELOPE とシステム オプションの値を設定することにより変更できます。アドレス リバースは、リバース チャネル キーワードを使って、チャネルごとにオン/オフを切り替えることができます。
各ユーザの公式アドレスは、ディレクトリ内のユーザ エントリのメール属性で指定されています。配布リストについても同様です。
リバース データベースには、有効なアドレスと公式アドレス間のマッピングが含まれており、imsmta dirsync により更新/作成されます。
リバース データベースは、imsimta dirsync コマンドを実行するたびに作成されます。
通常、リバース データベースは MTA データベース ディレクトリにあります。このデータベースは、サーバ_ルート/msg-インスタンス/imta/config/imta_tailor ファイルの IMTA_REVERSE_DATABASE オプションで指定される名前のファイルで構成されます。特に設定を変更しない限り、これらのファイルは サーバ_ルート/msg-インスタンス/imta/db/reversedb.* です。
データベース内でアドレスが見つかった場合には、そのデータベースの対応する右側部分がアドレスとして置き換えられます。アドレスが見つからなかった場合は、マッピング ファイルで REVERSE という名前のマッピング テーブルが検索されます。このマッピング テーブルが存在しない場合、またはマッピング テーブル内に一致するエントリがない場合には、代替は行われず、書き換えは通常どおりに終了します。
リバース マッピングもチャネルごとに実行することができます。src_channel| 宛先および channel| 内部アドレスは、*|tcp_local|*@*.siroe.com および $|@siroe.com$Y にマップされる必要があります。
アドレスがマッピング エントリに一致する場合には、マッピングの結果がテストされます。エントリが $Y を指定している場合は、結果の文字列によってアドレスが置き換えられ、エントリが $N を指定している場合は、マッピングの結果が破棄されます。マッピング エントリが $Y のほかに $D を指定している場合には、結果の文字列を使ってもう一度リバース データベースがスキャンされます。一致するエントリが見つかった場合は、データベースのテンプレートによってマッピングの結果 (つまりアドレス) が置き換えられます。
フラグ
説明
フラグの比較
説明
たとえば、siroe.com における内部アドレスが、実際には user@host.siroe.com 形式であるとします。しかし不都合なことに、ユーザ ネーム スペースの関係で、user@hosta.siroe.com と user@hostb.siroe.com のどちらも、siroe.com にあるすべてのホストに対して同じ人物を指してしまいます。このような場合、次に示す非常に簡単な REVERSE マッピングをアドレス リバース データベースとともに使用することができます。
REVERSE
* @ *.siroe.com $0@host.siroe.com$Y$Dこのマッピングは、user@anyhost.siroe.com 形式のアドレスを user@host.siroe.com にマップします。$D というメタ文字によって、アドレス リバース データベースが照合されます。アドレス リバース データベースには、以下の形式のエントリが含まれています。
user@host.siroe.com first.last@siroe.com reverse および noreverse チャネル キーワード、および MTA オプションの USE_REVERSE_DATABASE と REVERSE_ENVELOPE を使って、アドレス リバースが適用されるタイミングと方法を制御できます。特に、宛先チャネルが noreverse キーワードでマークされている場合、そのアドレスにアドレス リバースは適用されません。USE_REVERSE_DATABASE が 0 に設定されている場合は、どのチャネルに関してもアドレス リバースは適用されません。REVERSE_ENVELOPE オプションは、メッセージ ヘッダー アドレスとともにエンベロープ From アドレスにもアドレス リバースを適用するかどうか制御します。これらの効果の詳細については、それぞれのオプションおよびキーワードの説明を参照してください。デフォルトでは、ルーティングの範囲がメール サーバ ドメインに設定されている場合に、アドレス リバース データベースが使用されます。
FORWARD アドレス マッピング
アドレス リバースは、エンベロープ To: アドレスには適用されません。これらのアドレスは、メッセージがメール システム内で処理される際に常に書き換えられ、変更されます。ルーティングの目的は、エンベロープ To: アドレスをシステム固有やメールボックス固有のフォーマットに変換していくことです。アドレス リバースの公認機能は、エンベロープ To: アドレスに対して不適切です。エンベロープ To: アドレスのさまざまな代替機構によって、リバース データベースと同等の機能が提供されますが、リバース マッピングと同じ機能はありません。場合によっては、エンベロープ To: アドレスのマッピング機能が有用で、望ましいとされることもあります。
この不足している機能は、FORWARD マッピング テーブルによって補われます。マッピング ファイル内に FORWARD マッピング テーブルがある場合、それは各エンベロープ To: アドレスに適用されます。このマッピング テーブルがない場合や一致するエントリがマッピング テーブルにない場合、変更は行われません。
アドレスに一致するマッピング エントリがある場合は、マッピングの結果がテストされます。エントリが $Y を指定している場合は、結果の文字列によってエンベロープ To: アドレスが置き換えられ、エントリが $N を指定している場合は、マッピングの結果が破棄されます。
以下に、REVERSE マッピングと FORWARD マッピングの複雑な使用例を示します。native チャネルに関連付けられている am.sigurd.siroe.com という名前のシステムまたは擬似ドメインが、一般的な形式の RFC 822 アドレスを生成するとします。
"lastname, firstname"@am.sigurd.siroe.com または
"lastname,firstname"@am.sigurd.siroe.com これらのアドレスは正式なものですが、RFC 822 シンタックスの規則に準拠しないメール ソフトウェア (たとえば、引用符で囲まれたアドレスを正しく処理できないメール ソフトウェア) を混乱させることがあります。その結果として、引用符を必要としないアドレス フォーマットがより多くのメール ソフトウェアで使用される傾向にあります。たとえば、次のようなフォーマットです。
firstname.lastname@am.sigurd.siroe.com 以下のマッピング ファイル テーブルによって、目的どおりの結果が得られます。この REVERSE マッピングは、MTA のUSE_REVERSE_DATABASE オプションがビット 3 に設定されていることを前提にしています。
オプション ファイル
チャネル オプションとは異なり、グローバルな MTA オプションは MTA オプション ファイルに指定されています。MTA では、オプション ファイルを使って、MTA 全体に適用されるさまざまなパラメータのデフォルト値を無効にすることができます。特に、オプション ファイルは、設定ファイルやエイリアス ファイルが読み込まれるさまざまなテーブルのサイズを確立するのに使用されます。
MTA オプション ファイルを探して読み込む
オプション ファイルとは、IMTA テイラー ファイル (サーバ_ルート/msg-インスタンス/imta/config/imta_tailor) の IMTA_OPTION_FILE オプションで指定されているファイルのことです。デフォルトは サーバ_ルート/msg-インスタンス/imta//config/option.dat です。
オプション ファイルのフォーマットおよび使用可能なオプション
オプション ファイルは複数の行から構成されており、各行にはそれぞれ 1 つのオプション設定が含まれています。オプション設定は、次のフォーマットで記述されます。
option=値 値 は、オプションの要件に基づき、文字列または整数のいずれかとなります。オプションが整数値を受け入れる場合は、b%v の文字列表記規則を使って基数を指定することができます。この場合、b は底 10 で表す基数であり、v は底 b で表す実際の値です。
コメントを使用することもできます。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、オプション ファイルでは、空白行も無視されます。
表 5-16 に、使用可能なオプションを示します。
オプション
説明
MTA には、SunOS オペレーティング システムにおけるグループ ID ベースのチャネルへのアクセスを制限できる機能があります。ACCESS_ERRORS が 0 (デフォルト) に設定されている場合、アクセスに使用できないアドレスがあると MTA によって「不正なホストまたはドメインです。」という旨のエラー メッセージが表示されます。これはアドレスそのものが不正である場合と同じエラーです。紛らわしいようにも思えますが、制限されたチャネルに関する情報が公開されるのを防ぐ場合は、この機能を使用することがセキュリティ上の重要な要素となります。ACCESS_ERRORS を 1 に設定すると、デフォルトが無視され、より詳細なエラーが表示されます。
エイリアス ハッシュ テーブルのサイズを設定します。これは、エイリアス ファイルに定義できるエイリアスの数の上限です。デフォルト値は 256 で、最大値は 32,767 です。
エイリアスの変換値ポインタのリストを含むインデックス テーブルのサイズを制御します。エイリアス ファイル内のすべてのエイリアス定義の右側にあるアドレスの総数は、この値を超えることができません。デフォルト値は 320 で、最大値は 20.000 です。
MTA で送受信されるメッセージのサイズの絶対限界値 (ブロック単位) を指定します。このサイズを超えたメッセージはすべて拒否されます。デフォルトではサイズ制限がありません。ただし、blocklimit チャネル キーワードを使うと、チャネルごとに制限を設定することができます。ブロックのサイズ (バイト単位) は、BLOCK_SIZE オプションで指定されています。
MTA では、いくつかの方法で「ブロック」の概念が使用されています。たとえば MTA ログ ファイル (チャネルに logging キーワードを配置した場合) には、メッセージ サイズがブロック数で記録されます。また、メッセージのサイズが maxblocks キーワードを使って指定されている場合もブロック数で記録されます。通常、MTA ブロックは 1024 バイトです。このオプションは、ブロックの定義を変更するときに使用できます。
メッセージの指定サイズを超えた場合に、メッセージの内容全体ではなく、メッセージ ヘッダーのみを強制的に返送する場合に使用されます。
チャネル テーブルのサイズを制御します。設定ファイル内の合計チャネル数は、この値を超えることができません。デフォルト値は 256 で、最大値は 32,767 です。
変換エントリ テーブルのサイズを制御します。そのため、変換ファイルのエントリ数はこの数を超えることができません。デフォルトは 32 です。
MTA のメッセージ取りだし機能 (QU) からデバッグ出力を生成するかどうかを指定します。1 の値を使って有効になっている場合は、QU ルーチンを使用するすべてのチャネルでこの出力が生成されます。デフォルトは 0 で、この出力は無効になっています。
ドメイン書き換え規則のハッシュ テーブルのサイズを制御します。設定ファイルの各書き換え規則は、このハッシュ テーブルで 1 つのスロットを使用します。そのため、書き換え規則の数はこのオプションの値を超えることができません。デフォルト値は 512 で、書き換え規則の最大数は 32,767 です。
メッセージ ヘッダーにおける送信用アドレス (To、Cc、および Bcc の行) のexproute チャネル キーワードに関する使用を制御します。デフォルト値は 1 で、これは exproute が前方を探すアドレスに影響するように指定するものです。値が 0 の場合は、前方を探すアドレスにおける exproute キーワードによるアクションが無効となります。
返送されたメッセージに挿入される配信試行回数の履歴を制御します。配信履歴には、配信が試行された回数と、場合によっては配信が失敗した理由が表示されます。このオプションのデフォルト値は 20 です。
[Received:] ヘッダー行の数が多すぎるためにメッセージが強制的に保留にされたとき、オペレータによるメッセージの作成を制御します。
チャネル ホスト ハッシュ テーブルのサイズを制御します。MTA 設定ファイルのチャネル定義に指定された各チャネル ホスト (正規のホストとエイリアス) は、このハッシュ テーブルで 1 つのスロットを使用するため、チャネル ホストの総数は指定された値を超えることができません。デフォルト値は 512 で、許容最大値は 32,767 です。
メッセージ ID を作成するときに使用するドメイン名を指定します。デフォルトでは、ローカル チャネルの正規ホスト名が使用されます。
メッセージ ヘッダーにおける前方を探すアドレス (To、Cc、および Bcc の行) のimproute チャネル キーワードに関する使用を制御します。デフォルト値は 1 で、これは improute が前方を探すヘッダー アドレスに影響するように指定するものです。値が 0 の場合は、前方を探すアドレスの improute キーワードによるアクションが無効になります。
MTA で送受信されるメッセージにおける全行数の絶対限界値を指定します。この限界値を超えたメッセージはすべて拒否されます。デフォルトでは、行数の限界値が設定されていません。linelimit チャネル キーワードを使うと、チャネルごとに限界値を設定することができます。
たとえばメッセージを送信する SMTP クライアントのドメイン名など、接続情報を mail.log ファイルに保存するかどうかを指定します。値が 1 の場合は、接続ログが有効になります。値が 0 の場合 (デフォルト) は、ログ処理が無効になります。
メッセージが保存されているファイルの名前を mail.log に保存するかどうかを指定します。値が 1 の場合はファイル名のログ処理が有効になり、値が 0 の場合 (デフォルト) はログ処理が無効になります。
mail.log ファイルのフォーマット オプションを制御します。値が 1 (デフォルト) の場合は標準のフォーマットが使用され、値が 2 の場合は非 null フォーマット (「 < > 」という文字列に変換される空のアドレス フィールド) が要求されます。値が 3 の場合は、カウント済みのフォーマットが要求されます。可変長フィールドの先頭には N が付けられます。この N は、フィールド内の文字数を示します。
MTA が mail.log ファイルにメッセージ ヘッダーを書き込むかどうかを指定します。値が 1 の場合は、メッセージ ヘッダー のログが有効になります。ログ ファイルに書き込まれた特定のヘッダーは、サイトが供給する log_header.opt ファイルによって制御されます。このファイルのフォーマットは、その他の MTA ヘッダー オプション ファイルと同じです。たとえば、次の内容を含む log_header.opt ファイルの場合は、メッセージごとに最初の To ヘッダーと最初の From がログ ファイルに書き込まれます。値が 0 の場合 (デフォルト) は、メッセージ ヘッダーがログされません。
ドメイン名を含んでいないログ済みのアドレスにローカル ホストのドメイン名を追加するかどうかを指定します。値が 1 の場合はこの機能が有効になります。この機能は、MTA を実行する多数のシステムによるログを連結および処理するときに役立ちます。また、値が 0 の場合 (デフォルト) は、この機能が無効になります。
MTA が mail.log ファイルにメッセージ ID を保存するかどうかを指定します。値が 1 の場合は、メッセージ ID のログが有効になります。値が 0 の場合 (デフォルト) はログが行われません。
メールをキューに入れる処理に関連付けられたユーザ名を mail.log ファイルに保存するかどうか指定します。値が 1 の場合はユーザ名がログされ、値が 0 の場合 (デフォルト) はログされません。
マッピング テーブルとネーム テーブルのサイズを指定します。そのため、マッピング テーブルの総数は指定した数を超えることができません。デフォルトは 32 です。
エイリアスの階層レベルを制御します。つまり、エイリアスをどの階層までネスティングさせるか、または 1 つのエイリアスが別のエイリアスを参照するレベルを制御します。デフォルト値は 10 です。
MTA がメモリに保存するメッセージの最大サイズ (MTA ブロック単位) を指定します。このサイズよりも大きいメッセージは一時ファイルに書き込まれます。デフォルトは 10 に設定されています。容量の大きいシステムの場合は、この値を大きくすることにより、パフォーマンスが向上します。
MTA がメッセージを処理する際、正規のローカル ホスト名を参照するメッセージに付属する Received: ヘッダー行がスキャンされます。(MTA が挿入する Received 行にはすべてこの名前が含まれます。) この名前を含む Received 行の数が MAX_LOCAL_RECEIVED_LINES の値を超える場合、メッセージは保留状態として MTA キューに追加されます。オプション ファイルに値が指定されていない場合、デフォルト値の 10 が使用されます。その場合、ある種のメッセージ転送ループがブロックされます。処理を続行するには、メッセージを保留の状態から手作業で移動する必要があります。
MTA が MIME メッセージを処理する最大の深度を指定します。デフォルトは 100 に設定されています。つまり、MTA はメッセージのネスティングを最高 100 レベルまで処理します。
MTA がメッセージを処理する際、メッセージ ヘッダーにある Received: ヘッダー行の数が数えられます。Received 行の数が MAX_RECEIVED_LINES の値を超える場合、メッセージは 保留の状態で MTA キューに追加されます。オプション ファイルに値が指定されていない場合は、デフォルト値である 50 が使用されます。その場合、ある種のメッセージ転送ループがブロックされます。処理を続行するには、メッセージを保留の状態から手作業で移動する必要があります。
サイズに基づいたメッセージの優先度を下げるように MTA に指示を出します。指定のサイズを超えるメッセージは緊急でないレベルまで優先度が下がります。この優先度は、メッセージがすぐに処理されるかどうか、または次回の定期的なジョブ実行までメッセージが待機するかどうかに影響します。
サイズに基づいたメッセージの優先度を下げるように MTA に指示を出します。指定のサイズを超えるメッセージは、緊急でないレベル以下に優先度が下がります。このようなメッセージはすぐに処理されず、次に定期的なジョブが実行されるまで待機します。この値は、BLOCK_SIZE オプションで指定した MTA ブロックの条件に基づいて解釈されます。また、nonurgentblocklimit チャネル キーワードを使って、チャネルごとに低下のしきい値を指定することもできます。
MTA が定期的な配信ジョブを実行するときにデバッグ出力を生成するかどうかを指定します。値が 1 の場合は、この機能が有効となり、post.log ファイルにデバッグ出力が生成されます。デフォルトは 0 で、この出力は無効になっています。
Received ヘッダーを作成するときに使用するドメイン名を設定します。デフォルトでは、ローカル チャネルの正規ホスト名が使用されます。
ローカル postmaster の返信アドレスを設定します。ローカル postmaster のアドレスはデフォルトで「postmaster@ローカルホスト」に設定されていますが、希望のアドレスと置き換えることができます。この場合、アドレスの選択には注意してください。不正なアドレスを選択すると、高速のメッセージ ループが発生し、膨大な数のエラー メッセージが返されることになります。
毎終日実行するメッセージ バウンサー バッチ ジョブのデバッグ出力を有効または無効に設定します。値が 0 の場合はこの出力 (デフォルト) が無効になり、1 の場合は有効になります。デバッグ出力が有効になっている場合、その出力は出力ログ ファイルに記録されます。出力ログ ファイルの有無は、リターン ジョブの crontab エントリよって制御されます。
配信試行の履歴を返送メッセージに挿入するかどうかを指定します。配信履歴には、配信が試行された回数と、場合によっては配信に失敗した理由が表示されます。値が 1 の場合 (デフォルト) はこの情報が履歴に含まれ、値が 0 の場合は含まれません。HISTORY_TO_RETURN オプションは、どれだけの履歴情報が実際に返されるかを制御します。
1 つの整数値を受け入れ、それを一連のビット フラグとして解釈します。ビット 0 (値 = 1) は、MTA が生成した返送通知を空白のエンベロープ アドレスまたはローカル postmaster のアドレスのどちらで書き込むかを指定します。ビットを設定することにより、ローカル postmaster のアドレスが強制的に使用され、ビットをクリアすると空白のアドレスが強制的に使用されます。RFC 1123 の規制により、空白アドレスの使用が義務付けられていますが、システムによっては blank-envelope-from-address を正しく処理できないため、このオプションを使用します。ビット 1 (value = 2) は、MTA ですべての空白エンベロープ アドレスをローカル postmaster のアドレスと置き換えるかどうかを指定します。このオプションも、RFC 821、RFC 822、または RFC 1123 に準拠しないシステムに使用します。returnenvelope チャネル キーワードを使うと、チャネルごとにこの種の制御機能を使用できます。
MTA が postmaster メッセージ (例： 返送メッセージ) を生成するときに使用する個人名を指定します。MTA は、デフォルトで Internet Mail Delivery という文字列を使用します。
MTA がエンベロープの From アドレスとヘッダー アドレスにアドレス リバースを適用するかどうかを指定します。このオプションは、USE_REVERSE_DATABASE オプションが 0 に設定されている場合、またはリバース データベースが存在しない場合には効果を発揮しません。デフォルトは 1 に設定されており、MTA がデータベースをエンベロープの From アドレスに適用しようとします。一方、値が 0 の場合はアドレス リバース データベースが使用されません。
LOG_CONNECTION =1 の設定によって生成された接続ログ情報を通常の MTA メッセージ ログ ファイルである mail.log* に保存するか、または connection.log* ファイルに別途保存するかを指定します。値がデフォルトの 0 に設定されている場合、接続ログ情報は通常のメッセージ ログ ファイルに保存されます。値が 1 の場合、接続ログ情報は別途保存されます。
書き換え規則テンプレートとエイリアス リスト メンバーを保持するためのストリング プールに割当てられる文字スロットの数を制御します。これらの設定部分とエイリアス ファイルによって使われる文字の総数が限界値を超えると、致命的なエラーが発生します。デフォルト値は 60,000 で、許容最大値は 10,000,000 です。
サイズに基づいたメッセージの優先度を下げるように MTA に指示を出します。指定のサイズを超えるメッセージは、通常のレベルまで優先度が下がります。したがって、この優先度は、メッセージがすぐに処理されるかどうか、または次回の定期的なジョブが実行されるまでメッセージが待機するかどうかに影響します。この値は、BLOCK_SIZE オプションで指定している MTA ブロックの条件に基づいて解釈されます。また、urgentblocklimit チャネル キーワードを使って、チャネルごとに低下のしきい値を指定することもできます。
MTA がエイリアス データベースをローカル アドレス用のシステム エイリアス ソースとして使用するかどうかを指定します。値が 1 (デフォルト) の場合は、MTA がエイリアス データベースをチェックします (データベースが存在する場合)。値が 0 の場合、エイリアス データベースは使用されません。
ドメイン データベースの使用を制御します。値が 1 (デフォルト) の場合は、MTA がドメイン データベースをチェックします (データベースが存在する場合)。
メッセージの返送時に、MTA が Errors-to ヘッダー行に含まれる情報を使用するかどうかを指定します。このオプションを 1 に設定すると、このヘッダー行を使用します。値が 0 (デフォルト) の場合、ヘッダー行は使用されません。
MTA がアドレス リバース データベースと REVERSE マッピングを代替アドレスのソースとして使用するかどうかを指定します。この値は、ビットエンコード整数を表す 10 進整数です。表 5-17 に、この値の解釈を示します。
メッセージの返送時に、MTA が Warnings-to ヘッダー行に含まれている情報を使用するかどうかを指定します。このオプションを 1 に設定すると、これらのヘッダー行が使用されます。値が 0 (デフォルト) の場合、ヘッダー行は使用されません。
ヘッダー オプション ファイル
キュー内のメッセージからヘッダーを切り取る方法について記述しているチャネルには、いくつかの特殊なオプション ファイルが関連付けられている場合があります。この機能は一般的なもので、どのチャネルにも適用できます。この機能は、headertrim、noheadertrim、headerread、noheaderread チャネルのキーワードで制御されます。チャネル キーワードのほかに、オプション ファイルを使ってチャネルの動作を設定することもできます。また、チャネルのマスター プログラムが処理したメッセージにあるチャネル固有ヘッダーは、どのチャネルでもヘッダー オプション ファイルを使って作成または削除することができます。
ヘッダー オプション ファイルのフォーマットは、MTA オプション ファイルのフォーマットとは異なります。
ヘッダー オプション ファイルの場所
キューからメッセージを取り出すときに適用されるヘッダー切り取り機能の場合は、config ディレクトリ (サーバ_ルート/msg-インスタンス/config/imta) で チャネル_headers.opt という形式の名前を持つヘッダー オプション ファイルが探し出されます。この「チャネル」は、ヘッダー オプション ファイルが関連付けられているチャネルの名前です。このようなヘッダー オプション ファイルを使用できるようにするには、チャネルで headertrim キーワードを指定しておく必要があります。メッセージを キューに入れるときに適用されるヘッダー切り取り機能については、config ディレクトリ (サーバ_ルート/msg-インスタンス/config/imta) で チャネル_read_headers.opt という形式の名前を持つヘッダー オプション ファイルが探し出されます。この「チャネル」は、ヘッダー オプション ファイルが関連付けられているチャネルの名前です。このようなヘッダー オプション ファイルを使用できるようにするには、チャネルで headerread キーワードを指定しておく必要があります。
ヘッダー オプション ファイルは誰でも読み取り可能でなければなりません。
ヘッダー オプション ファイルのフォーマット
簡単に言うと、ヘッダー オプション ファイルは、一連のメッセージ ヘッダー行から構成されています。ただし、ヘッダー行の本文は RFC 822 に準拠していません。ヘッダー オプション ファイルの一般的な行構造は次のとおりです。
ヘッダー名: オプション=値, オプション=値, オプション=値, ... 「ヘッダー名」は、MTA が認識できるヘッダー行の名前です (このマニュアルで説明されているヘッダー行のほか、RFC 822、RFC 987、RFC 1049、RFC 1421、RFC 1422、RFC 1423、RFC 1424、RFC 1327、および RFC 1521 (MIME) の規格に適合するヘッダー行を指定できます)。
MTA が認識できないヘッダー行は、特殊ヘッダー行名である Other によって制御されます。ヘッダー オプション ファイルで名前の付いていないすべてのヘッダー行に適用される一連のオプションは、特殊な defaults 行にも適用できます。defaults を使用することによって、今後のリリースで MTA のヘッダー行テーブルが必然的に拡大することを防ぐことができます。
さまざまなオプションを指定して、ヘッダー行の保持を制御することができます。表 5-18 に、使用可能なオプションを示します。
テイラー ファイル
MTA テイラー ファイル (imta_tailor) は、さまざまな MTA コンポーネントの場所が設定されているオプション ファイルです。MTA の機能が正常に動作するには、このファイルが サーバ_ルート/msg-インスタンス/config/imta に保存されていなければなりません。このファイルは、特定のインストールにおける変更を反映させるように編集することができます。ただし、このファイルには編集してはならないオプションもあります。ファイルに変更を加えた後は MTA を再起動してください。MTA が停止しているときに変更を行うのが望ましい方法です。オプション設定は、次の形式で記述されています。
オプション=値 「値」は、オプションの要件に基づき、文字列または整数のいずれかとなります。この場合、コメントが使用できます。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。編集できるオプションおよび使用可能なオプションについては、表 5-19 を参照してください。
Dirsync オプション ファイル
このファイルは、コマンド ラインから設定できない dirsync プログラムのオプションを設定するときに使用します。このファイル (dirsync.opt) は、MTA 設定ディレクトリに保存されています。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。このファイルのフォーマットは次のとおりです。
オプション=値 「値」は、オプションの要件に基づいて文字列または整数のいずれかとなります。このファイル内のオプションを変更した場合は、変更後に完全な dirsync 処理を実行してください。使用可能なオプションは以下のとおりです。
自動返信オプション ファイル
このファイルは、自動返信 (すなわち休暇用) プログラムのオプションを設定するときに使用されます。このファイルは、MTA 設定ディレクトリに保存されています。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。このファイルのフォーマットは次のとおりです。
オプション=値 「値」は、オプションの要件に基づいて文字列また整数のいずれかとなります。
使用可能なオプションは以下のとおりです。
ジョブ コントローラ
ジョブ コントローラは、メッセージがチャネル キューに入るたびに、メッセージを配信するためのチャネル ジョブが実行されているかどうかを確認します。これには、新規ジョブ プロセスを開始したり、スレッドを追加したり、またはジョブがすでに実行していることを確認するなどの操作が含まれます。チャネルのジョブ範囲またはプール (例： チャネルの maxjobs キーワードの値、またはジョブ コントローラのプールに対する JOB_LIMIT オプション) の限界に達したためにジョブを開始できない場合、ジョブ コントローラは別のジョブが終了するまで待機し、ジョブの限界範囲内に入ったときに次のジョブを開始します。1 回目の試行でメッセージを配信できない場合、メッセージは該当するバックオフ キーワードによって決められた時間だけ遅れることになります。メッセージはバックオフ キーワードで指定された時間が経過したときに配信できる状態になり、必要に応じてチャネル ジョブがメッセージを処理し始めます。
ジョブ コントローラは、一連の処理プールを管理しています。同じプール内で実行することによって「リソースを共有」できるように、さまざまなチャネルを設定できます。その他のチャネルは、特定のチャネル専用の各プールでそれぞれ実行されるように設定できます。各プール内において、メッセージは優先順位に基づいて異なる処理キュー内に入れられます。その場合、優先順位の高いメッセージは優先順位の低いメッセージより前に処理されることになります。
ジョブ コントローラのメモリ内における処理中メッセージおよび処理待ちメッセージのデータの構造は、ディスクの MTA キュー領域に保存されているメッセージ ファイル全体を反映しています。ただし、ディスク上のメッセージ ファイルのバックログが大きくなり、ジョブ コントローラのメモリ内データ構造サイズ限界値 (MAX_MESSAGES オプションを参照) を超えると、ディスク上のメッセージ ファイルの一部だけしかトラッキングされず、トラッキングの対象となったメッセージだけが処理されます。充分な数のメッセージが配信され、空き領域ができると、ジョブ コントローラは自動的にメモリ内ストアを更新 (MTA キュー領域の更新) してメッセージ リストを更新し、ディスクで待機していたその他のメッセージ ファイルを処理します。通常、このような MTA キュー領域の自動再スキャンは目に見えるものではありませんが、必要に応じて自動的に実行されます。ただし、メッセージのバックログが頻繁に大きくなる場合には、MAX_MESSAGES オプションを使ってジョブ コントローラの動作を調節することができます。ジョブ コントローラによるメモリの使用量を増やすために MAX_MESSAGES オプションの値を大きくすると、メッセージのバックログがジョブ コントローラのメモリ内キャッシュでオーバーフローする回数が少なくなります。したがって、ジョブ コントローラが MTA キュー ディレクトリを再スキャンするための負荷が低減されますが、再スキャンを必要とする場合はメモリ内キャッシュの再構築に要する時間が長くなります (メモリ内キャッシュが大きいため)。また、ジョブ コントローラは起動 (または再起動)のたびに MTA キュー ディレクトリを再スキャンするため、メッセージのバックログが大きい場合 (特に、デフォルトのサイズよりも大きい MAX_MESSAGES がある場合) は、そのようなバックログが存在しない状態で起動または再起動する場合よりもジョブ コントローラに大きな負荷がかかります。
ジョブ コントローラの設定
ジョブ コントローラは、起動時に、パラメータ、プール、およびチャネル処理に関する情報が含まれた設定ファイルを読み取ります。これらの設定情報は、サーバ_ルート/msg-インスタンス/imta/config/ ディレクトリの job_controller.cnf ファイルに保存されています。
ジョブ コントローラ設定ファイル
ジョブ コントローラ設定ファイルは、MTA オプション ファイルのフォーマットに基づいており、次の形式の行を含んでいます。
オプション=値 設定ファイルには、オプション設定のほか、場合によっては以下に示すような角括弧 ([ ]) で囲まれたセクションと値からなる行があります。
[セクション-タイプ=値] この行は、この行に続くオプション設定が「値」で指定されたセクションにのみ適用されることを意味します。このようなセクション タグよりも前に記述されているオプション設定は、すべてのセクションに適用されます。セクションごとに指定されたオプション設定は、そのセクションに対するデフォルトのグローバル設定より優先されます。ジョブ コントローラ設定ファイルの認識可能なセクションのタイプには、プールとそれらのパラメータを定義する POOL、およびチャネル処理情報を定義する CHANNEL があります。
表 5-22 に、使用可能なオプションを示します。
ディスパッチャ
MTA マルチスレッド ディスパッチャとは、指定のサービスにおける負担を共有する複数のマルチスレッド サーバを許可するマルチスレッド接続ディスパッチ エージェントのことです。ディスパッチャを使用すると、複数のマルチスレッド SMTP、POP3、IMAP のサーバを同時に実行できるようになります。1 つのサービスに対して複数のサーバを使用できるほか、各サーバは 1 つ以上のアクティブな接続を同時に処理することができます。
ディスパッチャ設定ファイル
ディスパッチャの設定情報は、サーバ_ルート/msg-インスタンス/imta/dispatcher.cnf ファイルで指定されています。デフォルトの設定ファイルはインストール時に作成され、変更を加えなくても使用できます。ただし、セキュリティやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合には、dispatcher.cnf ファイルを編集します。
設定ファイルのフォーマット
ディスパッチャ設定ファイルのフォーマットは、他の MTA 設定ファイルのフォーマットに似ています。オプションを指定する行は、次の形式で記述されています。
オプション=値 「オプション」はオプション名で、「値」はオプションを設定する文字列または整数です。「オプション」が整数の「値」を受け入れる場合は、b%v という形式の記数法を使って基数を指定できます。b は底 10 で表される基数で、v は底 b で表される実際の値です。これらのオプション仕様は、次の形式の行を使って、サービスごとのセクションにグループ分けされます。
[SERVICE=サービス名] 「サービス名」はサービスの名前です。最初のオプション仕様、すなわちこのようなセクション タグよりも前に記述されているオプション仕様はすべてのセクションに適用されます。
以下に、ディスパッチャ設定ファイル (dispatcher.cnf) の例を示します。
表 5-23 に、使用可能なオプションを示します。
オプション
説明
ソケットの TCP バックログ キュー範囲を指定します。各サービスのデフォルト値は MAX_CONNS*MAX_PROCS です （最低値は 5）。このオプションは、該当する TCP/IP カーネル サポートよりも高く設定しないでください。
デバッグ出力を有効にします。すべてのデバッグ機能を有効にする場合は、オプションを 1 に設定するか、またはシステム全体の論理/環境変数を FFFFFFFF に定義します。表 5-24 に、各ビットの説明を示します。
ENABLE_RBL=1 を指定すると、ディスパッチャは受信接続と maps.vix.com の「Black Hole」リストとの比較を行います。たとえば、ディスパッチャが 192.168.51.32 からの接続を受信すると、ホスト名 192.168.51.32 の IP アドレスを取得しようとします。クエリに成功すると、その接続はワーカー プロセスには渡されるのではなく、閉じることになります。このオプションが、一般的なポート (25、110、または 143) で有効になっている場合は、接続を閉じる前に以下のような標準メッセージが送信されます。
5.7.1 192.168.51.32 からのメールが拒否されました。http://maps.vix.com/rbl/ を参照してください。
このような拒否メッセージを記録するように設定する場合は、ディスパッチャ デバッグ機能の 24 番目の DEBUG オプション DEBUG=16%1000000 を設定して、拒否メッセージが dispatcher.log ファイルに記録されるようにします。エントリは次のような形式になります。
統計をとる目的で、期限切れの接続 (閉じた接続) やプロセス (終了したプロセス) をリスト内に残しておく期間を指定します。
INTERFACE_ADDRESS オプションは、ディスパッチャ サービスがバインドする IP アドレスのインターフェイスを指定するのに使用されます。ディスパッチャは、デフォルトですべての IP アドレスにバインドします。ただし、それぞれに独自の IP アドレスを持つマルチネットワーク インターフェイスがシステムにあると、異なるサービスをいろいろなインターフェイスにバインドするときに役立ちます。サービスに INTERFACE_ADDRESS を指定した場合は、それがディスパッチャ サービスによってバインドされる唯一のインターフェイス IP アドレスとなります。このような専用インターフェイス IP アドレスは、1 つの特定サービスに対して 1 つだけ指定できます (他のインターフェイス IP アドレスには、他の類似したディスパッチャ サービスを定義できます)。
サービスに IDENT=1 が設定されている場合、ディスパッチャは、そのサービスに対する受信接続について IDENT クエリを試み、リモート ユーザ名 (ある場合) をディスパッチャの統計情報の一部として使用します。デフォルトは IDENT=0 に設定されているため、このようなクエリは実行されません。
サーバ プロセスで実行されるイメージを指定します。指定したイメージは、ディスパッチャによって制御されるように設計されたものでなければなりません。
ディスパッチャによって、対応するサーバ プロセスの出力が指定ファイルに直接送られるようになります。LOGFILE には、ファイル仕様にローカル システムのホスト名を含む %s を使用することができます。たとえば freddy ノードの LOGFILE=tcp_smtp_server_%s.log の場合は、ログファイル名がtcp_smtp_server_freddy.log-* になります。
サービス ポートに新たに確立された TCP/IP 接続に対し、ディスパッチャが同時に処理することのできる非同期ハンドオフの最大数を指定します。デフォルト値は 5 です。
サーバ プロセスの最大アイドル時間を指定します。指定した時間内にサーバ プロセスがアクティブにならなかった場合、そのサーバ プロセスはシャットダウンします。このオプションは、このサービスに対するディスパッチャのプールに MIN_PROCS の値よりも多いサーバ プロセスがある場合にのみ有効です。
サーバ プロセスがそのライフタイム (存続可能な期間) で処理できる最大接続数を指定します。これはワーカー プロセスを管理するために使用されます。
指定した秒数の間だけ、サーバ プロセスが保持されるように要求します。これは、ディスパッチャのワーカープロセス管理機能の一部です。サーバ プロセスが作成されると、カウントダウン タイマーが指定した秒数に設定されます。カウントダウン時間を過ぎると、SMTP サーバ プロセスがシャットダウンします。
ディスパッチャがシャットダウンする前のサーバ プロセスの最大数を指定します。サービスに対して最低限の利用可能性を提供するために、シャットダウンすることによってそのサービスのサーバ プロセス数が MAX_SHUTDOWN よりも少なくなる場合、ディスパッチャはそれらのサーバ プロセスをシャットダウンしません。つまり、それらのサーバ プロセスは、シャットダウン「スロット」が空くまで実行し続けます。
使用可能なサーバ プロセスのプールに新しいサーバ プロセスを追加するにあたり、各サーバ プロセスが必要とする最低接続数を決定します。ディスパッチャは、このプール全体にわたって均等に接続を割り当てようとします。
現在のサービスに対してディスパッチャが作成するサーバ プロセスの最小数を決定します。初期化が終了すると、ディスパッチャは、指定された数だけプロセスを作成してプールを開始します。プロセスがシャットダウンしても、このサービスのプールには指定数のプロセス数が残ります。
PARAMETER オプションの解釈および値は、サービスによって異なります。サービスに対し、PARAMETER オプションを CHANNEL=channelname に設定して、デフォルトの TCP/IP チャネルをそのサービスのポートに関連付けることができます。以下に例を示します。
PARAMETER=CHANNEL=tcp_incoming
これは、複数のポートでサーバを実行する場合に便利です (内部 POP クライアントおよび IMAP クライアントが通常のポート番号 25 以外のポートを使用するように設定されており、そのためにメッセージ トラフィックが外部のホストからの SMTP メッセージから切り離されるためです)。また、別の TCP/IP チャネルを他のポート番号に関連付ける場合にも有用です。
現在のサービスに対し、ディスパッチャが受信接続をリッスンする TCP ポートを指定します。このポートで確立された接続は、このサービスに対して作成された SMTP サーバ プロセスの 1 つに転送されます。PORT=0 を指定すると、現在のサービスが無効になります。
サーバのスレッド スタック サイズを指定します。このオプションの目的は、深くネスティングされた MIME メッセージ (数百レベルのネスティング) を処理するときにサーバがスタックを使い切る可能性を低くすることです。このようなメッセージはスパム メッセージである場合が多く、メール ハンドラが破壊される原因となります。したがって、サーバを異常停止させることにより、他のメール ハンドラを保護することができます。
デバッグとログ ファイル
ディスパッチャ エラーとデバッグ出力 (有効になっている場合) は、MTA ログ ディレクトリ内の dispatcher.log ファイルに書き込まれます。デバッグ出力は、ディスパッチャ設定ファイルの DEBUG オプションを使って有効にするか、または IMTA_DISPATCHER_DEBUG 環境変数 (UNIX) を使ってプロセス レベルで有効にすることができます。
DEBUG オプションまたは IMTA_DISPATCHER_DEBUG 環境変数 (UNIX) は、16 進数で 32 ビットのデバッグ マスクを定義するものです。すべてのデバッグ機能を有効にするには、オプションを 1 に設定するか、またはシステム全体で論理/環境変数を FFFFFFFF に定義します。表 5-24 に、各ビットの説明を示します。
ビット
16 進数値
10 進数値
使用目的
Solaris のシステム パラメータ
システムのヒープ サイズ (datasize) は、ディスパッチャによるスレッド スタックの使用を考慮して十分なサイズに設定する必要があります。各ディスパッチャ サービスに対して、STACKSIZE*MAX_CONNS を計算し、それらの計算値を合計します。システムのヒープ サイズは、この合計値の 2 倍以上でなければなりません。ヒープ サイズ (すなわち、デフォルトの datasize) を表示するには、csh コマンドを使用します。
前へ 目次 索引 次へ
Copyright (c) 2000 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2000 Netscape Communications Corp. All rights reserved.
最終更新日 2000 年 9 月 14 日