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

MTA がアドレスに書き換えルールを適用する方法

次に、MTA が指定アドレスに書き換えルールを適用する手順について説明します。

アドレスから最初のホスト仕様またはドメイン仕様を抽出します。

アドレスには、次のように 1 つ以上のホスト名またはドメイン名が指定されている場合があります。

jdoe%hostname@siroe.com.
最初のホスト名またはドメイン名を識別したあと、そのホスト名またはドメイン名に一致するパターンが含まれている書き換えルールを検索します。
一致する書き換えルールが見つかると、MTA により、そのルールのテンプレート部分に従ってアドレスが書き換えられます。
最後に、チャネルタグと各チャネルに関連するホスト名が比較されます。

一致するものが見つかると、MTA は関連するチャネルへのメッセージをキューに入れます。一致するものが見つからない場合、書き換えプロセスは失敗に終わります。一致するチャネルがローカルチャネルであれば、エイリアスデータベースとエイリアスファイルを検索して、アドレスの書き換えが追加されることもあります。

これらの動作の詳細については、後続の節を参照してください。

注 –

既存のどのチャネルにも属さないチャネルタグを使用すると、このルールに一致するアドレスを持つメッセージが戻ってきます。すなわち、ルールに一致するメッセージは配信不能となります。

動作 1: 最初のホストまたはドメイン仕様を抽出する

アドレス書き換えプロセスは、アドレスの最初のホストまたはドメイン仕様を抽出することから始まります。次の説明をより理解するために、RFC 822 アドレスルールについて把握しておくことをお勧めします。アドレス内のホストまたはドメイン仕様が検索される順序は、以下のとおりです。

ソースルートのホスト (左から右へ読み取り)
アットマーク @ の右側にあるホスト
最後のパーセント記号 % の右側にあるホスト
最初の感嘆符 ! の左側にあるホスト

最後の 2 項目の順序は、アドレスの書き換えを行なっているチャネルで bangoverpercent キーワードが有効になっているかどうかによって入れ替わります。すなわち、メッセージをキューに入れようとしているチャネルが bangoverpercent チャネルキーワードでマークされているかどうかによって順序が異なります。

表 11–3 に、アドレスと最初に抽出されるホスト名の例を示します。

表 11–3 抽出されるアドレスとホスト名


アドレス	最初のホストドメイン仕様	コメント
`user@a`	`a`	「省略形」のドメイン名。
`user@a.b.c`	`a.b.c`	「完全指定」ドメイン名 (FQDN)。
`user@[0.1.2.3]`	`[0.1.2.3]`	「ドメインリテラル」
`@a:user@b.c.d`	`a`	省略形のドメイン名を伴った「ルート」と呼ばれるソースルートアドレス。
`@a.b.c:user@d.e.f`	`a.b.c`	ソースルートアドレス: ルート部分は完全形。
`@[0.1.2.3]:user@d.e.f`	`[0.1.2.3]`	ソースルートアドレス: ルート部分はドメインリテラル。
`@a,@b,@c:user@d.e.f`	`a`	a-> b -> c ルーティングを伴ったソースルートアドレス。
`@a,@[0.1.2.3]:user@b`	`a`	ルート部分にドメインリテラルを伴ったソースルートアドレス。
`user%A@B`	`B`	この非標準形のルーティングは「パーセントハック」と呼ばれます。
`user%A`	`A`
`user%A%B`	`B`
`user%%A%B`	`B`
`A!user`	`A`	「bang-style」のアドレス。UUCP によく使用されます。
`A!user@B`	`B`
`A!user%B@C`	`C`
`A!user%B`	`B`	`nobangoverpercent` キーワードが有効な場合 (デフォルト)。
`A!user%B`	`A`	`bangoverpercent` キーワードが有効な場合。

RFC 822 には、アドレスにおける感嘆符 (!) およびパーセント記号 (%) の解釈が含まれていません。慣例上、パーセント記号はアットマーク (@) と同じように解釈されます (アットマークがない場合)。

パーセント記号をローカルユーザー名の一部として扱うために、繰り返しパーセント記号の解釈が使用されます。これは、外部メールシステムのアドレスを処理するような場合に便利です。感嘆符の解釈は、RFC 976 の「bang-style」アドレスルールに従います。この解釈により、Messaging Server MTA で UUCP アドレスを使用することが可能になります。

これらの解釈の順序については、RFC 822 または RFC 976 のどちらにも指定されていません。そのため、bangoverpercent および nobangoverpercent キーワードを使って、書き換えを行うチャネルによって解釈が適用される順序を制御します。デフォルト設定がより「標準的」ですが、状況によっては代わりの設定を使った方が便利な場合もあります。

注 –

アドレス内に感嘆符 (!) やパーセント記号 (%) を使用することはお勧めしません。

動作 2: 書き換えルールを検索する

アドレスから最初のホストまたはドメイン仕様が抽出されると、MTA は書き換えルールを調べてその仕様の処理方法を明らかにします。ホストまたはドメイン仕様は、各ルールのパターン部分 (各ルールの左側) と比較されます。その場合、大文字と小文字の区別はありません。大文字と小文字の区別がないことは、RFC 822 で定められています。MTA では、特に大文字と小文字を区別しませんが、可能な限り元の状態が維持されます。

ホストまたはドメイン仕様がどのパターンにも一致しない場合は、ホストまたはドメイン仕様の最初の部分 (最初のドット文字より前の部分、通常はホスト名) がアスタリスク (*) に置き換えられ、その新しいホストまたはドメイン仕様が検索されます。ただし、その場合、検索対象となるのは設定ファイル内の書き換えルールだけで、ドメインデータベースは調べられません。

この試行が失敗に終わると、最初の部分が削除され、プロセスが繰り返されます。この試行も失敗に終わると、次の部分 (通常はサブドメイン) が削除され、再び検索が行われます。最初にアスタリスクを含めて検索が行われ、その後アスタリスクを含めずに検索が行われます。アスタリスクを含んだ検索が行われるのは設定ファイル内の書き換えルールテーブルだけで、ドメインデータベースは調べられません。このプロセスは、一致するルールが見つかるか、ホストまたはドメイン仕様全体がなくなるまで続けられます。このようなプロセスを使用することにより、指定した内容にもっとも近いドメインから始めて、徐々に広範なドメインを検索することができます。

このマッチングプロセスのアルゴリズムを、次に示します。

ホストまたはドメイン仕様が比較文字列 spec_1 と spec_2 の初期値として使用されます(例: spec_1 = spec_2 = a.b.c)。
比較文字列 spec_1 は、一致するものが見つかるまで、まず設定ファイル内にある各書き換えルールのパターン部分が調べられ、次にドメインデータベース内が調べられます。このマッチングプロセスは、一致するものが見つかった時点で終了します。
一致するものが見つからなかった場合は、spec_2 のもっとも左側の部分 (アスタリスク以外) がアスタリスクに変換されます。たとえば、spec_2 が a.b.c の場合に一致するものが見つからなければ *.b.cに、spec_2 が *.b.c の場合に一致するものが見つからなければ *.*.c. に変換されます。このマッチングプロセスは、一致するものが見つかった時点で終了します。
一致するものが見つからなければ、比較文字列 spec_1 の最初の部分はドット文字も含めて削除されます。.c や c のように、spec_1 に 1 つの部分しかない場合は、文字列は 1 文字のドット文字「.」で置き換えられます。削除後の spec_1 文字列の長さがゼロでない場合は、動作 1 に戻ります。削除後の新しい文字列の長さがゼロの場合 (たとえば、置換後の文字列が「.」だった場合) は、検索プロセスが失敗に終わり、マッチングプロセスが終了します。

たとえば、アドレス dan@sc.cs.siroe.edu を書き換えるとします。これにより MTA は、指定した順に次のパターンを検索します。

sc.cs.siroe.edu
*.cs.siroe.edu
.cs.siroe.edu
*.*.siroe.edu
.siroe.edu
*.*.*.edu
.edu
*.*.*.*
.

動作 3: テンプレートに従ってアドレスを書き換える

ホストまたはドメイン仕様が書き換えルールに一致すると、そのホストまたはドメイン仕様はルールのテンプレート部分を使って書き換えられます。テンプレートには、次の 3 つの仕様があります。

アドレスの新しいユーザー名。
アドレスの新しいホストまたはドメイン仕様。
メッセージの送信先である既存の MTA チャネルが指定されたチャネルタグ。

動作 4: 書き換えプロセスを終了する

ホストまたはドメイン仕様が書き換えられると、次の 2 つの動作のうちどちらかが行われます。

チャネルタグがローカルチャネルまたは routelocal チャネルキーワードでマークされているチャネルのどちらにも関連付けられていない場合、またはアドレス内にほかのホストまたはドメイン仕様がない場合は、書き換え後の仕様が抽出された元の仕様に置き換えられ、書き換えプロセスが終了します。
チャネルタグがローカルチャネルまたは routelocal でマークされたチャネルに一致し、かつアドレス内にほかのホストまたはドメイン仕様がある場合は、書き換え後のアドレスが破棄され、アドレスから元 (初期設定) のホストまたはドメイン仕様が削除されます。次にそのアドレスから新しいホストまたはドメイン仕様が抽出され、プロセス全体が繰り返されます。書き換えプロセスは、すべてのホストまたはドメイン仕様がなくなるか、あるいはローカルでないチャネルまたはルートローカルでないチャネルを介したルートが見つかるまで続けられます。MTA がソースルートをサポートできるのは、この反復メカニズムがあるためです。実際、ローカルシステムまたはルートローカルシステムを介した不必要なルートは、このプロセスによってアドレスから削除されます。

書き換えルールの失敗

ホストまたはドメイン仕様がどの書き換えルールにも一致せず、デフォルトのルールもない場合には、「そのまま」の仕様が使われます。たとえば、元の仕様が新しい仕様およびルーティングシステムになります。アドレスに無意味なホストまたはドメイン仕様が含まれている場合、その仕様は、ルーティングシステムが任意のチャネルに関連付けられたどのシステム名にも一致しないときに検出され、メッセージが戻されます。

書き換え後の構文チェック

書き換えルールが適用されたあとのアドレスに対し、構文チェックは行われません。これは意図的なものです。構文チェックを行わないようにすることで、書き換えルールを使ってアドレスを RFC 822 に準拠しない形式に変換することができます。ただし、設定ファイル内に間違いがあると、MTA から送出されるメッセージに不正なアドレスが含まれる可能性もあります。

ドメインリテラルの処理

ドメインリテラルは、特に書き換えプロセス中に処理されます。アドレスのドメイン部分にあるドメインリテラルが書き換えルールのパターンに一致しない場合、そのリテラルは、角括弧で囲まれ、ドット文字で区切られた文字列の集まりとして解釈されます。そして、もっとも右側にある文字列が削除され、検索が繰り返されます。それでも一致するものが見つからない場合は、角括弧だけが残るまで次々に文字列が削除されていきます。空白の角括弧を使った検索も失敗に終わった場合は、ドメインリテラル全体が削除され、ドメインアドレスの次の部分について書き換え処理が実行されます (次の部分が存在する場合)。ドメインリテラルの内部処理では、アスタリスクが使用されません。ドメインリテラル全体がアスタリスクに置き換えられた場合は、アスタリスクの数とドメインリテラル内の要素の数とが一致します。

通常のホストまたはドメイン仕様の場合と同じように、ドメインリテラルの場合も指定した内容にもっとも近いものから順に検索が行われます。そして、パターンに一致した最初のルールを使って、ホストまたはドメイン仕様の書き換えが行われます。ルールリスト内に同じパターンが 2 つある場合は、先に記述されている方のルールが適用されます。

たとえば、dan@[128.6.3.40] というアドレスを書き換えるとします。この場合、まず [128.6.3.40] の検索が行われ、その後、[128.6.3.]、[128.6.]、[128.]、[]、[*.*.*.*]、そして最後に全一致ルール「.」という順に検索が実行されます。