Sun Java System Messaging Server 6 2005Q4 管理ガイド

第 12 章チャネル定義を設定する

この章では、MTA 設定ファイル imta.cnf でのチャネルキーワード定義の使用方法について説明します。この章を読む前に、第 10 章「MTA サービスと設定について」、「チャネル定義」、および「MTA 設定ファイル」をお読みください。この章には、次の節があります。

注 –

imta.cnf 内のチャネル定義を変更する場合は、imsimta restart コマンドを使って起動するときに設定データを 1 回だけ読み込むようなプログラムまたはチャネルを再起動する必要があります (例: SMTP サーバー)。コンパイルされた設定を使用する場合は、設定を再コンパイルしたあとにプログラムを再起動する必要があります。設定情報のコンパイルおよびプログラムの起動については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

チャネルのデフォルトを設定する

設定ファイルにはさまざまなチャネルキーワードが繰り返し記述されていることがあります。このような設定を管理するには時間がかかり、エラーの原因にもなります。複数のチャネルに対してデフォルトのキーワードを指定すると、設定を簡素化することができます。

たとえば、次の行を設定ファイルに追加すると、行中で指定したキーワードがそれ以降のすべてのチャネルブロックに適用されます。

defaults keyword1 keyword2 keyword3 ...

defaults 行はチャネルを特定せずにデフォルトのキーワードを変更するための特殊なチャネルブロックだと考えられます。また、defaults 行にほかのチャネルブロック情報を指定する必要はありません (指定しても無視される)。

1 つのファイルに使用できる defaults 行の数に上限はありません。複数の defaults 行を指定した場合、ファイルの下へ行くほど (あとで追加した行ほど) 優先度が高くなります。

設定ファイル内のある位置 (たとえば、外部ファイルのチャネルブロックの独立したセクションの冒頭など) 以降には無条件に defaults 行が適用されないように設定しておく方がよい場合もあります。そのためには、nodefaults 行を使用します。たとえば、次の行を設定ファイルに挿入すると、それ以前の部分で defaults を使って指定した設定がすべて無効になり、defaults を使用していないのと同じ状態に戻ります。

nodefaults

ほかのチャネルブロックと同様に、defaults や nodefaults チャネルブロックを使用する場合も、ブロック間の区切りには空白行を使用します。設定ファイル内でローカルチャネルの前に記述できるチャネルブロックは、defaults と nodefaults のみです。ただし、ほかのチャネルブロックと同様、書き換えルールの前に記述することはできません。

チャネルキーワードの一覧 (アルファベット順)

次の表にキーワードの一覧をアルファベット順に示します。

表 12–1 チャネルキーワード (アルファベット順)


キーワード	詳細の参照先
733	「アドレスのタイプとルール」
822	「アドレスのタイプとルール」
`addreturnpath`	「Return-path: ヘッダー行を生成する」
`addrsperfile`	「制限容量超過ユーザーへのメール配信を処理する」
`Aliasdetourhost`	「アドレス検証の後、かつアドレス拡張の前のルーティング」
`aliaslocal`	「エイリアスファイルとエイリアスデータベースプローブを指定する」
`aliaspostmaster`	「ポストマスター返送メッセージの内容」
`allowetrn`	「ETRN コマンドのサポート」
`allowswitchchannel`	「着信メール用代替チャネル (切り替えチャネル)」
`alternatechannel`	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」
`alternateblocklimit`	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」
`alternatelinelimit`	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」
`alternaterecipientlimit`	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」
`authrewrite`	「TCP/IP 接続と DNS 検索のサポート」
`backoff`	「配信失敗メッセージの再配信回数を指定する」
`bangoverpercent`	「アドレスにルーティング情報を追加する」
`bangstyle`	「アドレスのタイプとルール」
`bidirectional`	「チャネルの方向性を設定する」
`blocketrn`	「ETRN コマンドのサポート」
`blocklimit`	「絶対的なメッセージサイズ制限を指定する」
`cacheeverything`	「チャネル接続情報のキャッシング」
`cachefailures`	「チャネル接続情報のキャッシング」
`cachesuccesses`	「チャネル接続情報のキャッシング」
`channelfilter`	「メールボックスフィルタファイルの場所を指定する」
`charset7`	「文字セットのラベルと 8 ビットデータ」
`charset8`	「文字セットのラベルと 8 ビットデータ」
`charsetesc`	「文字セットのラベルと 8 ビットデータ」
`checkehlo`	「EHLO コマンドのサポート」
`commentinc`	「アドレスヘッダー行内のコメントを処理する」
`commentmap`	「アドレスヘッダー行内のコメントを処理する」
`commentomit`	「アドレスヘッダー行内のコメントを処理する」
`commentstrip`	「アドレスヘッダー行内のコメントを処理する」
`commenttotal`	「アドレスヘッダー行内のコメントを処理する」
`connectalias`	「メッセージがキューから取り出されるときのアドレス書き換え」
`connectcanonical`	「メッセージがキューから取り出されるときのアドレス書き換え」
`copysendpost`	「返送された配信不能メッセージ」
`copywarnpost`	「警告メッセージ」
`daemon`	「ターゲットホストの選択」
`datefour`	「日付表示を 2 桁から 4 桁に変換する」
`datetwo`	「日付表示を 2 桁から 4 桁に変換する」
`dayofweek`	「日付の曜日を指定する」
`defaulthost`	「不完全なアドレスを修正する際に使用するホスト名を指定する」
`defaultmx`	「TCP/IP MX レコードのサポート」
`defaultnameservers`	「ネームサーバー検索」
`deferralrejectlimit`	「不正な `RCPT TO` アドレスに制限を設定する」
`deferred`	「指定配信日を実行する」
`defragment`	「メッセージあるいは部分メッセージの自動再組み立て」
`dequeue_removeroute`	「ソースルートを削除する」
`destinationfilter`	「メールボックスフィルタファイルの場所を指定する」
`destinationnosolicit`	「非請求の SMTP 拡張のサポート」
destinationspamfilterXoptin	「スパムフィルタのキーワード」
`disableetrn`	「ETRN コマンドのサポート」
`dispositionchannel`	「プロセスチャネルのオーバーライド」
`disconnectbadauthlimit`	「認証の試行失敗回数の制限」
disconnectbadcommandlimit	「セッションの制限を設定する」
`domainetrn`	「ETRN コマンドのサポート」
`domainvrfy`	「VRFY コマンドのサポート」
`dropblank`	「不正な空白の受取人ヘッダーを削除する」
`ehlo`	「EHLO コマンドのサポート」
`eightbit`	「文字セットのラベルと 8 ビットデータ」
`eightnegotiate`	「文字セットのラベルと 8 ビットデータ」
`eightstrict`	「文字セットのラベルと 8 ビットデータ」
`errsendpost`	「返送された配信不能メッセージ」
`errwarnpost`	「警告メッセージ」
`expandchannel`	「複数アドレスの拡張」
`expandlimit`	「複数アドレスの拡張」
`expnallow`	「EXPN サポート」
`expndisable`	「EXPN サポート」
`expndefault`	「EXPN サポート」
`exproute`	「アドレスにルーティング情報を追加する」
`fileinto`	「メールボックスフィルタファイルの場所を指定する」
`filesperjob`	「サービスジョブの制限」
`filter`	「メールボックスフィルタファイルの場所を指定する」
`forwardcheckdelete`	「リバース DNS 検索」
`forwardchecknone`	「リバース DNS 検索」
`forwardchecktag`	「リバース DNS 検索」
`header_733`	「アドレスのタイプとルール」
`header_822`	「アドレスのタイプとルール」
`header_uucp`	「アドレスのタイプとルール」
`headerlabelalign`	「ヘッダーの配置と折り返し」
`headerlimit`	「ヘッダーのサイズを制限する」
`headerlinelength`	「ヘッダーの配置と折り返し」
`headerread`	「メッセージヘッダー行を選択して削除する」
`headertrim`	「メッセージヘッダー行を選択して削除する」
`holdexquota`	「制限容量超過ユーザーへのメール配信を処理する」
`holdlimit`	「複数アドレスの拡張」
`identnone`	「IDENT 検索」
`identnonelimited`	「IDENT 検索」
`identnonenumeric`	「IDENT 検索」
`identnonesymbolic`	「IDENT 検索」
`identtcp`	「IDENT 検索」
`identtcplimited`	「IDENT 検索」
`identtcpsymbolic`	「IDENT 検索」
`ignoreencoding`	「Encoding ヘッダー行を無視する」
`immnonurgent`	「指定配信日を実行する」
`improute`	「アドレスにルーティング情報を追加する」
`includefinal`	「ステータス通知メッセージに代替アドレスを含めるには」
`inenttcpnumeric`	「IDENT 検索」
`inner`	「埋め込まれたヘッダーを書き換える」
`innertrim`	「メッセージヘッダー行を選択して削除する」
`interfaceaddress`	「TCP/IP ポート番号とインタフェースアドレス」
`interpretencoding`	「Encoding ヘッダー行を無視する」
`language`	「ヘッダーのデフォルト言語を設定する」
`lastresort`	「最後のホスト」
`linelength`	「メッセージ行の長さを制限する」
`linelimit`	「絶対的なメッセージサイズ制限を指定する」
`localvrfy`	「VRFY コマンドのサポート」
`logging`	「ログ記録のキーワード」
`logheader`	「ログ記録のキーワード」
`loopcheck`	「Loopcheck を設定する」
`mailfromdnsverify`	「DNS ドメイン確認」
`master`	「チャネルの方向性を設定する」
`master_debug`	「デバッグのキーワード」
`maxblocks`	「大きなメッセージの自動断片化」
`maxheaderaddrs`	「長いヘッダー行を自動分割する」
`maxheaderchars`	「長いヘッダー行を自動分割する」
`maxjobs`	「サービスジョブの制限」
`maxlines`	「大きなメッセージの自動断片化」
`maxprocchars`	「ヘッダーの配置と折り返し」
`maysaslserver`	「SMTP 認証、SASL、TLS」
`maytls`	「Transport Layer Security」
`maytlsclient`	「Transport Layer Security」
`maytlsserver`	「Transport Layer Security」
`missingrecipientpolicy`	「受取人ヘッダー行がないメッセージを有効にする」
`msexchange`	「Microsoft Exchange ゲートウェイチャネルを指定する」
`multiple`	「制限容量超過ユーザーへのメール配信を処理する」
`mustsaslserver`	「SMTP 認証、SASL、TLS」
`musttls`	「Transport Layer Security」
`musttlsclient`	「Transport Layer Security」
`musttlsserver`	「Transport Layer Security」
`mx`	「TCP/IP MX レコードのサポート」
`namelengthlimit`	「General Content-type、Filename Content-type、および Content-disposition パラメータの長さを制御する」
`nameservers`	「ネームサーバー検索」
`noaddreturnpath`	「Return-path: ヘッダー行を生成する」
`nobangoverpercent`	「アドレスにルーティング情報を追加する」
`noblocklimit`	「絶対的なメッセージサイズ制限を指定する」
`nocache`	「チャネル接続情報のキャッシング」
`nochannelfilter`	「メールボックスフィルタファイルの場所を指定する」
`nodayofweek`	「日付の曜日を指定する」
`nodefaulthost`	「不完全なアドレスを修正する際に使用するホスト名を指定する」
`nodeferred`	「指定配信日を実行する」
`nodefragment`	「メッセージあるいは部分メッセージの自動再組み立て」
`nodestinationfilter`	「メールボックスフィルタファイルの場所を指定する」
`nodropblank`	「不正な空白の受取人ヘッダーを削除する」
`noehlo`	「EHLO コマンドのサポート」
`noexproute`	「アドレスにルーティング情報を追加する」
`noexquota`	「制限容量超過ユーザーへのメール配信を処理する」
`nofileinto`	「メールボックスフィルタファイルの場所を指定する」
`nofilter`	「メールボックスフィルタファイルの場所を指定する」
`noheaderread`	「メッセージヘッダー行を選択して削除する」
`noheadertrim`	「メッセージヘッダー行を選択して削除する」
`noimproute`	「アドレスにルーティング情報を追加する」
`noinner`	「埋め込まれたヘッダーを書き換える」
`noinnertrim`	「メッセージヘッダー行を選択して削除する」
`nolinelimit`	「絶対的なメッセージサイズ制限を指定する」
`nologging`	「ログ記録のキーワード」
`noloopcheck`	「Loopcheck を設定する」
`nomailfromdnsverify`	「DNS ドメイン確認」
`nomaster_debug`	「デバッグのキーワード」
`nomsexchange`	「TCP/IP 接続と DNS 検索のサポート」
`nomx`	「TCP/IP MX レコードのサポート」
`norandomemx`	「TCP/IP MX レコードのサポート」
`nonurgentbackoff`	「配信失敗メッセージの再配信回数を指定する」
`nonurgentblocklimit`	「サイズに基づくメッセージの優先度」
`nonurgentnotices`	「通知メッセージの配信間隔を設定するには」
`noreceivedfor`	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」
`noreceivedfrom`	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」
`noremotehost`	「不完全なアドレスを修正する際に使用するホスト名を指定する」
`norestricted`	「制限されたメールボックスのエンコーディングを有効にする」
`noreturnaddress`	「ポストマスター返送メッセージの内容」
`noreturnpersonal`	「ポストマスター返送メッセージの内容」
`noreverse`	「チャネル固有のリバースデータベースの使用を有効にする」
`normalbackoff`	「配信失敗メッセージの再配信回数を指定する」
`normalblocklimit`	「サイズに基づくメッセージの優先度」
`normalnotices`	「通知メッセージの配信間隔を設定するには」
`norules`	「チャネル固有の書き換えルールチェックを有効にする」
`nosasl`	「SMTP 認証、SASL、TLS」
`nosaslserver`	「SMTP 認証、SASL、TLS」
`nosaslswitchchannel`	「SMTP 認証、SASL、TLS」
`nosendetrn`	「ETRN コマンドのサポート」
`nosendpost`	「返送された配信不能メッセージ」
`noservice`	「サービス変換を有効にする」
`noslave_debug`	「デバッグのキーワード」
`nosmtp`	「チャネルプロトコル選択と改行記号」
`nosourcefilter`	「メールボックスフィルタファイルの場所を指定する」
`noswitchchannel`	「着信メール用代替チャネル (切り替えチャネル)」
`notices`	「通知メッセージの配信間隔を設定するには」
`notificationchannel`	「プロセスチャネルのオーバーライド」
`notls`	「Transport Layer Security」
`notlsclient`	「Transport Layer Security」
`notlsserver`	「Transport Layer Security」
`novrfy`	「VRFY コマンドのサポート」
`nowarnpost`	「警告メッセージ」
`nox_env_to`	「X-Envelope-to ヘッダー行を生成するまたは削除する」
`parameterlengthlimit`	「General Content-type、Filename Content-type、および Content-disposition パラメータの長さを制御する」
`percentonly`	「アドレスにルーティング情報を追加する」
`percents`	「アドレスのタイプとルール」
`personalinc`	「アドレスヘッダー行内の個人名を処理する」
`personalmap`	「アドレスヘッダー行内の個人名を処理する」
`personalomit`	「アドレスヘッダー行内の個人名を処理する」
`personalstrip`	「アドレスヘッダー行内の個人名を処理する」
`pool`	「チャネル実行ジョブの処理プール」
`port`	「TCP/IP ポート番号とインタフェースアドレス」
`postheadbody`	「ポストマスター返送メッセージの内容」
`postheadonly`	「ポストマスター返送メッセージの内容」
`randommx`	「TCP/IP MX レコードのサポート」
`receivedfor`	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」
`receivedfrom`	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」
`recipientcutoff`	「メッセージの受取人を制限する」
`recipientlimit`	「メッセージの受取人を制限する」
`rejectsmtplonglines`	「1000 文字を超える行を含む SMTP メールを処理する」
`remotehost`	「不完全なアドレスを修正する際に使用するホスト名を指定する」
`restricted`	「制限されたメールボックスのエンコーディングを有効にする」
`returnaddress`	「ポストマスター返送メッセージの内容」
`returnenvelope`	「空白のエンベロープ返信アドレス」
`returnpersonal`	「ポストマスター返送メッセージの内容」
`reverse`	「チャネル固有のリバースデータベースの使用を有効にする」
`routelocal`	「明示的なルーティングアドレスの書き換えを無効にする」
`rules`	「チャネル固有の書き換えルールチェックを有効にする」
`saslswitchchannel`	「SMTP 認証、SASL、TLS」
`sendetrn`	「ETRN コマンドのサポート」
`sendpost`	「返送された配信不能メッセージ」
sensitivitycompanyconfidential	「機密度チェック」
`sensitivitynormal`	「機密度チェック」
`sensitivitypersonal`	「機密度チェック」
`sensitivityprivate`	「機密度チェック」
`service`	「サービス変換を有効にする」
`sevenbit`	「文字セットのラベルと 8 ビットデータ」
`silentetrn`	「ETRN コマンドのサポート」
`single`	「制限容量超過ユーザーへのメール配信を処理する」
`single_sys`	「ターゲットホストの選択」
`slave`	「チャネルの方向性を設定する」
`slave_debug`	「デバッグのキーワード」
`smtp`	「チャネルプロトコル選択と改行記号」
`smtp_cr`	「チャネルプロトコル選択と改行記号」
`smtp_crlf`	「チャネルプロトコル選択と改行記号」
`smtp_crorlf`	「チャネルプロトコル選択と改行記号」
`smtp_lf`	「チャネルプロトコル選択と改行記号」
`sourceblocklimit`	「絶対的なメッセージサイズ制限を指定する」
`sourcecommentinc`	「アドレスヘッダー行内のコメントを処理する」
`sourcecommentmap`	「アドレスヘッダー行内のコメントを処理する」
`sourcecommentomit`	「アドレスヘッダー行内のコメントを処理する」
`sourcecommentstrip`	「アドレスヘッダー行内のコメントを処理する」
`sourcecommenttotal`	「アドレスヘッダー行内のコメントを処理する」
`sourcefilter`	「メールボックスフィルタファイルの場所を指定する」
`sourcenosolicit`	「非請求の SMTP 拡張のサポート」
`sourcepersonalinc`	「アドレスヘッダー行内の個人名を処理する」
`sourcepersonalmap`	「アドレスヘッダー行内の個人名を処理する」
`sourcepersonalomit`	「アドレスヘッダー行内の個人名を処理する」
`sourcepersonalstrip`	「アドレスヘッダー行内の個人名を処理する」
`sourceroute`	「アドレスのタイプとルール」
`sourcespamfilterXoptin`	「スパムフィルタのキーワード」
`streaming`	「プロトコルストリーミング」
`subaddressexact`	「サブアドレスを処理する」
`subaddressrelaxed`	「サブアドレスを処理する」
`subaddresswild`	「サブアドレスを処理する」
`subdirs`	「複数のサブディレクトリにチャネルメッセージキューを拡散する」
`submit`	「チャネル動作のタイプ」
`suppressfinal`	「ステータス通知メッセージに代替アドレスを含めるには」
`switchchannel`	「着信メール用代替チャネル (切り替えチャネル)」
`threaddepth`	「SMTP チャネルスレッド」
`tlsswitchchannel`	「Transport Layer Security」
`transactionlimit`	「接続トランザクションの制限を設定する」
`truncatesmtplonglines`	「1000 文字を超える行を含む SMTP メールを処理する」
`unrestricted`	「制限されたメールボックスのエンコーディングを有効にする」
`urgentbackoff`	「配信失敗メッセージの再配信回数を指定する」
`urgentblocklimit`	「サイズに基づくメッセージの優先度」
`urgentnotices`	「通知メッセージの配信間隔を設定するには」
`useintermediate`	「ステータス通知メッセージに代替アドレスを含めるには」
`user`	「pipe チャネル」
`uucp`	「アドレスのタイプとルール」
`viaaliasoptional`	「エイリアスからアドレスを指定する」
`viaaliasrequired`	「エイリアスからアドレスを指定する」
`vrfyallow`	「VRFY コマンドのサポート」
`vrfydefault`	「VRFY コマンドのサポート」
`vrfyhide`	「VRFY コマンドのサポート」
`warnpost`	「警告メッセージ」
`wrapsmtplonglines`	「1000 文字を超える行を含む SMTP メールを処理する」
`x_env_to`	「X-Envelope-to ヘッダー行を生成するまたは削除する」

機能別チャネルキーワード

次の表に分類したキーワードの一覧を示します。各表およびその種類は次のとおりです。

表 12–2 アドレス処理のキーワード
表 12–3 添付と MIME 処理
表 12–4 文字セットと 8 ビットデータ
表 12–5 MTA キュー領域でのファイル作成
表 12–6 ヘッダーのキーワード
表 12–7 着信チャネルの一致と切り替えのキーワード
表 12–8 ログ記録とデバッグのチャネルキーワード
表 12–9 長いアドレスリストやヘッダーのチャネルキーワード
表 12–10 メールボックスフィルタのチャネルキーワード
表 12–11 非請求の SMTP 拡張サポートのキーワード
表 12–12 通知メッセージとポストマスターメッセージのキーワード
表 12–13 処理制御とジョブ送信のキーワード
表 12–14 重要度の上限のキーワード
表 12–15 メッセージの制限、ユーザー制限容量、権限、認証の試行のキーワード
表 12–16 SMTP 認証、SASL、TLS のキーワード
表 12–17 SMTP コマンドとプロトコルのキーワード
表 12–18 TCP/IP 接続と DNS 検索サポートのキーワード
表 12–19 その他のキーワード

表 12–2 アドレス処理のキーワード


キーワード	ページ	定義
アドレス処理
733	エンベロープで % ルーティングを使用します。`percents` と同義。「アドレスのタイプとルール」
822	「アドレスのタイプとルール」エンベロープでソースルートを使用します。`sourceroute` と同義。
addreturnpath	「Return-path: ヘッダー行を生成する」このチャネルのキューに入れるメッセージに `Return-path:` ヘッダーを追加します。
aliaslocal	「エイリアスファイルとエイリアスデータベースプローブを指定する」書き換えられたアドレスをエイリアスファイルとエイリアスデータベースで検索します。
authrewrite	「TCP/IP 接続と DNS 検索のサポート」認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用します。
bangoverpercent	「アドレスにルーティング情報を追加する」 A!B%C を A!(B%C) としてグループ化します。
bangstyle	「アドレスのタイプとルール」エンベロープで UUCP! ルーティングを使用します。`uucp` と同義。
defaulthost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるためにドメイン名を指定します。
dequeue_removeroute	「ソースルートを削除する」エンベロープの `To:` アドレスからソースルートを削除します。
exproute	「アドレスにルーティング情報を追加する」アドレスをリモートシステムに渡す際に明示的なルーティングを要求します。
holdlimit	「複数アドレスの拡張」エンベロープ受取人アドレス数がこの制限を越えた場合、メッセージを保留します。
improute	「アドレスにルーティング情報を追加する」このチャネルのアドレスに対して黙示的なルーティングを実行します。
missingrecipientpolicy	「受取人ヘッダー行がないメッセージを有効にする」受取人ヘッダーがないメッセージを有効にする (どのヘッダーを追加するか指定する) ポリシーを設定します。
noaddreturnpath	「Return-path: ヘッダー行を生成する」メッセージをキューに入れる際に、メッセージに `Return-path:` ヘッダーを追加しません。
nobangoverpercent	「アドレスにルーティング情報を追加する」 A!B%C を (A!B)%C としてグループ化します。
nodefaulthost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるために使用する、ドメイン名を指定しません。
noexproute	「アドレスにルーティング情報を追加する」このチャネルのアドレスに対して明示的なルーティングを実行しません。
noimproute	「アドレスにルーティング情報を追加する」このチャネルのアドレスに対して黙示的なルーティングを実行しません。
noreceivedfrom	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」元のエンベロープの From: アドレスを含めずに `Received:` ヘッダー行を作成します。
noremotehost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるために、ローカルホストのドメイン名をデフォルトのドメイン名として使用します。
norestricted	「制限されたメールボックスのエンコーディングを有効にする」 `unsrestricted` と同じ。
noreverse	「チャネル固有のリバースデータベースの使用を有効にする」メッセージのアドレスを、アドレスリバース処理から外すことを指定します。
norules	「チャネル固有の書き換えルールチェックを有効にする」このチャネル固有の書き換えルールを確認しません。
percentonly	「アドレスにルーティング情報を追加する」 bang パスを無視します。エンベロープで % ルーティングを使用します。
percents	「アドレスのタイプとルール」エンベロープで % ルーティングを使用します。`733` と同義。
remotehost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるために、リモートホストの名前をデフォルトのドメイン名として使用します。
restricted	「制限されたメールボックスのエンコーディングを有効にする」チャネルは、エンコーディングを必要とするメールシステムに接続します。
reverse	「チャネル固有のリバースデータベースの使用を有効にする」アドレスリバースデータベースまたは REVERSE マッピングに対してアドレスを確認します。
routelocal	「明示的なルーティングアドレスの書き換えを無効にする」アドレスをチャネルに書き換える際に、MTA がアドレスのすべての明示的ルーティングの「短絡化」を試行するようにします。
rules	「チャネル固有の書き換えルールチェックを有効にする」このチャネル固有の書き換えルールを確認します。
sourceroute	「アドレスのタイプとルール」 `822` と同義。
subaddressexact	「サブアドレスを処理する」エントリの一致の確認中に特別なサブアドレスの処理を行いません。エイリアスが一致するとみなされるためには、サブアドレスを含むメールボックス全体が一致する必要があります。
subaddressrelaxed	「サブアドレスを処理する」完全一致と「名前+*」の形式一致を検索したあと、MTA で名前の部分のみの一致を検索します。
subaddresswild	「サブアドレスを処理する」サブアドレス全体を含む完全一致を検索したあと、MTA で「名前+*」の形式のエントリを検索します。
unrestricted	「制限されたメールボックスのエンコーディングを有効にする」 RFC 1137 エンコーディングとデコーディングを実行しないように MTA に指示します。
uucp	「アドレスのタイプとルール」エンベロープで UUCP! ルーティングを使用します。bangstyle と同義。
viaaliasoptional	「エイリアスからアドレスを指定する」チャネルに一致する最終受取人のアドレスを、エイリアスで作成する必要がありません。
viaaliasrequired	「エイリアスからアドレスを指定する」チャネルに一致する最終受取人アドレスを、エイリアスで作成する必要があります。

表 12–3 添付と MIME 処理


キーワード	定義
defragment	「メッセージあるいは部分メッセージの自動再組み立て」このチャネルのキューに入れられる部分メッセージは、代わりに再組み立てチャネルのキューに入れられます。
ignoreencoding	「Encoding ヘッダー行を無視する」着信メッセージの `Encoding:` ヘッダーを無視します。
interpretencoding	「Encoding ヘッダー行を無視する」着信メッセージの `Encoding:` ヘッダーを必要に応じて解釈します。
nodefragment	「メッセージあるいは部分メッセージの自動再組み立て」再組み立てを無効にします。

表 12–4 文字セットと 8 ビットデータ


キーワード	定義
charset7	「文字セットのラベルと 8 ビットデータ」 7 ビットのテキストメッセージに関連付けるデフォルトの文字セット。
charset8	「文字セットのラベルと 8 ビットデータ」 8 ビットのテキストメッセージに関連付けるデフォルトの文字セット。
charsetesc	「文字セットのラベルと 8 ビットデータ」エスケープ文字を含む 7 ビットのテキストに関連付けるデフォルトの文字セット
eightbit	「文字セットのラベルと 8 ビットデータ」チャネルが 8 ビット文字をサポートします。
eightnegotiate	「文字セットのラベルと 8 ビットデータ」チャネルが 8 ビット転送の使用をネゴシエートします (可能な場合)。
eightstrict	「文字セットのラベルと 8 ビットデータ」ネゴシエーションが行われていない 8 ビットデータがメッセージヘッダーに含まれている場合は、そのメッセージを拒否します。
sevenbit	「文字セットのラベルと 8 ビットデータ」 8 ビット文字をサポートしません。8 ビット文字はエンコードされる必要があります。

表 12–5 MTA キュー領域でのファイル作成


キーワード	ページ	定義
addrsperfile	「制限容量超過ユーザーへのメール配信を処理する」チャネルのキューにある 1 つのメッセージファイルに関連付けられる受取人の最大数の制限。
expandchannel	「複数アドレスの拡張」 expandlimit の適用による遅延拡張を実行するチャネルを指定します。
expandlimit	「複数アドレスの拡張」アドレスの数がこの制限を超えた場合、着信メッセージを「オフライン」で処理します。
multiple	「制限容量超過ユーザーへのメール配信を処理する」メッセージファイル内の受取人数を制限しません。ただし SMTP チャネルのデフォルトは 99 です。
single	「制限容量超過ユーザーへのメール配信を処理する」チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成されます。
single_sys	「制限容量超過ユーザーへのメール配信を処理する」各宛先システム用にメッセージのコピーを 1 つずつ作成します。
subdirs	「複数のサブディレクトリにチャネルメッセージキューを拡散する」チャネルキューのメッセージを拡散するサブディレクトリの数を指定します。

表 12–6 ヘッダーのキーワード


キーワード	定義
authrewrite	「TCP/IP 接続と DNS 検索のサポート」認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用します。
commentinc	「アドレスヘッダー行内のコメントを処理する」メッセージのヘッダー行内のコメントをそのままにします。
commentmap	「アドレスヘッダー行内のコメントを処理する」 `COMMENT_STRINGS` マッピングテーブルを通じて、メッセージヘッダー行でコメント文字列を実行します。
commentomit	「アドレスヘッダー行内のコメントを処理する」メッセージのヘッダー行内のコメントを取り除きます。
commentstrip	「アドレスヘッダー行内のコメントを処理する」メッセージのヘッダー行内のコメントフィールドから問題を起こす文字を取り除きます。
commenttotal	「アドレスヘッダー行内のコメントを処理する」 Received: ヘッダー行以外のすべてのヘッダー行から ( ) に入っているコメントを削除します。ただし、推奨しません。
datefour	「日付表示を 2 桁から 4 桁に変換する」すべての年表示フィールドを 4 桁に展開します。
datetwo	「日付表示を 2 桁から 4 桁に変換する」 4 桁の日付表示から先頭の 2 桁を削除します。2 桁の日付表示を要求するメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないでください。
dayofweek	「日付の曜日を指定する」曜日情報を残し、曜日情報がない場合にはその情報を日付/時刻ヘッダーに追加します。
defaulthost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるためにドメイン名を指定します。
dropblank	「不正な空白の受取人ヘッダーを削除する」着信メッセージから不正な空白ヘッダーを削除します。
header_733	「アドレスのタイプとルール」メッセージヘッダーで % ルーティングを使用します。
header_822	「アドレスのタイプとルール」メッセージヘッダーでソースルートを使用します。
headerlabelalign	「ヘッダーの配置と折り返し」このチャネルのキューに入れられたメッセージヘッダーの配置ポイントを制御します。整数値の引数をとります。
headerlinelength	「ヘッダーの配置と折り返し」このチャネルのキューに入れられたヘッダー行の長さを制御します。
headerread	「メッセージヘッダー行を選択して削除する」オリジナルのメッセージヘッダーが処理される前に、メッセージがキューに入れられたときに、オプションファイルからそのメッセージのヘッダーにトリミングのルールを適用します (注意して使用すること)。
headertrim	「メッセージヘッダー行を選択して削除する」元のメッセージヘッダーが作成されたあとで、オプションファイルからそのメッセージのヘッダーにトリミングのルールを適用します。
header_uucp	「アドレスのタイプとルール」ヘッダーで ! ルーティングを使用します。
inner	「埋め込まれたヘッダーを書き換える」メッセージをパースして、内部ヘッダーを書き換えます。
innertrim	「メッセージヘッダー行を選択して削除する」内部のメッセージヘッダーに、オプションファイルからのヘッダートリミングルールを適用します (注意して使用すること)。
language	「ヘッダーのデフォルト言語を設定する」ヘッダーにデフォルトの言語を指定します。
maxheaderaddrs	「長いヘッダー行を自動分割する」 1 行に表示できるアドレスの数を指定します。
maxheaderchars	「長いヘッダー行を自動分割する」 1 行に表示できる文字数を指定します。
missingrecipientpolicy	「受取人ヘッダー行がないメッセージを有効にする」受取人ヘッダーがないメッセージを有効にする (どのヘッダーを追加するか指定する) ポリシーを設定します。
nodayofweek	「日付の曜日を指定する」日付/時刻ヘッダーから曜日情報を削除します。この情報が処理できないメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないでください。
nodefaulthost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるために使用する、ドメイン名を指定しません。
nodropblank	「不正な空白の受取人ヘッダーを削除する」着信メッセージから不正な空白ヘッダーを削除しません。
noheaderread	「メッセージヘッダー行を選択して削除する」オプションファイルからのヘッダートリミングルールを適用しません。
noheadertrim	「メッセージヘッダー行を選択して削除する」オプションファイルからのヘッダートリミングルールを適用しません。
noinner	「埋め込まれたヘッダーを書き換える」内部のメッセージヘッダー行を書き換えません。
noinnertrim	「メッセージヘッダー行を選択して削除する」内部のメッセージヘッダーにヘッダートリミングルールを適用しません。
noreceivedfor	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」エンベロープ受取人の情報を含めずに `Received:` ヘッダー行を作成します。
noreceivedfrom	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」元のエンベロープの From: アドレスを含めずに `Received:` ヘッダー行を作成します。
noremotehost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるために、ローカルホストのドメイン名をデフォルトのドメイン名として使用します。
noreverse	「チャネル固有のリバースデータベースの使用を有効にする」チャネルのキューに入れられたメッセージのアドレスを、アドレスリバース処理から外します。
norules	「チャネル固有の書き換えルールチェックを有効にする」このチャネル固有の書き換えルールを確認しません。
nox_env_to	「X-Envelope-to ヘッダー行を生成するまたは削除する」 `X-Envelope-to` ヘッダー行を削除します。
personalinc	「アドレスヘッダー行内の個人名を処理する」メッセージのヘッダー行にある個人名のフィールドをそのままにします。
personalmap	「アドレスヘッダー行内の個人名を処理する」 PERSONAL_NAMES マッピングテーブルを通じて、個人名を実行します。
personalomit	「アドレスヘッダー行内の個人名を処理する」メッセージのヘッダー行にある個人名のフィールドを削除します。
personalstrip	「アドレスヘッダー行内の個人名を処理する」ヘッダー行にある個人名のフィールドから問題になる文字を削除します。
receivedfor	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」メッセージの宛先になっているエンベロープ受取人アドレスが 1 つだけの場合は、そのエンベロープの Received: ヘッダー行に `To:` アドレスを含めます。
receivedfrom	「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」 MTA がエンベロープ `From:` アドレスを変更した場合、着信メッセージの `Received:` ヘッダー行を作成する際に元のエンベロープの `From:` アドレスを含めます。
remotehost	「不完全なアドレスを修正する際に使用するホスト名を指定する」アドレスを完成させるために、リモートホストの名前をデフォルトのドメイン名として使用します。
restricted	「制限されたメールボックスのエンコーディングを有効にする」チャネルは、このエンコーディングを必要とするメールシステムに接続します。
reverse	「チャネル固有のリバースデータベースの使用を有効にする」アドレスリバースデータベースまたは REVERSE マッピングに対してアドレスを確認します。
rules	「チャネル固有の書き換えルールチェックを有効にする」このチャネル固有の書き換えルールを確認します。
sensitivitycompanyconfidential	「機密度チェック」 `Companyconfidential` が、受け付けるメッセージの重要度の上限です。
sensitivitynormal	「機密度チェック」 `Normal` が、受け付けるメッセージの重要度の上限です。
sensitivitypersonal	「機密度チェック」 `Personal` が、受け付けるメッセージの重要度の上限です。
sensitivityprivate	「機密度チェック」 `Private` が、受け付けるメッセージの重要度の上限です。
sourcecommentinc	「アドレスヘッダー行内のコメントを処理する」着信メッセージのヘッダー行にコメントを残します。
sourcecommentmap	「アドレスヘッダー行内のコメントを処理する」ソースチャネルを通じて、ヘッダー行のコメント文字列を実行します。
sourcecommentomit	「アドレスヘッダー行内のコメントを処理する」着信メッセージの To:、From:、Cc: などのヘッダー行からコメントを削除します。
sourcecommentstrip	「アドレスヘッダー行内のコメントを処理する」着信メッセージのヘッダー行内のコメントフィールドから問題を起こす文字を削除します。
sourcecommenttotal	「アドレスヘッダー行内のコメントを処理する」着信メッセージから、( ) 内に入っているコメントを削除します。
sourcepersonalinc	「アドレスヘッダー行内の個人名を処理する」着信メッセージのヘッダー行にある個人名のフィールドをそのままにします。
sourcepersonalmap	「アドレスヘッダー行内の個人名を処理する」ソースチャネルを通じて個人名を実行します。
sourcepersonalomit	「アドレスヘッダー行内の個人名を処理する」着信メッセージのヘッダー行にある個人名のフィールドを削除します。
sourcepersonalstrip	「アドレスヘッダー行内の個人名を処理する」着信メッセージのヘッダー行にある個人名のフィールドから、問題になる文字を削除します。
unrestricted	「制限されたメールボックスのエンコーディングを有効にする」 RFC 1137 エンコーディングとデコーディングを実行しないように MTA に指示します。
x_env_to	「X-Envelope-to ヘッダー行を生成するまたは削除する」 `X-Envelope-to` ヘッダー行の生成を有効にします。

表 12–7 着信チャネルの一致と切り替えのキーワード


キーワード	定義
allowswitchchannel	「着信メール用代替チャネル (切り替えチャネル)」 `switchchannel` チャネルからこのチャネルへの切り替えを許可します。
nosaslswitchchannel	「SMTP 認証、SASL、TLS」 SASL 認証に成功した場合、このチャネルへの切り替えは許可されません。
noswitchchannel	「着信メール用代替チャネル (切り替えチャネル)」このチャネルへの、またはこのチャネルからの切り替えを行いません。
switchchannel	「着信メール用代替チャネル (切り替えチャネル)」サーバーチャネルから送信元のホストに関連付けられたチャネルに切り替えます。
saslswitchchannel	「SMTP 認証、SASL、TLS」クライアントが SASL の使用に成功した場合、着信接続が指定のチャネルに切り替えられます。
tlsswitchchannel	「Transport Layer Security」 TLS のネゴシエートが成功した場合に、ほかのチャネルに切り替えます。

表 12–8 ログ記録とデバッグのチャネルキーワード


キーワード	定義
logging	「ログ記録のキーワード」キューに対するメッセージの出入りをログに記録し、特定のチャネルのログ機能を有効にします。
loopcheck	「Loopcheck を設定する」 MTA が MTA 自体と通信しているかどうかを確認するために、SMTP EHLO 応答見出しに文字列を配置します。
master_debug	「デバッグのキーワード」チャネルのマスタープログラム出力内にデバッグ出力を作成します。
nologging	「ログ記録のキーワード」キューに対するメッセージの出入りをログに記録しません。
noloopcheck	「Loopcheck を設定する」 SMTP EHLO 応答見出しに文字列がありません。
nomaster_debug	「デバッグのキーワード」チャネルのマスタープログラム出力内にデバッグ出力を行いません。
noslave_debug	「デバッグのキーワード」スレーブのデバッグ出力を生成しません。
slave_debug	「デバッグのキーワード」スレーブのデバッグ出力を生成します。

表 12–9 長いアドレスリストやヘッダーのチャネルキーワード


キーワード	定義
expandchannel	「複数アドレスの拡張」 expandlimit の適用による遅延拡張を実行するチャネルを指定します。
expandlimit	「複数アドレスの拡張」アドレスの数がこの制限を超えた場合、着信メッセージを「オフライン」で処理します。
holdlimit	「複数アドレスの拡張」アドレスの数がこの制限を越えた場合、メッセージを保留します。
maxprocchars	「ヘッダーの配置と折り返し」処理や書き換えができるヘッダーの最大長。

表 12–10 メールボックスフィルタのチャネルキーワード


キーワード	定義
channelfilter	「メールボックスフィルタファイルの場所を指定する」チャネルフィルタファイルの場所。`destinationfilter` と同じ。
destinationfilter	送信するメッセージに提供されるチャネルフィルタの場所。
destinationspamfilterXoptin	「スパムフィルタのキーワード」スパムのフィルタ処理のソフトウェア X によってこのチャネル宛てのメッセージを起動します。
fileinto	「メールボックスフィルタファイルの場所を指定する」メールボックスフィルタ `fileinto` の操作が適用されたときの、アドレスに対する効果を指定します。
filter	「メールボックスフィルタファイルの場所を指定する」ユーザーフィルタファイルの場所を指定します。
nochannelfilter	「メールボックスフィルタファイルの場所を指定する」送信メッセージに対するチャネルフィルタリングを行いません。`nodestinationfilter` とも呼ばれます。
nodestinationfilter	「メールボックスフィルタファイルの場所を指定する」送信メッセージに対するチャネルフィルタリングを実行しません。
nofileinto	「メールボックスフィルタファイルの場所を指定する」メールボックスフィルタ fileinto のオペレータが効果を発揮しません。
nofilter	「メールボックスフィルタファイルの場所を指定する」ユーザーメールボックスのフィルタリングを実行しません。
nosourcefilter	「メールボックスフィルタファイルの場所を指定する」着信メッセージに対してチャネルフィルタリングを実行しません。
sourcefilter	「メールボックスフィルタファイルの場所を指定する」着信メッセージ用のチャネルフィルタファイルの場所を指定します。
sourcespamfilterXoptin	「スパムフィルタのキーワード」スパムのフィルタ処理のソフトウェア X によってこのチャネルから発信されるメッセージを起動します。

表 12–11 非請求の SMTP 拡張サポートのキーワード


キーワード	定義
sourcenosolicit	「非請求の SMTP 拡張のサポート」このチャネルから送信されたメール内でブロックされる請求フィールドの値のコンマ区切りの一覧を指定します。
destinationnosolicit	「非請求の SMTP 拡張のサポート」このチャネルのキューに入れられたメール内で受け入れられない請求フィールドの値のコンマ区切りの一覧を指定します。

表 12–12 通知メッセージとポストマスターメッセージのキーワード


キーワード	定義
(完全な通知手順については「配信ステータス通知メッセージを制御する」を参照)
aliaspostmaster	「ポストマスター返送メッセージの内容」正式なチャネル名でのユーザー名が postmaster であるユーザーに宛てられたメッセージは postmaster@ローカルホストにリダイレクトされます。ローカルホストには、ローカルホスト名 (ローカルチャネルの名前) が入ります。
copysendpost	「返送された配信不能メッセージ」メッセージの差出人アドレスが空白になっている場合を除き、配信不能メッセージのコピーがポストマスターに送信されます。
copywarnpost	「警告メッセージ」未配信メッセージの差出人アドレスが空白になっている場合を除き、警告メッセージのコピーがポストマスターに送信されます。
errsendpost	「返送された配信不能メッセージ」通知を差出人に返すことができない場合に、配信不能通知のコピーをポストマスターに送信します。
errwarnpost	「警告メッセージ」通知を差出人に返すことができない場合に、警告メッセージのコピーをポストマスターに送信します。
includefinal	「ステータス通知メッセージに代替アドレスを含めるには」配信通知の中に受取人アドレスの最終的な形式を含めます。
nonurgentnotices	「通知メッセージの配信間隔を設定するには」優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
noreturnaddress	「ポストマスター返送メッセージの内容」ポストマスターアドレス名に `RETURN_ADDRESS` オプション値を使用します。
noreturnpersonal	「ポストマスター返送メッセージの内容」ポストマスター個人名に `RETURN_PERSONAL` オプション値を使用します。
normalnotices	「通知メッセージの配信間隔を設定するには」優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
nosendpost	「返送された配信不能メッセージ」配信不能メッセージのコピーをポストマスターには一切送信しません。
notices	「通知メッセージの配信間隔を設定するには」通知を送り、メッセージを返すまでの時間を指定します。
nowarnpost	「警告メッセージ」警告メッセージのコピーをポストマスターには一切送信しません。
postheadbody	「ポストマスター返送メッセージの内容」ヘッダーとメッセージの内容の両方を返送します。
postheadonly	「ポストマスター返送メッセージの内容」ポストマスターにヘッダーだけを返送します。
returnaddress	「ポストマスター返送メッセージの内容」ローカルポストマスターの返信アドレスを設定します。
returnenvelope	「空白のエンベロープ返信アドレス」空白のエンベロープ返信アドレスの使用を制御します。
returnpersonal	「ポストマスター返送メッセージの内容」ローカルのポストマスターに対する個人名を設定します。
sendpost	「返送された配信不能メッセージ」配信不能メッセージのコピーをすべてポストマスターに送信します。
suppressfinal	「ステータス通知メッセージに代替アドレスを含めるには」オリジナルの形式のアドレスが存在する場合に、通知メッセージに最終アドレス形式を表示しないようにします。
urgentnotices	「通知メッセージの配信間隔を設定するには」優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
useintermediate	「ステータス通知メッセージに代替アドレスを含めるには」リストの展開後、ユーザーメールボックス名を生成するまでの間に作成された中間形式のアドレスを使用します。
warnpost	「警告メッセージ」警告メッセージのコピーをすべてポストマスターに送信します。

表 12–13 処理制御とジョブ送信のキーワード


キーワード	定義
(より大きい機能単位については「メッセージの処理と配信を設定する」を参照)
backoff	「配信失敗メッセージの再配信回数を指定する」配信不能メッセージを再配信する回数。`normalbackoff`、`nonurgentbackoff`、`urgentbackoff` キーワードで置き換え可能。
bidirectional	「チャネルの方向性を設定する」マスターとスレーブの両方のプログラムによって処理されるチャネル。
deferred	「指定配信日を実行する」 `Deferred-delivery:` ヘッダー行を認識し、許可します。
expandchannel	「複数アドレスの拡張」 expandlimit の適用による遅延拡張を実行するチャネルを指定します。
expandlimit	「複数アドレスの拡張」アドレスの数がこの制限を超えた場合、着信メッセージを「オフライン」で処理します。
filesperjob	「サービスジョブの制限」 1 つのジョブで処理できるキューエントリの数。
immnonurgent	「指定配信日を実行する」優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始します。
master	「チャネルの方向性を設定する」マスタープログラムによって処理されるチャネル (`master`)。
maxjobs	「サービスジョブの制限」 1 つのチャネルに対して同時実行できるジョブの最大数。
nodeferred	「指定配信日を実行する」 `Deferred-delivery:` ヘッダー行が許可されないように指定します。
nonurgentbackoff	「配信失敗メッセージの再配信回数を指定する」優先度が低いメッセージの配信試行頻度。
nonurgentblocklimit	「サイズに基づくメッセージの優先度」指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定します。該当するメッセージは次の定期ジョブまで処理されません。
normalbackoff	「配信失敗メッセージの再配信回数を指定する」優先度が標準であるメッセージの配信試行頻度。
normalblocklimit	「サイズに基づくメッセージの優先度」指定値以上のサイズを持つメッセージの優先度を「低」に設定します。
noservice	「サービス変換を有効にする」このチャネルで受信するメッセージのサービス変換は `CHARSET-CONVERSION` を使用して有効にします。
pool	「チャネル実行ジョブの処理プール」チャネル用のプールを指定します。この後ろに、現在のチャネルの配信ジョブのプール先となるプール名を指定します。
service	「サービス変換を有効にする」 `CHARSET-CONVERSION` エントリにかかわらず、無条件でサービス変換を有効にします。
slave	「チャネルの方向性を設定する」スレーブプログラム (slave) によって処理されるチャネル。
threaddepth	「SMTP チャネルスレッド」マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数。
transactionlimit	1 つの接続について許されるメッセージの数を制限します。
urgentbackoff	「配信失敗メッセージの再配信回数を指定する」優先度が高いメッセージの配信試行頻度。
urgentblocklimit	「サイズに基づくメッセージの優先度」指定値以上のサイズを持つメッセージの優先度を「標準」に設定します。
user	「pipe チャネル」 pipe チャネルでどのユーザー名で実行するかを示すのに使用されます。

表 12–14 重要度の上限のキーワード


キーワード	定義
sensitivitycompanyconfidential	「機密度チェック」受け付けるメッセージの重要度の上限。
sensitivitynormal	「機密度チェック」 `Normal` が、受け付けるメッセージの重要度の上限です。
sensitivitypersonal	「機密度チェック」 `Personal` が、受け付けるメッセージの重要度の上限です。
sensitivityprivate	「機密度チェック」 `Private` が、受け付けるメッセージの重要度の上限です。

表 12–15 メッセージの制限、ユーザー制限容量、権限、認証の試行のキーワード


キーワード	定義
alternatechannel	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」 alternateblocklimit、alternatelinelimit、および alternaterecipientlimit の代替宛先チャネル。
alternateblocklimit	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」メッセージが alternativechannel に送信される前に、メッセージのブロック数の制限を指定します。
alternatelinelimit	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」メッセージが alternativechannel に送信される前に、メッセージの行数の制限を指定します。
alternaterecipientlimit	「サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する」メッセージが alternativechannel に送信される前に、メッセージの受取人数の制限を指定します。
blocklimit	「絶対的なメッセージサイズ制限を指定する」 1 つの着信メッセージに対して許可されている MTA ブロックの最大数。
disconnectbadauthlimit	「認証の試行失敗回数の制限」 1 つのセッションで許可される認証の試行失敗回数の制限。この回数に達するとセッションの接続は切断されます。
disconnectbadcommandlimit	「セッションの制限を設定する」セッションの不良コマンド数を制限します。
disconnectrecipientlimit	「セッションの制限を設定する」セッションの受取人数を制限します。
disconnectrejectlimit	「セッションの制限を設定する」拒否される受取人数を制限します。
disconnecttransactionlimit	「セッションの制限を設定する」トランザクション数を制限します。
headerlimit	「ヘッダーのサイズを制限する」プライマリ (もっとも外側の) メッセージヘッダーの最大サイズの制限。
holdexquota	「制限容量超過ユーザーへのメール配信を処理する」制限容量を超過したユーザーに対するメッセージを保留します。
holdlimit	「複数アドレスの拡張」アドレスの数がこの制限を越えた場合、着信メッセージを保留します。
linelength	「メッセージ行の長さを制限する」チャネルごとに許可される最大のメッセージ行の長さを制限します。
linelimit	「絶対的なメッセージサイズ制限を指定する」 1 つのメッセージに対して許可される最大の行数を指定します。
maxblocks	「大きなメッセージの自動断片化」 1 つのメッセージに許可するブロックの最大数を指定します。
maxlines	「大きなメッセージの自動断片化」 1 つのメッセージに許可する最大行数を指定します。
nameparameterlengthlimit	「General Content-type、Filename Content-type、および Content-disposition パラメータの長さを制御する」 name content-type および filename content-disposition パラメータが切り捨てられる位置を制御します。
noblocklimit	「絶対的なメッセージサイズ制限を指定する」 1 つのメッセージに許可される MTA ブロックの数に制限はありません。
noexquota	「制限容量超過ユーザーへのメール配信を処理する」制限容量を超過したユーザーに宛てられたメッセージをすべて差出人に送り返します。
nolinelimit	「絶対的なメッセージサイズ制限を指定する」 1 つのメッセージに許可される行数に制限はありません。
nonurgentblocklimit	「サイズに基づくメッセージの優先度」指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定します。該当するメッセージは次の定期ジョブまで処理されません。
normalblocklimit	「サイズに基づくメッセージの優先度」指定値以上のサイズを持つメッセージの優先度を「低」に設定します。
parameterlengthlimit	「General Content-type、Filename Content-type、および Content-disposition パラメータの長さを制御する」 general content-type および content-disposition パラメータが切り捨てられる位置を制御します。
recipientcutoff	「メッセージの受取人を制限する」受取人がこの値を超えるとメッセージを拒否します。
recipientlimit	「メッセージの受取人を制限する」メッセージが受け付ける受取人アドレスの数を制限します。
rejectsmtplonglines	「1000 文字を超える行を含む SMTP メールを処理する」 1000 文字よりも長い行 (CRLF を含む) を含むメッセージを拒否します。
sourceblocklimit	「絶対的なメッセージサイズ制限を指定する」 1 つの着信メッセージに対して許可されている MTA ブロックの最大数。
truncatesmtplonglines	「1000 文字を超える行を含む SMTP メールを処理する」 1 行が 1000 文字を超えるとそれ以降の文字を切り捨てます。
wrapsmtplonglines	「1000 文字を超える行を含む SMTP メールを処理する」 1 行が 1000 文字を超えると折り返します。
urgentblocklimit	「サイズに基づくメッセージの優先度」指定値以上のサイズを持つメッセージの優先度を「標準」に設定します。

表 12–16 SMTP 認証、SASL、TLS のキーワード


キーワード	定義
(より大きい機能単位については「SMTP 認証、SASL、TLS」を参照)
authrewrite	「TCP/IP 接続と DNS 検索のサポート」認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用します。
maysaslserver	「SMTP 認証、SASL、TLS」クライアントが SASL 認証を使用することを許可します。
maytls	「Transport Layer Security」 MTA は TLS 使用の接続を受け入れ、送信接続にも TLS を使用しようと試みます。
maytlsclient	「Transport Layer Security」 MTA SMTP クライアントは TLS をサポートする SMTP サーバーにメッセージを送信する際に TLS を使用します。
maytlsserver	「Transport Layer Security」 MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用することを許可します。
msexchange	「Microsoft Exchange ゲートウェイチャネルを指定する」 TCP/IP チャネルで使用して、MTA にこれが MS Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示します。
mustsaslserver	「SMTP 認証、SASL、TLS」 SMTP サーバーは、リモートクライアントが認証に成功しないかぎり、メッセージを受け付けません。
musttls	「Transport Layer Security」 MTA は送着信接続に必ず TLS を使用します。
musttlsclient	「Transport Layer Security」 MTA SMTP クライアントは、メッセージの送信に必ず TLS を使用します (MTA は STARTTLS コマンドを発行し、このコマンドは必ず成功する必要がある)。
musttlsserver	「Transport Layer Security」 MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、メッセージを着信する際に TLS を使用します。
nomsexchange	「TCP/IP 接続と DNS 検索のサポート」デフォルト。
nosasl	「SMTP 認証、SASL、TLS」 SASL 認証は許可されず、試行もされません。
nosaslserver	「SMTP 認証、SASL、TLS」 SASL 認証は許可されません。
notls	「Transport Layer Security」 TLS 認証は許可されず、試行もされません。
notlsclient	「Transport Layer Security」送信接続時に MTA SMTP クライアントは TLS を使用しません (送信接続時に STARTTLS コマンドが発行されない)。
notlsserver	「Transport Layer Security」着信接続時に MTA SMTP サーバーは TLS の使用を許可しません (SMTP サーバーもコマンド自体も STARTTLS 拡張に通知しない)。
saslswitchchannel	「SMTP 認証、SASL、TLS」クライアントが SASL の使用に成功した場合、着信接続が指定のチャネルに切り替えられます。
tlsswitchchannel	「Transport Layer Security」クライアントが TLS ネゴシエーションに成功した場合、着信接続が指定のチャネルに切り替えられます。このキーワードには、切り替え先のチャネルを指定する必要があります。

表 12–17 SMTP コマンドとプロトコルのキーワード


キーワード	定義
(より大きい機能単位については「SMTP コマンドとプロトコルのサポート」を参照)
allowetrn	「ETRN コマンドのサポート」 ETRN コマンドを処理します。
blocketrn	「ETRN コマンドのサポート」 ETRN コマンドをブロックします。
checkehlo	「EHLO コマンドのサポート」 SMTP 応答の見出しを確認して、EHLO と HELO のどちらを使用するか決定します。
disableetrn	「ETRN コマンドのサポート」 ETRN SMTP コマンドのサポートを無効にします。
domainetrn	「ETRN コマンドのサポート」ドメインを指定する ETRN コマンドだけを処理します。
domainvrfy	「VRFY コマンドのサポート」完全なアドレスを使用して VRFY コマンドを発行します。
ehlo	「EHLO コマンドのサポート」初期接続に SMTP EHLO コマンドを使用します。
eightbit	「文字セットのラベルと 8 ビットデータ」チャネルが 8 ビット文字をサポートします。
eightnegotiate	「文字セットのラベルと 8 ビットデータ」チャネルが 8 ビット転送の使用をネゴシエートします (可能な場合)。
eightstrict	「文字セットのラベルと 8 ビットデータ」ネゴシエーションが行われていない 8 ビットデータがメッセージヘッダーに含まれている場合は、そのメッセージを拒否します。
expnallow	「EXPN サポート」 `DISABLE_EXPAND` SMTP チャネルオプションによって SMTP サーバーレベルで `EXPN` が無効にされている場合でも、EXPN を許可します。
expndisable	「EXPN サポート」 `EXPN` を無条件で無効にします。
expndefault	「EXPN サポート」 SMTP サーバーの設定で `EXPN` が許可されていれば EXPN を許可します。
localvrfy	「VRFY コマンドのサポート」ローカルアドレスを使用して VRFY コマンドを発行します。
mailfromdnsverify	「DNS ドメイン確認」 `MAIL FROM:` コマンドに使用されているドメインが DNS に存在するかどうかを確認します。
noehlo	「EHLO コマンドのサポート」 EHLO コマンドを使用しません。
nomailfromdnsverify	「DNS ドメイン確認」 `MAIL FROM:` コマンドに使用されているドメインが DNS に存在するかどうかを確認しません。
nosendetrn	「ETRN コマンドのサポート」 ETRN コマンドを送信しません。
nosmtp	「チャネルプロトコル選択と改行記号」 SMTP プロトコルをサポートしません。これがデフォルトです。
novrfy	「VRFY コマンドのサポート」 VRFY コマンドを発行しません。
sendetrn	「ETRN コマンドのサポート」 ETRN コマンドを送信します。
sevenbit	「文字セットのラベルと 8 ビットデータ」 8 ビット文字をサポートしません。8 ビット文字はエンコードされる必要があります。
silentetrn	「ETRN コマンドのサポート」チャネル情報をエコーせずに ETRN コマンドを処理します。
smtp	「チャネルプロトコル選択と改行記号」 SMTP プロトコルをサポートします。キーワード `smtp` は、すべての SMTP チャネルで必須です。(このキーワードは `smtp_crorlf` と同等。)
smtp_cr	「チャネルプロトコル選択と改行記号」ラインフィーダ (LF) なしの、キャリッジリターン (CR) のみが改行記号として受け入れられます。
smtp_crlf	「チャネルプロトコル選択と改行記号」キャリッジリターン (CR) + ラインフィーダ (LF) のシーケンスのみが改行記号として認識されます。
smtp_crorlf	「チャネルプロトコル選択と改行記号」キャリッジリターン (CR) 、ラインフィーダ (LF) のシーケンス、または完全な CRLF が改行記号として使用可能です。
smtp_lf	「チャネルプロトコル選択と改行記号」キャリッジリターン (CR) なしの、ラインフィーダ (LF) のみを使用できます。
streaming	「プロトコルストリーミング」チャネルに関連付けられたプロトコルのストリーミングの程度を制御します。
vrfyallow	「VRFY コマンドのサポート」 VRFY コマンドに対して詳細な情報を提供する応答を出します。
vrfydefault	「VRFY コマンドのサポート」チャネルの HIDE_VERIFY オプションの設定に従い、VRFY コマンドに対してデフォルトの応答を提供します。
vrfyhide	「VRFY コマンドのサポート」 SMTP VRFY コマンドに対してあいまいな応答を出します。

表 12–18 TCP/IP 接続と DNS 検索サポートのキーワード


キーワード	定義
TCP/IP 接続と DNS 検索のサポート (より大きい機能単位については「TCP/IP 接続と DNS 検索のサポート」を参照)
cacheeverything	「チャネル接続情報のキャッシング」すべての接続情報をキャッシュします。
cachefailures	「チャネル接続情報のキャッシング」接続失敗に関する情報だけをキャッシュします。
cachesuccesses	「チャネル接続情報のキャッシング」接続成功に関する情報だけをキャッシュします。
connectalias	「メッセージがキューから取り出されるときのアドレス書き換え」受取人のアドレスに書かれているホストに配信します。
connectcanonical	「メッセージがキューから取り出されるときのアドレス書き換え」 MTA が接続するシステムのホストエイリアスに接続します。
daemon	「ターゲットホストの選択」エンベロープアドレスにかかわらず特定のホストシステムに接続します。
defaultmx	「TCP/IP MX レコードのサポート」チャネルが、ネットワークから MX 検索を実行するかどうかを決定します。
defaultnameservers	「ネームサーバー検索」 TCP/IP スタックが選択したネームサーバーを照合します。
forwardcheckdelete	「リバース DNS 検索」リバース DNS 検索のあとに正引き検索を行い、リバース DNS 検索で返された名前の正引き検索がオリジナルの接続の IP 番号に一致するかどうかを確認します。一致しない場合、リバース DNS 検索で返された名前は削除され、IP アドレスが使用されます。
forwardchecknone	「リバース DNS 検索」 DNS リバース検索のあとに正引き検索を実行しません。
forwardchecktag	「リバース DNS 検索」リバース DNS 検索を実行して返された名前を正引き検索して、IP 番号がオリジナルの接続の IP 番号に一致するかどうかを確認します。一致しなければ名前に「*」を付けます。
identnone	「IDENT 検索」 IDENT 検索を実行しません。IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名と IP アドレスの両方を含めます。
identnonelimited	「IDENT 検索」 IDENT 検索を実行しません。IP からホスト名への変換を実行し (ただしチャネルの切り替えを行う際にはホスト名を使用しない)、`Received:` ヘッダーにホスト名と IP アドレスの両方を含めます。
identnonenumeric	「IDENT 検索」 IDENT 検索および IP からホスト名への変換を実行しません。
identnonesymbolic	「IDENT 検索」 IDENT 検索を実行しません。IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名だけを含めます。
identtcp	「IDENT 検索」着信 SMTP 接続での IDENT 検索および IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名と IP アドレスの両方を含めます
identtcplimited	「IDENT 検索」着信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行します (ただし、チャネルの切り替えを行う際にはホスト名を使用しない)。`Received:` ヘッダーにホスト名と IP アドレスを含めます。
indenttcpnumeric	「IDENT 検索」着信 SMTP 接続で IDENT 検索を実行します。IP からホスト名への変換を実行しません。
identtcpsymbolic	「IDENT 検索」着信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名だけを含めます。
interfaceaddress	「TCP/IP ポート番号とインタフェースアドレス」指定された TCP/IP インタフェースアドレスにバインドします。
lastresort	「最後のホスト」最後のホストを指定します。
mailfromdnsverify	「DNS ドメイン確認」 `MAIL FROM:` コマンドに使用されているドメインが DNS に存在するかどうかを確認します。
mx	「TCP/IP MX レコードのサポート」 TCP/IP ネットワークおよびソフトウェアが MX レコード検索をサポートします。
nameservers	「ネームサーバー検索」 TCP/IP スタックが選択したネームサーバーの代わりに照合するネームサーバーのリストを指定します。`nameservers` には、空白文字で区切られたネームサーバーの IP アドレスのリストが必要です。
nocache	「チャネル接続情報のキャッシング」接続情報をキャッシュしません。
nomailfromdnsverify	「DNS ドメイン確認」 `MAIL FROM:` コマンドに使用されているドメインが DNS に存在するかどうかを確認しません。
nomx	「TCP/IP MX レコードのサポート」 TCP/IP ネットワークが MX 検索をサポートしません。
nonrandomemx	「TCP/IP MX レコードのサポート」 MX 検索を実行しますが、返されたエントリを同等の優先度でランダム化しません。
port	「TCP/IP ポート番号とインタフェースアドレス」 SMTP 接続用のデフォルトポート番号を指定します。標準ポートは 25 です。
randommx	「TCP/IP MX レコードのサポート」 MX 検索を実行し、返されたエントリを同等の優先度でランダム化します。
single	「ターゲットホストの選択」チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成されるように指定します。
single_sys	「ターゲットホストの選択」各宛先システム用にメッセージのコピーを 1 つずつ作成します。
threaddepth	「SMTP チャネルスレッド」マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数。

表 12–19 その他のキーワード


キーワード	定義
deferralrejectlimit	「不正な `RCPT TO` アドレスに制限を設定する」不正な RCPT TO: アドレス数を制限します。
dispositionchannel	「プロセスチャネルのオーバーライド」配信ステータス通知 (DSN) を最初にキューに入れるチャネルとしてプロセスチャネルよりも優先されます。
destinationfilter	「メールボックスフィルタファイルの場所を指定する」一般的な MTA チャネルで使用して、チャネルレベルのフィルタを指定して送信メッセージに適用します。
filter	「メールボックスフィルタファイルの場所を指定する」フィルタファイルの場所を示す URL を必要な引数としてとります。
nodestinationfilter	「メールボックスフィルタファイルの場所を指定する」チャネルのどちらの方向にもチャネルメールボックスフィルタが無効になります。
nosourcefilter	「メールボックスフィルタファイルの場所を指定する」どのチャネルメールボックスフィルタもソースチャネルに対して無効になります。
nofilter	「メールボックスフィルタファイルの場所を指定する」デフォルトで、ユーザーメールボックスフィルタがチャネルに対して有効ではないことを示します。
notificationchannel	「プロセスチャネルのオーバーライド」 MDN (Message Disposition Notification) を最初にキューに入れるチャネルとしてプロセスチャネルよりも優先されます。
sourcefilter	「メールボックスフィルタファイルの場所を指定する」一般的な MTA チャネルで使用して、チャネルレベルのフィルタを指定して着信メッセージに適用します。
submit	「チャネル動作のタイプ」チャネルを送信専用のチャネルに指定します。
user	「pipe チャネル」 pipe チャネルでどのユーザー名で実行するかを示すのに使用されます。

SMTP チャネルを設定する

インストールの種類によっては、Messaging Server のインストール時に数種の SMTP チャネルが提供されます (次の表を参照)。このようなチャネルは TCP/IP の上位プロトコルとして SMTP を実装します。マルチスレッド TCP SMTP チャネルには、ディスパッチャ制御下のマルチスレッド SMTP サーバーが含まれます。送信された SMTP メールは、必要に応じてジョブコントローラの制御下で動作し、チャネルプログラム tcp_smtp_client によって処理されます。

表 12–20 SMTP チャネル


チャネル	定義
`tcp_local`	リモート SMTP ホストからのメッセージを受信します。メッセージを送信する場合は、スマートホスト/ファイアウォール設定が使われているかどうかによって、直接リモート SMTP ホストに送るか、またはスマートホスト/ファイアウォールシステムに送ります。
`tcp_intranet`	イントラネット内のメッセージを送受信します。
`tcp_auth`	tcp_local のスイッチチャネルとして使用されます。認証されたユーザーは、リレーブロックの制約を回避するため `tcp_auth` チャネルに移されます。
`tcp_submit`	送信されたメッセージ (通常の場合はユーザーエージェントからのメッセージ) を予約されている送信ポート 587 で受け入れます (RFC 2476 を参照)。
`tcp_tas`	Unified Messaging を使用するサイト用の特殊な IA チャネル。

この節で説明するチャネルキーワードを追加または削除することで、これらのチャネルの定義を変更したり、新規チャネルを作成したりできます。また、オプションファイルは TCP/IP チャネルのさまざまな特徴を制御するために使用されます。このようなオプションファイルは、MTA 設定ディレクトリ (msg_svr_base/config) に保存し、x_option という名前を付けなければなりません。この x はチャネルの名前です。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Option File」を参照してください。

この節には、次の項があります。

SMTP チャネルオプションを設定する

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

オプションファイルは、1 つまたは複数のキーワードとその関連値によって構成されています。たとえば、サーバーのメーリングリストの展開を無効にするには、オプションファイルに DISABLE_EXPAND キーワードを追加し、値を 1 に設定します。

その他のオプションファイルキーワードを使用すると、次のような制御を行うことができます。

メッセージ当たりの宛先数を制限する (ALLOW_RECIPIENTS_PER_TRANSACTION)
接続当たりのメッセージ数を制限する (ALLOW_TRANSACTIONS_PER_SESSION)
MTA ログファイルに記録される情報のタイプを微調整する (LOG_CONNECTION、LOG_TRANPORTINFO)
クライアントチャネルプログラムが許可できる同時送信接続の最大数を指定する (MAX_CLIENT_THREADS)

すべてのチャネルオプションキーワードと構文の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

SMTP コマンドとプロトコルのサポート

SMTP チャネルで EHLO、ETRN、EXPN、VRFY などの SMTP コマンドをサポートするかどうかを指定することができます。また、チャネルが DNS ドメイン確認をサポートするかどうかや、どの文字を改行記号として受け入れるかなどを指定することも可能です。この項では、次の内容について説明します。

表 12–21 に、この節で説明するキーワードの要約を示します。

表 12–21 SMTP コマンドとプロトコルのキーワード


チャネルキーワード	説明
プロトコル選択と改行記号	チャネルが SMTP プロトコルをサポートするかどうかを指定し、改行記号として受け入れる文字シーケンスを指定します。
`smtp`	SMTP プロトコルをサポートします。キーワード `smtp` は、すべての SMTP チャネルで必須です。(このキーワードは `smtp_crorlf` と同等。)
`nosmtp`	SMTP プロトコルをサポートしません。これがデフォルトです。
`smtp_cr`	ラインフィーダ (LF) なしの、キャリッジリターン (CR) のみが改行記号として受け入れられます。
`smtp_crlf`	キャリッジリターン (CR) + ラインフィーダ (LF) のシーケンスのみが改行記号として認識されます。
`smtp_lf`	キャリッジリターン (CR) なしの、ラインフィーダ (LF) のみを使用できます。
`smtp_crorlf`	キャリッジリターン (CR) 、ラインフィーダ (LF) のシーケンス、または完全な CRLF が改行記号として使用可能です。
EHLO キーワード	チャネルによる EHLO コマンドの処理方法を指定します。
`ehlo`	初期接続に SMTP EHLO コマンドを使用します。
`checkehlo`	SMTP 応答の見出しを確認して、EHLO と HELO のどちらを使用するか決定します。
`noehlo`	EHLO コマンドを使用しません。
ETRN キーワード	チャネルによる ETRN コマンド (キュー処理の要求) の処理方法を指定します。
`allowetrn`	ETRN コマンドを処理します。
`blocketrn`	ETRN コマンドをブロックします。
`domainetrn`	ドメインを指定する ETRN コマンドだけを処理します。
`silentetrn`	チャネル情報をエコーせずに ETRN コマンドを処理します。
`sendetrn`	ETRN コマンドを送信します。
`nosendetrn`	ETRN コマンドを送信しません。
VRFY キーワード	チャネルによる VRFY コマンドの処理方法を指定します。
`domainvrfy`	完全なアドレスを使用して VRFY コマンドを発行します。
`localvrfy`	ローカルアドレスを使用して VRFY コマンドを発行します。
`novrfy`	VRFY コマンドを発行しません。
`vrfyallow`	VRFY コマンドに対して詳細な情報を提供する応答を出します。
`vrfydefault`	チャネルの HIDE_VERIFY オプションの設定に従い、VRFY コマンドに対してデフォルトの応答を提供します。
`vrfyhide`	SMTP VRFY コマンドに対してあいまいな応答を出します。
EXPN キーワード	チャネルによる EXPN キーワードの処理方法を指定します。
`expnallow`	`DISABLE_EXPAND` SMTP チャネルオプションによって SMTP サーバーレベルで `EXPN` が無効にされている場合でも、EXPN を許可します。
`expndisable`	`EXPN` を無条件で無効にします。
`expndefault`	SMTP サーバーの設定で `EXPN` が許可されていれば EXPN を許可します。(デフォルト)
DNS ドメイン検査	チャネルが DNS ドメイン確認を行うかどうかを指定します。
`mailfromdnsverify`	`MAIL FROM:` コマンドに使用されているドメインが DNS に存在するかどうかを確認します。
`nomailfromdnsverify`	`MAIL FROM:` コマンドに使用されているドメインが DNS に存在するかどうかを確認しません。
文字セットと 8 ビットデータ	チャネルによる 8 ビットデータの処理方法を指定します (注: これらのキーワードは主に SMTP チャネルで使用されるが、その他のチャネルで使用されることもある。)
`charset7`	7 ビットのテキストメッセージに関連付けるデフォルトの文字セット。
`charset8`	8 ビットのテキストメッセージに関連付けるデフォルトの文字セット。
`charsetesc`	エスケープ文字を含む 7 ビットのテキストに関連付けるデフォルトの文字セット
`eightbit`	チャネルが 8 ビット文字をサポートします。
`eightnegotiate`	チャネルが 8 ビット転送の使用をネゴシエートします (可能な場合)。
`eightstrict`	ヘッダーに不正な 8 ビットデータが含まれている場合は、チャネルがそのメッセージを拒否するように指定します。
`sevenbit`	チャネルは 8 ビット文字をサポートしません。8 ビット文字はエンコードされる必要があります。
プロトコルストリーミング	プロトコルストリーミングチャネルが使用するプロトコルストリーミングの程度を指定します。
`streaming`	チャネルに関連付けられたプロトコルのストリーミングの程度を制御します。

チャネルプロトコル選択と改行記号

キーワード: smtp、nosmtp、smtp_crlf、smtp_cr、smtp_crorlf、 smtp_lf

smtp および nosmtp キーワードは、チャネルが SMTP プロトコルをサポートするかどうかを指定するものです。smtp (またはその変形) は、すべての SMTP チャネルに対して必須のキーワードです。

smtp_crlf、smtp_cr、smtp_crorlf、および smtp_lf キーワードは、MTA が改行記号として受け入れる文字シーケンスの種類を指定するために、SMTP チャネルに対して使用されます。smtp_crlf キーワードを使用すると、キャリッジリターン (CR) + ラインフィーダ (LF) のシーケンスのみが改行記号として認識されます。smtp_lf または smtp キーワードでは、CR なしの LF のみを使用できます。また、smtp_cr キーワードでは、LF なしの CR のみを使用できます。これらのオプションは、着信データにしか適用されません。

SMTP では改行記号として CRLF が要求されるため、MTA は常に CRLF シーケンスを生成します。各種の smtp キーワードは、MTA がその他の非標準的な改行記号を受け入れるかどうかを指定するだけのものです。たとえば、MTA が規定どおりの SMTP メッセージだけを受け入れ、非標準的な改行記号を含むメッセージを拒否するように指定するには、smtp_crlf を使います。

EHLO コマンドのサポート

キーワード: ehlo、noehlo、checkehlo

SMTP プロトコルは、その他のコマンドの使用のネゴシエーションを行うことができるよう拡張されています (RFC 1869)。これを利用するには、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」文字列が含まれている場合は HELO を使用し、それ以外の場合は EHLO を使用するように設定されています。このデフォルト設定は ehlo キーワードと checkehlo キーワードの中間的な効果を得るものであり、この設定を指定するためのキーワードは存在しないことに注意してください。

ETRN コマンドのサポート

キーワード: allowetrn、blocketrn、disableetrn、domainetrn、silentetrn、sendetrn、nosendetrn、novrfy

RFC 1985 で規定されている ETRN コマンドは SMTP サービスの拡張を可能にするものです。このコマンドによって SMTP サーバーがクライアントとの通信に基づいてメッセージキューの処理を開始し、指定のホストにメッセージを配信できるようになります。

SMTP クライアントは ETRN を使用して、自分宛のメッセージキューの処理を開始するようリモート SMTP サーバーに要求できます。つまり、ETRN は、自分のシステムに入ってくるメッセージのためにリモート SMTP システムをポーリングする方法を提供します。これは、一過性の接続しか持たないシステム間 (たとえば、ダイアルアップ以外の方法ではインターネットに接続できないサイト用に二次的な MX ホストとして設定されているサイトなど) に対して有用です。このコマンドを有効にすることで、ダイアルアップ接続を行うリモートサーバーもメール配信の要求を送ることができるようになります。

SMTP クライアントは、SMTP ETRN コマンド行でメッセージの送信先となるシステム名 (通常、その SMTP クライアントシステムの名前) を指定します。リモート SMTP サーバーが ETRN コマンドをサポートする場合、サーバーは指定のシステムに別途接続し、そのシステム宛のメッセージの配信を開始するためのプロセスがトリガされます。

ETRN コマンドへの応答

allowetrn、blocketrn、domainetrn、および silentetrn キーワードは、SMTP クライアントが ETRN コマンドを発行して MTA キュー内のメッセージを配信するよう要求した際に、MTA がどのように対応するかを指定するキーワードです。

デフォルト設定では allowetrn キーワードが有効になっているため、MTA はすべての ETRN コマンドを処理します。MTA が ETRN コマンドを拒否するように指定するには、チャネル定義に blocketrn キーワードを使用します。

MTA がすべての ETRN コマンドに従い、かつドメインによって確認されたチャネル名をエコーしないように指定するには、silentetrn キーワードを使用します。ETRN コマンドがドメインを指定している場合にのみ MTA がそのコマンドを処理するように指定するには、domainetrn キーワードを使用します。また、このキーワードを使用すると、MTA は、ドメインと一致し、MTA が実行しようとするチャネル名をエコーしません。

disableetrn では、ETRN コマンドに対するサポートが完全に無効となります。SMTP サーバーで、ETRN はサポートされているコマンドとして通知されません。

ETRN コマンドを送信する

sendetrn および nosendetrn チャネルキーワードは、MTA が SMTP 接続開始時に ETRN コマンドを送るかどうかを指定するためのものです。デフォルト設定では nosendetrn が有効になっているため、MTA は ETRN コマンドを送りません。リモート SMTP サーバーが ETRN コマンドをサポートする場合にのみ MTA が ETRN を発行するように指定するには、sendetrn キーワードを使用します。sendetrnn キーワードのあとには、メッセージの配信先となるシステムの名前を記述する必要があります。

VRFY コマンドのサポート

キーワード: domainvrfy、localvrfy、vrfyallow、vrfydefault、vrfyhide

VRFY コマンドは、SMTP クライアントが特定のユーザー名に宛てられたメールが存在するかどうかを確認するよう SMTP サーバーに要求するためのコマンドです。VRFY コマンドは、RFC 821 で定義されています。

サーバーは、ユーザーがローカルであるかどうか、メールが転送されるかどうかなどの情報を返します。250 という応答はユーザー名がローカルであることを意味し、251 はローカルではないがメッセージの転送は可能であることを意味します。サーバーの応答には、メールボックス名が含まれます。

VRFY コマンドを送信する

通常の環境では、SMTP ダイアログの一部として VRFY コマンドを発行する必要はありません。SMTP RCPT TO コマンドに VRFY コマンドと同じ効果があり、必要に応じて適切なエラーを返すためです。ただし、サーバーの中には RCPT TO コマンドを受け取った場合にはコマンドが指定するアドレスをいったん受理してからバウンスし、VRFY コマンドを受け取った場合はより広範なチェックを実行するものもあります。

デフォルト設定では novrfy キーワードが有効になっているため、MTA は VRFY コマンドを発行しません。

MTA が SMTP VRFY コマンドを発行するように指定するには、チャネル定義に domainvrfy または localvrfy キーワードを挿入します。domainvrfy キーワードを使用すると、完全なアドレス (user@host) を引数とする VRFY コマンドが発行されます。localvrfy キーワードを使用すると、アドレスのローカル部分 (user) だけを引数とする VRFY コマンドが発行されます。

VRFY コマンドに応答する

vrfyallow、vrfydefault、および vrfyhide キーワードは、送信側の SMTP クライアントから SMTP VRFY コマンドを出したときの SMTP サーバーの応答を制御します。

MTA が詳細な情報を含む応答を返すように指定するには、vrfyallow キーワードを使用します。HIDE_VERIFY=1 チャネルオプションが指定されていないかぎり、MTA が詳細な情報を含む応答を返すよう指定するには、vrfydefault キーワードを使用します。MTA があいまいな応答を返すよう指定するには、vrfyhide キーワードを使用します。これらのキーワードを使用すると、VRFY コマンドに対する応答をチャネルごとに制御できます。一方、HIDE_VERIFY オプションは、1 つの SMTP サーバーを介して処理されるすべての着信 TCP/IP チャネルに適用されます。

EXPN サポート

キーワード: expnallow、expndisable、expndefault

expnallow は、DISABLE_EXPAND SMTP チャネルオプションによって SMTP サーバーレベルで EXPN が無効にされている場合でも、EXPN を許可します。expndisable は、EXPN を無条件で無効にします。expndefault は、SMTP サーバーの設定で EXPN が許可されていればを許可します (デフォルト)。リストごとに展開を無効にすることができますが、サーバーレベルで無効にされている場合は、リストごとの設定は意味を持ちません。

DNS ドメイン確認

キーワード: mailfromdnsverify、nomailfromdnsverify

mailfromdnsverify を着信 TCP/IP チャネルに対して設定すると、MTA は SMTP MAIL FROM コマンドで指定されているドメインのエントリが DNS に存在するかどうかを確認し、エントリが存在しない場合にはメッセージを拒否します。デフォルト設定では、nomailfromdnsverify が有効になっているため、この確認は行われません。ただし、返信アドレスに対して DNS 確認を行うと、許可されるべきメッセージも拒否されてしまう可能性があることに注意してください (たとえば、正規のサイトでもそのドメイン名がまだ登録されていない場合や、DNS が適切に動作していない場合など)。これは、RFC 1123 の「Requirements for Internet Hosts (インターネットホストの必要条件)」で規定されている電子メール受信の心得に反する行為です。ただし、存在しないドメインから不特定多数宛のメール (UBE) が送られる場合は、この確認を行なった方がよい場合もあります。

COM および ORG トップレベルドメインの DNS ワイルドカードエントリの導入によって mailfromdnsverify が有用でなくなったため、mailfromdnsverify コードは変更されました。DNS が 1 つまたは複数の A レコードを返すと、これらの値と新しい MTA オプション BLOCKED_MAIL_FROM_IPS によって指定されたドメインリテラルとが比較されます。一致する値が見つかると、ドメインは無効とみなされます。正しい動作を復元するための、現在の正しい設定は次のとおりです。

BLOCKED_MAIL_FROM_IPS=[64.94.110.11]

このオプションの値はデフォルトでは空の文字列です。

文字セットのラベルと 8 ビットデータ

キーワード: charset7、charset8、charsetesc、sevenbit、eightbit、 eightnegotiate、eightstrict

文字セットのラベル

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: ヘッダー行には文字セット名が挿入されません。

charset8 キーワードでは、メッセージヘッダーの 8 ビット文字の MIME エンコーディングも制御されます (メッセージヘッダーでは、8 ビットのデータは常に不正)。MTA では通常、メッセージヘッダーにあるすべての不正な 8 ビットデータが MIME でエンコードされ、charset8 の値が指定されていない場合は「UNKNOWN」文字セットとしてラベル付けされます。

これらの文字セット指定が既存のラベルより優先されることはありません。メッセージにすでに文字セットラベルが含まれている場合やメッセージがテキストでない場合、これらのキーワードは効果をもたらしません。通常、MTA のローカルチャネルは次のようにラベル付けされます。

l ... charset7 US-ASCII charset8 ISO-8859-1 ...
hostname

Content-type ヘッダーがメッセージにない場合は、このヘッダーが追加されます。また、MIME-version: ヘッダー行がない場合は、そのヘッダー行が追加されます。

charsetesc キーワードは、特に日本語や韓国語の文字セットを使用し、エスケープ文字を含むラベルのないメッセージを受信するチャネルに便利です。

8 ビットデータ

127 (10 進) 以上の序数値を持つ文字の使用は制限される場合があります。特に、SMTP サーバーの中には、高ビットを切り捨てるために 8ビット領域の文字を含むメッセージの文字化けの原因となるものもあります。

Messaging Server は、そのようなメッセージを自動的にエンコードし、8 ビットデータがメッセージに直接表示されないようにする機能を備えています。特定のチャネルのキューに入れられるすべてのメッセージにエンコードを適用するには、sevenbit キーワードを使用します。そのような制限がない場合は、eightbit を使用します。

リモート SMTP サーバーが 8 ビットをサポートすると明示していないかぎり、SMTP プロトコルは 8 ビットを許可しません。ただし、拡張 SMTP など、転送形式によっては、8 ビットの文字を転送できるかどうかを判断するためのネゴシエーションの形式をサポートするものもあります。ネゴシエートが失敗した場合に備えて、eightnegotiate キーワードを使用し、チャネルがメッセージをエンコードするように指定しておくことを強くお勧めします。デフォルト設定ではすべてのチャネルに対してこのキーワードが有効になっているため、ネゴシエーションをサポートしないチャネルは 8 ビットデータの転送が可能であるという仮定のもとに動作します。

Messaging Server が、ヘッダーに不正な 8 ビットデータを含むメッセージをすべて拒否するように設定するには、eightstrict キーワードを使用します。

プロトコルストリーミング

キーワード: streaming

メールプロトコルによっては、ストリーミングをサポートするものもあります。ストリーミングがサポートされている場合は、MTA が一度に複数の要求を発行し、それぞれに対する応答をバッチで受け取ることができます。streaming キーワードは、チャネルに関連付けられたプロトコルのストリーミングの程度を制御するキーワードです。このキーワードには整数値のパラメータが必要です。パラメータの解釈は、プロトコルによって異なります。

通常の環境では、ストリーミングサポートが可能な範囲は SMTP パイプライン拡張でネゴシエートされます。このキーワードは、通常の環境で使用されることがありません。

ストリーミング値の範囲は 0 から 3 までです。値が 0 の場合はストリーミングが指定されず、値が 1 の場合は RCPT TO コマンドグループがストリーミングされ、2 の場合は MAIL FROM/RCPT TO が、3 の場合は HELO/MAIL FROM/RCPT TO または RSET/MAIL FROM/RCPT TO がストリーミングされます。デフォルトは 0 です。

TCP/IP 接続と DNS 検索のサポート

サーバーによる TCP/IP 接続およびアドレス検索の処理方法を指定することができます。この項では、次の内容について説明します。

表 12–22 に、この項で説明されている TCP/IP 接続および DNS 検索に関連するキーワードの一覧を示します。

表 12–22 TCP/IP 接続と DNS 検索のキーワード


チャネルキーワード	説明
ポート選択とインタフェースのアドレス	SMTP 接続用のデフォルトポート番号とインタフェースのアドレスを指定します。
`port`	SMTP 接続用のデフォルトポート番号を指定します。標準ポートは 25 です。
`interfaceaddress`	指定された TCP/IP インタフェースアドレスにバインドします。
キャッシュキーワード	接続情報のキャッシュ方法を指定します。
`cacheeverything`	すべての接続情報をキャッシュします。
`cachefailures`	接続失敗に関する情報だけをキャッシュします。
`cachesuccesses`	接続成功に関する情報だけをキャッシュします。
`nocache`	接続情報をキャッシュしません。
リバース DNS 検索	着信 SMTP 接続に対するリバース DNS 検索の処理方法を指定します。
`forwardcheckdelete`	リバース DNS 検索のあとに正引き検索を行い、リバース DNS 検索で返された名前の正引き検索がオリジナルの接続の IP 番号に一致するかどうかを確認します。一致しない場合、リバース DNS 検索で返された名前は削除され、IP アドレスが使用されます。
`forwardchecknone`	DNS リバース検索のあとに正引き検索を実行しません。
`forwardchecktag`	リバース DNS 検索を実行して返された名前を正引き検索して、IP 番号がオリジナルの接続の IP 番号に一致するかどうかを確認します。一致しなければ名前に「*」を付けます。
IDENT 検索 /DNS リバース検索	着信 SMTP 接続に対する IDENT 検索および DNS リバース検索の処理方法を指定します。
`identnone`	IDENT 検索を実行しません。IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名と IP アドレスの両方を含めます。
`identnonelimited`	IDENT 検索を実行しません。IP からホスト名への変換を実行し (ただしチャネルの切り替えを行う際にはホスト名を使用しない)、`Received:` ヘッダーにホスト名と IP アドレスの両方を含めます。
`identnonenumeric`	IDENT 検索および IP からホスト名への変換を実行しません。
`identnonesymbolic`	IDENT 検索を実行しません。IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名だけを含めます。
`identtcp`	着信 SMTP 接続での IDENT 検索および IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名と IP アドレスの両方を含めます
`identtcplimited`	着信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行します (ただし、チャネルの切り替えを行う際にはホスト名を使用しない)。`Received:` ヘッダーにホスト名と IP アドレスを含めます。
`indenttcpnumeric`	着信 SMTP 接続で IDENT 検索を実行します。IP からホスト名への変換を実行しません。
`identtcpsymbolic`	着信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行し、`Received:` ヘッダーにホスト名だけを含めます。
MX レコードのサポートと TCP/IP ネームサーバー	チャネルが MX レコード検索をサポートするかどうか、およびどのように処理するかを指定します。
`mx`	TCP/IP ネットワークおよびソフトウェアが MX レコード検索をサポートします。
`nomx`	TCP/IP ネットワークが MX 検索をサポートしません。
`defaultmx`	チャネルが、ネットワークから MX 検索を実行するかどうかを決定します。
`randommx`	MX 検索を実行し、返されたエントリを同等の優先度でランダム化します。
`nonrandomemx`	MX 検索を実行しますが、返されたエントリを同等の優先度でランダム化しません。
`nameservers`	TCP/IP スタックが選択したネームサーバーの代わりに照合するネームサーバーのリストを指定します。`nameservers` には、空白文字で区切られたネームサーバーの IP アドレスのリストが必要です。
`defaultnameservers`	TCP/IP スタックが選択したネームサーバーを照合します。
`lastresort`	最後のホストを指定します。
switch キーワード	メールを着信する代替チャネルの選択を制御します。
`allowswitchchannel`	`switchchannel` チャネルからこのチャネルへの切り替えを許可します。
`noswitchchannel`	サーバーチャネルの使用を継続し、送信元ホストに関連付けられているチャネルに切り替えません。また、ほかのチャネルからこのチャネルへの切り替えを許可しません。
`switchchannel`	サーバーチャネルから送信元のホストに関連付けられたチャネルに切り替えます。
`tlsswitchchannel`	TLS のネゴシエートが成功した場合に、ほかのチャネルに切り替えます。
`saslswitchchannel`	SASL 認証が成功した場合にほかのチャネルへ切り替えます。
ターゲットホストの選択とメッセージコピーのストレージ	ターゲットホストシステムと、メッセージコピーのストレージ方法を指定します。
`daemon`	エンベロープアドレスにかかわらず特定のホストシステムに接続します。
`single`	チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成されるように指定します。
`single_sys`	各宛先システム用にメッセージのコピーを 1 つずつ作成します。

TCP/IP ポート番号とインタフェースアドレス

キーワード: port、interfaceaddress

通常、SMTP 実装 TCP/IP チャネルは、ポート 25 に接続してメッセージを送信します。SMTP 実装 TCP/IP チャネルがその他のポートを使用するように指定するには、port キーワードを使用します。このキーワードは、PORT ディスパッチャオプション (SMTP 接続を受け入れるために MTA が待機するポートを制御するオプション) を補足するものです。

interfaceaddress キーワードは、TCP/IP チャネルが送信時にソースアドレスとしてバインドするアドレスを制御します。つまり、複数のインタフェースアドレスが存在するシステム上で、MTA が SMTP メッセージを送信する際にどのアドレスをソース IP アドレスとして使用するかを制御するキーワードです。このキーワードは、INTERFACE_ADDRESS ディスパッチャオプション (接続およびメッセージを受け入れるために TCP/IP チャネルが待機するインタフェースアドレスを制御するオプション) を補足するものです。

チャネル接続情報のキャッシング

キーワード: cacheeverything、nocache、cachefailures、cachesuccesses

SMTP プロトコルを使用するチャネルは、過去の接続試行の履歴を含むキャッシュを管理しています。このキャッシュは、アクセスできないホストに繰り返し接続しようとして時間を浪費し、ほかのメッセージの配信が遅延されることを回避するために使用されます。このキャッシュは送信 SMTP チャネルが動作中の間のみ維持され、動作が終了するたびに削除されます。

通常、キャッシュには、成功した接続試行と失敗した接続試行の両方に関する情報が記録されます。(成功した試行は、その後失敗する試行を相殺するために記録される。すなわち、一度接続に成功したホストがその後失敗しても、はじめて試行する接続や以前失敗した接続ほど次の接続試行が遅れることはない。)

ただし、MTA が使用するキャッシング方法がすべての状況に適しているというわけではありません。そこで、チャネルキーワードを使用して MTA キャッシュを調整します。

cacheeverything キーワードは、すべての形式のキャッシングを有効にします。デフォルト設定ではこのキーワードが使用されます。nocache キーワードは、すべてのキャッシングを無効にします。

cachefailures キーワードは、失敗した接続のキャッシングだけを有効にします。このキーワードを使用すると、次の試行は cacheeverything を使用した場合より多くの制約を受けることになります。cachesuccesses は成功した接続だけをキャッシュします。このキーワードは、SMTP チャネルに対する nocache キーワードと同等のものです。

リバース DNS 検索

キーワード: forwardchecknone、forwardchecktag、 forwardcheckdelete

forwardchecknone、forwardchecktag、および forwardcheckdelete チャネルキーワードは、リバース DNS 検索の影響を修正します。これらのキーワードは、MTA が DNS リバース検索によって検出された IP 名の正引き検索を実行するかどうか、および実行する場合には正引き検索の結果がオリジナルの接続の IP 番号と一致しなかった場合にどのように対処するかを制御します。

デフォルト設定では forwardchecknone キーワードが有効になっているため、正引き検索は実行されません。forwardchecktag キーワードは、リバース検索が行われるたびに正引き検索を実行し、検出された番号がオリジナルの接続の番号と一致しない場合は IP 名にアスタリスク (*) を付けるように指定します。forwardcheckdelete キーワードは、リバース検索が行われるたびに正引き検索を実行し、リバース検索で返された名前の正引き検索がオリジナルの接続の IP アドレスに一致しなかった場合はリバース検索で返された名前を無視 (削除) するように、MTA に指示します。この場合、MTA はオリジナルの IP アドレスを使用します。

注 –

複数の IP アドレスに「一般的な」IP 名が使用されているサイトの場合、正引きの結果がオリジナルの IP アドレスと一致しないのは比較的頻繁に見られる現象です。

IDENT 検索

キーワード: identnone、identnonelimited、identtnonnumeric、identnonesymbolic、identtcp、identtcpnumeric、identtcpsymbolic、 identtcplimited

IDENT キーワードは、MTA が IDENT プロトコルを使用して接続や検索を処理する方法を制御します。IDENT プロトコルは、RFC 1413 で規定されています。

identtcp、identtcpsymbolic、および identtcpnumeric キーワードは、MTA が接続や検索に IDENT プロトコルを使用するように指定するものです。IDENT プロトコルから入手した情報 (通常、SMTP 接続を使用しているユーザーの ID) は、次のようにメッセージの Received: ヘッダー行に挿入されます。

identtcp は着信した IP 番号に呼応するホスト名 (DNS リバース検索で検出された名前) および IP 番号そのものを挿入します。
identtcpsymbolic は着信した IP 番号に呼応するホスト名 (DNS リバース検索で検出された名前) を挿入します。IP 番号そのものは Received: ヘッダーに挿入されません。
identtcpnumeric は着信した IP 番号を挿入します。リバース DNS 検索は実行されません。

注 –

identtcp、identtcpsymbolic、または identtcpnumeric による IDENT 検索が役に立つのは、リモートシステムで IDENT サーバーが稼働している場合です。

IDENT クエリの試行でパフォーマンスヒットが発生する場合があります。そうすると、ルーターは認識できないポートへの接続試行を次第に「ブラックホール化」するようになります。IDENT 検索でこのような状況が発生した場合は、接続がタイムアウトするまで MTA には応答が返されません (通常、このタイムアウトは TCP/IP スタックが制御するもので、1、2 分ほどかかる)。

別のパフォーマンスの問題が、identtcp、indenttcplimited、あるいは identtcpsymbolic を identtcpnumeric と比較するときにも発生します。identtcp、identtcplimited、または identtcpsymbolic によって DNS リバース検索が実行された場合、よりユーザーフレンドリーなホスト名を返すにはより長い時間が必要になります。

identnone キーワードは IDENT 検索を無効にしますが、IP からホスト名への変換は行われます。メッセージの Received: ヘッダーには IP 番号とホスト名の両方が含まれます。

identnonesymbolic キーワードは IDENT 検索を無効にしますが、IP からホスト名への変換は行われます。メッセージの Received: ヘッダーにはホスト名だけが含まれます。

identnonenumeric キーワードは IDENT 検索を無効にし、DNS リバース検索の IP 番号からホスト名への変換を禁止します。また、Received: ヘッダーにユーザーフレンドリーではない情報を使用するため、パフォーマンスの向上につながる可能性もあります。これがデフォルトです。

IDENT 検索、リバース DNS 検索、Received: ヘッダーに表示する情報などに関し、identtcplimited キーワードは identtcp と、identnonelimited キーワードは identnone とそれぞれ同様の効果をもたらします。ただし、異なる点として、identtcplimited および identnonelimited の場合は、switchchannel キーワードの影響で、DNS リバース検索によってホスト名が検出されたかどうかにかかわらず常に IP リテラルアドレスがチャネルスイッチのベースとして使用されます。

TCP/IP MX レコードのサポート

キーワード: mx、nomx、defaultmx、randommx、nonrandommx

TCP/IP ネットワークには、MX (メールの転送) レコードの使用をサポートするものとしないものがあります。MTA システムの接続先であるネットワークから提供される MX レコードだけを使用するように設定できる TCP/IP チャネルプログラムもあります。mx、nomx、defaultmx、randommx、nonrandommx キーワードは MX レコードのサポートを制御します。

randommx キーワードは、MX 検索を実行し、同等の優先順位を持つ MX レコード値を順不同で処理するように指定するものです。nonrandommx キーワードは、MX 検索を実行し、同等の優先順位を持つ MX レコード値を受信したとおりの順番で処理するように指定するものです。

現在のところ、mx キーワードは nonrandommx キーワードと同じものですが、将来のリリースでは randommx と同じになるように変更される可能性もあります。nomx キーワードは MX 検索を無効にします。defaultmx キーワードは、ネットワークが MX レコードをサポートする場合に mx を使用するように指定します。MX 検索をサポートするチャネルではすべて defaultmx キーワードがデフォルトとして設定されています。

ネームサーバー検索

キーワード: nameservers、defaultnameservers

ネームサーバー検索が実行される際、TCP/IP スタックが選択したネームサーバーの代わりに nameservers チャネルキーワードを使ってネームサーバーのリストを指定することができます。nameservers キーワードには、空白文字で区切られたネームサーバーの IP アドレスのリストが必要です。次の例を参照してください。

nameservers 1.2.3.1 1.2.3.2

デフォルト設定では defaultnameservers が有効になっているため、TCP/IP スタックの選択によるネームサーバーが使用されます。

UNIX でネームサーバー検索を禁止するには、nsswitch.conf ファイルを編集します。NT の場合は、TCP/IP 設定を変更します。

最後のホスト

キーワード: lastresort

lastresort キーワードは、ほかのホストへの接続試行がすべて失敗した場合に最終的な接続先となるホストを指定します。このキーワードは、事実上の最終手段的 MX レコードとして動作します。このキーワードは、SMTP チャネルに対してのみ効果があります。

このキーワードでは、「最終手段的システム」の名前を指定する単一のパラメータが必要です。例:

tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON

着信メール用代替チャネル (切り替えチャネル)

キーワード: switchchannel、allowswitchchannel、 noswitchchannel。「SMTP 認証、SASL、TLS」の saslswitchchannel および「Transport Layer Security」の tlsswitchchannel も参照してください。

次の各キーワードは、着信メール用代替チャネルの選択を制御するものです。switchchannel、allowswitchchannel、noswitchchannel。

MTA がリモートシステムから着信接続を受け付ける場合、MTA はその接続に関連付けるチャネルを選ぶ必要があります。通常、使用するチャネルは転送形式に基づいて決定されます。たとえば、TCP/IP を介する着信 SMTP 接続は、自動的に tcp_local チャネルに関連付けられます。

ただし、異なる性質を持つ複数の送信チャネルが複数のシステムに対して同時に使用される場合は、この限りではありません。この場合、着信と送信がそれぞれ異なるチャネルで行われるため、対応するチャネルの性質がリモートシステムに関連付けられません。

この問題は、switchchannel キーワードを使用することにより解決できます。サーバーが最初に使用するチャネルに switchchannel を指定すると、送信元ホストの IP アドレスがチャネルテーブルに照合され、一致した場合はソースチャネルがそれに合わせて切り替えられます。一致するものがない場合、または最初のデフォルト着信チャネルに一致するものが検出された場合は、MTA がリバース DNS 検索によって検出したホスト名に一致するエントリを見つけようと試みる場合もあります。ソースチャネルは switchchannel または allowswitchchannel にマークされているチャネルに切り替えられます (デフォルト)。noswitchchannel キーワードは、チャネルの切り替えを行わないように指定するためのものです。

デフォルトでは、サーバーが関連付けられているチャネル以外のチャネルに switchchannel を使用しても効果はありません。現在のところ、switchchannel を使用できるのは SMTP チャネルに対してのみですが、いずれにしても SMTP チャネル以外に switchchannel を使用すべきではありません。

ターゲットホストの選択

キーワード: daemon、single、single_sys

daemon キーワードの解釈と使用は、適用するチャネルの種類によって異なります。

daemon キーワードは、SMTP チャネル上でターゲットホストの選択を制御するために使用します。

通常、ホストへの接続に使用されているチャネルは、メッセージのエンベロープアドレスに表示されます。daemon キーワードは、エンベロープアドレスにどのチャネルが表示されているかにかかわらず、チャネルがファイアウォールやメールハブシステムなど特定のリモートシステムに接続するように設定します。実際のリモートシステム名は、次の例に示すように daemon キーワードの直後に表示されます。

tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMON

daemon キーワードの後ろの引数が完全なドメイン名ではない場合、引数は無視され、チャネルは正規ホストに接続します。正規ホストは、チャネルに関連付けられている完全修飾ホスト名です。これは、3 行からなるチャネルブロックの 2 行目に指定できます。

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

正規ホストを 2 行からなるチャネルブロックの TCP-DAEMON のあとに指定して、送信接続がそれぞれの接続を特定のホストとして識別するようにもできます。

tcp_firewall smtp mx daemon router
TCP-DAEMON firewall.acme.com

ファイアウォールやゲートウェイシステムを正規ホスト名として指定する場合、次の例に示すように daemon キーワードに与えられる引数は、一般的にルーターとして指定されます。

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

また、関連するキーワードとして、single および single_sys があります。single キーワードは、各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。single_sys キーワードは、各宛先システム用にメッセージのコピーを 1 つずつ作成します。どちらのキーワードを使用しても、メッセージがキューに入れられる各チャネルに最低 1 つずつメッセージのコピーが作成されることに注意してください。

SMTP 認証、SASL、TLS

キーワード: maysaslserver、mustsaslserver、nosasl、nosaslserver、saslswitchchannel、nosaslswitchchannel

Messaging Server が SASL (Simple Authentication and Security Layer) を使用したSMTP サーバーの認証をサポートするかどうかを指定できます。SASL は RFC 2222 で定義されています、SASL、SMTP 認証、およびセキュリティーの詳細については、第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

maysaslserver、mustsaslserver、nosasl、nosaslserver, switchchannel、および saslswitchchannel チャネルキーワードは、SMTP プロトコルが使用される際に、TCP/IP チャネルなどの SMTP チャネルによって SASL (SMTP AUTH) が使用されるように設定するためのものです。

デフォルト設定では nosasl が有効になっているため、SASL 認証は許可または試行されません。このキーワードは nosaslserver を包括するため、SASL 認証の使用はすべて禁止されます。maysaslserver を指定すると、SMTP サーバーは、クライアントが SASL 認証の使用を試行することを許可します。mustsaslserver を指定すると、SMTP サーバーは、クライアントが SASL 認証を使用することを要求します。SMTP サーバーは、リモートクライアントが認証に成功しないかぎり、メッセージを受け付けません。

クライアントが SASL の使用に成功したときに着信接続を指定のチャネルに切り替えるには、saslswitchchannel を使います。このキーワードには、切り替え先のチャネルを指定する必要があります。

ヘッダー内の SMTP AUTH から認証済みアドレスを使用する

キーワード: authrewrite

authrewrite チャネルキーワードと関連の AUTH_REWRITE マッピングテーブルを使用すると、認証動作で取得したアドレス情報に基づいてヘッダーとエンベロープアドレスを変更することができます。特に、SASL 認証で、認証された電子メールアドレスが提供されるように設定することができます。FROM_ACCESS マッピングによって無視されることもありますが、通常は SMTP AUTH 情報が使用されます。表 12–23 にあるように、authrewrite キーワードは必須のビット値をとります。

表 12–23 authrewrite のビット値


ビット	値	説明
0	1	何も変更しないでください (デフォルト)。
1	2	認証動作によって提供されたアドレスを含む、Sender: または Resent-sender: ヘッダーフィールドを追加します。ほかの Resent- フィールドが存在する場合は、Resent-variant が使用されます。
2	4	認証動作によって提供されたアドレスを含む、Sender: ヘッダーフィールドを追加します。
3	8	次のような形式の `AUTH_REWRITE` というマッピングテーブルプローブを作成します。 `mail-from\|sender\|from\|auth-sender` `mail-from` はエンベロープ `From:` アドレス、`sender` は `Sender:` または `Resent-sender:` ヘッダーフィールドのアドレス、`from` は `From:` または `Resent-From:` ヘッダーフィールドのアドレス、`auth-sender` は認証動作によって提供されたアドレスです。この結果は、`AUTH_REWRITE` マッピングを使用して実行されます。マッピングでは、縦棒文字 (`\|`) で区切られた項目の一覧が返されます。項目は、次のフラグ設定に基づいて順番に消費されます。 `$J $K` メッセージのエンベロープ `From:` アドレスを置き換えます `$Y $T` 適切な `Sender:` または `Resent-sender:` ヘッダーフィールドを追加します。 `$N` メッセージを拒否します。エラーメッセージのテキストはマッピングの結果によって指定されます。テキストがなにも指定されていない場合は、`invalid originator address used` (無効な差出人アドレス) というエラーメッセージが表示されます。 `$Z` 適切な `From:` または `Resent-from:` ヘッダーフィールドを追加します。(注: 一般に、`From:` フィールドを無効にするべきではない。) ほかの `Resent-` フィールドがヘッダー内に存在する場合、`Resent-`variants が使用されます。
4	16	認証によって認証済みアドレスが提供されていない場合でも、`AUTH_REWRITE` マッピングを適用します。このビットがクリアされている場合は、認証済みアドレスが利用可能なときだけマッピングが適用されます。
5	32	`AUTH_REWRITE` マッピングプローブの先頭にソースチャネルを含めます。ほかの情報とは `\|` で区切られています。このビットがクリアされている場合、チャネルは含められません。

注意 –

エンベロープおよびヘッダーアドレスの変更はほとんどの場合に正しく行われないため、$Z フラグは厳しく制限する必要があります。

Microsoft Exchange ゲートウェイチャネルを指定する

キーワード: msexchange、nomsexchange

msexchange チャネルキーワードは TCP/IP チャネルで使用して、MTA にこれが Microsoft Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示できます。SASL に対応した (maysaslserver キーワード、または mustsaslserver キーワードを使用する) 着信 TCP/IP チャネルに配置されると、MTA の SMTP サーバーが、「誤った」形式 (オリジナルの ESMTP_AUTH 仕様に基づくもの。この仕様は、新しく適切な AUTH 仕様ではなく、適切な ESMTP 形式とは互換性がない) の AUTH を通知することになります。たとえば、Microsoft Exchange クライアントの中には、適切な AUTH 形式を認識せず、不正な AUTH 形式のみを認識するものがあります。

msexchange チャネルキーワードでも、破損した TLS コマンドを通知 (および認識) するようになります。

デフォルトは nomsexchange です。

Transport Layer Security

キーワード: maytls、maytlsclient、maytlsserver、musttls、musttlsclient、 musttlsserver、notls、notlsclient、 notlsserver、tlsswitchchannel

maytls、maytlsclient、maytlsserver、musttls、musttlsclient、musttlsserver、notls、notlsclient、notlsserver、および tlsswitchchannel チャネルキーワードは、TCP/IP チャネルなどの SMTP ベースのチャネルが SMTP プロトコルを使用するときに TLS をどのように処理するかを設定するためのキーワードです。

デフォルト設定では notls が有効になっているため、TLS は許可または試行されません。このキーワードは notlsclient (MTA SMTP クライアントは送信接続に TLS を使用しない。送信接続時に STARTTLS コマンドは発行されない) および notlsserver (MTA SMTP サーバーは着信接続時に TLS の使用を許可しない。SMTP サーバーもコマンド自体も STARTTLS 拡張に通知しない) を包括しています。

maytls が設定されている場合、MTA は TLS 使用の接続を受け入れ、送信接続にも TLS を使用しようと試みます。このキーワードは、maytlsclient (メッセージを送信する際に TLS をサポートする SMTP サーバーに送信するのであれば、MTA SMTP クライアントは TLS を使用する) および maytlsserver (MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、メッセージを着信する際に TLS を使用できる) を包括しています。

TLS が機能するためには、次の条件が整っている必要があります。

mailsrv アカウントでファイルにアクセスできるように、証明書の保護と所有権が設定されている。
証明書が保存されているディレクトリに、mailsrv アカウントでその中のファイルにアクセスできるような保護と所有権が設定されている。

musttls キーワードを指定すると、MTA は送着信接続に必ず TLS を使用します。TLS の使用をネゴシエートできなかったリモートシステムとの電子メールの交換は許可されません。このキーワードは、musttlsclient を包括しているので、MTA SMTP クライアントはメッセージの送信に必ず TLS を使用し、TLS 使用のネゴシエーションが成功しない SMTP サーバーにはメッセージを送りません (MTA は STARTTLS コマンドを発行し、そのコマンドは必ず成功しなけらばならない)。また、このキーワードは musttlsserver も包括しているので、MTA SMTP サーバーは STARTTLS 拡張をサポートすることを通知し、着信メッセージを受け入れる際には必ず TLS を使用し、TLS の使用のネゴシエーションが成功しないクライアントからのメッセージは拒否します。

tlsswitchchannel キーワードは、クライアントが TSL 使用のネゴシエートに成功した場合、着信した接続を指定のチャネルに切り替えるためのキーワードです。このキーワードには、切り替え先のチャネルを指定する必要があります。

メッセージの処理と配信を設定する

サーバーが特定の条件に基づいてメッセージの配信を試みるように指定できます。また、サービスジョブの処理制限や、新しい SMTP チャネルスレッドを作成するタイミングなど、ジョブ処理に関するパラメータを指定することも可能です。この項では、次の内容について説明します。

メッセージの処理と配信の詳細については、表 12–24 を参照してください。

「メッセージの処理と配信を設定する」に、この節で説明されているキーワードのリストを示します。

表 12–24 メッセージの処理と配信のキーワード


キーワード	定義
即時配信	メッセージの即時配信に関する設定を定義します。
`immnonurgent`	優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始します。
チャネルの方向性	チャネルを処理するプログラムの種類を指定します。
bidirectional	チャネルはマスターとスレーブの両方のプログラムによって処理されます。
master	チャネルはマスタープログラム (`master`) によって処理されます。
slave	チャネルはスレーブプログラム (`slave`) によって処理されます。
遅延配信	遅延ジョブの配信に関する設定を定義します。
`backoff`	遅延メッセージの配信試行頻度を指定します。`normalbackoff`、`nonurgentbackoff`、`urgentbackoff` で置き換え可能。
`deferred`	`Deferred-delivery:` ヘッダー行の認識と処理を行います。
`nodeferred`	デフォルト。`Deferred-delivery:` ヘッダー行が許可されないように指定します。
`nonurgentbackoff`	優先度が低いメッセージの配信試行頻度。
`normalbackoff`	優先度が標準であるメッセージの配信試行頻度。
`urgentbackoff`	優先度が高いメッセージの配信試行頻度。
サイズに基づくメッセージの優先度	サイズに基づいてメッセージの優先度を定義します。
`nonurgentblocklimit`	指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定します。該当するメッセージは次の定期ジョブまで処理されません。
`normalblocklimit`	指定値以上のサイズを持つメッセージの優先度を「低」に設定します。
`urgentblocklimit`	指定値以上のサイズを持つメッセージの優先度を「標準」に設定します。
チャネル実行ジョブの処理プール	優先度やジョブ期日が異なる処理プールを指定します。
`pool`	チャネルが動作するプールを指定します。
`after`	チャネルが動作するまでの遅延時間を指定します。
サービスジョブの制限	サービスジョブ数、および 1 つのジョブで処理できるメッセージファイルの最大数を指定します。
`maxjobs`	1 つのチャネルに対して同時実行できるジョブの最大数を指定します。
`filesperjob`	1 つのジョブで処理できるキューエントリの数を指定します。
SMTP チャネルスレッド
`threaddepth`	マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数。
複数アドレス拡張	複数の受取人を持つメッセージ処理を定義します。
`expandlimit`	アドレスの数がこの制限を超えた場合、着信メッセージを「オフライン」で処理します。
`expandchannel`	expandlimit の適用による遅延拡張を実行するチャネルを指定します。
`holdlimit`	アドレスの数がこの制限を越えた場合、着信メッセージを保留します。
トランザクションの制限	接続トランザクションの制限を指定します。
transactionlimit	1 つの接続について許されるメッセージの数を制限します。
配信不能メッセージ通知	配信不能メッセージ通知を送るタイミングを指定します。
`notices`	通知を送り、メッセージを返すまでの時間を指定します。
`nonurgentnotices`	優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
`normalnotices`	優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。
`urgentnotices`	優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。

チャネルの方向性を設定する

キーワード: master、slave、bidirectional

チャネルを処理するプログラムは、マスタープログラム (master)、スレーブプログラム (slave)、あるいは両方のプログラム (bidirectional ) という 3 つのキーワードで指定されます。これらのどのキーワードも指定されていない場合のデフォルトは bidirectional です。これらのキーワードによって、チャネルのキューにメッセージが入れられたときに MTA が配信活動を開始するかどうかが決まります。

これらのキーワードを使用すると、対応するチャネルプログラムの特徴が反映されるようになります。これらのキーワードをいつ、どこで使用すべきかについては、MTA がサポートする各種チャネルの説明を参照してください。

指定配信日を実行する

キーワード: deferred、nodeferred、immnonurgent

deferred チャネルキーワードは、Deferred-delivery: ヘッダー行の認識と処理を行います。未来の deferred 指定配信日が付いているメッセージは、有効期限が切れて返されるか、あるいは指定配信日がくるまでチャネルのキューに保管されます。Deferred-delivery: ヘッダー行の形式と操作の詳細については、RFC 1327 を参照してください。

デフォルトのキーワードは nodeferred です。RFC 1327 では配信日指定によるメッセージ処理のサポートが義務付けられていますが、実際にそれを効果的に行えば、人々がディスク制限容量の拡張手段としてメールシステムを使用できるようになります。

immnonurgent キーワードは、優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始します。

配信失敗メッセージの再配信回数を指定する

キーワード: backoff、nonurgentbackoff、normalbackoff、urgentbackoff、notices

デフォルトでは、配信に失敗したメッセージの再配信回数はメッセージの優先度によって異なります。次にデフォルトの再配信間隔を分単位で示します。優先度に続いて数字が示されていますが、最初の数字は最初に配信に失敗してから再配信を試みるまでの時間 (分) です。

緊急: 30, 60, 60, 120, 120, 120, 240
標準: 60, 120, 120, 240, 240, 240, 480
緊急ではない: 120, 240, 240, 480, 480, 480, 960

優先度が「緊急」のメッセージの場合、最初の配信失敗から 30 分後に再度の配信を試み、再配信から 60 分後に次の再配信、その 60 分後に次の再配信、さらに 120 分後に次の再配信が続きます。最後に示した配信後は同じ間隔で再配信が試みられます。優先度が高いメッセージの場合では 240 分ごとに再配信が試みられます。

再配信が行われるのは、notices、nonurgentnotices、normalnotices、または urgentnotices キーワードで指定された期間内です。期間内に配信が成功しなければ、配信失敗通知が作成され、メッセージは差出人に返送されます。notices キーワードの詳細については、「通知メッセージの配信間隔を設定するには」を参照してください。

backoff キーワードを使うと、優先度ごとにメッセージ再配信間隔を設定することができます。nonurgentbackoff は優先度が低いメッセージの再配信間隔を指定します。normalbackoff は優先度が標準のメッセージの再配信間隔を指定します。urgentbackoff は優先度が高いメッセージの再配信間隔を指定します。backoff のどのキーワードも指定されていなければ、優先度とは無関係に再配信間隔が指定されます。

次に例を示します。

urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"

これは優先度の高いメッセージの再配信の場合です。最初の配信失敗から 30 分後に再度の配信を試み、再配信から1 時間後 (最初の配信失敗から 1 時間半後) に 2 回目の再配信、その 2 時間後に 3 回目、その 3 時間後に 4 回目、その 4 時間後に 5 回目、その 5 時間後に 6 回目、その 8 時間後に 7 回目、その 16 時間後に 8 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 16 時間ごとに再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。間隔の構文は ISO 8601P に記述されており、『Sun Java System Messaging Server Administration Reference』でも説明されています。

次に、優先度が標準のメッセージの例を示します。

normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d” "p1w"

最初の配信失敗から 30 分後に再度の配信を試み、その 1 時間後に 2 回目の再配信、その 8 時間後に 3 回目、その 1 日後に 4 回目、その 2 日後に 5 回目、その 1 週間後に 6 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで毎週、再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。

最後に、優先度によらない、すべての配信失敗メッセージの例を示します。

backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"

nonurgentbackoff、normalbackoff、または urgentbackoff で置き換えなければ、どのメッセージも、最初の配信失敗から 30 分後に再度の配信を試み、その 2 時間後に 2 回目の再配信、その 16 時間後に 3 回目、その 36 時間後に 4 回目、その 3 日後に 5 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 3 日ごとに再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。

チャネル実行ジョブの処理プール

キーワード: pool

複数のチャネルが 1 つのプール内で動作するように設定すると、複数のチャネルが同じプールのリソースを共有できるようになります。特定のチャネル専用に指定されているプール内でほかのチャネルが動作するように設定することも可能です。各プール内のメッセージは優先度に基づいて自動的に適切な処理キューに割り当てられます。優先度の高いメッセージは優先度が低いメッセージよりも先に処理されます。(「サイズに基づくメッセージの優先度」を参照。)

pool キーワードを使用すると、ジョブが作成されるプールをチャネルごとに指定できます。pool キーワードの後ろには、現在のチャネルの配信ジョブのプール先となるプール名を指定する必要があります。プール名の長さの上限は 12 バイトです。

ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「ジョブコントローラファイル」、および「サービスジョブの制限」を参照してください。

サービスジョブの制限

キーワード: maxjobs、filesperjob

メッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。しかし、1 つのサービスジョブではすべてのメッセージを手際よく配信できない場合もあります。ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「チャネル実行ジョブの処理プール」、および「ジョブコントローラ」を参照してください。

メッセージ配信のために開始されるプロセスやスレッドの数には、妥当な制限があります。このプロセスやスレッド数の上限は、プロセッサの数、ディスクの速度、接続の性質などによって決定されます。MTA 設定ファイルでは、次のものを制御することができます。

1 つのチャネルに対して開始できるプロセス数の上限 (maxjobs チャネルキーワード)
1 つのチャネルセットに対して開始できるプロセス数の上限 (ジョブコントローラ設定ファイルの該当するプールセクションに設定されている JOB_LIMIT パラメータ)
新しいスレッドまたはプロセスを開始する前に受信したキュー内のメッセージ数 (threaddepth チャネルキーワード)
チャネルによっては、特定の配信プログラム内で実行するスレッド数の上限 (チャネルオプションファイル内の max_client_threads パラメータ)

1 つのチャネルに対して開始されるプロセス数の上限は、そのチャネルに対して設定されている maxjobs、またはチャネルが動作しているプールに対して設定されている JOB_LIMIT の最小値に当たります。

あるメッセージに処理が必要だとします。一般に、ジョブコントローラは次の場合に新しい処理を開始します。

チャネルに対してプロセスが実行されておらず、プールのジョブ数が制限に達していない場合は、新しいプロセスを開始します。
チャネルプログラムがシングルスレッドの場合、またはスレッド数が制限に達していて threaddepth で指定されている以上のバックログがあり、かつチャネルとプールのジョブ数がともに制限に達していない場合は、新しいプロセスを開始します。
チャネルプログラムがマルチスレッドで、スレッド数が制限に達しておらず、かつ threaddepth で指定されている以上のバックログがある場合は、新しいスレッドを開始します。

特に、SMTP チャネルに対しては、異なるホスト宛のメッセージがキューに入るにつれて新しいスレッドやプロセスを開始します。ジョブコントローラは、SMTP チャネルに対し、次に示す基準に基づいて新しいプロセスを開始します。あるメッセージに処理が必要だとします。

SMTP チャネルに対してプロセスが実行されておらず、プールが制限に達していない場合、ジョブコントローラは新しいプロセスを開始します。
スレッド数が制限 (MAX_CLIENT_THREADS) に達していて、サービス待ち状態のホスト宛のメッセージがキューに入っており、チャネル数 (maxjobs) もプールジョブ (JOB_LIMIT) も制限に達していなければ、新しいプロセスが開始されます。
スレッド数が制限に達しておらず、サービス待ち状態のホスト宛のメッセージがキューに入った場合は、新しいスレッドが開始されます。
スレッド数が制限に達しておらず、メッセージがキューに入ったためにそのホスト宛のメッセージのバックログが threaddepth で指定されている以上の数になった場合は、新しいスレッドが開始されます。

「SMTP チャネルスレッド」も参照してください。

filesperjob キーワードを使うと、MTA に追加のサービスジョブを作成するよう指示することもできます。このキーワードには、正の整数を 1 つパラメータとして設定する必要があります。この整数は、チャネルへ送られるべきキューエントリ (ファイル) の数を指定するもので、その後それらのファイルを処理するために複数のサービスジョブが作成されます。パラメータに 0 またはそれ以下の値を指定した場合は、1 つのサービスジョブだけがキューに入れられます。キーワードを指定しないと、パラメータの値は 0 に指定されます。このキーワードの影響は最大化されます。すなわち、算出された大きな方の数値が実際に作成されるサービスジョブの数となります。

filesperjob キーワードは、実際のキューエントリ (ファイル) 数を与えられた値で割って、作成するジョブ数を算出します。各メッセージのキューエントリ数は、single や single_sys キーワード、メーリングリストのヘッダー修正アクション、そのほかさまざまな要素によって決定されます。

maxjobs キーワードは、同時実行可能な合計サービスジョブ数を制限します。このキーワードの後ろには、整数値を指定する必要があります。算出されたサービスジョブ数がこの値より大きい場合には、maxjobs ジョブだけが作成されます。maxjobs が使用されていない場合のデフォルト値は 100 に設定されています。通常、maxjobs には、そのチャネルが使用する 1 つまたは複数のサービスプールで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を使用します。

接続トランザクションの制限を設定する

キーワード: transactionlimit

transactionlimit は、1 つの接続について許されるメッセージの数を制限します。これを使用して、次のように攻撃を阻止できます。

攻撃者が SMTP を介して接続し、正しい電子メールアドレスを推測しようとして多数の RCPT TO コマンドを送信するとします。このような攻撃は、1 つのトランザクションで許可される無効な RCPT TO の回数を制限することによって阻止できます。これに対抗して攻撃者が複数のトランザクションを使用したとしても、1 つの SMTP セッションで許可されるトランザクション数を transactionlimit で制限できます。攻撃者は複数のセッションを使用することはできますが、多大な負担がかかることになります。接続抑制を使用してさまざまな方法でセッション数を制限することで、ほとんどの場合負担を非常に大きくできます。

ただし、阻止する側にも負担はかかります。受取人制限やトランザクション制限、あるいはその両方にうまく対応できない SMTP クライアントもあります。このようなクライアントのために例外をもうける必要があります。ただし、TCP チャネルオプションは無条件で SMTP サーバーに適用されます。これを解決するには、チャネルキーワードと switchchannel を使って、問題になるエージェントをより制限値の高いチャネルにルーティングします。

サイズに基づくメッセージの優先度

キーワード: urgentblocklimit、normalblocklimit、nonurgentblocklimit

urgentblocklimit、normalblocklimit、および nonurgentblocklimit キーワードは、サイズに基づいてメッセージの優先度を下げるように MTA に指定するためのものです。これらのキーワードは、ジョブコントローラがメッセージ処理時に適用する優先度に影響を及ぼします。

SMTP チャネルスレッド

キーワード: threaddepth

マルチスレッドの SMTP クライアントは、メッセージを宛先ごとにそれぞれ異なるスレッドに割り当てるために、送信メッセージを並べ替えます。threaddepth キーワードは、マルチスレッドの SMTP クライアントが 1 つのスレッドに割り当てられるメッセージの数を制限し、それ以上のメッセージがある場合には別のスレッドに割り当てるよう指定します。通常、同じ宛先へのメッセージはすべて 1 つのスレッドによって処理されますが、このキーワードを指定すると、それらのメッセージが複数のスレッドによって処理されるようになります。このキーワードのデフォルト値は 10 です。

チャネルに対するバックログが threaddepth で指定されている以上の数に達すると、ジョブコントローラはより多くのリソースをそのチャネルのキューにあるメッセージの処理に割り当てようとします。チャネルがマルチスレッドの場合、ジョブコントローラはメッセージを処理するジョブがそのチャネルに対して新しくスレッドを開始するように指示し、すべてのジョブのスレッド数がそのチャネルの制限に達している場合 (tcp_* チャネルの MAX_CLIENT_THREADS オプション) は、新しいプロセスを開始するように指示します。シングルスレッドのチャネルに対しては、新しいプロセスを開始するように指示します。ただし、チャネルのジョブ数 (maxjobs) またはプールのジョブ数 (JOB_LIMIT) が制限に達している場合、新しいジョブは開始されません。

基本的に、threaddepth はジョブがどのくらい集中してスケジューリングされるかを制御します。次の 2 つの状況を考えてみましょう。

(1) 標準 (送信) SMTP チャネル

(2) スマートホスト宛転送の SMTP チャネル

ジョブコントローラは、宛先ホストによって特定のチャネルに送信されるメッセージを分類し、それらの宛先ホストのバックログに基づいてメッセージが処理されるようにジョブをスケジューリングします。

(1) の場合は、多数の宛先ホストが存在し、それらのほとんどのバックログは少量になります。多数のスレッドが動作していて、aol、yahoo、hotmail などの大量のトラフィックが存在する宛先ホストを除いて、すべてが良好に機能している必要があります。スレッドの深さが 128 の場合、バックログが 128 に達すると yahoo への配信を行う 2 番目のスレッドだけが取得できます。これは適切な状態とはいえません。

(2) の場合は、1 つの宛先ホストだけが存在し、多数のスレッドがそのホストへの配信を行なっていて、理想的な状態です。あえていうなら、10 というデフォルト値は小さすぎます。

threaddepth キーワードは、チャネルの接続先の SMTP サーバーが複数の接続を同時に処理できる場合に、デーモンルーター TCP/IP チャネル (ある特定の SMTP サーバーに接続する TCP/IP チャネル) 上でマルチスレッドを確立する際に便利です。

複数アドレスの拡張

キーワード: expandlimit、expandchannel、holdlimit

ほとんどのチャネルでは、複数の受取人アドレスを持つメッセージの転送がサポートされています。ただし、1 つのメッセージに多くの受取人アドレスが指定されていると、メッセージ転送処理に遅延 (オンライン遅延) が生じる場合があります。遅延時間が長いとネットワークのタイムアウトが発生し、メッセージの重複送信やその他の問題が発生する可能性があります。

MTA は、1 つのメッセージに特定数以上のアドレスが指定されている場合に配信を遅らせて処理 (オフライン処理) することができます。この方法によって、オンライン遅延を大きく軽減することが可能です。処理のオーバーヘッドを遅らせることはできますが、遅延を完全に回避することはできません。

この機能を有効にするには、たとえば一般的な reprocessing チャネルと expandlimit キーワードを使用します。expandlimit キーワードは、オフライン処理を開始するまでにチャネルから受け入れることのできるメッセージのアドレス数の上限を示す整数の引数をとります。expandlimit キーワードが設定されていない場合のデフォルトは無限大です。引数の値を 0 にすると、そのチャネルで着信したすべてのメッセージがオフラインで処理されます。

expandlimit キーワードは、ローカルチャネルおよび reprocessing チャネルには使用できません。使用すると、予測できない事態が発生する可能性があります。

オフライン処理を行うチャネルを指定するには、expandchannel キーワードを使用します。特に設定を変更しないかぎり、expandchannel が設定されていない場合は reprocessing チャネルが使用されますが、特別な目的のためにはその他の reprocessing チャネルまたは processing チャネルを設定することもできます。expandchannel を使ってオフライン処理を行うチャネルを指定する場合、reprocessing チャネルまたは processing チャネル以外のチャネルを使用することはできません。その他のチャネルを使用すると、予測できない事態が発生する可能性があります。

expandlimit キーワードを適切に機能させるには、reprocessing チャネル (またはオフライン処理を実行するその他のチャネル) を MTA 設定ファイルに追加する必要があります。ただし、MTA 設定ユーティリティーによって生成された設定ファイルを使用しているのであれば、その必要はありません。

非常に多くの宛先アドレスが指定されているのは、不特定多数宛メールの特徴です。holdlimit キーワードは、MTA が特定数以上の宛先アドレスを持つメッセージを受信した場合、そのメッセージを .HELD メッセージとして reprocess チャネル (または expandchannel キーワードが指定するチャネル) のキューに入れるように指示します。メッセージは MTA ポストマスターが手動で介入するまで reprocess キュー内で未処理のまま待機します。

サービス変換を有効にする

キーワード: service、noservice

service キーワードは、CHARSET-CONVERSION エントリにかかわらず、無条件でサービス変換を有効にします。noservice キーワードが設定されている場合、チャネルで受信するメッセージのサービス変換は、CHARSET-CONVERSION で有効にします。

アドレス処理を設定する

この節ではアドレス処理を行うキーワードを説明します。この章には、次の節があります。

アドレスのタイプとルール

キーワード: 822、733、uucp、header_822、header_733、header_uucp

このキーワードのグループでは、チャネルでサポートするアドレスのタイプが制御されます。転送レイヤー (メッセージエンベロープ) に使われるアドレスとメッセージヘッダーに使われるアドレスとは区別されます。

822 (sourceroute)

ソースルートのエンベロープアドレス。このチャネルでは、ソースルートを含む、完全な RFC 822 形式のエンベロープアドレスルールがサポートされます。sourceroute キーワードは、822 と同義で使用できます。ほかのエンベロープアドレスタイプのキーワードが指定されていない場合、これがデフォルトになります。

733 (percents)

パーセント記号のエンベロープアドレス。このチャネルでは、ソースルートを除く、完全な RFC 822 形式のエンベロープアドレスがサポートされます。ソースルートは、パーセント記号のルールを使用して、書き換える必要があります。percents キーワードは、733 と同義で使用できます。

注 –

SMTP チャネルで 733 アドレスルールを使用すると、SMTP エンベロープの転送レイヤーのアドレスでもこれらのルールが使われるようになります。これは、RFC 821 に違反する場合があるため、必要時以外は 733 を使用しないでください。

uucp (bangstyle)

bang-style のエンベロープアドレス。このチャネルでは、エンベロープの RFC 976 の bbang-style アドレスルールに準拠するアドレスが使用されます (たとえば、UUCP チャネル)。bangstyle キーワードは、uucp と同義で使用できます。

header_822

ソースルートのヘッダーアドレス。このチャネルでは、ソースルートを含む、完全な RFC 822 形式のヘッダーアドレスルールがサポートされます。ほかのヘッダーアドレスタイプのキーワードが指定されていない場合、これがデフォルトになります。

header_733

パーセント記号のヘッダーアドレス。このチャネルでは、ソースルートを除く、完全な RFC 822 形式のヘッダーアドレスがサポートされます。ソースルートは、パーセント記号のルールを使用して、書き換える必要があります。

注 –

メッセージヘッダーで 733 アドレスルールを使用すると、RFC 822 と RFC 976 に違反する場合があります。このキーワードは、チャネルがソースルートアドレスを処理できないシステムに接続することが確実な場合以外は使用しないでください。

header_uucp

UUCP または bang-style のヘッダーアドレス。このキーワードの使用は推奨しません。使用すると RFC 976 に違反することになります。

! と % を使用するアドレスを解釈する

キーワード: bangoverpercent、nobangoverpercent、percentonly

アドレスは常に 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 の両方で義務付けられています。

percentonly キーワードで、bang パスが無視されます。このキーワードが設定されている場合、パーセントはルーティング用に解釈されます。

アドレスにルーティング情報を追加する

キーワード: 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 書き換えルールテンプレートによってアクティブになります。

指定ルートは、アクティブになったときに、ヘッダーとエンベロープ内のすべてのアドレスに適用されます。指定ルートは特定の書き換えルールによってアクティブになるもので、通常、現在使用中のチャネルとは関係がありません。一方、明示的ルーティングと黙示的ルーティングはチャネルごとに制御され、挿入されるルートアドレスは常にローカルシステムのものです。

明示的なルーティングアドレスの書き換えを無効にする

キーワード: routelocal

routelocal チャネルキーワードでは、アドレスをチャネルに書き換える際に、MTA がアドレスのすべての明示的ルーティングの「短絡化」を試行するようにします。明示的にルーティングされたアドレス (using ! 、%、または @ の文字を使用) は簡略化されています。

このキーワードを内部 TCP/IP チャネルなどの内部チャネルに使用すると、SMTP リレーブロッキングの設定を簡単にすることができます。

ただし、明示的 % やその他のルーティングを必要とする可能性があるチャネルには、このキーワードを使用してはいけません。

メッセージがキューから取り出されるときのアドレス書き換え

キーワード: connectalias、connectcanonical

通常、MTA はチャネルのキューにメッセージを入れるときにアドレスを書き換えます。メッセージがキューから取り出されるときに、さらに書き換えが行われることはありません。したがって、ホスト名が変更されたときにチャネルのキュー内に元のホスト名宛のメッセージがまだ残っていても、問題は生じません。

connectalias キーワードは、受取人のアドレスに書かれているホストに配信するように、MTA に指示します。これがデフォルトです。connectcanonical キーワードは、MTA が接続するシステムのホストエイリアスに接続するように指示します。

不完全なアドレスを修正する際に使用するホスト名を指定する

キーワード: remotehost、noremotehost、defaulthost、 nodefaulthost

MTA は、間違って設定された、あるいは標準に準拠しないメーラーや SMTP クライアントから、ドメイン名を含まないアドレスを受け取ることがよくあります。MTA は、そのようなメッセージを通過させる前に、アドレスを有効な形式にしようと試みます。MTA は、アドレスにドメイン名を付け加える (たとえば、@siroe.com を mrochek に付け加える) ことによってそれを行います。

エンベロープ To: アドレスにドメイン名がない場合、MTA では常にローカルホスト名を追加するものと仮定します。From: アドレスなどのその他のアドレスの場合、MTA SMTP サーバーには、ドメイン名に関して少なくとも 2 つのオプションが考えられます。それらのオプションとは、ローカル MTA ホスト名と、クライアント SMTP でレポートされたリモートホスト名です。また場合によっては、そのチャネルで受信するメッセージに特定のドメイン名を追加するという、3 つ目のオプションが考えられる可能性もあります。最初の 2 つのオプションは、どちらもある程度の頻度で発生することが考えられるため、適切なものと考えられます。不適切に構成された SMTP クライアントを扱う場合には、リモートホストのドメイン名を使用することが適切です。メッセージを掲示するために SMTP を使う POP や IMAP クライアントのように軽量級のリモートメールクライアントを扱う場合には、ローカルホストのドメイン名を使用することが適切です。また、(POP や IMAP などの) 軽量級のリモートメールクライアントの場合は、各クライアントにはローカルホスト以外の専用の特定ドメイン名があります。この場合には、その他の特定ドメイン名の追加が適当な場合もあります。MTA がとれる最善の策は、チャネルごとに選択できるようにすることです。

noremotehost チャネルキーワードはローカルホストの名前が使用されるように指定するものです。デフォルトのキーワードは noremotehost です。

defaulthost チャネルキーワードを使用して、着信するユーザー ID に追加する特定のホスト名を指定します。このキーワードの後ろには、チャネルで受信するアドレスを完成させるためのドメイン名 (エンベロープ From: 内とヘッダー内) を追加する必要があります。送信チャネルの場合は、defaulthost キーワードの最初の引数もエンベロープ To: アドレスに影響します。省略可能な 2 番目のドメイン名 (少なくとも 1 つのピリオドが含まれている) を指定してエンベロープ To: アドレスを完成させることもできます。デフォルトは nodefaulthost です。

switchchannel キーワードは、前出の「着信メール用代替チャネル (切り替えチャネル)」で説明されているとおり、着信 SMTP 接続を特定のチャネルに関連付けるために使用することができます。この機能は、リモートのメールクライアントを、適切な処理を受けることができるチャネルにグループ化するために使用することができます。代わりの方法として、(標準に準拠しないクライアントが多数使用されていたとしても) 標準に準拠するリモートメールクライアントを配備する方が、MTA ホストでネットワーク全体の問題を解決しようとするより簡単です。

受取人ヘッダー行がないメッセージを有効にする

キーワード: missingrecipientpolicy

RFC 822 (インターネット) メッセージには、受取人ヘッダー行である To:、Cc:、または Bcc: ヘッダー行が必要です。そのようなヘッダー行がないメッセージは無効になります。しかし、うまく稼働していないユーザーエージェントやメーラー (たとえば、古いバージョンの sendmail) は、無効なメッセージを受け入れます。

missingrecipientpolicy キーワードは、そのようなメッセージを扱うときに使用すべきアプローチを指定する整数値をとります。このキーワードが明示的に表現されていない場合は、デフォルト値の 1 (無効なメッセージを変更せずに通過させる) が使用されます。

表 12–25 missingrecipientpolicy の値


値	動作
0	エンベロープ To: 受取人で `To:` ヘッダー行を置き換えます。
1	無効なメッセージを変更せずに通過させます。
2	エンベロープ To: 受取人で `To:` ヘッダー行を置き換えます。
3	すべてのエンベロープ To: 受取人で単一の `Bcc:` ヘッダー行を置き換えます。
4	`To:` ヘッダー行にグループのコンストラクタ (たとえば「;」) を生成します。「To: Recipients not specified: ;」のようになります。
5	空白の `Bcc:` ヘッダー行を生成します。
6	メッセージを拒否します。

MISSING_RECIPIENT_POLICY オプションは、MTA システムがデフォルトでこの動作をするように設定するためのものであることに注意してください。初期の Messaging Server 設定では、MISSING_RECIPIENT_POLICY が 1 に設定されます。

不正な空白の受取人ヘッダーを削除する

キーワード: dropblank、nodropblank

RFC 822 (インターネット) メッセージでは、To:、Resent-To:、Cc:、または Resent-Cc: ヘッダーにアドレスが少なくとも 1 つ必要です。空白値は使用できません。ただし、一部のメーラーでは、このような不正なヘッダーが生成されることがあります。ソースチャネルに dropblank チャネルキーワードが指定されている場合、MTA により着信メッセージからこれらの不正な空白ヘッダーが削除されます。

チャネル固有のリバースデータベースの使用を有効にする

キーワード: reverse、noreverse

reverse キーワードは、チャネルのキューに入れられたメッセージ内のアドレスを、アドレスリバースデータベースまたは REVERSE マッピングのどちらか存在する方に対して照合し、必要に応じて変更するように MTA に指示するものです。また、noreverse は、チャネルのキューに入れられたメッセージのアドレスを、アドレスリバース処理から外すことを指定するものです。デフォルトのキーワードは reverse です。「内部形式から公的な形式にアドレスを変換するには」を参照してください。

制限されたメールボックスのエンコーディングを有効にする

キーワード: restricted、unrestricted

メールシステムの中には、RFC 822 で許されるアドレスのすべての形式を扱うことができないものもあります。もっとも一般的に見られる例は、設定ファイルが不適切に設定された sendmail ベースのメーラーです。引用されたローカルパート (あるいはメールボックス仕様) が、頻繁に見られる問題の原因です。

"smith, ned"@siroe.com

これは大きな問題なので、この問題を回避するための方策が RFC 1137 に記載されています。基本的なアプローチは、アドレスから引用を取り除き、引用を要する文字を、アトムに許可する文字にマップする変換ルールを適用することです (ここで使われているアトムという語の定義については RFC 822 を参照)。たとえば、上記のアドレスは次のようになります。

smith#m#_ned@siroe.com

restricted チャネルキーワードでは、MTA に、このチャネルがこのエンコーディングを必要とするメールシステムに接続することを示します。すると MTA は、メッセージがチャネルに書かれるときに、ヘッダーとエンベロープアドレスの両方において引用されたローカルパートをエンコードします。そのチャネルの着信メールのアドレスは自動的にデコードされます。unrestricted キーワードは、RFC 1137 エンコーディングとデコーディングを実行しないように MTA に指示します。デフォルトは unrestricted キーワードです。

注 –

restricted キーワードは、引用されたローカルパートを受け入れることができないシステムに接続するチャネルに対して適用します。引用されたローカルパートを実際に生成するチャネルには適用しません。(そのようなアドレスを生成することができるチャネルは、そのようなアドレスを処理することができると想定されるため。)

Return-path: ヘッダー行を生成する

キーワード: addreturnpath、noaddreturnpath

通常、Return-path: ヘッダー行の追加は、最終的な配信を実行するチャネルが行います。ただし、ims-ms チャネルなどの一部のチャネルでは、MTA で Return-path: ヘッダー行を追加する方が、チャネルで追加するよりも効率的です。addreturnpath キーワードでは、このチャネルのキューにメッセージを入れる際に、MTA により Return-path: ヘッダーが追加されます。

エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する

キーワード: receivedfor、noreceivedfor、receivedfrom、noreceivedfrom

receivedfor キーワードは、メッセージの宛先になっているエンベロープ受取人アドレスが１つだけの場合は、そのエンベロープの To: アドレスを Received: ヘッダー行に含めるように MTA に指示します。デフォルトのキーワードは receivedfor です。noreceivedfor キーワードは、エンベロープアドレス情報を含めずに、Received: ヘッダー行を作成するよう MTA に指示します。

receivedfrom キーワードは、たとえばメーリングリストの拡大などのために MTA がエンベロープ From: アドレスを変更した場合、着信メッセージの Received: ヘッダー行を作成する際に元のエンベロープの From: アドレスを含めるように MTA に指示します。デフォルトは receivedfrom です。noreceivedfrom キーワードは、元のエンベロープ From: アドレスを使わずに、Received: ヘッダー行を作成するよう MTA に指示します。

アドレスヘッダー行内のコメントを処理する

キーワード: commentinc、commentmap commentomit、commentstrip、commenttotal、sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip、sourcecommenttotal

MTA は必要なときだけヘッダー行の内容を解釈します。ただし、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべての登録されたヘッダー行をパースしなければなりません。この処理の途中では、コメント (括弧で囲まれた文字列) が抽出され、ヘッダー行が再構成されるときに変更されるか、あるいは除外されることがあります。

この動作は、commentinc、commentmap、commentomit、commentstrip、および commenttotal キーワードを使用して制御されます。commentinc キーワードは、ヘッダー行内のコメントを残すように MTA に指示します。デフォルトでは、このキーワードが使用されます。commentomit キーワードは、アドレスヘッダー、たとえば To:、From:、あるいは Cc: ヘッダー行からコメントを取り除くように MTA に指示します。

commenttotal キーワードは、MTA にすべてのヘッダー行 (Received: ヘッダー行を除く) からコメントを削除するように指示します。このキーワードは通常有用ではなく、お勧めもしません。commentstrip キーワードは、すべてのコメントフィールドからすべての非原子的文字を削除するように MTA に指示します。commentmap キーワードは、COMMENT_STRINGS マッピングテーブルを通じてコメント文字列を実行します。

ソースチャネルでは、この動作は sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip、および sourcecommenttotal の各キーワードを使用して制御されます。sourcecommentinc キーワードは、MTA にヘッダー行のコメントを維持するように指示します。デフォルトでは、このキーワードが使用されます。sourcecommentomit キーワードは、MTA にアドレスヘッダー (To:、From:、Cc: などのヘッダー) からすべてのコメントを削除するように指示します。sourcecommenttotal キーワードは、MTA にすべてのヘッダー行 (Received: ヘッダー行を除く) からコメントを削除するように指示します。このキーワードは通常有用ではなく、お勧めもしません。最後に、sourcecommentstrip キーワードは MTA に、すべてのコメントフィールドから非原子的文字を削除するように指示します。sourcecommentmap キーワードは、ソースチャネルを通じてコメント文字列を実行します。

これらのキーワードはどのチャネルにも適用できます。

COMMENT_STRINGS マッピングテーブルの構文は、次のとおりです。

(comment_text) | address

エントリテンプレートに $Y フラグが設定されている場合、元のコメントは指定したテキスト (閉じる括弧を含むこと) に置き換えられます。

アドレスヘッダー行内の個人名を処理する

キーワード: personalinc、personalmap、personalomit、personalstrip、sourcepersonalinc、sourcepersonalmap、sourcepersonalomit、sourcepersonalstrip

書き換えプロセスの際には、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべてのヘッダー行をパースしなければなりません。このプロセスの際に、個人名 (角括弧で区切られたアドレスの前にある文字列) が抽出されるが、これはヘッダー行を再構築するときに変更したり除外することもできます。

この動作は、personalinc、personalmap、personalomit、および personalstrip キーワードを使用して制御されます。personalinc キーワードは、ヘッダーの個人名を維持するように MTA に指示します。デフォルトでは、このキーワードが使用されます。personalomit キーワードは、すべての個人名を削除するように MTA に指示します。personalstrip キーワードは、すべての個人名フィールドからすべての非原子的文字を削除するように、MTA に指示します。personalmap キーワードは、PERSONAL_NAMES マッピングテーブルを通じて個人名を実行するように、MTA に示します。

ソースチャネルでは、この動作は sourcepersonalinc、sourcepersonalmap、sourcepersonalomit、または sourcepersonalstrip キーワードを使用して制御されます。sourcepersonalinc キーワードは、ヘッダーの個人名を維持するように MTA に指示します。デフォルトでは、このキーワードが使用されます。sourcepersonalomit キーワードは、すべての個人名を削除するように MTA に指示します。最後に、sourcepersonalstrip キーワードは、すべての個人名フィールドから非原子的文字を削除するように、MTA に指示します。sourcepersonalmap キーワードは、ソースチャネルを通じて個人名を実行するように MTA に指示します。

これらのキーワードはどのチャネルにも適用できます。

PERSONAL_NAMES マッピングテーブルプローブの構文は、次のとおりです。

personal_name | address

テンプレートで $Y フラグが設定されている場合、元の個人名は指定したテキストで置き換えられます。

エイリアスファイルとエイリアスデータベースプローブを指定する

キーワード: aliaslocal

通常、ローカルチャネル (UNIX の 1 チャネル) に書き換えられるアドレスのみが、エイリアスファイルとエイリアスデータベースで検索されます。aliaslocal キーワードをチャネルに使用すると、そのチャネルに書き換えられるアドレスも、エイリアスファイルとエイリアスデータベースで検索するようにできます。作成される検索プローブの形式は、ALIAS_DOMAINS オプションで制御されます。

サブアドレスを処理する

キーワード: subaddressexact、subaddressrelaxed、subaddresswild

サブアドレスの概念の背景として、ネイティブと ims-ms のチャネルでは + 記号がアドレスのローカル部分 (メールボックスの部分) として解釈されます。特に、name+subaddress@domain の形式のアドレスでは、MTA はプラス記号の後ろのメールボックス部分をサブアドレスとみなします。ローカルチャネルでは、サブアドレスを追加の余分な情報とみなして、サブアドレスを考慮せず実際にアカウント名への配信を行います。ims-ms チャネルでは、サブアドレスを配信先のフォルダ名と解釈します。

また、サブアドレスはローカルチャネル (UNIX の L チャネル) によるエイリアスの検索、aliaslocal キーワードでマークされたすべてのチャネルによるエイリアスの検索、およびディレクトリチャネルによるメールボックスの検索に影響を与えます。これらの検索に対するサブアドレスの処理については、設定可能です。アドレスをエントリと比較する場合、MTA では必ず最初に完全一致の検索にサブアドレスを含むメールボックス全体を確認します。追加のチェックを実行するかどうかは、設定可能です。

subaddressexact キーワードは、MTA にエントリの一致の確認中に、特別なサブアドレスの処理を行わないように指示します。エイリアスが一致するとみなされるためには、サブアドレスを含むメールボックス全体が一致しなければなりません。その他の比較 (特に、ワイルドカードによる比較や、サブアドレスを削除した比較) は行われません。subaddresswild キーワードは、MTA に、サブアドレスを含む完全な一致を検索した後、「名前+*」の形式のエントリを検索するように指示します。subaddressrelaxed キーワードは MTA に、完全一致と「名前+*」の形式の一致を検索した後、名前の部分のみの一致を検索するように指示します。subaddressrelaxed では、次の形式のエイリアスエントリが、名前か「名前+サブアドレス」に一致し、名前を新規の名前に、「名前+サブアドレス」を「新規の名前+サブアドレス」に変換します。デフォルトのキーワードは subaddressrelaxed です。

name:   newname+*

このように、subaddresswild キーワードや subaddressrelaxed キーワードは、エイリアスやディレクトリが使用されていて、ユーザーが任意のサブアドレスを使用してメールの受信を希望する場合に便利です。これらのキーワードを使用することにより、アドレスの各サブアドレスに独立のエントリを作成する必要がなくなります。

これらのキーワードは、ローカルチャネル (UNIX の L チャネル) とディレクトリチャネル、および aliaslocal キーワードでマークされたチャネルにかぎり使用できます。

標準の Messaging Server 設定では、実際に subaddressrelaxed キーワード (ほかのキーワードが明示的に使用されていない場合のデフォルト) を指定した L チャネルでリレーします。

チャネル固有の書き換えルールチェックを有効にする

キーワード: rules、norules

rules キーワードは、MTA にこのチャネルにおけるチャネル固有の書き換えルールのチェックを強制するように指示します。これがデフォルトです。norules キーワードは、MTA にこのチャネルをチェックしないように指示します。これらの 2 つのキーワードは、通常デバッグに使用され、実際のアプリケーションで使用されることはほとんどありません。

ソースルートを削除する

キーワード: dequeue_removeroute

dequeue_removeroute キーワードは、メッセージがキューから取り出されると、エンベロープの To: アドレスからソースルートを削除します。現在、このキーワードは tcp-* チャネルだけに実装されています。ソースルートを正しく処理しないシステムにメッセージを転送する場合に便利なキーワードです。

エイリアスからアドレスを指定する

キーワード: viaaliasoptional、viaaliasrequired

viaaliasrequired は、チャネルに一致する最終受取人アドレスをエイリアスで作成するように指定するキーワードです。最終受取人アドレスとは、関連するエイリアス拡張を行なった後で一致するアドレスです。アドレスを受取人アドレスとして MTA に直接渡すことはできません。チャネルに書き換えただけでは十分ではないからです。チャネルに書き換えた後で、本当にチャネルと一致したとみなされるよう、アドレスもエイリアスから展開する必要があります。

viaaliasrequired キーワードは、たとえば、ローカルチャネルで、任意のアカウント (UNIX システム上の任意のネイティブ Berkeley メールボックスなど) への配信を防ぐために使用できます。

デフォルトは viaaliasoptional であり、そのチャネルに一致する最終受取人アドレスはエイリアスで作成する必要がありません。

ヘッダー処理を設定する

この節ではヘッダーとエンベロープ情報を扱うキーワードを説明します。この章には、次の節があります。

埋め込まれたヘッダーを書き換える

キーワード: noinner、inner

ヘッダー行の内容は必要なときにだけ解釈されます。ただし、メッセージの中にメッセージを埋め込むことができる能力 (メッセージ /RFC822) があるために、MIME メッセージには複数のメッセージヘッダーが含まれていることもあります。通常、MTA は一番外側のメッセージヘッダーだけを解釈し、書き換えます。オプションとして、メッセージの内部ヘッダーに書き換えルールを適用するように指示することも可能です。

この動作は、noinner および inner キーワードを使用して制御できます。キーワード noinner は、内部ヘッダー行を書き換えないように MTA に指示するものです。デフォルトでは、このキーワードが使用されます。キーワード inner は、メッセージをパースして、内部ヘッダーを書き換えるように MTA に指示します。これらのキーワードはどのチャネルにも適用できます。

メッセージヘッダー行を選択して削除する

キーワード: headertrim、noheadertrim、headerread、noheaderread、innertrim、noinnertrim

MTA には、メッセージから特定のメッセージヘッダー行をトリミングする (取り除く)、チャネル単位の機能があります。これは、チャネルキーワードと関連する 1 つまたは 2 つのヘッダーオプションファイルの組み合わせによって行われます。ヘッダーオプションファイルの形式については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Header Option Files」を参照してください。

headertrim キーワードは、元のメッセージヘッダーが処理されたあとで、そのチャネルに関連しているヘッダーオプションファイルを参照して、その宛先チャネルのキューに入れられているメッセージのヘッダーをトリムするよう MTA に指示します。noheadertrim キーワードは、ヘッダートリミングを行いません。デフォルトは noheadertrim キーワードです。

innertrim キーワードは、埋め込まれた MESSAGE/RFC822 部分のような、内部メッセージ部分にヘッダートリミングを実行するよう MTA に指示します。noinnertrim キーワードはデフォルトで、内部メッセージ部分のどのヘッダーにもトリミングを実行しないよう MTA に指示します。

headerread キーワードは、元のメッセージヘッダーが処理される前に、そのチャネルに関連しているヘッダーオプションファイルを参照して、そのソースチャネルによってキューに入れられているメッセージのヘッダーをトリムするよう MTA に指示します。一方、headertrim ヘッダートリミングはメッセージが処理されたあとに適用され、ソースチャネルではなく宛先チャネルになります。noheaderread キーワードは、キューに入っているヘッダーのトリミングを行いません。noheaderread がデフォルトです。

headeromit および headerbottom キーワードとは異なり、headertrim および headerread キーワードはどのチャネルにも適用できます。ただし、重要なヘッダー情報をメッセージから取り除くと MTA が正常に動作しなくなることもあるので、注意してください。取り除くヘッダーまたは制限するヘッダーを選ぶ際には、十分な配慮が必要です。この機能があるのは、特定のヘッダー行を取り除いたり、制限したりしなければならないような状況が発生することがあるからです。

注意 –

ヘッダー情報をメッセージから取り除くと、MTA が正常に動作しなくなることもあります。取り除くヘッダーまたは制限するヘッダーを選ぶ際には、配慮が必要です。これらのキーワードは、特定のヘッダー行を取り除いたり、制限したりしなければならないような稀な状況で指定します。ヘッダー行を取り除く前に、そのヘッダー行の用途を十分に理解し、それを取り除いた場合の結果を考慮してください。

headertrim および innertrim キーワードのヘッダーオプションファイルには channel_headers.opt という形式の名前があります。この channel には、ヘッダーオプションファイルが関連付けられているチャネルの名前が入ります。同じように、headerread キーワードのヘッダーオプションファイルには、channel_read_headers.opt の形式の名前があります。これらのファイルは MTA の設定ディレクトリ (instance_root/imta/config/) に保存されます。

X-Envelope-to ヘッダー行を生成するまたは削除する

キーワード: x_env_to、nox_env_to

x_env_to および nox_env_to キーワードは、特定のチャネルのキューに入れられたメッセージのコピーに X-Envelope-to ヘッダー行を生成するかどうかを制御します。single キーワードでマークされているチャネルでは、x_env_to はこれらのヘッダーの生成を有効にし、nox_env_to はキュー内のメッセージからこれらのヘッダーを削除します。デフォルトは nox_env_to です。

x_env_to キーワードには、有効にするための single キーワードが必要です。

日付表示を 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:  Alignment test

デフォルトの headerlabelalign は 0 で、ヘッダーは揃えられません。headerlinelength キーワードは、このチャネルのキューに入れられたメッセージヘッダー行の長さを制御します。これよりも長い行は、RFC 822 の折り返しルールに基づいて折り返されます。

これらのキーワードは、メッセージキュー内にあるメッセージのヘッダー形式を制御するだけのものです。実際のヘッダーの表示は、通常、ユーザーエージェントによって制御されます。さらに、ヘッダーはインターネットを転送されるときに何度もリフォーマットされるため、メッセージヘッダーをフォーマットしない単純なユーザーエージェントといっしょに使用された場合には、これらのキーワードの効果が見られないこともあります。

ヘッダーの最大長を指定する

キーワード: maxprocchars

たくさんのアドレスを含む長いヘッダー行の処理には、多くのシステムリソースを費やすことがあります。maxprocchars キーワードは、MTA が処理して書き換えることができるヘッダーの最大長を指定するために使用されます。これよりも長いヘッダーを持つメッセージも受け入れられて配信されますが、異なる点は、長いヘッダー行は書き換えられないということです。このキーワードには、1 つの整数引数を伴います。デフォルトでは、どのような長さのヘッダーも処理されます。

機密度チェック

キーワード: sensitivitynormal、sensitivitypersonal、sensitivityprivate、sensitivitycompanyconfidential

機密度チェックのキーワードは、チャネルが受け入れられる機密度の上限を設定するものです。デフォルトは sensitivitycompanyconfidential で、どの機密度レベルのメッセージも通過を許されます。Sensitivity: ヘッダーのないメッセージは、通常のメッセージ、つまり、機密度の最も低いメッセージとみなされます。このようなキーワードで指定された機密度よりも高い機密度が指定されたメッセージがチャネルのキューに入れられると、次のようなエラーメッセージが表示され、拒否されます。

message too sensitive for one or more paths used

(使用されている 1 つ以上のパスに対してメッセージの機密度が高すぎる)

MTA では、受取人ごとではなく、メッセージごとに機密度のチェックが行われます。1 人の受取人の宛先チャネルが機密度チェックに失敗した場合、そのチャネルに関連付けられた受取人だけでなく、すべての受取人のメッセージがバウンスされます。

ヘッダーのデフォルト言語を設定する

キーワード: language

ヘッダーのエンコードされた単語には、特定言語を含ませることが可能です。デフォルトの言語は、language キーワードで指定されます。

添付と MIME 処理

この節では添付と MIME 処理を扱うキーワードを説明します。この章には、次の節があります。

Encoding ヘッダー行を無視する

キーワード: ignoreencoding、interpretencoding

MTA は、Yes CHARSET-CONVERSION を使用して、さまざまな非標準のメッセージ形式を MIME に変換することができます。特に、RFC 1154 形式では非標準の Encoding: ヘッダー行が使用されます。しかし、ゲートウェイの中には、ヘッダー行に対して誤った情報を出すものもあり、その結果、このヘッダー行を無視したほうがいい場合もあります。ignoreencoding キーワードは、Encoding: ヘッダー行をすべて無視するように MTA に指示します。

注 –

MTA の CHARSET-CONVERSION が有効になっていないかぎり、このようなヘッダーはいずれにしても無視されます。interpretencoding キーワードは、特にほかの設定が行われている場合を除き、MTA にすべての Encoding: ヘッダー行に注目するように指示します。これはデフォルトです。

メッセージあるいは部分メッセージの自動再組み立て

キーワード: defragment、nodefragment

MIME 規格には、メッセージをより小さな部分に分割するための message/partial コンテンツタイプがあります。これはメッセージがサイズ制限のあるネットワークを通過する場合、または信頼性の低いネットワークを通過する場合に便利です。メッセージの断片化により、ある種の「チェックポイント」が提供され、メッセージの転送中にネットワークエラーが発生した場合でも、操作の不要な繰り返しを防ぐことができます。メッセージが宛先に到着したときに自動的に再組み立てが行われるように、それぞれの部分に情報が含まれています。

MTA では、defragment チャネルキーワードと再組み立てチャネルを使うことによって、メッセージの再組み立てを行うことができます。チャネルが defragment でマークされていれば、このチャネルのキューに入れられる部分メッセージはすべて、代わりに再組み立てチャネルのキューに入れられます。すべての部分が到着したら、メッセージは再構築されて本来の宛先に送られます。nodefragment は、このような特別な処理を無効にするものです。デフォルトのキーワードは nodefragment です。

再組み立てチャネルの保持時間

再組み立てチャネルのキューにあるメッセージは、一定の時間だけ保持されます。最初の非配信通知が送信されるまでの時間の半分が経過すると、メッセージの各部が再組み立てされないまま送信されます。この時間の値を選択すると、再組み立てチャネルのキューにあるメッセージについて非配信通知が送信されなくなります。

notices チャネルキーワードは、非配信通知を送信するまでの時間を指定します。したがって、メッセージを断片のまま送信するまでの保持時間も指定します。notices キーワードの値は、再組み立てのためにメッセージを保持する期間の 2 倍に設定してください。たとえば、notices の値を 4 にすると、メッセージの断片は 2 日間保持されます。

defragment notices 4 
DEFRAGMENT-DAEMON

大きなメッセージの自動断片化

キーワード: 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 * MAX_HEADER_BLOCK_USE のどちらか小さい方がヘッダーサイズとみなされる)。

たとえば、maxblocks が 10 で MAX_HEADER_BLOCK_USE がデフォルトの 0.5 である場合、5 ブロックより大きいメッセージヘッダーは 5 ブロックのヘッダーとして取り扱われ、メッセージのサイズが 5 あるいはそれ以下のブロックの場合、断片化されません。0 を指定すると、メッセージのサイズ制限をあてはめる場合にヘッダーは無視されます。

1 を指定すると、利用可能なサイズのすべてをヘッダーに使うことができます。それぞれの断片は、サイズ制限を超えたかどうかにかかわらず、常に最低 1 行のメッセージ行を含みます。MAX_HEADER_LINE_USE および maxlines キーワードも、同様に動作します。

メッセージ行の長さを制限する

キーワード: linelength

SMTP 仕様では、1000 バイトまでのテキスト行が許可されています。しかし、転送形式の中には、行長に制限を課すものもあります。linelength キーワードは、チャネルごとに許される最大のメッセージ行の長さを制限する仕組みを提供します。特定のチャネルのキューに入れられたメッセージの中で、そのチャネルに指定された行長を超えるメッセージは自動的にエンコードされます。

MTA にはさまざまなエンコーディング方式が用意されており、エンコーディングの結果、行長は常に 80 バイト以下になります。エンコーディングが行われた元のメッセージは、適切なデコーディングのフィルタを通すことによって元の状態に戻すことができます。

注 –

エンコーディングは、行長を 80 バイトより短くするだけです。行長に 80 バイトより短い値を指定しても、指定された制限より短い行にできるとはかぎりません。

linelength キーワードでは、データのエンコーディングによって転送用に「ソフト」改行が実行されます。エンコーディングは、通常受信側でデコードされるため、元の長い行が復元されます。「ハード」改行については、表 13–7 の「Record, Text」を参照してください。

メッセージの制限、制限容量、受取人、認証の試行

この節では、メッセージのサイズ制限、ユーザー制限容量、権限を設定するキーワードについて説明します。この章には、次の節があります。

認証の試行失敗回数の制限

キーワード: disconnectbadauthlimit

このキーワードを使用すると、1 つのセッションで許可される認証の試行失敗の回数を制限できます。この回数に達するとセッションの接続は切断されます。このオプションのデフォルト値は 3 です。

絶対的なメッセージサイズ制限を指定する

キーワード: blocklimit、noblocklimit、linelimit、nolinelimit、sourceblocklimit

メッセージは断片化によって自動的に小さな部分に分割されますが、場合によっては、管理者が指定した制限より大きいメッセージを拒否しなければならないこともあります (たとえば、サービス拒否攻撃を回避するためなど)。

blocklimit、linelimit、および sourceblocklimit キーワードは、絶対的なサイズ制限を実施するために使用されます。これらのキーワードの後ろには、それぞれ 1 つの整数値が必要です。

blocklimit キーワードは、1 つのメッセージに許可するブロックの最大数を指定します。MTA は、これよりも多いブロックを含むメッセージがチャネルのキューに入れられるのを拒否します。1 つの MTA ブロックは通常 1024 バイトで、これは MTA オプションファイルにある BLOCK_SIZE オプションを使用して変更することができます。

sourceblocklimit キーワードは、着信メッセージに許可するブロックの最大数を指定します。MTA は、これよりも多いブロックを含むメッセージがチャネルのキューに入れられるのを拒否します。つまり、blocklimit は宛先チャネルに、sourceblocklimit はソースチャネルに適用されます。1 つの MTA ブロックは通常 1024 バイトで、これは MTA オプションファイルにある BLOCK_SIZE オプションを使用して変更することができます。

ソースブロック制限を、差出人ごとに指定することもできます。MTA オプション LDAP_SOURCEBLOCKLIMIT を使用してユーザー LDAP 属性を指定し、この属性を差出人の LDAP エントリに追加します。ソースブロック制限は差出人のドメイン単位でも指定できます。この場合は、MTA オプション LDAP_DOMAIN_ATTR_SOURCEBLOCKLIMIT を使用してドメイン LDAP 属性を指定し、この属性を差出人のドメイン LDAP エントリに追加します。上記のどちらの場合にも、デフォルト値は設定されていません。

linelimit キーワードは、1 つのメッセージに許可する最大行数を指定します。MTA は、この数以上の行を含むメッセージがチャネルのキューに入れられるのを拒否します。blocklimit キーワードと linelimit キーワードは、必要に応じて同時に指定することができます。

同じ制限をすべてのチャネルに課すためには、LINE_LIMIT および BLOCK_LIMIT オプションを使用します。これらの制限は、すべてのチャネルに適用できるという利点があります。したがって、MTA サーバーは、メッセージ受信情報を得る前に、それをメールクライアントに知らせることができます。この効果によって、メッセージ拒否の処理を簡略化できるプロトコルもあります。

nolinelimit および noblocklimit チャネルキーワードはデフォルトであり、LINE_LIMIT や BLOCK_LIMIT MTA オプションで適用されている全体的な制限以外の制限がないことを意味します。

サイズまたは受取人数の制限を超えるメッセージを再ターゲット化する

キーワード: alternatechannel、alternateblocklimit 、alternatelinelimit、alternaterecipientlimit

MTA では、受取人数、サイズ、または行数の指定制限を超えるメッセージを別の宛先チャネルに再ターゲットできます。これは alternatechannel、alternateblocklimit、alternatelinelimit、および alternaterecipientlimit のチャネルキーワードのセットで実装されます。これらのキーワードは、任意の宛先チャネルに指定できます。alternatechannel キーワードは、使用する代替チャネルの名前を指定する単一の引数をとります。これ以外のキーワードはそれぞれ、対応するしきい値を指定する整数の引数を受け入れます。これらのしきい値のいずれかを超えるメッセージは、元の宛先チャネルではなく、代替チャネルのキューに保管されます。

次のチャネルブロックの例では、tcp_local チャネルからインターネットに送信されるはずだった 5,000 ブロックを超える大きなメッセージが tcp_big チャネルから送信されています。

tcp_local smtp ...other keywords... alternatechannel tcp_big alternateblocklimit 5
tcp-daemon


tcp_big smtp ...rest of keywords...
tcp-big-daemon

次に、alternate* チャネルキーワードの使用例を示します。

大きなメッセージを後でまたは時間外に配信する場合は、alternatechannel (たとえば tcp_big) を実行する時間が指定できます。

その方法の 1 つは、imsimta qm ユーティリティーの STOP channel_name コマンドおよび START channel_name コマンドを使用することです。ジョブコントローラによって実行されるカスタムな定期的ジョブまたは cron ジョブを介して、これらのコマンドを定期的に実行します。
ジョブコントローラで大きなメッセージや受取人の多いメッセージを専用のプールで処理する場合は、alternatechannel も使用できます。

小さなメッセージや受取人の少ないメッセージは、大きなメッセージや受取人の多いメッセージと分離できます (後者はリモート SMTP サーバーでの処理と受け入れに時間がかかることがあるため)。大きなメッセージのせいで小さなメッセージの配信が遅れるのを避けたい場合は分離します。

ジョブコントローラによる通常のメッセージスケジュールおよびスレッドやプロセスへのメッセージの割り当ては、ほとんどの構成で受け入れられます。
大きなメッセージや受取人の多いメッセージに対して TCP/IP チャネルのタイムアウト値を特別に指定する場合は、alternatechannel を使用できます。

特に、TCP/IP チャネルのタイムアウト値を設定すると、大きなメッセージや受取人の多いメッセージを受信するのに非常に長い時間を要するリモートホストにメッセージを送信する場合に役立ちます。

ただし、ほとんどの構成にはデフォルトの自動のタイムアウト調整で十分です。デフォルト値を調整することはあっても、特別なチャネルを使用する必要はありません。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』で STATUS_DATA_RECV_PER_ADDR_TIME および STATUS_DATA_RECV_PER_BLOCK_TIME の各チャネルオプションを参照してください。
特に大きなメッセージに対して MIME メッセージの断片化を特別に設定する場合は、alternatechannel および alternateblocklimit チャネルキーワードを maxblocks チャネルキーワードとともに使用できます。

指定したサイズを超えるメッセージを断片化する場合は、通常、指定したい maxblocks サイズを通常使用する送信 TCP/IP チャネルに設定します。maxblocks チャネルキーワードは、通常、断片化が実行されるしきい値でもあり、各断片のサイズでもあります。

しかし、しきい値トリガーを大きくし、実際の断片を小さくする場合は、送信 TCP/IP チャネルに対して alternatechannel および alternateblocklimit を使用できます。その後、代替チャネルに対して maxblock サイズを使用し、指定サイズを超えたメッセージを断片化できます。
alternatechannel を特別なフィルタ処理とともに使用することができます。たとえば、受取人が多いメッセージがスパムである可能性に備えてより慎重な検査が必要な場合です。送信チャネルに基づいて、別のフィルタ処理を行うことができます (「メールボックスフィルタファイルの場所を指定する」の destinationfilter チャネルキーワードを参照)。

変換チャネルを介して比較的多くのリソースを必要とするスキャン (ウィルスフィルタ処理など) を実行している場合、非常に大きなメッセージによってリソース問題が生じる可能性があります。この場合は、代替変換チャネルを使用できます。または、送信チャネルに基づいて、通常の変換チャネル内で特別な変換処理を行います。
大きな送信メッセージを専用のチャネルから送信する場合は、alternatechannel を使用できます。これを使用すると、mail.log* ファイルやカウンタ表示を分析したときに、大きな送信メッセージが見つけやすくなります。

さらに、大きなメッセージを専用のチャネルで処理すると、配信統計を慎重に分析する場合に役立ちます。リモート SMTP ホストに送信された大きなメッセージや受取人の多いメッセージは処理に時間がかかるため、標準メッセージとは別の配信統計が作成されるからです。

制限容量超過ユーザーへのメール配信を処理する

キーワード: holdexquota、noexquota

noexquota および holdexquota キーワードは、Berkeley メールボックスユーザー (UNIX) 宛のメッセージの処理を制御します。ここでいうユーザーとは、ディスク制限容量を超過していて、ネイティブチャネルのユーザー ID に配信されたユーザーを指します。

noexquota は MTA に、制限容量を超過したユーザー宛のメッセージを、差出人に返送するように指示します。holdexquota は MTA に、制限容量超過ユーザー宛のメッセージを保留にするように指示します。これらのメッセージは、配信可能になるまで、またはタイムアウトになってメッセージ返送ジョブによって返送されるまで、MTA キュー内に保持されます。

1000 文字を超える行を含む SMTP メールを処理する

キーワード: rejectsmtplonglines、wrapsmtplonglines、truncatesmtplonglines

rejectsmtplonglines は、SMTP で許可されている 1000 文字 (CRLF を含む) を超える行を含むメッセージを拒否するオプションを追加します。この領域のほかのオプションは wrapsmtplonglines と truncatesmtplonglines です。wrapsmtplonglines は長すぎる行を折り返し、truncatesmtplonglines は長すぎる行を切り捨てます。デフォルトは truncatesmtplonglines です。これらのキーワードは両方とも、送信に最初に使用されたチャネル (tcp_local など) に適用される必要があります。その後切り替えられるチャネルには影響はありません。

General Content-type、Filename Content-type、および Content-disposition パラメータの長さを制御する

キーワード: parameterlengthlimit および nameparameterlengthlimit

parameterlengthlimit は、general content-type および content-disposition パラメータが切り捨てられる位置を制御します。デフォルト値は 1024 です。nameparameterlengthlimit は、name content-type および filename content-disposition パラメータが切り捨てられる位置を制御します。デフォルト値は 128 です。メッセージ上で MIME 処理が実行されていない場合、もっとも外側のメッセージヘッダーのみが処理されるので注意してください。MIME 処理は、inner キーワードや文字セット変換の使用、そのほかさまざまな方法で有効化できます。

メッセージの受取人を制限する

キーワード: recipientlimit および recipientcutoff

recipientlimit は、メッセージが受け付ける受取人の合計アドレス数を指定します。recipientcutoff は、MTA に対して提示された受取人の合計数を指定した値と比較します。値が制限を超えた場合、配信のためのメッセージは受け付けられません。これらのキーワードは両方とも、1 つの整数引数を受け入れます。対応するチャネルキーワードが設定されていない場合、これらのデフォルトは無限大です。

受取人の制限を、差出人または差出人のドメインに設定することもできます。このためには、適切な MTA オプションを使用してユーザー LDAP 属性を指定し、その属性を差出人のユーザーエントリまたはドメインエントリに追加します。適切な MTA オプションには LDAP_RECIPIENTLIMIT、LDAP_RECIPIENTCUTOFF、LDAP_DOMAIN_ATTR_RECIPIENTLIMIT、LDAP_DOMAIN_ATTR_RECIPIENTCUTOFF があります。

ヘッダーのサイズを制限する

キーワード: headerlimit

プライマリ (もっとも外側の) メッセージヘッダーの最大サイズを制限します。この制限に達すると、プライマリメッセージヘッダーはそのまま切り捨てられます。グローバル MTA オプション HEADER_LIMIT が設定されている場合、このチャネルレベルの制限よりも優先されます。デフォルトでは制限なしです。

MTA キュー領域でのファイル作成

この節では、MTA キュー領域でのファイル作成を指定してディスクリソースを制御するキーワードを説明します。この章には、次の節があります。

複数のアドレスを処理する方法を制御する

キーワード: multiple、addrsperfile、single、single_sys

MTA では、キューに入れられたそれぞれのメッセージに複数の宛先アドレスを使用できるようになっています。チャネルプログラムの中には、1 つの受取人を持つメッセージ、限定された数の受取人を持つメッセージ、あるいは 1 つのメッセージコピーにつき 1 つの宛先システムを持つメッセージしか処理できないものもあります。たとえば、SMTP チャネルのマスタープログラムは、(1 つのチャネルがすべての SMTP トラフィックのために使用されるのにもかかわらず) 1 つのトランザクションで 1 つのリモートホストとの接続を確立するため、そのホストへのアドレスのみが処理されます。

もう 1 つの例として、SMTP サーバーの中には、一度に処理できる受取人の数を制限し、このタイプのエラーを処理できないものもあります。

キーワード multiple、addrsperfile、single、single_sys は、複数のアドレスを処理する方法を制御するために使用できます。single キーワードは、各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。tcp_* チャネル上での single の使用は推奨されません。使用するとジョブコントローラがトラフィックを管理する方法が変更され、通常の SMTP 利用状況に対して適切でないためです。single_sys キーワードは、各宛先システム用にメッセージのコピーを 1 つずつ作成します。multiple キーワードは、デフォルトではチャネル全体のメッセージのコピーを 1 つ作成します。

注 –

どちらのキーワードを使用しても、メッセージがキューに入れられる各チャネルごとに最低 1 つずつメッセージのコピーが作成されることに注意してください。

addrsperfile キーワードは、チャネルのキューにある 1 つのメッセージファイルに関連付けられる受取人の最大数に制限を付けるために使用されます。これによって、1 つの操作で処理される受取人の数が制限されます。このキーワードは、1 つのメッセージファイルに許可する受取人アドレスの最大数を指定する 1 つの整数引数を必要とします。この数に達すると MTA は自動的にそれらを処理するために追加のメッセージファイルを作成します。(一般に、デフォルトの multiple キーワードはメッセージファイル内の受取人数を制限しないことを意味する。ただし SMTP チャネルのデフォルトは 99。)

複数のサブディレクトリにチャネルメッセージキューを拡散する

キーワード: subdirs

デフォルトでは、チャネルのキューに入れられたすべてのメッセージは、ディレクトリ /imta/queue/channel-name にファイルとして格納されます。この channel-name はチャネルの名前です。ただし、TCP/IP チャネルのように、たくさんのメッセージを処理し、処理を待つメッセージファイルをたくさん格納しがちなチャネルの場合は、それらのメッセージファイルを複数のサブディレクトリに拡散するようなファイルシステムを使った方が処理能力が向上する可能性があります。この機能を提供するのが subdirs チャネルキーワードです。チャネルのメッセージを拡散するサブディレクトリの数を指定する整数を、このキーワードの後ろに付けます。次に例を示します。

tcp_local single_sys smtp subdirs 10

セッションの制限を設定する

キーワード: disconnectbadcommandlimit、disconnectrecipientlimit、disconnectrejectlimit、disconnecttransactionlimit

4 つの新しいチャネルキーワードが提供する機能によって、SMTP サーバーは、いくつかのエラーが検出されたあとにクライアントとの接続を切断されます。

disconnectrecipientlimit - セッションの受取人数を制限する。

disconnectrejectlimit - 拒否される受取人数を制限する。

disconnecttransactionlimit - トランザクション数を制限する。

disconnectbadcommandlimit - 不正なコマンド数を制限する。

これらはすべて、セッションの制限です。disconnectbadcommandlimit 以外のすべての制限は、MAIL FROM または RSET コマンドの発行時にチェックされます。制限のどれかを超えた場合、サーバーは 4xy エラーを発行して接続を切断します。disconnectbadcommandlimit は、不正なコマンドの発行時にチェックされるという点だけが異なります。

ログ記録とデバッグを設定する

この節では、ログ記録とデバッグのキーワードについて説明します。

ログ記録のキーワード

キーワード: logging、nologging、logheader

MTA は、メッセージがキューに出し入れされるたびにログを作成することができます。logging および nologging キーワードは、チャネルごとのメッセージログの作成を制御します。デフォルト設定では、すべてのチャネルに対してログが作成されます。特定のチャネルに対してログの作成を無効にするには、チャネル定義で logging の代わりに nologging キーワードを設定します。

logheader は、チャネル単位で MTA オプション LOG_HEADER よりも優先されます。値が 0 の場合 (デフォルト)、メッセージヘッダーのログ記録が無効になります。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Option File」を参照してください。

ログ記録については、第 21 章「ログの管理」を参照してください。

デバッグのキーワード

キーワード: master_debug、slave_debug、nomaster_debug、noslave_debug

チャネルプログラムによっては、デバッグ目的のためにより詳細な診断出力を生成するオプションコードがあるものもあります。このチャネルごとのデバッグとの出力の生成機能を有効にするためのチャネルキーワードには 2 種類あります。master_debug キーワードはマスタープログラムのデバッグ出力を有効にし、slave_debug キーワードはスレーブプログラムのデバッグ出力を有効にします。デフォルトでは両方のデバッグ出力とも無効になっています (nomaster_debug および noslave_debug に設定)。

デバッグを有効にすると、デバッグ出力は各チャネルプログラムに関連付けられているログファイルに記述されます。ログファイルの場所は、プログラムによって異なります。通常、ログファイルはログディレクトリに保存されます。マスタープログラムのログファイル名は、通常 x_master.log の形式をとります。この x はチャネル名です。また、スレーブプログラムのログファイル名は、通常 x_slave.log の形式をとります。

UNIX では、master_debug と slave_debug が l チャネルに対して有効になっている場合は、ユーザーは MTA デバッグ情報を含む imta_sendmail.log-uniqueid ファイルを、現在のディレクトリに受信できます (ディレクトリに書き込み権がある場合。書き込みがない場合はデバッグにより stdout に出力)。

Loopcheck を設定する

キーワード: loopcheck、noloopcheck

loopcheck キーワードは、MTA が MTA 自身と通信しているかどうかを確認するために、SMTP EHLO 応答見出しに文字列を入れます。loopcheck が設定されている場合、SMTP サーバーでは XLOOP 拡張がアドバタイズされます。

XLOOP をサポートする SMTP サーバーと通信する場合、MTA の SMTP クライアントにより、通知された文字列と MTA の値が比較され、クライアントが SMTP サーバーと通信している場合は、メッセージがただちにバウンスされます。

その他のキーワード

この節では、その他のキーワードを説明します。この章には、次の節があります。

プロセスチャネルのオーバーライド

キーワード: notificationchannel、dispositionchannel

これらのキーワードは、配信ステータス通知 (DSN) および Message Disposition Notification (MDN) をそれぞれ最初にキューに入れるチャネルとして、プロセスチャネルよりも優先されます。指定された名前のチャネルが存在しない場合、Messaging Server はプロセスチャネルの使用を再開します。

notificationchannel は、配信ステータス通知 (DSN) を最初にキューに入れるチャネルとしてプロセスチャネルよりも優先されます。指定された名前のチャネルが存在しない場合、Messaging Server はプロセスチャネルの使用を再開します。

dispositionchannel は、MDN (Message Disposition Notification) を最初にキューに入れるチャネルとしてプロセスチャネルよりも優先されます。指定された名前のチャネルが存在しない場合、Messaging Server はプロセスチャネルの使用を再開します。

チャネル動作のタイプ

キーワード: submit

Messaging Server は、RFC 2476 のメッセージ送信プロトコルをサポートしています。チャネルを送信専用に設定するには、submit キーワードを使用します。これは通常、特別なポートで実行され、メッセージを送信する目的だけに使用される SMTP サーバーなどの TCP/IP チャネルに便利です。RFC 2476 では、このようなメッセージ送信に使用するためにポート 587 を確立します。

pipe チャネル

キーワード: user

user キーワードは、pipe チャネルでどのユーザー名を実行するかを示すのに使用されます。

user の引数は、通常小文字に変換されますが、引数に引用符が付けられている場合は、元の大文字と小文字が維持されます。

メールボックスフィルタファイルの場所を指定する

キーワード: filter、nofilter、channelfilter、nochannelfilter、destinationfilter、nodestinationfilter、sourcefilter、nosourcefilter、fileinto、nofileinto

filter キーワードは、そのチャネル用のユーザーフィルタファイルの場所を指定するために、ネイティブチャネルと ims-ms チャネルに対して使用します。このキーワードは、フィルタファイルの場所を示す URL を必要な引数としてとります。nofilter がデフォルトで、ユーザーメールボックスフィルタがそのチャネルに対して有効にならないことを示します。

一般的な MTA チャネルにチャネルレベルのフィルタを指定するには、受信と送信のメッセージに対してそれぞれ sourcefilter と destinationfilter のキーワードを使用します。これらのキーワードは、チャネルフィルタファイルの場所を示す URL を引数としてとります。nosourcefilter と nodestinationfilter がデフォルトで、チャネルのどちらの方向にもチャネルメールボックスフィルタが無効になります。

旧バージョンの channelfilter キーワードと nochannelfilter キーワードは、それぞれ destinationfilter と nodestinationfilter と同義です。

fileinto キーワードは、現在 ims-ms チャネルおよび LMTP チャネルに対してのみサポートされており、fileinto メールボックスフィルタ演算子が適用された場合、アドレスをどのように変更するかを指定します。ims-ms チャネルの場合、通常の使用方法は次のとおりです。

fileinto $U+$S@$D

上の例では、最初のサブアドレスの代わりに、フォルダ名をサブアドレスとして元のアドレスに挿入するように指定しています。

LMTP チャネルの場合、通常の使用方法は次のとおりです。

fileinto @$4O:$U+$S@$D

この $4O は、数字の 4 と大文字の O です。数字の 0 ではありません。

スパムフィルタのキーワード

キーワード: destinationspamfilterXoptin、sourcespamfilterXoptin

destinationspamfilterXoptin は、このチャネル宛のすべてのメッセージがフィルタリングソフトウェア X を介して実行されることを指定します。(フィルタリングソフトウェア X は、option.dat の spamfilterX_library で定義される。) キーワードのあとにはフィルタパラメータが続き、使用できるパラメータはフィルタ処理プログラムによって異なります。

sourcespamfilterXoptin は、このチャネルから発信されるすべてのメッセージがフィルタリングソフトウェア X を介して実行されることを指定します。(フィルタリングソフトウェア X は、option.dat の spamfilterX_library で定義される。) キーワードのあとにはシステム全体のデフォルトパラメータが続き、使用できるパラメータはフィルタ処理プログラムによって異なります。switchchannel が有効な場合、このキーワードは switched-to チャネルに入れられます。

これらのキーワードの使用方法の詳細については、「チャネルレベルのフィルタ処理を指定するには」を参照してください。

アドレス検証の後、かつアドレス拡張の前のルーティング

キーワード: aliasdetourhost

aliasdetourhost を使用すると、ホストしているユーザーの mailHost 属性値にソースチャネル固有の優先順位を与えられます。特に、aliasdetourhost は、ある種の処理のために別々のホストに送られるローカル (このシステムでホストされている) ユーザー宛のメッセージのルーティングにおいて「迂回経路」を確保するために一般的に使用されています。メッセージは元のホストで検証されて (アドレスが正しいローカルアドレスであるかどうか)、迂回経路で処理ホストに送信され、再び元のホストに返送されて拡張および配信されます。

aliasdetourhost は、よりよい設定を実現し、「中間フィルタ」タイプのチャネルおよびサードパーティーのフィルタリングホストを使用可能にします。aliasdetourhost は通常、代替変換チャネルに追加して使用されます。aliasdetourhost は、ローカル (このシステムでホストされている) ユーザー宛のルーティングに適用されますが、代替変換チャネルはリモートの受取人宛てのルーティングに適用されます。

aliasdetourhost の引数は、ホスト名またはドメイン名か、ホストおよびドメインの仕様です。(書き換えルールでは、ホスト名、IP リテラルアドレス、およびチャネルタグの処理が可能で、これらは黙示的にホスト名とみなされることに注意。) このキーワードをソースチャネルで指定すると、LDAP に保存されたアドレスのエイリアス展開が、メールホスト情報がチェックされるよりも前に (変換タグ情報の処理のあと) 停止します。このとき、メッセージは aliasdetourhost の値に送信されてアドレスの処理は正常に完了していますが、エイリアス展開は実行されておらず、なおかつアドレス検証は完了済みです。

変換チャネルのフィルタ処理に関するさまざまな問題を回避するための aliasdetourhost の使用例を次に示します。システムは、フロントエンド MTA とバックエンドメールストアから構成されているとします。ユーザーは、配信オプションを forward および mailbox に設定しています。MTA は、ウィルス/スパム防止システム用に代替変換チャネルを使用します。このユーザー宛てにメッセージが到着すると、MTA エイリアスは展開され、ローカルとリモートに受取人を 1 人ずつ作成します。リモートの受取人のコピーは直接送信されます。一方、ローカルの受取人のコピーは、変換チャネルに送信されてスキャンされ、返送されます。次に、2 回目のエイリアス展開が行われて、リモートの受取人に対して 2 つ目のコピーが作成され、ローカルの受取人のコピーは通常どおり配信されます。最終結果: リモートの受取人には 2 つのコピー、ローカルの受取人には 1 つのコピーが送信されます。

ローカルにホストされているユーザーに代替変換チャネルを使用せずに (ただし、場合によっては他の受取人に対して代替変換チャネルを使用して)、aliasdetourhost を使用するチャネルを使うと、次のことが可能になります。

メッセージの受け入れ
外部のスパム/ウィルスフィルタへのメッセージのルーティング
アドレス拡張および配信のためのメッセージの再受け付け

例 1:

MTA とは別のホストでサードパーティー製のスキャナが動作していると想定します。次の例では、偽の重複エントリを作成しなくてもユーザーエントリの転送が可能であり、なおかつメッセージを受け入れる前に受取人アドレスの検証を実行する機能は保持されています。

新しいチャネル tcp_scanner を作成します。

作成したチャネルに daemon キーワードを設定し、使用するフィルタ処理システムを指定します。さらに、チャネルに enqueue_removeroute を追加します。tcp_scanner チャネルは、imta.cnf 内で次のようになります。
tcp_scanner smtp mx single_sys subdirs 20 noreverse maxjobs 7 pool SMTP_POOL daemon my_a-v_filter.siroe.com enqueue_removeroute tcp_scanner-daemon

スキャンするすべてのソース tcp チャネルの tcp_local に aliasDetourHost tcp_scanner-daemon を追加します。スキャンの対象となる tcp チャネルには、tcp_local、tcp_submit、tcp_intranet、tcp_auth などがあります。次に、tcp_local と tcp_submit の例を示します。

! tcp_local
tcp_local smtp mx single_sys remotehost inner switchchannel
identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0
aliasdetourhost tcp_scanner-daemon
tcp-daemon

! tcp_submit
tcp_submit submit smtp mx single_sys mustsaslserver maytlsserver
missingrecipientpolicy 4 aliasdetourhost tcp_scanner-daemon
tcp_submit-daemon

aliasdetourhost の引数 (tcp_scanner-daemon) は、新しいチャネル tcp_scanner の正規のホスト名です。

スキャニングシステムから tcp_scanner チャネルを介して返送されるメッセージを受け入れるように、書き換えルールを作成します。

[1.2.3.4] $E$R$U[1.2.3.4]@tcp_scanner-daemon

1.2.3.4 は、スキャナシステムの IP アドレスです。

この書き換えルールを使用しない場合、メッセージはほかのいずれかの tcp* ソースチャネルを介して送信されます。すべてのメッセージには aliasdetourhost が含まれるため、メッセージは再びスキャンされて、ループが発生します。
設定をコンパイルしなおし、ディスパッチャを再起動します。
#imsimta cnbuild #imsimta restart dispatcher

例 2:

サードパーティー製のスキャナは MTA と同じホストで動作しているが、異なるポートで待機していると想定します。ポート 10024 でメールが受け入れられ、10025 に返送されるとします。

新しいチャネル tcp_scanner を作成します。

! tcp_scanner
tcp_scanner smtp nomx single_sys identnonenumeric subdirs 20 maxjobs 
7 pool SCAN_POOL daemon 127.0.0.1 port 10024 enqueue_removeroute
tcp_scanner-daemon

スキャンするすべてのソース tcp チャネルの tcp_local に aliasDetourHost tcp_scanner-daemon を追加します。スキャンの対象となる tcp チャネルには、tcp_local、tcp_submit、tcp_intranet などがあります。次に、tcp_local と tcp_submit の例を示します。

! tcp_local
tcp_local smtp mx single_sys remotehost inner switchchannel
identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver
maysaslserversaslswitchchannel tcp_auth missingrecipientpolicy 0
aliasdetourhost tcp_scanner-daemon
tcp-daemon

! tcp_submit
tcp_submit submit smtp mx single_sys mustsaslserver maytlsserver
missingrecipientpolicy 4 aliasdetourhost tcp_scanner-daemon
tcp_submit-daemon

mappings ファイルに次のように追加して、tcp_scanner チャネルを経由して送信メールを再ルーティングします。
```
CONVERSIONS

in-chan=tcp_scanner;out-chan=*;CONVERT     No
in-chan=tcp_*;out-chan=tcp_local;CONVERT   Yes,Channel=tcp_scanner
```
SMTP_POOL の下の job_controller.cnf に、同時スキャン数の制限を追加します。

スキャニングソフトウェアにも制限が必要ですが、同時スキャン数と同じに設定して、メッセージングサーバーがメッセージを受け入れない場合にスキャナへのメール送信を試みないようにすることをお勧めします。
! [POOL=SCAN_POOL] job_limit=2 !
dispatcher.cnf に新しいサービスを追加して、特別なポートのスキャナから返されたメールを受け入れ、再びスキャンしないように tcp_scan を経由させて送信します。
! [SERVICE=SMTP_SCANNING] INTERFACE_ADDRESS=127.0.0.1 PORT=10025 IMAGE=IMTA_BIN:tcp_smtp_server LOGFILE=IMTA_LOG:tcp_smtp_server.log STACKSIZE=2048000 PARAMETER=CHANNEL=tcp_scanner !
設定をコンパイルしなおし、ディスパッチャを再起動します。
# imsimta cnbuild # imsimta restart job_controller # imsimta restart dispatcher

非請求の SMTP 拡張のサポート

キーワード: sourcenosolicit および destinationnosolicit

Internet Draft の draft-malamud-no-soliciting-07.txt に記述されている NO-SOLICIT SMTP 拡張は、プロポーズドスタンダードとして Messaging Server に実装されています。この機能を制御するためには、次のチャネルキーワードが使用できます。

sourcenosolicit は、このチャネルから送信されたメール内でブロックされる請求フィールドの値のコンマ区切りの一覧を指定します。値の一覧は、NO-SOLICIT EHLO 応答に表示されます。値にはグローバルな形式のワイルドカードを使用できますが、ワイルドカードを含む値は EHLO 通知には表示されません。

destinationnosolicit は、このチャネルのキューに入れられたメール内で受け入れられない請求フィールドの値のコンマ区切りの一覧を指定します。

不正な `RCPT TO` アドレスに制限を設定する

キーワード: deferralrejectlimit

1 つのセッション中に許可される不正な RCPT TO: アドレス数を制限します。指定した数の To: アドレスが拒否されると、続くすべての受取人は、正しいものも不正なものも 4xx エラーとして拒否されます。ALLOW_REJECTIONS_BEFORE_DEFERRAL SMTP チャネルキーワードと同じ機能が提供されますが、この場合はチャネル単位です。

第 12 章 チャネル定義を設定する

チャネルのデフォルトを設定する

チャネルキーワードの一覧 (アルファベット順)

機能別チャネルキーワード

SMTP チャネルを設定する

SMTP チャネルオプションを設定する

SMTP コマンドとプロトコルのサポート

チャネルプロトコル選択と改行記号

EHLO コマンドのサポート

ETRN コマンドのサポート

ETRN コマンドへの応答

ETRN コマンドを送信する

VRFY コマンドのサポート

VRFY コマンドを送信する

VRFY コマンドに応答する

EXPN サポート

DNS ドメイン確認

文字セットのラベルと 8 ビットデータ

文字セットのラベル

8 ビットデータ

プロトコルストリーミング

TCP/IP 接続と DNS 検索のサポート

TCP/IP ポート番号とインタフェースアドレス

チャネル接続情報のキャッシング

リバース DNS 検索

IDENT 検索

TCP/IP MX レコードのサポート

ネームサーバー検索

最後のホスト

着信メール用代替チャネル (切り替えチャネル)

ターゲットホストの選択

SMTP 認証、SASL、TLS

ヘッダー内の SMTP AUTH から認証済みアドレスを使用する

Microsoft Exchange ゲートウェイチャネルを指定する

Transport Layer Security

メッセージの処理と配信を設定する

チャネルの方向性を設定する

指定配信日を実行する

配信失敗メッセージの再配信回数を指定する

チャネル実行ジョブの処理プール

サービスジョブの制限

接続トランザクションの制限を設定する

サイズに基づくメッセージの優先度

SMTP チャネルスレッド

複数アドレスの拡張

サービス変換を有効にする

アドレス処理を設定する

アドレスのタイプとルール

822 (sourceroute)

733 (percents)

uucp (bangstyle)

header_822

header_733

header_uucp

! と % を使用するアドレスを解釈する

アドレスにルーティング情報を追加する

明示的なルーティングアドレスの書き換えを無効にする

メッセージがキューから取り出されるときのアドレス書き換え

不完全なアドレスを修正する際に使用するホスト名を指定する

受取人ヘッダー行がないメッセージを有効にする

不正な空白の受取人ヘッダーを削除する

チャネル固有のリバースデータベースの使用を有効にする

制限されたメールボックスのエンコーディングを有効にする

Return-path: ヘッダー行を生成する

エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する

アドレスヘッダー行内のコメントを処理する

アドレスヘッダー行内の個人名を処理する

エイリアスファイルとエイリアスデータベースプローブを指定する

サブアドレスを処理する

チャネル固有の書き換えルールチェックを有効にする

ソースルートを削除する

エイリアスからアドレスを指定する

ヘッダー処理を設定する

埋め込まれたヘッダーを書き換える

メッセージヘッダー行を選択して削除する

X-Envelope-to ヘッダー行を生成するまたは削除する

日付表示を 2 桁から 4 桁に変換する

日付の曜日を指定する

長いヘッダー行を自動分割する

ヘッダーの配置と折り返し

第 12 章チャネル定義を設定する

不正な `RCPT TO` アドレスに制限を設定する