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


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

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

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

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

• SMTP チャネルを設定する

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

• アドレス処理を設定する

• ヘッダー処理を設定する

• 添付と MIME 処理

• メッセージのサイズ制限、ユーザ制限容量、権限

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

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

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

• その他のキーワード

---

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

---

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

---

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

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

キーワード	ページ	キーワード	ページ	キーワード	ページ	キーワード	ページ
733	246	822	246	addreturnpath	253	addrsperfile	268
aliaslocal	256	aliaspostmaster	159	allowetrn	220	allowswitchchannel	232
authrewrite	234	backoff	239	bangoverpercent	248	bangstyle	246
bidirectional	238	blocketrn	220	blocklimit	267	cacheeverything	228
cachefailures	228	cachesuccesses	228	channelfilter	272	charset7	223
charset8	223	charsetesc	223	checkehlo	219	commentinc	254
commentmap	254	commentomit	254	commentstrip	254	commenttotal	254
connectalias	249	connectcanonical	249	copysendpost	157	copywarnpost	158
daemon	232	datefour	261	datetwo	261	dayofweek	261
defaulthost	250	defaultmx	230	defaultnameservers	231	deferred	238
defragment	264	dequeue_removeroute	257	destinationfilter	272	disableetrn	220
domainetrn	220	domainvrfy	221	dropblank	252	ehlo	219
eightbit	223	eightnegotiate	223	eightstrict	223	errsendpost	157
errwarnpost	158	expandchannel	244	expandlimit	244	exproute	248
fileinto	272	filesperjob	241	filter	272	forwardcheckdelete	229
forwardchecknone	229	forwardchecktag	229	header_733	246	header_822	246
header_uucp	246	headerlabelalign	262	headerlinelength	262	headerread	259
headertrim	259	holdexquota	268	holdlimit	244	identnone	229
identnonelimited	229	identnonenumeric	229	identnonesymbolic	229	identtcp	229
identtcplimited	229	identtcpsymbolic	229	ignoreencoding	264	immnonurgent
improute	248	includefinal	157	indenttcpnumeric	229	inner	259
innertrim	259	interfaceaddress	228	interpretencoding	264	language	263
lastresort	231	linelength	266	linelimit	267	localvrfy	221
logging	270	loopcheck	271	mailfromdnsverify	222	master	238
master_debug	270	maxblocks	265	maxheaderaddrs	262	maxheaderchars	262
maxjobs	241	maxlines	265	maxprocchars	262	maysaslserver	233
maytls	235	maytlsclient	235	maytlsserver	235	missingrecipientpolicy	251
msexchange	234	multiple	268	mustsaslserver	233	musttls	235
musttlsclient	235	musttlsserver	235	mx	230	nameservers	231
noaddreturnpath	253	nobangoverpercent	248	noblocklimit	267	nocache	228
nochannelfilter	272	nodayofweek	261	nodefaulthost	250	nodeferred	238
nodefragment	264	nodestinationfilter	272	nodropblank	252	noehlo	219
noexproute	248	noexquota	268	nofileinto	272	nofilter	272
noheaderread	259	noheadertrim	259	noimproute	248	noinner	259
noinnertrim	259	nolinelimit	267	nologging	270	noloopcheck	271
nomailfromdnsverify	222	nomaster_debug	270	nomsexchange	234	nomx	230
nonrandomemx	230	nonurgentbackoff	239	nonurgentblocklimit	243	nonurgentnotices	156
noreceivedfor	253	noreceivedfrom	253	noremotehost	250	norestricted	252
noreturnaddress	159	noreturnpersonal	159	noreverse	252	normalbackoff	239
normalblocklimit	243	normalnotices	156	norules	257	nosasl	233
nosaslserver	233	nosaslswitchchannel	233	nosendetrn	220	nosendpost	157
noservice	245	noslave_debug	270	nosmtp	219	nosourcefilter	272
noswitchchannel	232	notices	156	notls	235	notlsclient	235
notlsserver	235	novrfy	221	nowarnpost	158	nox_env_to	260
percentonly	248	percents	246	personalinc	255	personalmap	255
personalomit	255	personalstrip	255	pool	240	port	228
postheadbody	159	postheadonly	159	randommx	230	receivedfor	253
receivedfrom	253	remotehost	250	restricted	252	returnaddress	159
returnenvelope	158	returnpersonal	159	reverse	252	routelocal	249
rules	257	rules	257	saslswitchchannel	233	sendetrn	220
sendpost	157	sensitivitycompanyconfidential	263	sensitivitynormal	263	sensitivitypersonal	263
sensitivityprivate	263	service	245	sevenbit	223	silentetrn	220
single	268	single_sys	232	slave	238	slave_debug	270
smtp	219	smtp_cr	219	smtp_crlf	219	smtp_crorlf	219
smtp_lf	219	sourceblocklimit	267	sourcecommentinc	254	sourcecommentmap	254
sourcecommentomit	254	sourcecommentstrip	254	sourcecommenttotal	254	sourcefilter	272
sourcepersonalinc	255	sourcepersonalmap	255	sourcepersonalomit	255	sourcepersonalstrip	255
sourceroute	246	streaming	224	subaddressexact	256	subaddressrelaxed	256
subaddresswild	256	subdirs	269	submit	271	suppressfinal	157
switchchannel	232	threaddepth	243	tlsswitchchannel	235	unrestricted	252
urgentbackoff	239	urgentblocklimit	243	urgentnotices	156	useintermediate	157
user	271	uucp	246	viaaliasoptional	258	viaaliasrequired	258
vrfyallow	221	vrfydefault	221	vrfyhide	221	warnpost	158
x_env_to	260

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

---

次の表に分類したキーワードの一覧を示します。

表 8-2    機能別チャネルキーワード (太字はデフォルト) 

キーワード	ページ	定義
アドレス処理
733	246	エンベロープで % ルーティングを使用する。percents と同義
822	246	エンベロープでソースルートを使用する。sourceroute と同義
addreturnpath	253	このチャネルにキューを入れる際に、メッセージに Return-Path: ヘッダーを追加する
aliaslocal	256	書き換えられたアドレスをエイリアスファイルとエイリアスデータベースで検索する
authrewrite	234	認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用する
bangoverpercent	248	A!B%C を A!(B%C) としてグループ化する
bangstyle	246	エンベロープで UUCP! ルーティングを使用する。uucp と同義
defaulthost	250	アドレスを完成させるためにドメイン名を指定する
dequeue_removeroute	257	エンベロープの To: アドレスからソースルートを削除する
exproute	248	アドレスをリモートシステムに渡す際に明示的なルーティングを要求する
holdlimit	244	エンベロープ受取人アドレス数がこの制限を越えた場合、メッセージを保留する
improute	248	このチャネルのアドレスに対して黙示的なルーティングを実行する
missingrecipientpolicy	251	受取人ヘッダーがないメッセージを有効にする (どのヘッダーに追加するか指定する) ポリシーを設定する
noaddreturnpath	253	メッセージをキューに入れる際に Return-Path: ヘッダーを追加しない
nobangoverpercent	248	A!B%C を (A!B)%C としてグループ化する
nodefaulthost	250	アドレスを完成させるために使用する、ドメイン名を指定しない
noexproute	248	このチャネルのアドレスに対して明示的なルーティングを実行しない
noimproute	248	このチャネルのアドレスに対して黙示的なルーティングを実行しない
noreceivedfrom	253	元のエンベロープの From: アドレスを含めずに Received: ヘッダー行を作成する
noremotehost	250	アドレスを完成させるために、ローカルホストのドメイン名をデフォルトのドメイン名として使用する
norestricted	252	unsrestricted と同じ
noreverse	252	メッセージのアドレスを、アドレスリバース処理から外すことを指定する
norules	257	このチャネル固有の書き換え規則を確認しない
percentonly	248	bang パスを無視する。エンベロープで % ルーティングを使用する
percents	246	エンベロープで % ルーティングを使用する。733 と同義
remotehost	250	アドレスを完成させるために、リモートホストの名前をデフォルトのドメイン名として使用する
restricted	252	チャネルは、エンコーディングを必要とするメールシステムに接続する
reverse	252	アドレスリバースデータベースまたは REVERSE マッピングのアドレスを確認
routelocal	249	アドレスをチャネルに書き換える際に、MTA にアドレスのすべての明示的ルーティングを短絡化しようとする
rules	257	このチャネル固有の書き換え規則を確認する
sourceroute	246	822 と同義
subaddressexact	256	エントリの一致の確認中に特別なサブアドレスの処理を行わない。エイリアスが一致するとみなされるためには、サブアドレスを含むメールボックス全体が一致する必要がある
subaddressrelaxed	256	完全一致と「名前+*」の形式一致を検索したあと、MTA で名前の部分のみの一致を検索する
subaddresswild	256	サブアドレス全体を含む完全一致を検索したあと、MTA で「名前+*」の形式のエントリを検索する
unrestricted	252	RFC 1137 エンコーディングとデコーディングを実行するように MTA に指示する
uucp	246	エンベロープで UUCP! ルーティングを使用する。bangstyle と同義
viaaliasoptional	258	チャネルに一致する最終受取人のアドレスを、エイリアスで作成する必要がない
viaaliasrequired	258	チャネルに一致する最終受取人アドレスを、エイリアスで作成する必要がある
添付と MIME 処理
defragment	264	このチャネルのキューに入っている部分メッセージは、デフラグメンテーションチャネルのキューに移動する
ignoreencoding	264	受信メッセージの Encoding: ヘッダーを無視する
interpretencoding	264	受信メッセージの Encoding: ヘッダーを必要に応じて解釈する
nodefragment	264	デフラグメンテーションを無効にする
文字セットと 8 ビットデータ
charset7	223	7 ビットのテキストメッセージに関連付けるデフォルトの文字セット
charset8	223	8 ビットのテキストメッセージに関連付けるデフォルトの文字セット
charsetesc	223	エスケープ文字を含む 7 ビットのテキストに関連付けるデフォルトの文字セット
eightbit	223	チャネルが 8 ビット文字をサポートする
eightnegotiate	223	チャネルが 8 ビット転送の使用をネゴシエートする (可能な場合)
eightstrict	223	ネゴシエーションが行われていない 8 ビットデータを含むメッセージを拒否する
sevenbit	223	8 ビット文字をサポートしない。8 ビット文字はエンコードされなければならない
MTA キュー領域でのファイル作成
addrsperfile	268	チャネルのキューにある 1 つのメッセージファイルに関連付けられる受取人の最大数を制限する
expandchannel	244	expandlimit の適用による遅延拡張を実行するチャネルを指定する
expandlimit	244	アドレスの数がこの制限を超えた場合、受信メッセージを「オフライン」で処理する
multiple	268	メッセージファイル内の受取人数を制限しない。ただし SMTP チャネルのデフォルトは 99 である
single	268	チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成される
single_sys	268	各宛先システム用にメッセージのコピーを 1 つずつ作成する
subdirs	269	チャネルキューのメッセージを拡散するサブディレクトリの数を指定する
ヘッダー
authrewrite	234	認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用する
commentinc	254	メッセージのヘッダー行内のコメントをそのままにする
commentmap	254	COMMENT_STRINGS マッピングテーブルを通じて、メッセージヘッダー行でコメント文字列を実行する
commentomit	254	メッセージのヘッダー行内のコメントを削除する
commentstrip	254	メッセージのヘッダー行内にある問題を起こす文字を削除する
commenttotal	254	Received: ヘッダー行以外のすべてのヘッダー行から ( ) に入っているコメントを削除する。ただし、推奨しない
datefour	261	すべての年表示フィールドを 4 桁に展開する
datetwo	261	4 桁の日付表示から先頭の 2 桁を削除する。2 桁の日付表示を要求するメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないこと
dayofweek	261	曜日情報を残し、曜日情報がない場合にはその情報を日付 / 時刻ヘッダーに追加する
defaulthost	250	アドレスを完成させるためにドメイン名を指定する
dropblank	252	受信メッセージから不正な空白ヘッダーを削除する
header_733	246	メッセージヘッダーで % ルーティングを使用する
header_822	246	メッセージヘッダーでソースルートを使用する
headerlabelalign	262	このチャネルのキューに入れられたメッセージヘッダーの配置ポイントを制御する。整数値の引数をとる
headerlinelength	262	このチャネルのキューに入れられたヘッダー行の長さを制御する
headerread	259	メッセージがキューに入れられたときに、元のメッセージヘッダーが作成される前にオプションファイルからそのメッセージのヘッダーにトリミングの規則を適用する (注意して使用すること)
headertrim	259	元のメッセージヘッダーが作成されたあとで、オプションファイルからそのメッセージのヘッダーにトリミングの規則を適用する
header_uucp	246	ヘッダーで ! ルーティングを使用する
inner	259	メッセージを解析して、内部ヘッダーを書き換える
innertrim	259	内部のメッセージヘッダーに、オプションファイルからのヘッダートリミング規則を適用する (注意して使用すること)
language	263	ヘッダーにデフォルトの言語を指定する
maxheaderaddrs	262	1 行に表示できるアドレスの数を指定する
maxheaderchars	262	1 行に表示できる文字数を指定する
missingrecipientpolicy	251	受取人ヘッダーがないメッセージを有効にする (どのヘッダーに追加するか指定する) ポリシーを設定する
nodayofweek	261	日付 / 時刻ヘッダーから曜日情報を削除する。この情報が処理できないメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないこと
nodefaulthost	250	アドレスを完成させるために使用する、ドメイン名を指定しない
nodropblank	252	受信メッセージから不正な空白ヘッダーを削除しない
noheaderread	259	オプションファイルからのヘッダートリミング規則を適用しない
noheadertrim	259	オプションファイルからのヘッダートリミング規則を適用しない
noinner	259	内部のメッセージヘッダー行を書き換えない
noinnertrim	259	内部のメッセージヘッダーにヘッダートリミング規則を適用しない
noreceivedfor	253	エンベロープ受取人情報を含めずに Received: ヘッダー行を作成する
noreceivedfrom	253	元のエンベロープの From: アドレスを含めずに Received: ヘッダー行を作成する
noremotehost	250	アドレスを完成させるために、ローカルホストのドメイン名をデフォルトのドメイン名として使用する
noreverse	252	チャネルのキューに入れられたメッセージのアドレスを、アドレスリバース処理から外す
norules	257	このチャネル固有の書き換え規則を確認しない
nox_env_to	260	X-Envelope-to ヘッダー行を削除する
personalinc	255	メッセージのヘッダー行にある個人名のフィールドをそのままにする
personalmap	255	PERSONAL_NAMES マッピングテーブルを通じて、個人名を実行する
personalomit	255	メッセージのヘッダー行にある個人名のフィールドを削除する
personalstrip	255	ヘッダー行にある個人名のフィールドから問題になる文字を削除する
receivedfor	253	メッセージの宛先になっているエンベロープ受取人アドレスが 1 つだけの場合は、そのエンベロープの To: アドレスを Received: ヘッダー行に含める
receivedfrom	253	MTA がエンベロープの From: アドレスを変更する場合は、受信メッセージの Received: ヘッダー行を作成するときに元のエンベロープの From: アドレスを含める
remotehost	250	アドレスを完成させるために、リモートホストの名前をデフォルトのドメイン名として使用する
restricted	252	チャネルは、このエンコーディングを必要とするメールシステムに接続する
reverse	252	アドレスリバースデータベースまたは REVERSE マッピングのアドレスを確認
rules	257	このチャネル固有の書き換え規則を確認する
sensitivitycompanyconfidential	263	Companyconfidential が、受け付けるメッセージの重要度の上限である
sensitivitynormal	263	Normal が、受け付けるメッセージの重要度の上限である
sensitivitypersonal	263	Personal が、受け付けるメッセージの重要度の上限である
sensitivityprivate	263	Private が、受け付けるメッセージの重要度の上限である
sourcecommentinc	254	受信メッセージのヘッダー行にコメントを残す
sourcecommentmap	254	ソースチャネルを通じて、ヘッダー行のコメント文字列を実行する
sourcecommentomit	254	受信メッセージの To:、From:、Cc: などのヘッダー行からコメントを削除する
sourcecommentstrip	254	受信メッセージのヘッダー行内にある問題を起こす文字を削除する
sourcecommenttotal	254	受信メッセージから、( ) 内に入っているコメントを削除する
sourcepersonalinc	255	メッセージのヘッダー行にある個人名のフィールドをそのままにする
sourcepersonalmap	255	ソースチャネルを通じて個人名を実行する
sourcepersonalomit	255	メッセージのヘッダー行にある個人名のフィールドを削除する
sourcepersonalstrip	255	メッセージのヘッダー行にある個人名のフィールドから、問題になる文字を削除する
unrestricted	252	RFC 1137 エンコーディングとデコーディングを実行するように MTA に指示する
x_env_to	260	X-Envelope-to ヘッダー行の生成を有効にする
受信チャネルの一致と切り替え
allowswitchchannel	232	switchchannel チャネルからこのチャネルへの切り替えを許可する
nosaslswitchchannel	233	SASL 認証に成功した場合、このチャネルへの切り替えは許可されない
noswitchchannel	232	チャネルへの切り替えを行わない
switchchannel	232	サーバチャネルから送信元のホストに関連付けられたチャネルに切り替える
saslswitchchannel	233	クライアントが SASL の使用に成功した場合、受信接続が指定のチャネルに切り替えられる
tlsswitchchannel	235	TLS のネゴシエートが成功した場合に、ほかのチャネルに切り替える
ログ記録とデバッグ
logging	270	キューに対するメッセージの出入りがログに記録され、特定チャネルのログ機能を有効にする
loopcheck	271	MTA が MTA 自体と通信しているかどうかを確認するために、SMTP EHLO 応答見出しに文字列を配置する
master_debug	270	チャネルのマスタープログラム出力内にデバッグ出力を作成する
nologging	270	キューに対するメッセージの出入りをログに記録しない
noloopcheck	271	SMTP EHLO 応答見出しに文字列がない
nomaster_debug	270	チャネルのマスタープログラム出力内にデバッグ出力を行わない
noslave_debug	270	スレーブのデバッグ出力を生成しない
slave_debug	270	スレーブのデバッグ出力を生成する
長いアドレスリストやヘッダー
expandchannel	244	expandlimit の適用による遅延拡張を実行するチャネルを指定する
expandlimit	244	アドレスの数がこの制限を超えた場合、受信メッセージを「オフライン」で処理する
holdlimit	244	アドレスの数がこの制限を越えた場合、メッセージを保留する
maxprocchars	262	処理や書き換えができるヘッダーの最大長
メールボックスフィルタ
channelfilter	272	チャネルフィルタファイルの場所。destinationfilter と同じ
destinationfilter	272	送信するメッセージに提供されるチャネルフィルタの場所
fileinto	272	メールボックスフィルタ fileinto の操作が適用されたときの、アドレスに対する効果を指定する
filter	272	ユーザフィルタファイルの場所を指定する
nochannelfilter	272	送信メッセージに対するチャネルフィルタリングを行わない。nodestinationfilter とも呼ばれる
nodestinationfilter	272	送信メッセージに対するチャネルフィルタリングを実行しない
nofileinto	272	メールボックスフィルタ fileinto の演算子が効果を発揮しない
nofilter	272	ユーザメールボックスのフィルタリングを実行しない
nosourcefilter	272	受信メッセージに対してチャネルフィルタリングを実行しない
sourcefilter	272	受信メッセージ用のチャネルフィルタの場所を指定する
通知メッセージとポストマスターメッセージ (完全な通知手順については 150 ページを参照)
aliaspostmaster	159	正式なチャネル名でのユーザ名がポストマスターのメッセージは postmaster@ローカルホストにリダイレクトされる。ローカルホストには、ローカルホスト名 (ローカルチャネルの名前) が入る
copysendpost	157	メッセージの差出人アドレスが空白になっている場合を除き、配信不能メッセージのコピーがポストマスターに送信される
copywarnpost	158	配信不能メッセージの差出人アドレスが空白になっている場合を除き、警告メッセージのコピーがポストマスターに送信される
errsendpost	157	通知を差出人に返すことができない場合に、配信不能通知のコピーをポストマスターに送信する
errwarnpost	158	通知を差出人に返すことができない場合に、警告メッセージのコピーをポストマスターに送信する
includefinal	157	配信通知の中に受取人アドレスの最終的な形式を含める
nonurgentnotices	156	優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する
noreturnaddress	159	ポストマスターアドレス名に RETURN_ADDRESS オプション値を使用する
noreturnpersonal	159	ポストマスター個人名に RETURN_PERSONAL オプション値を使用する
normalnotices	156	優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する
nosendpost	157	配信不能メッセージのコピーをポストマスターには一切送信しない
notices	156	通知を送り、メッセージを返すまでの時間を指定する
nowarnpost	158	警告メッセージのコピーをポストマスターには一切送信しない
postheadbody	159	ヘッダーとメッセージの内容の両方を返送する
postheadonly	159	ポストマスターにヘッダーだけを返送する
returnaddress	159	ローカルポストマスターの返信アドレスを設定する
returnenvelope	158	空白のエンベロープ返信アドレスの使用を制御する
returnpersonal	159	ローカルのポストマスターに対する個人名を設定する
sendpost	157	配信不能メッセージのコピーをすべてポストマスターに送信する
suppressfinal	157	元の形式のアドレスが存在する場合は、通知メッセージに最終形式のアドレスを含めない
urgentnotices	156	優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する
useintermediate	157	リストのエクスパンド後、ユーザメールボックス名の設定前に作成された中間形式のアドレスを使用する
warnpost	158	警告メッセージのコピーをすべてポストマスターに送信する。
処理制御とジョブ送信 (より大きい機能単位については 表 8-7 を参照)
backoff	239	配信不能メッセージを再配信する回数。normalbackoff、nonurgentbackoff、urgentbackoff キーワードで置き換え可能
bidirectional	238	マスターとスレーブの両方のプログラムによって処理されるチャネル
deferred	238	Deferred-delivery: ヘッダー行を認識および処理する
expandchannel	244	expandlimit の適用による遅延拡張を実行するチャネルを指定する
expandlimit	244	アドレスの数がこの制限を超えた場合、受信メッセージを「オフライン」で処理する
filesperjob	241	1 つのジョブで処理できるキューエントリの数
immnonurgent		優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始する
master	238	マスタープログラムによって処理されるチャネル (master)
maxjobs	241	1 つのチャネルに対して同時実行できるジョブの最大数
nodeferred	238	Deferred-delivery: ヘッダー行が許可されないように指定する
nonurgentbackoff	239	優先度が低いメッセージの配信試行頻度
nonurgentblocklimit	243	指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定する。該当するメッセージは次の定期ジョブまで処理されない
normalbackoff	239	優先度が標準であるメッセージの配信試行頻度
normalblocklimit	243	指定値以上のサイズを持つメッセージの優先度を「低」に設定する
noservice	245	このチャネルで受信するメッセージのサービス変換は CHARSET-CONVERSION を使用して有効にする
pool	240	チャネル用のプールを指定する。この後ろに、現在のチャネルの配信ジョブのプール先となるプール名を指定する
service	245	CHARSET-CONVERSION エントリにかかわらず、無条件でサービスを有効にする
slave	238	マスタープログラムによって処理されるチャネル (slave)
threaddepth	243	マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数
urgentbackoff	239	優先度が高いメッセージの配信試行頻度
urgentblocklimit	243	指定値以上のサイズを持つメッセージの優先度を「標準」に設定する
user	271	pipe チャネルでどのユーザ名で実行するかを示すのに使用される
重要度の上限
sensitivitycompanyconfidential	263	受け付けるメッセージの重要度の上限
sensitivitynormal	263	Normal が、受け付けるメッセージの重要度の上限である
sensitivitypersonal	263	Personal が、受け付けるメッセージの重要度の上限である
sensitivityprivate	263	Private が、受け付けるメッセージの重要度の上限である
メッセージのサイズ制限、ユーザ制限容量、権限
blocklimit	267	メッセージ当たりの許可されている MTA ブロックの最大数
holdexquota	268	制限容量を超過したユーザに対するメッセージを保留する
holdlimit	244	アドレスの数がこの制限を越えた場合、受信メッセージを保留する
linelength	266	チャネルごとに許される最大のメッセージ行の長さを制限する
linelimit	267	1 つのメッセージに対して許可される最大行数
maxblocks	265	1 つのメッセージに許可するブロックの最大数を指定する
maxlines	265	1 つのメッセージに許可する最大行数を指定する
noblocklimit	267	メッセージ当たりに許可される MTA ブロックの数に制限はない
noexquota	268	制限容量を超過したユーザに対し、すべてのメッセージを差出人に送り返す
nolinelimit	267	メッセージ当たりに許可される行数に制限はない
nonurgentblocklimit	243	指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定する。該当するメッセージは次の定期ジョブまで処理されない
normalblocklimit	243	指定値以上のサイズを持つメッセージの優先度を「低」に設定する
sourceblocklimit	267	メッセージ当たりの許可されている MTA ブロックの最大数
urgentblocklimit	243	指定値以上のサイズを持つメッセージの優先度を「標準」に設定する
SMTP 認証、SASL および TLS (より大きい機能単位については 233 を参照)
authrewrite	234	認証された差出人の情報がある場合は MTA がヘッダーに含めるようにするために、ソースチャネルで使用する
maysaslserver	233	クライアントが SASL 認証を使用することを許可する
maytls	235	MTA は TLS 使用の接続を受け入れ、送信接続にも TLS を使用しようと試みる
maytlsclient	235	MTA SMTP クライアントは TLS をサポートする SMTP サーバにメッセージを送信する際に TLS を使用する
maytlsserver	235	MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用することを許可する
msexchange	234	TCP/IP チャネルで使用して、MTA にこれが MS Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示する
mustsaslserver	233	SMTP サーバは、リモートクライアントが認証に成功しないかぎり、メッセージを受け付けない
musttls	235	MTA は送受信接続に必ず TLS を使用する
musttlsclient	235	MTA SMTP クライアントは、メッセージの送信に必ず TLS を使用する (MTA は STARTTLS コマンドを発行し、このコマンドは必ず成功する必要がある)
musttlsserver	235	MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用する
nomsexchange	234	デフォルト
nosasl	233	SASL 認証は許可されない。試行もされない
nosaslserver	233	SASL 認証は許可されない
notls	235	TLS 認証は許可されない。試行もされない
notlsclient	235	送信接続時に MTA SMTP クライアントは TLS を使用することがない (送信接続時に STARTTLS コマンドが発行されない)
notlsserver	235	受信接続時に MTA SMTP サーバは TLS の使用を許可しない (SMTP サーバもコマンド自体も STARTTLS 拡張に通知しない)
saslswitchchannel	233	クライアントが SASL の使用に成功した場合、受信接続が指定のチャネルに切り替えられる
tlsswitchchannel	235	クライアントが TLS ネゴシエーションに成功した場合、受信接続が指定のチャネルに切り替えられる。このキーワードには、切り替え先のチャネルを指定する必要がある
SMTP コマンドとプロトコル (より大きい機能単位については 表 8-4 を参照)
allowetrn	220	ETRN コマンドを処理する
blocketrn	220	ETRN コマンドをブロックする
checkehlo	219	SMTP 応答の見出しを確認して、EHLO とHELO のどちらを使用するか決定する
disableetrn	220	ETRN SMTP コマンドのサポートを無効にする
domainetrn	220	ドメインを指定する ETRN コマンドだけを処理する
domainvrfy	221	完全なアドレスを使用して VRFY コマンドを発行する
ehlo	219	初期接続に SMTP EHLO コマンドを使用する
eightbit	223	チャネルが 8 ビット文字をサポートする
eightnegotiate	223	チャネルが 8 ビット転送の使用をネゴシエートする (可能な場合)
eightstrict	223	ネゴシエーションが行われていない 8 ビットデータを含むメッセージを拒否する
localvrfy	221	ローカルアドレスを使用して VRFY コマンドを発行する
mailfromdnsverify	222	MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認する
noehlo	219	EHLO コマンドを使用しない
nomailfromdnsverify	222	MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認しない
nosendetrn	220	ETRN コマンドを発行しない
nosmtp	219	SMTP プロトコルをサポートしない。デフォルトでは、このキーワードが使用される
novrfy	221	VRFY コマンドを発行しない
sendetrn	220	ETRN コマンドを発行する
sevenbit	223	8 ビット文字をサポートしない。8 ビット文字はエンコードされなければならない
silentetrn	220	チャネル情報をエコーせずに ETRN コマンドを処理する
smtp	219	SMTP プロトコルをサポートする。smtp キーワードはすべての SMTP チャネルで必須(このキーワードは smtp_crorlf と同等)
smtp_cr	219	ラインフィーダ (LF) なしの、キャリッジリターン (CR) のみが改行記号として受け入れられる
smtp_crlf	219	キャリッジリターン (CR) + ラインフィーダ (LF) のシーケンスのみがで改行記号として認識される
smtp_crorlf	219	キャリッジリターン (CR) 、ラインフィーダ (LF) のシーケンス、または完全な CRLF が改行記号として使用可能である
smtp_lf	219	キャリッジリターン (CR) なしの、ラインフィーダ (LF) のみを使用できる
streaming	224	チャネルに関連付けられたプロトコルのストリーミングの程度を制御する
vrfyallow	221	VRFY コマンドに対して詳細な情報を提供する応答を出す
vrfydefault	221	チャネルの HIDE_VERIFY オプションの設定に従い、VRFY コマンドに対してデフォルトの応答を提供する
vrfyhide	221	SMTP VRFY コマンドに対してあいまいな応答を出す
TCP/IP 接続および DNS 検索サポート (より大きい機能単位については 表 8-5 を参照)
cacheeverything	228	すべての接続情報をキャッシュする
cachefailures	228	接続失敗に関する情報だけをキャッシュする
cachesuccesses	228	接続成功に関する情報だけをキャッシュする
connectalias	249	受取人のアドレスに書かれているホストに配信する
connectcanonical	249	MTA が接続するシステムのホストエイリアスに接続する
daemon	232	エンベロープアドレスにかかわらず特定のホストシステムに接続する
defaultmx	230	チャネルが、ネットワークから MX 検索を実行するかどうかを決定する
defaultnameservers	231	TCP/IP スタックが選択したネームサーバを照合する
forwardcheckdelete	229	リバース DNS 検索のあとに正引き検索を行い、リバース DNS 検索で返された名前の正引き検索がオリジナルの接続の IP 番号に一致するかどうかを確認する。一致しない場合、リバース DNS 検索で返された名前は削除され、IP アドレスが使用される
forwardchecknone	229	DNS リバース検索のあとに正引き検索を実行しない
forwardchecktag	229	リバース DNS 検索が実行して返された名前を正引き検索して、IP 番号がオリジナルの接続の IP 番号に一致するかどうかを確認する。一致しなければ名前に「*」を付ける
identnone	229	IDENT 検索を実行しない。IP からホスト名への変換を実行し、Received: ヘッダーにホスト名と IP アドレスを含める
identnonelimited	229	IDENT 検索を実行しない。IP からホスト名への変換を実行し (ただしチャネルの切り替えを行う際にはホスト名を使用しない)、Received: ヘッダーにホスト名と IP アドレスの両方を含める
identnonenumeric	229	IDENT 検索および IP からホスト名への変換を実行しない
identnonesymbolic	229	IDENT 検索を実行しない。IP からホスト名への変換を実行し、Received: ヘッダーにホスト名だけを含める
identtcp	229	受信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行し、Received: ヘッダーにホスト名と IP アドレスの両方を含める
identtcplimited	229	受信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行する。チャネルの切り替えを行う際にはホスト名を使用しない。Received: ヘッダーにホスト名と IP アドレスを含める
indenttcpnumeric	229	受信 SMTP 接続で IDENT 検索を実行する。IP からホスト名への変換を実行しない
identtcpsymbolic	229	受信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行し、Received: ヘッダーにホスト名だけを含める
interfaceaddress	228	指定された TCP/IP インタフェースアドレスにバインドする
lastresort	231	最後のホストを指定する
mailfromdnsverify	222	MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認する
mx	230	TCP/IP ネットワークおよびソフトウェアが MX レコード検索をサポートする
nameservers	231	TCP/IP スタックが選択したネームサーバの代わりに照合するネームサーバのリストを指定する。nameservers には、空白文字で区切られたネームサーバの IP アドレスのリストが必要
nocache	228	接続情報をキャッシュしない
nomailfromdnsverify	222	MAIL FROM: コマンドに使用されているドメインが DNS に存在するかどうかを確認しない
nomx	230	TCP/IP ネットワークが MX 検索をサポートしない
nonrandomemx	230	MX 検索を実行するが、返されたエントリを同等の優先度でランダム化しない
port	228	SMTP 接続用のデフォルトポート番号を指定する。標準ポートは 25
randommx	230	MX 検索を実行し、返されたエントリを同等の優先度でランダム化する
single	232	チャネル上の各宛先アドレス用にメッセージのコピーが 1 つずつ作成されるように指定する
single_sys	232	各宛先システム用にメッセージのコピーを 1 つずつ作成する
threaddepth	243	マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数
その他
submit	271	チャネルを送信専用のチャネルに指定する
user	271	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 によって処理されます。

表 8-3    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 設定ディレクトリ (ServerRoot/msg-instance/imta/config) に保存し、x_option という名前を付けなければなりません。この「x」はチャネルの名前です。詳細については『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

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

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

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

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

• SMTP 認証、SASL、TLS

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

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

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

• Transport Layer Security

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

TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。ファイルには x_option という名前を付けてください。ファイル名の x はチャネル名となります。たとえば、/ServerInstance/imta/config/tcp_local_option のようになります。

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

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

• メッセージ当たりの宛先数を制限する (ALLOW_RECIPIENTS_PER_TRANSACTION)

• 接続当たりのメッセージ数を制限する (ALLOW_TRANSACTIONS_PER_SESSION)

• MTA ログファイルに記録される情報のタイプを微調整する (LOG_CONNECTION、LOG_TRANSPORTINFO)

• クライアントチャネルプログラムが許可できる同時送信接続の最大数を指定する (MAX_CLIENT_THREADS)

チャネルオプションキーワードとシンタックスの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

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

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

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

• EHLO コマンドのサポート

• ETRN コマンドのサポート

• VRFY コマンドのサポート

• DNS ドメイン確認

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

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

表 8-4 に、この節で説明されているキーワードのリストを示します。

表 8-4    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 コマンドに対してあいまいな応答を出す
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 を使用すると、CR のみのターミネータが受け入れられます。これらのオプションは、受信データにしか適用されません。

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

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 のローカルチャネルは次のようにラベル付けされます。

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 接続およびアドレス検索の処理方法を指定することができます。この項では、以下の内容について説明します。

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

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

• リバース DNS 検索

• IDENT 検索

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

• ネームサーバ検索

• 最後のホスト

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

• ターゲットホストの選択

表 8-5 に、この項で説明されている TCP/IP 接続および DNS 検索に関連するキーワードのリストを示します。

表 8-5    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 に指示します。

---

注	複数の 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: ヘッダーにユーザフレンドリーでないホスト名を使用するため、パフォーマンスの向上につながる可能性もあります。

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
233 ページの「saslswitchchannel」および 235 ページの「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 キーワードの後ろの引数が完全なドメイン名ではない場合、引数は無視され、チャネルは正規ホストに接続します。ファイヤウォールやゲートウェイシステムを正規ホスト名として指定する場合、以下の例に示すように 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 SecurityLayer) を使用した SMTP サーバの認証をサポートするかどうかを指定できます。SASL は RFC 2222 で定義されています。SASL、SMTP 認証、セキュリティの詳細については、第 12 章「セキュリティとアクセス制御を設定する」を参照してください。

maysaslserver、mustsaslserver、nosasl、nosaslserver, itchchannel、および 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 情報が使用されます。表 8-6 にあるように、authrewrite キーワードは必須の整数値をとります。

表 8-6    authrewrite の整数値 

値	使用目的
1	AUTH 差出人を含む Resent-from: や 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 を使用できる) を包括しています。

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

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

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

---

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

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

• 「指定配信日を実行する」

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

• 「チャネル実行ジョブのプールを処理する」

• 「サービスジョブの制限」

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

• 「SMTP チャネルスレッド」

• 「複数アドレスの拡張」

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

メッセージの処理と配信の詳細については、「ジョブコントローラ」および 「ジョブコントローラファイル」を参照してください。

表 8-7 に、この節で説明されているキーワードのリストを示します。

表 8-7    メッセージの処理と配信のキーワード 

キーワード	定義
即時配信	メッセージの即時配信に関する設定を定義
immnonurgent	優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始する
遅延配信	遅延ジョブの配信に関する設定を定義
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	アドレスの数がこの制限を越えた場合、受信メッセージを保留する
配信不能メッセージ通知	配信不能メッセージ通知を送るタイミングを指定
notices	通知を送り、メッセージを返すまでの時間を指定する
nonurgentnotices	優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する
normalnotices	優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する
urgentnotices	優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する

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

キーワード : 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 分後に 2 回目の再配信を、2 回目の再配信から 120 分後に 3 回目の再配信を試みます。最後に示した配信後は同じ間隔で再配信が試みられます。優先度が高いメッセージの場合では 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 に記述されており、『iPlanet Messaging Server リファレンスマニュアル』でも説明されています。

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

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 チャネルキーワード)

• 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 には、そのチャネルが使用するプールまたはサービスプールで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を使用します。

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

キーワード : 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 で有効にします。

アドレス処理を設定する

---

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

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

• 「アドレスのタイプと規則」

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

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

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

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

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

• 「Recipient ヘッダー行がないメッセージを有効にする」

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

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

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

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

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

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

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

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

• 「サブアドレスを処理する」

• 「チャネル固有の書き換え規則チェックを有効にする」

• 「ソースルートを削除する」

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

アドレスのタイプと規則

キーワード : 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 スタイルのエンベロープアドレス。このチャネルでは、エンベロープの RFC 976 の bang スタイルアドレス規則に準拠するアドレスが使用されます (たとえば、UUCP チャネル)。bangstyle キーワードは、uucp と同義で使用できます。

header_822

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

header_733

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

---

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

---

header_uucp

UUCP または bang スタイルのヘッダーアドレス。このキーワードの使用はお勧めしません。使用すると 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 にアドレスのすべての明示的ルーティングを短絡化しようとします。明示的にルーティングされたアドレス (!、%、または @ の文字を使用) は簡略化されています。

このキーワードを内部 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: アドレスが使用されます。

表 8-8    missingrecipientpolicy の値 

値	動作
0	To: ヘッダー行にエンベロープ To: 受取人を使用する
1	変更せずに無効なメッセージを通過させる
2	To: ヘッダー行にエンベロープ To: 受取人を使用する
3	単一の Bcc: ヘッダー行にすべてのエンベロープ To: 受取人を使用する
4	グループのコンストラクタ (たとえば ;) を To: ヘッダー行にし、To: 受取人は指定しない
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 マッピング (存在する場合) のいずれかに対して照合し、必要に応じて変更するように指示するものです。また、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: ヘッダー行を作成する際は MTA に元のエンベロープの From: アドレスを含めるように指示します。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: などのヘッダー) からすべてのコメントを削除するように指示します。commenttotal キーワードは、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 キーワードは、MTA に PERSONAL_NAMES マッピングテーブルを通じて個人名を実行するように示します。

ソースチャネルでは、この動作は 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 であり、そのチャネルに一致する最終受取人アドレスはエイリアスで作成する必要がありません。

ヘッダー処理を設定する

---

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

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

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

• 「X-Envelope-to: ヘッダー行の生成と削除」

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

• 「日付の曜日を指定する」

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

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

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

• 「機密度チェック」

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

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

キーワード : noinner、inner

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

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

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

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

MTA には、メッセージから特定のメッセージヘッダー行をトリミングする (取り除く)、チャネル単位の機能があります。これは、チャネルキーワードと関連する 1 つまたは 2 つのヘッダーオプションファイルの組み合わせによって行われます。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 という形式の名前があります。このチャネルには、ヘッダーオプションファイルが関連付けられているチャネルの名前が入ります。同じように、headerread キーワードのヘッダーオプションファイルには、channel_read_headers.opt の形式で名前があります。これらのファイルは MTA の設定ディレクトリ (server_root/msg-instance/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: ヘッダー行を無視する」

• 「メッセージあるいは部分メッセージの自動再組立」

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

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

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 です。

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

キーワード : 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 バイト以下になります。エンコーディングが行われた元のメッセージは、適切なデコーディングのフィルタを通すことによって元の状態に戻すことができます。

---

注	エンコーディングは、行長を 80 バイトより短くするだけです。行長に 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 は、この数以上の行を含むメッセージがチャネルのキューに入れられるのを拒否します。これらの 2 つのキーワード (blocklimit と linelimit) は、必要に応じて同時に指定することができます。

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

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

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

キーワード : 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 サーバの中には、1 度に処理できる受取人の数を制限し、このタイプのエラーを処理できないものもあります。

multiple、addrsperfile、single、および single_sys キーワードは、複数のアドレスを処理する方法を制御するために使用できます。single キーワードは、各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。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

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

---

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

• 「ログ記録のキーワード」

• 「デバッグのキーワード」

• 「Loopcheck を設定する」

ログ記録のキーワード

キーワード : logging、nologging

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

ログ記録については、第 13 章「ログ記録とログ解析」を参照してください。

デバッグのキーワード

キーワード : 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 サーバと通信している場合は、メッセージがただちに返送されます。

その他のキーワード

---

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

• 「チャネル動作のタイプ」

• 「pipe チャネル」

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

チャネル動作のタイプ

キーワード : 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

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