|
| |
| Sun Java System Messaging Server 6 2004Q2 管理ガイド | |
第 12 章
チャネル定義を設定するこの章では、MTA 設定ファイル imta.cnf でのチャネルキーワード定義の使用方法について説明します。この章を読む前に、第 10 章「MTA サービスと設定について」、および「チャネル定義」と「MTA 設定ファイル」をお読みください。この章には、以下の節があります。
チャネルキーワードの一覧 (アルファベット順)次の表にキーワードの一覧をアルファベット順に示します。
機能別チャネルキーワード次の表に分類したキーワードの一覧を示します。
表 12-2 機能別チャネルキーワード
キーワード
ページ
定義
アドレス処理
733
エンベロープで % ルーティングを使用する。percents と同義
822
エンベロープでソースルートを使用する。sourceroute と同義
addreturnpath
このチャネルにキューを入れる際に、メッセージに Return-Path: ヘッダーを追加する
aliaslocal
書き換えられたアドレスをエイリアスファイルとエイリアスデータベースで検索する
authrewrite
認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用する
bangoverpercent
A!B%C を A!(B%C) としてグループ化する
bangstyle
エンベロープで UUCP! ルーティングを使用する。uucp と同義
defaulthost
アドレスを完成させるためにドメイン名を指定する
dequeue_removeroute
エンベロープの To: アドレスからソースルートを削除する
exproute
アドレスをリモートシステムに渡す際に明示的なルーティングを要求する
holdlimit
エンベロープ受取人アドレス数がこの制限を越えた場合、メッセージを保留する
improute
このチャネルのアドレスに対して黙示的なルーティングを実行する
missingrecipientpolicy
受取人ヘッダーがないメッセージを有効にする (どのヘッダーに追加するか指定する) ポリシーを設定する
noaddreturnpath
メッセージをキューに入れる際に Return-Path: ヘッダーを追加しない
nobangoverpercent
A!B%C を (A!B)%C としてグループ化する
nodefaulthost
アドレスを完成させるために使用する、ドメイン名を指定しない
noexproute
このチャネルのアドレスに対して明示的なルーティングを実行しない
noimproute
このチャネルのアドレスに対して黙示的なルーティングを実行しない
noreceivedfrom
元のエンベロープの 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
チャネルに一致する最終受取人アドレスを、エイリアスで作成する必要がある
添付と MIME 処理
defragment
このチャネルのキューに入れられる部分メッセージは、代わりに再組み立てチャネルのキューに入れられる
ignoreencoding
受信メッセージの Encoding: ヘッダーを無視する
interpretencoding
受信メッセージの Encoding: ヘッダーを必要に応じて解釈する
nodefragment
再組み立てを無効にする
文字セットと 8 ビットデータ
charset7
7 ビットのテキストメッセージに関連付けるデフォルトの文字セット
charset8
8 ビットのテキストメッセージに関連付けるデフォルトの文字セット
charsetesc
エスケープ文字を含む 7 ビットのテキストに関連付けるデフォルトの文字セット
eightbit
チャネルが 8 ビット文字をサポートする
eightnegotiate
チャネルが 8 ビット転送の使用をネゴシエートする (可能な場合)
eightstrict
ネゴシエーションが行われていない 8 ビットデータがメッセージヘッダーに含まれている場合は、そのメッセージを拒否する
sevenbit
8 ビット文字をサポートしない。8 ビット文字はエンコードされなければならない
MTA キュー領域でのファイル作成
addrsperfile
チャネルのキューにある 1 つのメッセージファイルに関連付けられる受取人の最大数を制限する
expandchannel
expandlimit の適用による遅延拡張を実行するチャネルを指定する
expandlimit
アドレスの数がこの制限を超えた場合、受信メッセージを「オフライン」で処理する
multiple
メッセージファイル内の受取人数を制限しない。ただし SMTP チャネルのデフォルトは 99 である
single
チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成される
single_sys
各宛先システム用にメッセージのコピーを 1 つずつ作成する
subdirs
チャネルキューのメッセージを拡散するサブディレクトリの数を指定する
ヘッダー
authrewrite
認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用する
commentinc
メッセージのヘッダー行内のコメントをそのままにする
commentmap
COMMENT_STRINGS マッピングテーブルを通じて、メッセージヘッダー行でコメント文字列を実行する
commentomit
メッセージのヘッダー行内のコメントを取り除く
commentstrip
メッセージのヘッダー行内にある問題を起こす文字を取り除く
commenttotal
Received: ヘッダー行以外のすべてのヘッダー行から ( ) に入っているコメントを削除する。ただし、推奨しない
datefour
すべての年表示フィールドを 4 桁に展開する
datetwo
4 桁の日付表示から先頭の 2 桁を削除する。2 桁の日付表示を要求するメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないこと
dayofweek
曜日情報を残し、曜日情報がない場合にはその情報を日付 / 時刻ヘッダーに追加する
defaulthost
アドレスを完成させるためにドメイン名を指定する
dropblank
受信メッセージから不正な空白ヘッダーを削除する
header_733
メッセージヘッダーで % ルーティングを使用する
header_822
メッセージヘッダーでソースルートを使用する
headerlabelalign
このチャネルのキューに入れられたメッセージヘッダーの配置ポイントを制御する。整数値の引数をとる
headerlinelength
このチャネルのキューに入れられたヘッダー行の長さを制御する
headerread
オリジナルのメッセージヘッダーが処理される前に、メッセージがキューに入れられたときに、オプションファイルからそのメッセージのヘッダーにトリミングのルールを適用する (注意して使用すること)
headertrim
元のメッセージヘッダーが作成されたあとで、オプションファイルからそのメッセージのヘッダーにトリミングのルールを適用する
header_uucp
ヘッダーで ! ルーティングを使用する
inner
メッセージをパースして、内部ヘッダーを書き換える
innertrim
内部のメッセージヘッダーに、オプションファイルからのヘッダートリミングルールを適用する (注意して使用すること)
言語
ヘッダーにデフォルトの言語を指定する
maxheaderaddrs
1 行に表示できるアドレスの数を指定する
maxheaderchars
1 行に表示できる文字数を指定する
missingrecipientpolicy
受取人ヘッダーがないメッセージを有効にする (どのヘッダーに追加するか指定する) ポリシーを設定する
nodayofweek
日付 / 時刻ヘッダーから曜日情報を削除する。この情報が処理できないメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないこと
nodefaulthost
アドレスを完成させるために使用する、ドメイン名を指定しない
nodropblank
受信メッセージから不正な空白ヘッダーを削除しない
noheaderread
オプションファイルからのヘッダートリミングルールを適用しない
noheadertrim
オプションファイルからのヘッダートリミングルールを適用しない
noinner
内部のメッセージヘッダー行を書き換えない
noinnertrim
内部のメッセージヘッダーにヘッダートリミングルールを適用しない
noreceivedfor
エンベロープ受取人情報を含めずに Received: ヘッダー行を作成する
noreceivedfrom
元のエンベロープの From: アドレスを含めずに Received: ヘッダー行を作成する
noremotehost
アドレスを完成させるために、ローカルホストのドメイン名をデフォルトのドメイン名として使用する
noreverse
チャネルのキューに入れられたメッセージのアドレスを、アドレスリバース処理から外す
norules
このチャネル固有の書き換えルールを確認しない
nox_env_to
X-Envelope-to ヘッダー行を削除する
personalinc
メッセージのヘッダー行にある個人名のフィールドをそのままにする
personalmap
PERSONAL_NAMES マッピングテーブルを通じて、個人名を実行する
personalomit
メッセージのヘッダー行にある個人名のフィールドを削除する
personalstrip
ヘッダー行にある個人名のフィールドから問題になる文字を削除する
receivedfor
メッセージの宛先になっているエンベロープ受取人アドレスが 1 つだけの場合は、そのエンベロープの Received: ヘッダー行に To: アドレスを含める
receivedfrom
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 ヘッダー行の生成を有効にする
受信チャネルの一致と切り替え
allowswitchchannel
switchchannel チャネルからこのチャネルへの切り替えを許可する
nosaslswitchchannel
SASL 認証に成功した場合、このチャネルへの切り替えは許可されない
noswitchchannel
チャネルへの切り替えを行わない
switchchannel
サーバーチャネルから送信元のホストに関連付けられたチャネルに切り替える
saslswitchchannel
クライアントが SASL の使用に成功した場合、受信接続が指定のチャネルに切り替えられる
tlsswitchchannel
TLS のネゴシエートが成功した場合に、ほかのチャネルに切り替える
ログ記録とデバッグ
logging
キューに対するメッセージの出入りをログに記録し、特定のチャネルのログ機能を有効にする
loopcheck
MTA が MTA 自体と通信しているかどうかを確認するために、SMTP EHLO 応答見出しに文字列を配置する
master_debug
チャネルのマスタープログラム出力内にデバッグ出力を作成する
nologging
キューに対するメッセージの出入りをログに記録しない
noloopcheck
SMTP EHLO 応答見出しに文字列がない
nomaster_debug
チャネルのマスタープログラム出力内にデバッグ出力を行わない
noslave_debug
スレーブのデバッギング出力を生成しない
slave_debug
スレーブのデバッグ出力を生成する
長いアドレスリストやヘッダー
expandchannel
expandlimit の適用による遅延拡張を実行するチャネルを指定する
expandlimit
アドレスの数がこの制限を超えた場合、受信メッセージを「オフライン」で処理する
holdlimit
アドレスの数がこの制限を越えた場合、メッセージを保留する
maxprocchars
処理や書き換えができるヘッダーの最大長
メールボックスフィルタ
channelfilter
チャネルフィルタファイルの場所。destinationfilter と同じ
destinationfilter
送信するメッセージに提供されるチャネルフィルタの場所
fileinto
メールボックスフィルタ fileinto の操作が適用されたときの、アドレスに対する効果を指定する
filter
ユーザーフィルタファイルの場所を指定する
nochannelfilter
送信メッセージに対するチャネルフィルタリングを行わない。nodestinationfilter とも呼ばれる
nodestinationfilter
送信メッセージに対するチャネルフィルタリングを実行しない
nofileinto
メールボックスフィルタ fileinto のオペレータが効果を発揮しない
nofilter
ユーザーメールボックスのフィルタリングを実行しない
nosourcefilter
受信メッセージに対してチャネルフィルタリングを実行しない
sourcefilter
受信メッセージ用のチャネルフィルタの場所を指定する
通知メッセージとポストマスターメッセージ (完全な通知手順については 270 ページを参照)
aliaspostmaster
正式なチャネル名でのユーザー名がポストマスターのメッセージは 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-7 を参照)
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 クライアントに対して新しいスレッドをトリガするために必要なメッセージ数
transactionlimit
1 つの接続について許されるメッセージの数を制限する
urgentbackoff
優先度が高いメッセージの配信試行頻度
urgentblocklimit
指定値以上のサイズを持つメッセージの優先度を「標準」に設定する
user
pipe チャネルでどのユーザー名で実行するかを示すのに使用される
重要度の上限
sensitivitycompanyconfidential
受け付けるメッセージの重要度の上限
sensitivitynormal
Normal が、受け付けるメッセージの重要度の上限である
sensitivitypersonal
Personal が、受け付けるメッセージの重要度の上限である
sensitivityprivate
Private が、受け付けるメッセージの重要度の上限である
メッセージのサイズ制限、ユーザー制限容量、権限
alternatechannel
alternateblocklimit、alternatelinelimit、および alternaterecipientlimit の代替宛先チャネル
alternateblocklimit
メッセージが alternativechannel に送信される前に、メッセージのブロック数の制限を指定する
alternatelinelimit
メッセージが alternativechannel に送信される前に、メッセージの行数の制限を指定する
alternaterecipientlimit
メッセージが alternativechannel に送信される前に、メッセージの受取人数の制限を指定する
blocklimit
メッセージあたりの許可されている MTA ブロックの最大数
holdexquota
制限容量を超過したユーザーに対するメッセージを保留する
holdlimit
アドレスの数がこの制限を越えた場合、受信メッセージを保留する
linelength
チャネルごとに許される最大のメッセージ行の長さを制限する
linelimit
1 つのメッセージに対して許可される最大の行数を指定する
maxblocks
1 つのメッセージに許可するブロックの最大数を指定する
maxlines
1 つのメッセージに許可する最大行数を指定する
noblocklimit
メッセージ当たりに許可される MTA ブロックの数に制限はない
noexquota
制限容量を超過したユーザーに対し、すべてのメッセージを差出人に送り返す
nolinelimit
メッセージあたりに許可される行数に制限はない
nonurgentblocklimit
指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定する。該当するメッセージは次の定期ジョブまで処理されない
normalblocklimit
指定値以上のサイズを持つメッセージの優先度を「低」に設定する
sourceblocklimit
メッセージあたりの許可されている MTA ブロックの最大数
urgentblocklimit
指定値以上のサイズを持つメッセージの優先度を「標準」に設定する
SMTP 認証、SASL および TLS (より大きい機能単位については 359 ページを参照)
authrewrite
認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用する
maysaslserver
クライアントが SASL 認証を使用することを許可する
maytls
MTA は TLS 使用の接続を受け入れ、送信接続にも TLS を使用しようと試みる
maytlsclient
MTA SMTP クライアントは TLS をサポートする SMTP サーバーにメッセージを送信する際に TLS を使用する
maytlsserver
MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用することを許可する
msexchange
TCP/IP チャネルで使用して、MTA にこれが MS Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示する
mustsaslserver
SMTP サーバーは、リモートクライアントが認証に成功しないかぎり、メッセージを受け付けない
musttls
MTA は送受信接続に必ず TLS を使用する
musttlsclient
MTA SMTP クライアントは、メッセージの送信に必ず TLS を使用する (MTA は STARTTLS コマンドを発行し、このコマンドは必ず成功する必要がある)
musttlsserver
MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用する
nomsexchange
デフォルト
nosasl
SASL 認証は許可されず、試行もされない
nosaslserver
SASL 認証は許可されない
notls
TLS 認証は許可されない。試行もされない
notlsclient
送信接続時に MTA SMTP クライアントは TLS を使用しない (送信接続時に STARTTLS コマンドが発行されない)
notlsserver
受信接続時に MTA SMTP サーバーは TLS の使用を許可しない (SMTP サーバーもコマンド自体も STARTTLS 拡張に通知しない)
saslswitchchannel
クライアントが SASL の使用に成功した場合、受信接続が指定のチャネルに切り替えられる
tlsswitchchannel
クライアントが TLS ネゴシエーションに成功した場合、受信接続が指定のチャネルに切り替えられる。このキーワードには、切り替え先のチャネルを指定する必要がある
SMTP コマンドとプロトコル (より大きい機能単位については表 12-4 を参照)
allowetrn
ETRN コマンドを処理する
blocketrn
ETRN コマンドをブロックする
checkehlo
SMTP 応答の見出しを確認して、EHLO と HELO のどちらを使用するか決定する
disableetrn
ETRN SMTP コマンドのサポートを無効にする
domainetrn
ドメインを指定する ETRN コマンドだけを処理する
domainvrfy
完全なアドレスを使用して VRFY コマンドを発行する
ehlo
初期接続に SMTP EHLO コマンドを使用する
eightbit
チャネルが 8 ビット文字をサポートする
eightnegotiate
チャネルが 8 ビット転送の使用をネゴシエートする (可能な場合)
eightstrict
ネゴシエーションが行われていない 8 ビットデータがメッセージヘッダーに含まれている場合は、そのメッセージを拒否する
expnallow
DISABLE_EXPAND SMTP チャネルオプションによって SMTP サーバーレベルで EXPN が無効にされている場合でも、EXPN を許可する
expndisable
EXPN を無条件で無効にする
expndefault
SMTP サーバーの設定で EXPN が許可されていれば EXPN を許可する
localvrfy
ローカルアドレスを使用して VRFY コマンドを発行する
mailfromdnsverify
MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認する
noehlo
EHLO コマンドを使用しない
nomailfromdnsverify
MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認しない
nosendetrn
ETRN コマンドを発行しない
nosmtp
SMTP プロトコルをサポートしない。これがデフォルト
novrfy
VRFY コマンドを発行しない
sendetrn
ETRN コマンドを発行する
sevenbit
8 ビット文字をサポートしない。8 ビット文字はエンコードされなければならない
silentetrn
チャネル情報をエコーせずに 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 コマンドに対して詳細な情報を提供する応答を出す
vrfydefault
チャネルの HIDE_VERIFY オプションの設定に従い、VRFY コマンドに対してデフォルトの応答を提供する
vrfyhide
SMTP VRFY コマンドに対してあいまいな応答を出す
TCP/IP 接続および DNS 検索サポート (より大きい機能単位については表 12-5 を参照)
cacheeverything
すべての接続情報をキャッシュする
cachefailures
接続失敗に関する情報だけをキャッシュする
cachesuccesses
接続成功に関する情報だけをキャッシュする
connectalias
受取人のアドレスに書かれているホストに配信する
connectcanonical
MTA が接続するシステムのホストエイリアスに接続する
daemon
エンベロープアドレスにかかわらず特定のホストシステムに接続する
defaultmx
チャネルが、ネットワークから MX 検索を実行するかどうかを決定する
defaultnameservers
TCP/IP スタックが選択したネームサーバーを照合する
forwardcheckdelete
リバース DNS 検索のあとに正引き検索を行い、リバース DNS 検索で返された名前の正引き検索がオリジナルの接続の IP 番号に一致するかどうかを確認する。一致しない場合、リバース DNS 検索で返された名前は削除され、IP アドレスが使用される
forwardchecknone
DNS リバース検索のあとに正引き検索を実行しない
forwardchecktag
リバース DNS 検索が実行して返された名前を正引き検索して、IP 番号がオリジナルの接続の IP 番号に一致するかどうかを確認する。一致しなければ名前に「*」を付ける
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: ヘッダーにホスト名だけを含める
interfaceaddress
指定された TCP/IP インタフェースアドレスにバインドする
lastresort
最後のホストを指定する
mailfromdnsverify
MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認する
mx
TCP/IP ネットワークおよびソフトウェアが MX レコード検索をサポートする
nameservers
TCP/IP スタックが選択したネームサーバーの代わりに照合するネームサーバーのリストを指定する。nameservers には、空白文字で区切られたネームサーバーの IP アドレスのリストが必要
nocache
接続情報をキャッシュしない
nomailfromdnsverify
MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認しない
nomx
TCP/IP ネットワークが MX 検索をサポートしない
nonrandomemx
MX 検索を実行するが、返されたエントリを同等の優先度でランダム化しない
port
SMTP 接続用のデフォルトポート番号を指定する。標準ポートは 25
randommx
MX 検索を実行し、返されたエントリを同等の優先度でランダム化する
single
チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成されるように指定する
single_sys
各宛先システム用にメッセージのコピーを 1 つずつ作成する
threaddepth
マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数
その他
submit
チャネルを送信専用のチャネルに指定する
user
pipe チャネルでどのユーザー名で実行するかを示すのに使用される
チャネルのデフォルトを設定する設定ファイルにはさまざまなチャネルキーワードが繰り返し記述されていることがあります。このような設定を管理するには時間がかかり、エラーの原因にもなります。複数のチャネルに対してデフォルトのキーワードを指定すると、設定を簡素化することができます。
たとえば、以下の行を設定ファイルに追加すると、行中で指定したキーワードがそれ以降のすべてのチャネルブロックに適用されます。
defaults keyword1 keyword2 keyword3 ...
defaults 行はチャネルを特定せずにデフォルトのキーワードを変更するための特殊なチャネルブロックだと考えられます。また、defaults 行にほかのチャネルブロック情報を指定する必要はありません (指定しても無視される)。
1 つのファイルに使用できる defaults 行の数に上限はありません。複数の defaults 行を指定した場合、ファイルの下へ行くほど (あとで追加した行ほど) 優先度が高くなります。
設定ファイル内のある位置 (たとえば、外部ファイルのチャネルブロックの独立したセクションの冒頭など) 以降には無条件に defaults 行が適用されないように設定しておく方がよい場合もあります。そのためには、nodefaults 行を使用します。たとえば、以下の行を設定ファイルに挿入すると、それ以前の部分で defaults を使って指定した設定がすべて無効になり、defaults を使用していないのと同じ状態に戻ります。
nodefaults
ほかのチャネルブロックと同様に、defaults や nodefaults チャネルブロックを使用する場合も、ブロック間の区切りには空白行を使用します。設定ファイル内でローカルチャネルの前に記述できるチャネルブロックは、defaults と nodefaults のみです。ただし、ほかのチャネルブロックと同様、書き換えルールの前に記述することはできません。
SMTP チャネルを設定するインストールの種類によっては、Messaging Server のインストール時に数種の SMTP チャネルが提供されます (以下の表を参照)。このようなチャネルは TCP/IP の上位プロトコルとして SMTP を実装します。マルチスレッド TCP SMTP チャネルには、ディスパッチャ制御下のマルチスレッド SMTP サーバーが含まれます。送信された SMTP メールは、必要に応じてジョブコントローラの制御下で動作し、チャネルプログラム tcp_smtp_client によって処理されます。
この節で説明するチャネルキーワードを追加または削除することで、これらのチャネルの定義を変更したり、新規チャネルを作成したりできます。また、オプションファイルは、TCP/IP チャネルのさまざまな特徴を制御するために使用されます。このようなオプションファイルは、MTA 設定ディレクトリ (msg_svr_base/config) に保存し、x_option という名前を付けなければなりません。この「x」はチャネルの名前です。詳細は、『Sun Java System Messaging Server Administration Reference』を参照してください。
この節には、以下の項があります。
SMTP チャネルオプションを設定する
TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。チャネルオプションファイルは MTA 設定ディレクトリに保存し、x_option という名前を付けてください。x はチャネル名です。たとえば、/msg_svr_base/config/tcp_local_option のようになります。
オプションファイルは、1 つまたは複数のキーワードとその関連値によって構成されています。たとえば、サーバーのメーリングリストの展開を無効にするには、オプションファイルに DISABLE_EXPAND キーワードを追加し、値を 1 に設定します。
その他のオプションファイルキーワードを使用すると、以下の制御を行うことができます。
チャネルオプションキーワードと構文の詳細については、『Messaging Server Reference Manual』を参照してください。
SMTP コマンドとプロトコルのサポート
SMTP チャネルが EHLO、ETRN、EXPN、VRFY などの SMTP コマンドをサポートするように指定することができます。また、チャネルが DNS ドメイン確認をサポートするかどうかや、どの文字を改行記号として受け入れるかなどを指定することも可能です。この項では、以下の内容について説明します。
表 12-4 に、この節で説明されているキーワードのリストを示します。
チャネルプロトコル選択と改行記号
キーワード : 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 はドメインによって確認されたチャネル名をエコーしません。
disableetrn では、ETRN コマンドに対するサポートが完全に無効となります。SMTP サーバーで、ETRN はサポートされているコマンドとして通知されません。
ETRN コマンドを送信する
sendetrn および nosendetrn チャネルキーワードは、MTA が SMTP 接続開始時に ETRN コマンドを送るかどうかを指定するためのものです。デフォルト設定では nosendetrn が有効になっているため、MTA は ETRN コマンドを送りません。リモート SMTP サーバーが ETRN コマンドをサポートする場合にのみ MTA が ETRN を発行するように指定するには、sendetrn キーワードを使用します。sendetrn キーワードの後には、メッセージの配信先となるシステムの名前を記述する必要がある
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 が許可されていれば EXPN を許可します (デフォルト)。リストごとに展開を無効にすることができますが、サーバーレベルで無効にされている場合は、リストごとの設定は意味を持ちません。
DNS ドメイン確認
キーワード : mailfromdnsverify、nomailfromdnsverify
mailfromdnsverify を受信 TCP/IP チャネルに対して設定すると、MTA は SMTP MAIL FROM コマンドで指定されているドメインのエントリが DNS に存在するかどうかを確認し、エントリが存在しない場合にはメッセージを拒否します。デフォルト設定では nomailfromdnsverify が有効になっているため、この確認は行われません。ただし、返信アドレスに対して DNS 確認を行うと、許可されるべきメッセージも拒否されてしまう可能性があることに注意してください (たとえば、正規のサイトでもそのドメイン名がまだ登録されていない場合や、DNS が適切に動作していない場合など)。これは、RFC 1123 の「Requirements for Internet Hosts (インターネットホストの必要条件)」で規定されている電子メール受信の心得に反する行為です。ただし、存在しないドメインから不特定多数宛のメール (UBE) が送られる場合は、この確認を行った方がよい場合もあります。
文字セットのラベルと 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 のローカルチャネルは次のようにラベル付けされます。
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-5 に、この項で説明されている TCP/IP 接続および DNS 検索に関連するキーワードの一覧を示します。
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 アドレスを使用します。
IDENT 検索
キーワード : identnone、identnonelimited、identtnonnumeric、identnonesymbolic、identtcp、identtcpnumeric、identtcpsymbolic、identtcplimited
IDENT キーワードは、MTA が IDENT プロトコルを使用して接続や検索を処理する方法を制御します。IDENT プロトコルは、RFC 1413 で規定されています。
identtcp、identtcpsymbolic、および identtcpnumeric キーワードは、MTA が接続や検索に IDENT プロトコルを使用するように指定するものです。IDENT プロトコルから入手した情報 (通常、SMTP 接続を使用しているユーザーの ID) は、次のようにメッセージの Received: ヘッダー行に挿入されます。
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: ヘッダーにユーザーフレンドリーではない情報を使用するため、パフォーマンスの向上につながる可能性もあります。
identtcplimited および identnonelimited キーワードは、IDENT 検索、リバース DNS 検索、Received: ヘッダーに表示する情報などに関し、identtcp および 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。「saslswitchchannel」および「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.comTCP-DAEMON
daemon キーワードの後ろの引数が完全なドメイン名ではない場合、引数は無視され、チャネルは正規ホストに接続します。ファイアウォールやゲートウェイシステムを正規ホスト名として指定する場合、以下の例に示すように 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
MTA が認証された差出人の情報をヘッダーに含めるようにするために、authrewrite チャネルキーワードをソースチャネルに使用することもできます。FROM_ACCESS マッピングによって無視されることもありますが、通常はSMTP AUTH 情報が使用されます。表 12-6 にあるように、authrewrite キーワードは必須の整数値をとります。
表 12-6 authrewrite の整数値
値
使用目的
1
AUTH 差出人を含む Sender: や Resent-sender: がすでに存在していれば、Sender: ヘッダーまたは Resent-sender: ヘッダーを追加する
2
AUTH 差出人を含む Sender: ヘッダーを追加する
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 が機能するためには、次の条件が整っている必要があります。
musttls キーワードを指定すると、MTA は送受信接続に必ず TLS を使用します。TLS の使用をネゴシエーションを行うことができなかったリモートシステムとの電子メールの交換は許可されません。このキーワードは、musttlsclient (MTA SMTP クライアントはメッセージの送信に必ず TLS を使用し、TLS の使用のネゴシエーションが成功しない。SMTP サーバーにはメッセージを送らない。MTA 発行の STARTTLS コマンドは必ず成功しなければならない) および musttlsserver (MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、TLS 使用のメッセージを受け入れる際には必ず TLS を使用する。TLS の使用のネゴシエーションが成功しないクライアントからのメッセージは拒否される) を包括しています。
tlsswitchchannel キーワードは、クライアントが TSL 使用のネゴシエートに成功した場合、受信した接続を指定のチャネルに切り替えるためのキーワードです。このキーワードには、切り替え先のチャネルを指定する必要があります。
メッセージの処理と配信を設定するサーバーが特定の条件に基づいてメッセージの配信を試みるように指定できます。また、サービスジョブの処理制限や、新しい SMTP チャネルスレッドを作成するタイミングなど、ジョブ処理に関するパラメータを指定することも可能です。この項では、以下の内容について説明します。
メッセージの処理と配信の詳細については、「ジョブコントローラ」および「ジョブコントローラファイル」を参照してください。
表 12-7 に、この節で説明されているキーワードのリストを示します。
チャネルの方向性を設定する
キーワード : master、slave、bidirectional
チャネルを処理するプログラムは、マスタープログラム (master)、スレーブプログラム (slave)、あるいは両方のプログラム (bidirectional) という 3 つのキーワードで指定されます。これらのどのキーワードも指定されていない場合のデフォルトは bidirectional です。これらのキーワードによって、チャネルのキューにメッセージが入れられたときに MTA が配信活動を開始するかどうかが決まります。
これらのキーワードを使用すると、対応するチャネルプログラムの特徴が反映されるようになります。これらのキーワードをいつ、どこで使用すべきかについては、MTA がサポートする各種チャネルの説明を参照してください。
指定配信日を実行する
キーワード : deferred、nodeferred
deferred チャネルキーワードは、Deferred-delivery: ヘッダー行の認識と処理を行います。未来の deferred 指定配信日が付いているメッセージは、有効期限が切れて返されるか、あるいは指定配信日がくるまでチャネルのキューに保管されます。Deferred-delivery: ヘッダー行の形式と操作の詳細については、RFC 1327 を参照してください。
デフォルトのキーワードは nodeferred です。RFC 1327 では配信日指定によるメッセージ処理のサポートが義務付けられていますが、実際にそれを効果的に行えば、人々がディスク制限容量の拡張手段としてメールシステムを使用できるようになります。
配信失敗メッセージの再配信回数を指定する
キーワード : 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 分後に再度の配信を試み、その 120 分後に 2 回目の再配信、16 時間後に 3 回目、36 時間後に 4 回目、3 日後に 5 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 3 日ごとに再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。
チャネル実行ジョブの処理プール
キーワード : pool
複数のチャネルが 1 つのプール内で動作するように設定すると、複数のチャネルが同じプールのリソースを共有できるようになります。特定のチャネル専用に指定されているプール内でほかのチャネルが動作するように設定することも可能です。各プール内のメッセージは優先度に基づいて自動的に適切な処理キューに割り当てられます。優先度の高いメッセージは優先度が低いメッセージよりも先に処理されます (「サイズに基づくメッセージの優先度」を参照)。
pool キーワードを使用すると、ジョブが作成されるプールをチャネルごとに指定できます。pool キーワードの後ろには、現在のチャネルの配信ジョブのプール先となるプール名を指定する必要があります。プール名の長さの上限は 12 バイトです。
ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「ジョブコントローラ」、および「サービスジョブの制限」を参照してください。
サービスジョブの制限
キーワード : maxjobs、filesperjob
メッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。しかし、1 つのサービスジョブではすべてのメッセージを手際よく配信できない場合もあります。ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「チャネル実行ジョブの処理プール」、および「ジョブコントローラ」を参照してください。
メッセージ配信のために開始されるプロセスやスレッドの数には、妥当な制限があります。このプロセスやスレッド数の上限は、プロセッサの数、ディスクの速度、接続の性質などによって決定されます。MTA 設定ファイルでは、以下のものを制御することができます。
1 つのチャネルに対して開始されるプロセス数の上限は、そのチャネルに対して設定されている maxjobs、またはチャネルが動作しているプールに対して設定されている JOB_LIMIT の最小値に当たります。
あるメッセージに処理が必要だとします。一般に、ジョブコントローラは次の場合に新しい処理を開始します。
特に、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 には、そのチャネルが使用するプールまたはサービスプールで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を使用します。
接続トランザクションの制限を設定する
キーワード : 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 つのスレッドによって処理されますが、このキーワードを指定すると、それらのメッセージが複数のスレッドによって処理されるようになります。
threaddepth キーワードは、チャネルの接続先の SMTP サーバーが複数の接続を同時に処理できる場合に、デーモンルーター TCP/IP チャネル (ある特定の SMTP サーバーに接続する TCP/IP チャネル) 上でマルチスレッドを確立する際に便利です。
チャネルに対するバックログが threaddepth で指定されている以上の数に達すると、ジョブコントローラはより多くのリソースをそのチャネルのキューにあるメッセージの処理に割り当てようとします。チャネルがマルチスレッドの場合、ジョブコントローラはメッセージを処理するジョブがそのチャネルに対して新しくスレッドを開始するように指示し、すべてのジョブのスレッド数がそのチャネルの制限に達している場合 (tcp_* チャネルの MAX_CLIENT_THREADS オプション) は、新しいプロセスを開始するように指示します。シングルスレッドのチャネルに対しては、新しいプロセスを開始するように指示します。ただし、チャネルのジョブ数 (maxjobs) またはプールのジョブ数 (JOB_LIMIT) が制限に達している場合、新しいジョブは開始されません。
複数アドレスの拡張
キーワード : 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 という形式のアドレスは次のどちらにも解釈できます。
または
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 にアドレスのすべての明示的ルーティングを短絡化しようとします。明示的にルーティングされたアドレス (!、%、または @ の文字を使用) は簡略化されている。
このキーワードを内部 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 ホストでネットワーク全体の問題を解決しようとするより簡単です。
Recipient ヘッダー行がないメッセージを有効にする
キーワード : missingrecipientpolicy
RFC 822 (Internet) メッセージには、受取人ヘッダー行である To:、Cc:、または Bcc: ヘッダー行が必要です。そのようなヘッダー行がないメッセージは無効になります。しかし、うまく稼働していないユーザーエージェントやメーラー (たとえば、古いバージョンの sendmail) は、無効なメッセージを受け入れます。
missingrecipientpolicy キーワードは、そのようなメッセージを扱うときに使用すべきアプローチを指定する整数値をとります。このキーワードが明示的に表現されていない場合は、デフォルト値の 0 が使用され、エンベロープ To: アドレスが To: ヘッダーに置かれます。
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 マッピング (存在する場合) のいずれかに対して照合し、必要に応じて変更するように指示するものです。また、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 キーワードは、メッセージの宛先になっているエンベロープ受取人アドレスが 1 つだけの場合は、そのエンベロープの 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 Administration Reference』の MTA の章を参照してください。
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 のヘッダー行は次のようになります。
デフォルトの 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 の積を、* MAX_HEADER_BLOCK_USE ヘッダーのサイズ (ヘッダーサイズは、実際のヘッダーサイズと maxblocks より小さいものとみなされる) としてとります。
たとえば、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 バイト以下になります。エンコーディングが行われた元のメッセージは、適切なデコーディングのフィルタを通すことによって元の状態に戻すことができます。
linelength キーワードでは、データのエンコードに、転送用にソフト改行を実行するこのエンコーディングは、通常受信側でデコードされるため、元の長い行が復元されます。ハード改行については、「Record, text」CHARSET-CONVERSION を参照してください。
メッセージのサイズ制限、ユーザー制限容量、権限この節では、メッセージのサイズ制限、ユーザー制限容量、権限を設定するキーワードについて説明します。この章には、以下の節があります。
絶対的なメッセージサイズ制限を指定する
キーワード : 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 オプションを使用して変更することができます。
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 ... rest of keywords ... alternatechannel tcp_big alternateblocklimit 5
tcp-daemon
tcp_big smtp ...rest of keywords...
tcp-big-daemon次に、alternate* チャネルキーワードの使用例を示します。
特に、TCP/IP チャネルのタイムアウト値を設定すると、大きなメッセージや受取人の多いメッセージを受信するのに非常に長い時間を要するリモートホストにメッセージを送信する場合に役立ちます。
ただし、ほとんどの構成にはデフォルトの自動のタイムアウト調整で十分です。デフォルト値を調整することはあっても、特別なチャネルを使用する必要はありません。詳細については、『Messaging Server Reference Manual』で STATUS_DATA_RECV_PER_ADDR_TIME および STATUS_DATA_RECV_PER_BLOCK_TIME の各チャネルオプションを参照してください。
制限容量超過ユーザーへのメール配信を処理する
キーワード : holdexquota、noexquota
noexquota および holdexquota キーワードは、Berkeley メールボックスユーザー (UNIX) 宛のメッセージの処理を制御します。ここでいうメッセージとは、ディスク制限容量を超過しているユーザーがローカルチャネルのユーザー ID に配信したメッセージです。
noexquota は MTA に、制限容量を超過したユーザー宛のメッセージを、差出人に返送するように指示します。holdexquota は MTA に、制限容量超過ユーザー宛のメッセージを保留にするように指示します。これらのメッセージは、配信可能になるまで、またはタイムアウトになってメッセージ返送ジョブによって返送されるまで、MTA キュー内に保持されます。
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 つずつ作成するように指定します。single_sys キーワードは、各宛先システム用にメッセージのコピーを 1 つずつ作成します。multiple キーワードは、デフォルトではチャネル全体のメッセージのコピーを 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
ログ記録とデバッグを設定するこの節では、ログ記録とデバッグのキーワードについて説明します。
ログ記録のキーワード
キーワード : logging、nologging
MTA は、メッセージがキューに出し入れされるたびにログを作成することができます。logging および nologging キーワードは、チャネルごとのメッセージログの作成を制御します。デフォルト設定では、すべてのチャネルに対してログが作成されます。特定のチャネルに対してログの作成を無効にするには、チャネル定義で logging の代わりに nologging キーワードを設定します。
ログ記録については、第 20 章「ログ記録とログ解析」を参照してください。
デバッグのキーワード
キーワード : 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 が 1 チャネルに対して有効になっている場合は、ユーザーが MTA デバッグ情報を含む imta_sendmail.log-uniqueid ファイルを、現在のディレクトリに受信できます (ディレクトリに書き込み権がある場合。書き込み権がない場合はデバッグにより stdout に出力)。
Loopcheck を設定する
キーワード : loopcheck、noloopcheck
loopcheck キーワードは、MTA が MTA 自身と通信しているかどうかを確認するために、SMTP EHLO 応答見出しに文字列を入れます。loopcheck が設定されている場合、SMTP サーバーでは XLOOP 拡張がアドバタイズされます。
XLOOP をサポートする SMTP サーバーと通信する場合、MTA の SMTP クライアントにより、通知された文字列と MTA の値が比較され、クライアントが SMTP サーバーと通信している場合は、メッセージがただちに返送されます。
その他のキーワードこの節では、その他のキーワードを説明します。この章には、以下の節があります。
チャネル動作のタイプ
キーワード : submitsubmit
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 チャネルに対してのみサポートされており、fileinto メールボックスフィルタ演算子が適用された場合、アドレスをどのように変更するかを指定します。ims-ms チャネルの場合、通常の使用方法は以下のとおりです。
fileinto $U+$S@$D
上の例では、最初のサブアドレスの代わりに、フォルダ名をサブアドレスとして元のアドレスに挿入するように指定しています。