アドレス処理を設定する
この節ではアドレス処理を行うキーワードを説明します。この章には、次の節があります。
アドレスのタイプとルール
キーワード: 822、733、uucp、header_822、header_733、header_uucp
このキーワードのグループでは、チャネルでサポートするアドレスのタイプが制御されます。転送レイヤー (メッセージエンベロープ) に使われるアドレスとメッセージヘッダーに使われるアドレスとは区別されます。
822 (sourceroute)
ソースルートのエンベロープアドレス。このチャネルでは、ソースルートを含む、完全な RFC 822 形式のエンベロープアドレスルールがサポートされます。sourceroute キーワードは、822 と同義で使用できます。ほかのエンベロープアドレスタイプのキーワードが指定されていない場合、これがデフォルトになります。
733 (percents)
パーセント記号のエンベロープアドレス。このチャネルでは、ソースルートを除く、完全な RFC 822 形式のエンベロープアドレスがサポートされます。ソースルートは、パーセント記号のルールを使用して、書き換える必要があります。percents キーワードは、733 と同義で使用できます。
注 –
SMTP チャネルで 733 アドレスルールを使用すると、SMTP エンベロープの転送レイヤーのアドレスでもこれらのルールが使われるようになります。これは、RFC 821 に違反する場合があるため、必要時以外は 733 を使用しないでください。
uucp (bangstyle)
bang-style のエンベロープアドレス。このチャネルでは、エンベロープの RFC 976 の bbang-style アドレスルールに準拠するアドレスが使用されます (たとえば、UUCP チャネル)。bangstyle キーワードは、uucp と同義で使用できます。
header_822
ソースルートのヘッダーアドレス。このチャネルでは、ソースルートを含む、完全な RFC 822 形式のヘッダーアドレスルールがサポートされます。ほかのヘッダーアドレスタイプのキーワードが指定されていない場合、これがデフォルトになります。
header_733
パーセント記号のヘッダーアドレス。このチャネルでは、ソースルートを除く、完全な RFC 822 形式のヘッダーアドレスがサポートされます。ソースルートは、パーセント記号のルールを使用して、書き換える必要があります。
注 –
メッセージヘッダーで 733 アドレスルールを使用すると、RFC 822 と RFC 976 に違反する場合があります。このキーワードは、チャネルがソースルートアドレスを処理できないシステムに接続することが確実な場合以外は使用しないでください。
header_uucp
UUCP または bang-style のヘッダーアドレス。このキーワードの使用は推奨しません。使用すると RFC 976 に違反することになります。
! と % を使用するアドレスを解釈する
キーワード: bangoverpercent、nobangoverpercent、percentonly
アドレスは常に RFC 822 と RFC 976 に準拠して解釈されます。ただし、これらの規格で扱われていない複合アドレスの処理方法については、あいまいな部分があります。特に、A!B%C という形式のアドレスは次のどちらにも解釈できます。
-
A がルーティングホストで、C が最終的な宛先ホスト
または
-
C がルーティングホストで、A が最終的な宛先ホスト
RFC 976 では、メールプログラムが後者のルールを使ってアドレスを解釈できるという旨が示唆されていますが、そのような解釈が要求されるとは書かれていません。状況によっては、前者の解釈方法を使ったほうがよい場合があるかもしれません。
bangoverpercent キーワードを使うと、前者の A!(B%C) のように解釈されます。nobangoverpercent キーワードを使うと、後者の (A!B)%C のように解釈されます。nobangoverpercent がデフォルトです。
注 –
このキーワードは、A!B@C 形式のアドレス処理に影響を与えません。これらのアドレスは、常に (A!B)@C として扱われます。このような処理は RFC 822 と RFC 976 の両方で義務付けられています。
percentonly キーワードで、bang パスが無視されます。このキーワードが設定されている場合、パーセントはルーティング用に解釈されます。
アドレスにルーティング情報を追加する
キーワード: exproute、noexproute、improute、noimproute
MTA が扱うアドレスモデルは、すべてのシステムがほかのすべてのシステムのアドレスを知っていて、それらのアドレスにどのように到達するかを知っているものと想定しています。しかし、このような理想は、世界に知られていない 1 つ以上のシステムにチャネルが接続する (たとえば、プライベートな TCP/IP ネットワーク内にあるマシン) 場合など、どのような場合にも当てはまるとはかぎりません。このチャネルにあるシステムのアドレスは、サイトの外にあるリモートのシステムからは見ることができないようになっているのかもしれません。このようなアドレスに応答したい場合は、ローカルマシンを通ってメッセージをルーティングするようリモートのシステムに指示するソースルートを含んでいなければなりません。そうすれば、ローカルマシンは (自動的に) これらのマシンにルーティングすることができます。
exproute キーワード (「explicit routing」の略) は、アドレスがリモートのシステムに渡されるときに、関連するチャネルが明示的なルーティングを要するということを MTA に指示するものです。このキーワードがチャネルに指定されている場合、MTA により、ローカルシステムの名前 (またはローカルシステムの現在のエイリアス) を含むルーティング情報が、チャネルに一致するすべてのヘッダーアドレスとすべてのエンベロープの From: アドレスに追加されます。noexproute はデフォルトであり、ルーティング情報を追加しないことを指定します。
EXPROUTE_FORWARD オプションは、後方を探すアドレスに対する exproute の動作を制限するために使用できます。MTA が適切なルーティングを独自に実行することができないチャネルを通して相手システムに接続する場合には、別の状況が発生します。この場合、ほかのチャネルに関連するアドレスはすべて、能力のないシステムに接続するチャネルに送られたメール内で使用されるときに、ルーティング指定を必要とします。
この状況を処理するには、黙示的なルーティングと improute キーワードが使用されます。MTA は、ほかのチャネルに合致するすべてのアドレスが improute マークの付いたチャネルに送られたメールの中で使用されるときにルーティングを必要とすることを知っています。デフォルトの noimproute は、指定されたチャネルに送られるメッセージのアドレスにルーティングの情報を加えないことを指定するものです。IMPROUTE_FORWARD オプションは、後方を探すアドレスに対する improute の動作を制御するために使用できます。
exproute および improute キーワードは慎重に使用するようにしてください。これらのキーワードは、アドレスを長く、より複雑にし、相手側のシステムで使用されているインテリジェントなルーティング機能を妨害する可能性があります。明示的ルーティングと黙示的ルーティングを、指定ルートと混同しないようにしてください。指定ルートは、書き換えルールからアドレスにルーティング情報を挿入するときに使用されます。これは、特殊な A@B@C 書き換えルールテンプレートによってアクティブになります。
指定ルートは、アクティブになったときに、ヘッダーとエンベロープ内のすべてのアドレスに適用されます。指定ルートは特定の書き換えルールによってアクティブになるもので、通常、現在使用中のチャネルとは関係がありません。一方、明示的ルーティングと黙示的ルーティングはチャネルごとに制御され、挿入されるルートアドレスは常にローカルシステムのものです。
明示的なルーティングアドレスの書き換えを無効にする
routelocal チャネルキーワードでは、アドレスをチャネルに書き換える際に、MTA がアドレスのすべての明示的ルーティングの「短絡化」を試行するようにします。明示的にルーティングされたアドレス (using ! 、%、または @ の文字を使用) は簡略化されています。
このキーワードを内部 TCP/IP チャネルなどの内部チャネルに使用すると、SMTP リレーブロッキングの設定を簡単にすることができます。
ただし、明示的 % やその他のルーティングを必要とする可能性があるチャネルには、このキーワードを使用してはいけません。
メッセージがキューから取り出されるときのアドレス書き換え
キーワード: connectalias、connectcanonical
通常、MTA はチャネルのキューにメッセージを入れるときにアドレスを書き換えます。メッセージがキューから取り出されるときに、さらに書き換えが行われることはありません。したがって、ホスト名が変更されたときにチャネルのキュー内に元のホスト名宛のメッセージがまだ残っていても、問題は生じません。
connectalias キーワードは、受取人のアドレスに書かれているホストに配信するように、MTA に指示します。これがデフォルトです。connectcanonical キーワードは、MTA が接続するシステムのホストエイリアスに接続するように指示します。
不完全なアドレスを修正する際に使用するホスト名を指定する
キーワード: remotehost、noremotehost、defaulthost、 nodefaulthost
MTA は、間違って設定された、あるいは標準に準拠しないメーラーや SMTP クライアントから、ドメイン名を含まないアドレスを受け取ることがよくあります。MTA は、そのようなメッセージを通過させる前に、アドレスを有効な形式にしようと試みます。MTA は、アドレスにドメイン名を付け加える (たとえば、@siroe.com を mrochek に付け加える) ことによってそれを行います。
エンベロープ To: アドレスにドメイン名がない場合、MTA では常にローカルホスト名を追加するものと仮定します。From: アドレスなどのその他のアドレスの場合、MTA SMTP サーバーには、ドメイン名に関して少なくとも 2 つのオプションが考えられます。それらのオプションとは、ローカル MTA ホスト名と、クライアント SMTP でレポートされたリモートホスト名です。また場合によっては、そのチャネルで受信するメッセージに特定のドメイン名を追加するという、3 つ目のオプションが考えられる可能性もあります。最初の 2 つのオプションは、どちらもある程度の頻度で発生することが考えられるため、適切なものと考えられます。不適切に構成された SMTP クライアントを扱う場合には、リモートホストのドメイン名を使用することが適切です。メッセージを掲示するために SMTP を使う POP や IMAP クライアントのように軽量級のリモートメールクライアントを扱う場合には、ローカルホストのドメイン名を使用することが適切です。また、(POP や IMAP などの) 軽量級のリモートメールクライアントの場合は、各クライアントにはローカルホスト以外の専用の特定ドメイン名があります。この場合には、その他の特定ドメイン名の追加が適当な場合もあります。MTA がとれる最善の策は、チャネルごとに選択できるようにすることです。
noremotehost チャネルキーワードはローカルホストの名前が使用されるように指定するものです。デフォルトのキーワードは noremotehost です。
defaulthost チャネルキーワードを使用して、着信するユーザー ID に追加する特定のホスト名を指定します。このキーワードの後ろには、チャネルで受信するアドレスを完成させるためのドメイン名 (エンベロープ From: 内とヘッダー内) を追加する必要があります。送信チャネルの場合は、defaulthost キーワードの最初の引数もエンベロープ To: アドレスに影響します。省略可能な 2 番目のドメイン名 (少なくとも 1 つのピリオドが含まれている) を指定してエンベロープ To: アドレスを完成させることもできます。デフォルトは nodefaulthost です。
switchchannel キーワードは、前出の 「着信メール用代替チャネル (切り替えチャネル)」で説明されているとおり、着信 SMTP 接続を特定のチャネルに関連付けるために使用することができます。この機能は、リモートのメールクライアントを、適切な処理を受けることができるチャネルにグループ化するために使用することができます。代わりの方法として、(標準に準拠しないクライアントが多数使用されていたとしても) 標準に準拠するリモートメールクライアントを配備する方が、MTA ホストでネットワーク全体の問題を解決しようとするより簡単です。
受取人ヘッダー行がないメッセージを有効にする
RFC 822 (インターネット) メッセージには、受取人ヘッダー行である To:、Cc:、または Bcc: ヘッダー行が必要です。そのようなヘッダー行がないメッセージは無効になります。しかし、うまく稼働していないユーザーエージェントやメーラー (たとえば、古いバージョンの sendmail) は、無効なメッセージを受け入れます。
missingrecipientpolicy キーワードは、そのようなメッセージを扱うときに使用すべきアプローチを指定する整数値をとります。このキーワードが明示的に表現されていない場合は、デフォルト値の 1 (無効なメッセージを変更せずに通過させる) が使用されます。
表 12–25 missingrecipientpolicy の値|
値 |
動作 |
|---|---|
|
0 |
エンベロープ To: 受取人で To: ヘッダー行を置き換えます。 |
|
1 |
無効なメッセージを変更せずに通過させます。 |
|
2 |
エンベロープ To: 受取人で To: ヘッダー行を置き換えます。 |
|
3 |
すべてのエンベロープ To: 受取人で単一の Bcc: ヘッダー行を置き換えます。 |
|
4 |
To: ヘッダー行にグループのコンストラクタ (たとえば「;」) を生成します。「To: Recipients not specified: ;」のようになります。 |
|
5 |
空白の Bcc: ヘッダー行を生成します。 |
|
6 |
メッセージを拒否します。 |
MISSING_RECIPIENT_POLICY オプションは、MTA システムがデフォルトでこの動作をするように設定するためのものであることに注意してください。初期の Messaging Server 設定では、MISSING_RECIPIENT_POLICY が 1 に設定されます。
不正な空白の受取人ヘッダーを削除する
RFC 822 (インターネット) メッセージでは、To:、Resent-To:、Cc:、または Resent-Cc: ヘッダーにアドレスが少なくとも 1 つ必要です。空白値は使用できません。ただし、一部のメーラーでは、このような不正なヘッダーが生成されることがあります。ソースチャネルに dropblank チャネルキーワードが指定されている場合、MTA により着信メッセージからこれらの不正な空白ヘッダーが削除されます。
チャネル固有のリバースデータベースの使用を有効にする
reverse キーワードは、チャネルのキューに入れられたメッセージ内のアドレスを、アドレスリバースデータベースまたは REVERSE マッピングのどちらか存在する方に対して照合し、必要に応じて変更するように MTA に指示するものです。また、noreverse は、チャネルのキューに入れられたメッセージのアドレスを、アドレスリバース処理から外すことを指定するものです。デフォルトのキーワードは reverse です。「内部形式から公的な形式にアドレスを変換するには」を参照してください。
制限されたメールボックスのエンコーディングを有効にする
キーワード: restricted、unrestricted
メールシステムの中には、RFC 822 で許されるアドレスのすべての形式を扱うことができないものもあります。もっとも一般的に見られる例は、設定ファイルが不適切に設定された sendmail ベースのメーラーです。引用されたローカルパート (あるいはメールボックス仕様) が、頻繁に見られる問題の原因です。
"smith, ned"@siroe.com
これは大きな問題なので、この問題を回避するための方策が RFC 1137 に記載されています。基本的なアプローチは、アドレスから引用を取り除き、引用を要する文字を、アトムに許可する文字にマップする変換ルールを適用することです (ここで使われているアトムという語の定義については RFC 822 を参照)。たとえば、上記のアドレスは次のようになります。
smith#m#_ned@siroe.com
restricted チャネルキーワードでは、MTA に、このチャネルがこのエンコーディングを必要とするメールシステムに接続することを示します。すると MTA は、メッセージがチャネルに書かれるときに、ヘッダーとエンベロープアドレスの両方において引用されたローカルパートをエンコードします。そのチャネルの着信メールのアドレスは自動的にデコードされます。unrestricted キーワードは、RFC 1137 エンコーディングとデコーディングを実行しないように MTA に指示します。デフォルトは unrestricted キーワードです。
注 –
restricted キーワードは、引用されたローカルパートを受け入れることができないシステムに接続するチャネルに対して適用します。引用されたローカルパートを実際に生成するチャネルには適用しません。(そのようなアドレスを生成することができるチャネルは、そのようなアドレスを処理することができると想定されるため。)
Return-path: ヘッダー行を生成する
キーワード: addreturnpath、noaddreturnpath
通常、Return-path: ヘッダー行の追加は、最終的な配信を実行するチャネルが行います。ただし、ims-ms チャネルなどの一部のチャネルでは、MTA で Return-path: ヘッダー行を追加する方が、チャネルで追加するよりも効率的です。addreturnpath キーワードでは、このチャネルのキューにメッセージを入れる際に、MTA により Return-path: ヘッダーが追加されます。
エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する
キーワード: receivedfor、noreceivedfor、receivedfrom、noreceivedfrom
receivedfor キーワードは、メッセージの宛先になっているエンベロープ受取人アドレスが １ つだけの場合は、そのエンベロープの To: アドレスを Received: ヘッダー行に含めるように MTA に指示します。デフォルトのキーワードは receivedfor です。noreceivedfor キーワードは、エンベロープアドレス情報を含めずに、Received: ヘッダー行を作成するよう MTA に指示します。
receivedfrom キーワードは、たとえばメーリングリストの拡大などのために MTA がエンベロープ From: アドレスを変更した場合、着信メッセージの Received: ヘッダー行を作成する際に元のエンベロープの From: アドレスを含めるように MTA に指示します。デフォルトは receivedfrom です。noreceivedfrom キーワードは、元のエンベロープ From: アドレスを使わずに、Received: ヘッダー行を作成するよう MTA に指示します。
アドレスヘッダー行内のコメントを処理する
キーワード: commentinc、commentmap commentomit、commentstrip、commenttotal、sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip、sourcecommenttotal
MTA は必要なときだけヘッダー行の内容を解釈します。ただし、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべての登録されたヘッダー行をパースしなければなりません。この処理の途中では、コメント (括弧で囲まれた文字列) が抽出され、ヘッダー行が再構成されるときに変更されるか、あるいは除外されることがあります。
この動作は、commentinc、commentmap、commentomit、commentstrip、および commenttotal キーワードを使用して制御されます。commentinc キーワードは、ヘッダー行内のコメントを残すように MTA に指示します。デフォルトでは、このキーワードが使用されます。commentomit キーワードは、アドレスヘッダー、たとえば To:、From:、あるいは Cc: ヘッダー行からコメントを取り除くように MTA に指示します。
commenttotal キーワードは、MTA にすべてのヘッダー行 (Received: ヘッダー行を除く) からコメントを削除するように指示します。このキーワードは通常有用ではなく、お勧めもしません。commentstrip キーワードは、すべてのコメントフィールドからすべての非原子的文字を削除するように MTA に指示します。commentmap キーワードは、COMMENT_STRINGS マッピングテーブルを通じてコメント文字列を実行します。
ソースチャネルでは、この動作は sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip、および sourcecommenttotal の各キーワードを使用して制御されます。sourcecommentinc キーワードは、MTA にヘッダー行のコメントを維持するように指示します。デフォルトでは、このキーワードが使用されます。sourcecommentomit キーワードは、MTA にアドレスヘッダー (To:、From:、Cc: などのヘッダー) からすべてのコメントを削除するように指示します。sourcecommenttotal キーワードは、MTA にすべてのヘッダー行 (Received: ヘッダー行を除く) からコメントを削除するように指示します。このキーワードは通常有用ではなく、お勧めもしません。最後に、sourcecommentstrip キーワードは MTA に、すべてのコメントフィールドから非原子的文字を削除するように指示します。sourcecommentmap キーワードは、ソースチャネルを通じてコメント文字列を実行します。
これらのキーワードはどのチャネルにも適用できます。
COMMENT_STRINGS マッピングテーブルの構文は、次のとおりです。
(comment_text) | address
エントリテンプレートに $Y フラグが設定されている場合、元のコメントは指定したテキスト (閉じる括弧を含むこと) に置き換えられます。
アドレスヘッダー行内の個人名を処理する
キーワード: personalinc、personalmap、personalomit、personalstrip、sourcepersonalinc、sourcepersonalmap、sourcepersonalomit、sourcepersonalstrip
書き換えプロセスの際には、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべてのヘッダー行をパースしなければなりません。このプロセスの際に、個人名 (角括弧で区切られたアドレスの前にある文字列) が抽出されるが、これはヘッダー行を再構築するときに変更したり除外することもできます。
この動作は、personalinc、personalmap、personalomit、および personalstrip キーワードを使用して制御されます。personalinc キーワードは、ヘッダーの個人名を維持するように MTA に指示します。デフォルトでは、このキーワードが使用されます。personalomit キーワードは、すべての個人名を削除するように MTA に指示します。personalstrip キーワードは、すべての個人名フィールドからすべての非原子的文字を削除するように、MTA に指示します。personalmap キーワードは、PERSONAL_NAMES マッピングテーブルを通じて個人名を実行するように、MTA に示します。
ソースチャネルでは、この動作は sourcepersonalinc、sourcepersonalmap、sourcepersonalomit、または sourcepersonalstrip キーワードを使用して制御されます。sourcepersonalinc キーワードは、ヘッダーの個人名を維持するように MTA に指示します。デフォルトでは、このキーワードが使用されます。sourcepersonalomit キーワードは、すべての個人名を削除するように MTA に指示します。最後に、sourcepersonalstrip キーワードは、すべての個人名フィールドから非原子的文字を削除するように、MTA に指示します。sourcepersonalmap キーワードは、ソースチャネルを通じて個人名を実行するように MTA に指示します。
これらのキーワードはどのチャネルにも適用できます。
PERSONAL_NAMES マッピングテーブルプローブの構文は、次のとおりです。
personal_name | address
テンプレートで $Y フラグが設定されている場合、元の個人名は指定したテキストで置き換えられます。
エイリアスファイルとエイリアスデータベースプローブを指定する
通常、ローカルチャネル (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 キーワードは、MTA にこのチャネルにおけるチャネル固有の書き換えルールのチェックを強制するように指示します。これがデフォルトです。norules キーワードは、MTA にこのチャネルをチェックしないように指示します。これらの 2 つのキーワードは、通常デバッグに使用され、実際のアプリケーションで使用されることはほとんどありません。
ソースルートを削除する
dequeue_removeroute キーワードは、メッセージがキューから取り出されると、エンベロープの To: アドレスからソースルートを削除します。現在、このキーワードは tcp-* チャネルだけに実装されています。ソースルートを正しく処理しないシステムにメッセージを転送する場合に便利なキーワードです。
エイリアスからアドレスを指定する
キーワード: viaaliasoptional、viaaliasrequired
viaaliasrequired は、チャネルに一致する最終受取人アドレスをエイリアスで作成するように指定するキーワードです。最終受取人アドレスとは、関連するエイリアス拡張を行なった後で一致するアドレスです。アドレスを受取人アドレスとして MTA に直接渡すことはできません。チャネルに書き換えただけでは十分ではないからです。チャネルに書き換えた後で、本当にチャネルと一致したとみなされるよう、アドレスもエイリアスから展開する必要があります。
viaaliasrequired キーワードは、たとえば、ローカルチャネルで、任意のアカウント (UNIX システム上の任意のネイティブ Berkeley メールボックスなど) への配信を防ぐために使用できます。
デフォルトは viaaliasoptional であり、そのチャネルに一致する最終受取人アドレスはエイリアスで作成する必要がありません。
- © 2010, Oracle Corporation and/or its affiliates