第 11 章書き換えルールの設定

この章では、imta.cnf ファイル内で書き換えルールを設定する方法について説明します。この章を読む前に、第 10 章「MTA サービスと設定について」をお読みください。

Messaging Server のアドレス書き換え機能は、アドレスのホストまたはドメイン部分を操作および変更するのに欠かせない重要な機能です。Messaging Server には、エイリアス、アドレスリバースデータベース、および特殊化されたマッピングテーブルといったほかの機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換えルールを使用するようにしてください。


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

書き換えルールの構造

書き換えルールは、MTA 設定ファイルである imta.cnf の上半分に表示されます。設定ファイルに、各ルールが 1 行ごとに記述されています。空白行ではないコメントを、ルールとルールの間に入力できます。書き換えルールは空白行で終わり、その後にチャネル定義が続きます。設定ファイル内の書き換えルールセクションの例を以下に示します。

書き換えルールは次の 2 つの部分から構成されます。最初にパターン、その後ろに同等の文字列またはテンプレートを指定します。これらの 2 つの部分は空白文字を挿入して区切る必要があります。ただし、パターンやテンプレート自体に空白文字を使用することはできません。書き換えルールの構造は以下のとおりです。

ドメイン名の中の検索する文字列を指定します。表 11-3 では、パターンは a.com、b.org、c.edu、および d.com です。

パターンがアドレスのドメインの部分と一致する場合、書き換えルールはアドレスに適用されます。パターンはスペースでテンプレートと区切る必要があります。パターンの構文については、「書き換えルールのパターンとタグ」を参照してください。

UserTemplate は、アドレスのユーザー部分を書き換える方法を指定します。置換シーケンスを使用して、オリジナルのアドレスの一部、またはデータベース検索の結果を表すことができます。書き換えられたアドレスを作成するために、置換シーケンスはそれが表すものと置き換えられます。表 11-4 では、$U という置換シーケンスが使用されています。詳細は、「テンプレートの置換と書き換えルールのコントロールシーケンス」を参照してください。

DomainTemplate は、アドレスのドメイン部分を書き換える方法を指定します。UserTemplate と同様、DomainTemplate には置換シーケンスを入力できます。

ChannelTag は、このメッセージが送信されるチャネルを表します。チャネル定義にはすべて、チャネルタグとチャネル名が必要です。一般に、チャネルタグは書き換えルールとそのチャネル定義に記述されます。

controls を使用して、ルールの適用を制限することができます。コントロールシーケンスの中には、ルールの先頭に指定するものと、ルールの最後に指定するものとがあります。コントロールについては、「テンプレートの置換と書き換えルールのコントロールシーケンス」を参照してください。

書き換えルールのパターンとタグ

書き換えルールのほとんどのパターンは、該当のホストだけと一致する特定のホスト名か、サブドメイン全体の任意のホスト/ドメインと一致するサブドメインパターンのいずれかで構成されます。

たとえば、以下の書き換えルールのパターンは、指定したホストだけと一致する特定のホスト名で構成されます。

次の書き換えルールのパターンは、サブドメイン全体の任意のホストまたはドメインと一致するサブドメインのパターンで構成されます。

ただし、このパターンは、ホスト名 siroe.com 自体とは一致しません。ホスト名 siroe.com 自体と一致させるには、別の siroe.com パターンが必要になります。

MTA は、特定のホスト名で始まるホスト/ドメイン名を書き換えてから、固有性を少なくするよう、増分で名前を生成しようとします。つまり、より固有な書き換えルールパターンは、より一般的な書き換えルールパターンに優先して使用されます。たとえば、設定ファイルに以下の書き換えルールパターンが指定されているとします。

書き換えルールパターンに基づいて、jdoe@hosta.subnet.siroe.com のアドレスは書き換えルールパターン hosta.subnet.siroe.com と一致し、jdoe@hostb.subnet.siroe.com のアドレスは書き換えルールパターン .subnet.siroe.com と一致し、jdoe@hostc.siroe.com のアドレスは書き換えルールパターン .siroe.com と一致します。

特に、インターネットのサイトではサブドメイン書き換えルールパターンを含む書き換えルールの使用が一般的です。通常、このようなサイトにはそれ自体の内部ホストおよびサブネットの多数の書き換えルールがあり、internet.rules ファイルからその設定に、トップレベルインターネットドメインの書き換えルールが組み込まれます (msg_svr_base/config/internet.rules)。

インターネット宛先 (より特定の書き換えルールを通じて処理される内部ホスト宛先を除く) へのメッセージが正しく書き換えられ、送信 TCP/IP チャネルに送られるようにするには、imta.cnf ファイルに以下の内容を含めます。

同様に、IP ドメインリテラルの場合も階層に基づいて照合が行われます。ただし、左から右ではなく、右から左へ照合が行われます。たとえば、次のパターンは [1.2.3.4] という IP リテラルにのみ一致します。

次のパターンは 1.2.3.0 サブネット内の任意の IP リテラルに一致します。

すでに説明したより一般的な種類のホストまたはサブドメインの書き換えルールパターンのほか、書き換えルールではいくつかの特殊なパターンも使われます。これについては、表 11-1 で要約し、以降の項で説明します。

表 11-1 書き換えルールの特殊パターンの要約
パターン	説明/使用目的
$*	任意のアドレスと一致します。このルールが指定されている場合、それがファイル内のどの位置にあっても、最初に適用されます。
$%	パーセントハックルール。A%B という形式のホスト/ドメイン仕様と一致します。
$!	bang-style ルール。B!A という形式のホスト/ドメイン仕様と一致します。
[ ]	IP リテラル全一致ルール。任意の IP ドメインリテラルと一致します。
.	任意のホスト/ドメイン仕様と一致します。たとえば、joe@[129.165.12.11]

Messaging Server には、このような特殊なパターンのほか、書き換えルールパターンに現れることのあるタグという概念があります。これらのタグは、アドレスが複数回にわたって書き換えられる場合に使用されます。この区別は、直前に行われた書き換えに基づき、どの書き換えルールがアドレスに一致するかを制御することによって行います。詳細は、「タグ付き書き換えルールセット」を参照してください。

パーセントハックに一致するルール

MTA が A%B 形式のアドレスを書き換えようとして失敗した場合は、そのアドレスが A%B@localhost 形式のアドレスとして扱われる前に、もう 1 つのルールが適用されます (これらのアドレス形式については、「書き換えルールテンプレート」を参照)。このもう 1 つのルールがパーセントハックルールです。形式は $% です。形式が変更されることはありません。このルールは、パーセント記号を含むローカル部分がほかのすべての方法 (あとで説明する全一致ルールを含む) で書き換えに失敗した場合にのみアクティブになります。

パーセントハックルールは、パーセントハックアドレスに何らかの特別な意味を持たせる場合に便利です。

bang-style (UUCP) アドレスに一致するルール

MTA が B!A 形式のアドレスを書き換えようとして失敗した場合は、そのアドレスが B!A@localhost 形式のアドレスとして扱われる前に、もう 1 つのルールが適用されます。このルールが bang-style ルールです。形式は $! です。形式が変更されることはありません。このルールは、感嘆符を含むローカル部分がほかのすべての方法 (あとで説明するデフォルトのルールを含む) で書き換えに失敗した場合にのみアクティブになります。

bang-style ルールを使用すると、UUCP スタイルのアドレスが UUCP システムおよびルーティングに関する総合的な情報を備えたシステムを経由するように書き換えることができます。

任意のアドレスに一致するルール

特殊パターン「.」(ドット文字) は、ほかに一致するルールがなく、ホストまたはドメイン仕様がチャネルテーブル内で見つからない場合に、任意のホストまたはドメイン仕様に一致します。つまり、「.」ルールは、アドレスの書き換えに失敗する前の最後の手段として使用されます。

タグ付き書き換えルールセット


注	置換シーケンスについては、全一致ルールが一致し、そのテンプレートが展開される場合、$H はホストのフルネームに展開し、$D は単一のドット記号「.」に展開します。したがって、全一致ルールのテンプレートでは、$D の使用が制限されます。

書き換えプロセスを実行するにあたり、別のルールセットを追加するとうまくいく場合があります。別のルールセットを追加するには、書き換えルールタグを使用します。現在のタグは、設定ファイルまたはドメインデータベースでパターンが検索される前に、各パターンの前に付けられます。タグは、書き換えルールテンプレート内の $T という置換文字列を使って一致する書き換えルールにより変更することができます (後述の説明を参照)。

タグは、1 つのアドレスから抽出されたすべてのホストに対し、連続して適用されます。そのため、タグを使用した場合は、別のルールを指定する際にそれが正しいタグ値から始まるように注意してください。一般に、タグは特殊な目的でしか使用しないため、このことが問題になることはほとんどありません。アドレスの書き換えが完了すると、タグはデフォルトのタグ (空白文字列) にリセットされます。

ルールにより、すべてのタグ値には、その最後に縦棒 (|) が付けられます。この文字は通常のアドレスには使用されないため、パターンの残りの部分とタグとを区別することができます。

書き換えルールテンプレート

以下の節では、書き換えルールのテンプレートの形式について説明します。表 11-2 にテンプレートの形式を示します。

よく使われる書き換えテンプレート: A%B@C または A@B

表 11-2 書き換えルールのテンプレートの形式の要約
テンプレート	ページ	使用目的
A%B	299	A は新しいユーザー/メールボックスの名前になり、B は新しいホスト/ドメイン仕様になります。繰り返し書き換えます。
A@B	299	A%B@B として扱われます。
A%B@C	299	A は新しいユーザー/メールボックスの名前になり、B は新しいホスト/ドメイン仕様になり、ホスト C と関連するチャネルにルーティングされます。
A@B@C	299	A@B@C@C として扱われます。
A@B@C@D	299	A は新しいユーザー/メールボックスの名前になり、B は新しいホスト/ドメイン仕様になり、C をソースルートとして挿入し、ホスト D と関連するチャネルにルーティングされます。

以下に示すテンプレート形式は、もっともよく使われるものです。ルールは、アドレスのユーザー部分とドメイン部分に適用されます。その後、新しいアドレスがメッセージを特定のチャネル (ChannelTag で指定されたチャネル) へ送るために使用されます。

以下に示すテンプレート形式は、上記のテンプレートと実質的に同じものです。ただし、この形式は、DomainTemplate と ChannelTag が同じ場合にしか使用できません。

繰り返し書き換えテンプレート: A%B

以下に示すテンプレート形式は、繰り返して適用する必要があるルールに使用されます。ルール適用後は、新しいアドレスで書き換えプロセス全体を繰り返します (ほかのテンプレート形式では、ルールを適用すると書き換えプロセスが終了)。

たとえば、以下に示すルールを使うと、.removable というドメイン名で終わるすべてのアドレスから .removable が削除されます。

繰り返しルールを使用する場合には、「ルールループ」が生じないように特別な注意が必要です。そのため、特に必要がない限り、繰り返し書き換えルールの使用を控えることをお勧めします。繰り返しルールを使用する際には、imsimta test -rewrite コマンドを使ってルールをテストするとよいでしょう。test -rewrite コマンドについては、『Messaging Server Reference Manual』を参照してください。

指定ルート書き換えテンプレート: A@B@C@D または A@B@C

以下に示すテンプレート形式は、一般によく使われる形式 UserTemplate%DomainTemplate@ChannelTag と同じように機能します (最初の区切り文字が異なることに注意)。ただし、ChannelTag はソースルートとしてアドレスに挿入される点で異なります。メッセージは ChannelTag に送られます。

書き換えられたアドレスは @route:user@domain になります。また、次のテンプレートも使用できます。

たとえば、以下に示すルールを使うと、jdoe@com1 というアドレスが @siroe.com:jdoe@com1 というソースルートアドレスに書き換えられます。チャネルタグは siroe.com になります。

書き換えルールテンプレートにおける大文字と小文字の区別

書き換えルール内のパターンとは異なり、テンプレートでは大文字と小文字が区別されます。この機能は、大文字と小文字を区別するメールシステムへのインタフェースを提供するような書き換えルールを使用する場合に必要となります。アドレスから抽出された部分の代わりに使われる $U や $D などの置換シーケンスでも、大文字と小文字が区別され、元のアドレスと同じ状態が維持されます。

UNIX システムでメールボックスを小文字にする場合など、置換部分に特定の大文字または小文字が使われるようにするには、テンプレートに特殊な置換シーケンスを使用します。たとえば、$¥ は後ろに続く置換部分を小文字にし、$^ は後ろに続く置換部分を大文字にします。また、$_ は元と同じ状態を保ちます。

たとえば、以下のルールを使うと、unix.siroe.com のアドレスに対するメールボックスを小文字にすることができます。

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 には、アドレスにおける感嘆符 (!) およびパーセント記号 (%) の解釈が含まれていません。慣例上、パーセント記号はアットマーク (@) と同じように解釈されます (アットマークがない場合)。このルールは Messaging Server MTA で採用されています。

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

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

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

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

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

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

このマッチングプロセスのアルゴリズムは、以下のとおりです。


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

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

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

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

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

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

書き換えルールの失敗

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

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

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

ドメインリテラルの処理

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

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

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

テンプレートの置換と書き換えルールのコントロールシーケンス

置換を使用して、書き換えられたアドレスに文字列を挿入することによって、ユーザー名またはアドレスを書き換えます。この値は、使用される特定の置換シーケンスによって決まります。この節には、以下の項があります。

たとえば、以下のテンプレートでは、$U が置換シーケンスです。この置換シーケンスを使用することにより、書き換えられるアドレスのユーザー名部分がテンプレートの出力に挿入されます。したがって、このテンプレートで jdoe@mailhost.siroe.com を書き換えると、その出力は jdoe@siroe.com になります。つまり $U が元のアドレスのユーザー名部分 jdoe に置き換えられます。

コントロールシーケンスは、指定した書き換えルールの適用に対して追加の条件を課します。書き換えルールのパターン部がチェックされるホストまたはドメイン仕様と一致する必要があるだけでなく、書き換えられているアドレスの他の側面も、コントロールシーケンスまたはシーケンスによる条件設定と一致する必要があります。たとえば、$E コントロールシーケンスは、書き換えるアドレスがエンベロープアドレスでなければならないことを意味します。また、$F コントロールシーケンスは、そのアドレスが前方を探すアドレスでなければならないことを意味します。以下の書き換えルールは、user@siroe.com 形式の (書き換え) エンベロープの To: アドレスにのみ適用されます。

ドメインまたはホスト仕様が書き換えルールのパターン部分と一致しても、そのルールのテンプレートの中のコントロールシーケンスによって生じる基準のすべてとは一致しない場合、書き換えルールは失敗し、適用可能なほかのルールの検索が続けられます。

表 11-4 では、テンプレートの置換とコントロールシーケンスを要約しています。

表 11-4 書き換えルールテンプレートの置換とコントロールシーケンスの要約
置換シーケンス	置き換える内容
$D	一致するドメイン仕様の部分。
$H	ホストまたはドメイン仕様 (パターンのドットの左側) の一致しない部分。
$L	ドメインリテラル (パターンリテラルのドットの右側) の一致しない部分。
$U	オリジナルのアドレスのユーザー名。
$nA	現在のアドレスの 0 の位置から左に n 番目の文字を挿入します。n を省略した場合、アドレス全体が挿入されます。
$nX	メールホストの 0 から左に n 番目のコンポーネントを挿入します。n を省略した場合、メールホスト全体が挿入されます。
$0U	オリジナルのアドレスのローカル部分 (ユーザー名) からサブアドレスを除いたもの。
$1U	存在する場合は、オリジナルのアドレスのローカル部分 (ユーザー名)。
$$	リテラルのドル記号 ($) を挿入します。
$%	リテラルのパーセント記号 (%) を挿入します。
$@	リテラルのアットマーク (@) を挿入します。
$¥	該当部分を小文字にします。
$^	該当部分を大文字にします。
$_	元の大文字と小文字を使用します。
$=	後続の置換文字が、LDAP 検索フィルタへの挿入に適した引用の対象となるようにして、その部分を大文字に変換します。
$W	ランダムで一意な文字列に置換します。
$]...[	LDAP 検索 URL ルックアップ。
$(テキスト)	一般データベースの置換。検索に失敗すると、ルールは失敗します。
${...}	指定したマッピングを、与えられた文字列に適用します。
$[...]	カスタマ提供のルーチンを起動し、結果の置換を行います。
$&n	左から右にゼロから数えて、一致しない (またはワイルドカードの) ホストの n 番目の部分。
$!n	右から左にゼロから数えて、一致しない (またはワイルドカードの) ホストの n 番目の部分。
$*n	左から右にゼロから数えて、一致するパターンの n 番目の部分。
$#n	右から左にゼロから数えて、一致するパターンの n 番目の部分。
$nD	一致するドメイン仕様の部分で、左側の 0 から n 番目までの部分が残されます
$nH	一致しないホスト/ドメイン仕様の部分で、左側の 0 から n 番目までの部分が残されます
コントロールシーケンス	書き換えルールの効果
$1M	チャネルが内部再処理チャネルの場合のみ適用されます。
$1N	チャネルが内部再処理チャネルではない場合のみ適用されます。
$1~	保留状態のチャネルの照合チェックを実行します。チェックに失敗した場合、現在の書き換えルールテンプレートの処理は正常に終了します。
$A	ホストがアットマーク (@) の右にある場合に適用されます
$B	ヘッダー/本文のアドレスのみに適用されます
$Cchannel	channel に送信中の場合は失敗します
$E	エンベロープアドレスのみに適用されます
$F	前方を探すアドレス (例、To:) のみに適用されます
$Mchannel	channel がアドレスを書き換えている場合のみ適用されます
$Nchannel	channel がアドレスを書き換えている場合は失敗します
$P	ホストがパーセント記号の右にある場合に適用されます
$Qchannel	channel に送信している場合のみ適用されます
$R	後方を探すアドレス (例、From:) にのみ適用されます
$S	ホストがソースルートからの場合に適用されます
$Tnewtag	書き換えルールタグを新規タグに設定します
$Vホスト	ホスト名が LDAP ディレクトリ (DC ツリー内または仮想ドメインとしてのいずれか) に定義されていない場合、失敗します。LDAP 検索がタイムアウトになると、書き換えパターンのホスト名の後の直後の文字の残りの部分は、MTA オプションの文字列 DOMAIN_FAILURE と置き換えられます。
$X	ホストが感嘆符の左にある場合に適用されます
$Zhost	ホスト名が LDAP ディレクトリ (DC ツリー内または仮想ドメインとしてのいずれか) に定義されている場合、失敗します。LDAP 検索がタイムアウトになると、書き換えパターンのホスト名の後の直後の文字の残りの部分は、MTA オプションの文字列 DOMAIN_FAILURE と置き換えられます。
$?errmsg	書き換えに失敗すると、デフォルトのエラーメッセージの代わりに errmsg が返されます。エラーメッセージは US ASCII 文字でなければなりません。
$number?errmsg	書き換えに失敗すると、デフォルトのエラーメッセージの代わりに errmsg が返され、SMTP 拡張エラーコードが a.b.c に設定されます。 a は、番号/1000000 (最初の桁) b は (番号/1000)、余り 1000 (桁 2 から 4 の値) c は番号、余り 1000 (最後の 3桁の値)。以下の例では、エラーコードを 3.45.89 に設定しています。 $3045089?the snark is a boojum

ユーザー名とサブアドレスの置換: $U、$0U、$1U

テンプレート内にある $U はすべて、元のアドレスから抽出されたユーザー名 (RFC 822「ローカル部」) に置き換えられます。この場合、a."b" 形式のユーザー名は "a.b" に置き換えられます。RFC2822 では、RFC 822 における古い構文の使用は推奨されていません。今後、より新しい構文の使用が中心になると考えられます。

テンプレート内にある $0U はすべて、元のアドレスのユーザー名に置き換えられます。ただし、サブアドレスおよびサブアドレスを示す文字 (+) は含まれません。テンプレート内にある $1U はすべて、元のアドレスのサブアドレスおよびサブアドレスを示す文字 (+) に置き換えられます (それらが存在する場合のみ)。$0U と $1U はユーザー名を互いに補う関係にあります。すなわち、$0U$1U と $U とは同じものです。

ホストまたはドメインと IP リテラルの置換: $D、$H、$nD、$nH、$L

$H はすべて、ルールに一致しなかったホストまたはドメイン仕様の部分に置き換えられます。また、$D はすべて、ルールに一致したホストまたはドメイン仕様の部分に置き換えられます。$nH および $nD は、通常の $H または $D の部分から左側の 0 から n 番目までの部分を残す変形体です。すなわち、$nH または $nD を使用すると、通常 $H または $D で得られる部分から左端の 1 から n 番目までの部分が省略されます。$0H と $H、および $0D と $D はそれぞれ同じものです。

たとえば、jdoe@host.siroe.com というアドレスが以下のルールに一致したとします。

このルールが適用されると、出力チャネルに TCP-DAEMON を使用する jdoe@siroe.com というアドレスが得られます。$D は一致したドメイン全体 (つまり host.siroe.com) に置き換えられる置換シーケンスですが、この例で使われている $1D は一致したドメインの部分 1 (siroe) 以降の部分 (siroe.com) に置き換えられます。

$L は、書き換えルールに一致しなかったドメインリテラルの部分に置き換えられます。

リテラル文字の置換: $$、$%、$@

通常、$、%、および @ 文字は書き換えルールテンプレートのメタキャラクタです。これらの文字を挿入する場合は、その文字の前にドル記号 $ を付けます。すなわち、$$ は単一のドル記号 $ に、$% は単一のパーセント記号 % (この場合、パーセントはテンプレートのフィールド区切り文字として解釈されない) に、$@ は単一のアットマーク @ (同様に、フィールド区切り文字として解釈されない) に展開されます。

LDAP クエリー URL の置換 : $]...[

$]ldap-url[ 形式の置換シーケンスは LDAP クエリー URL として解釈され、LDAP クエリーの結果に置き換えられます。標準の LDAP URL では、ホストとポートが省略されます。その代わり、ホストとポートは、msg.conf ファイル (local.ldaphost および local.ldapport 属性) で指定されています。

すなわち、LDAP URL は、以下のように指定されます。ここで、角括弧 [ ] は URL のオプション部分を表しています。

dn は検索ベースを指定する識別名で、この部分は必須です。URL のオプションである属性 (attributes)、範囲 (scope)、フィルタ (filter) は、戻される情報を指定するためのものです。書き換えルールの場合、戻される情報を指定するための属性として望ましいのは mailRoutingSystem 属性 (または同様の属性) です。範囲には、base (デフォルト)、one、または sub のいずれかを指定できます。また、フィルタには、mailDomain の値が書き換えられるドメインに一致するオブジェクトを戻すような要求を指定するとよいでしょう。

LDAP ディレクトリスキーマに mailRoutingSystem および mailDomain 属性が含まれている場合、指定アドレスの送り先となるシステムを決定する書き換えルールは、たとえば次のようになります。この例で、作成された LDAP クエリー内の LDAP URL 置換シーケンス $D は、現在のドメイン名に置き換えられます。

この例で使われている円記号は、書き換えルールの 1 行が次の行に続いていることを示すためのものです。表 11-5 に LDAP URL 置換シーケンスの一覧を示します。

表 11-5 LDAP URL 置換シーケンス
置換シーケンス	説明
$$	リテラル $ 文字
$~ アカウント	ユーザーアカウントのホームディレクトリ
$A	アドレス
$D	ドメイン名
$H	ホスト名 (完全指定ドメイン名の最初の部分)
$L	~ または _ などの特別な先頭文字を除くユーザー名
$S	サブアドレス
$U	ユーザー名

MTA は、書き換えルールおよびマッピング内で実行された検索結果の URL をキャッシュするようになりました。この新しい URL 結果キャッシュは、URL_RESULT_CACHE_SIZE (デフォルト: 10000 エントリ) および URL_RESULT_CACHE_TIMEOUT (デフォルト: 600 秒) の 2 つの新しい MTA オプションによって制御されます。

一般データベースの置換: $(...)

$(テキスト) 形式の置換シーケンスは、特殊な方法で処理されます。テキスト部分は、特殊な一般データベースにアクセスするためのキーとして使われます。このデータベースは、/imta/config/imta_tailor ファイル内の IMTA_GENERAL_DATABASE オプションで指定されているファイル (通常、/imta/db/generaldb.db ファイル) で構成されています。

このデータベースは、imsimta crdb ユーティリティを使って作成されます。「テキスト文字列」がデータベース内のエントリに一致すると、データベース内の対応するテンプレートがその文字列に置き換えられます。「テキスト文字列」がデータベース内のどのエントリにも一致しなかった場合は、書き換えプロセスが失敗に終わります。つまり、最初から何も一致しなかったのと同じ状態に戻ります。置き換えがうまくいくと、次にデータベースから抽出されたテンプレートに別の置換シーケンスが含まれていないかどうかが調べられます。ただし、再帰的参照のループを避けるために、抽出されたテンプレート内に別の $(テキスト) を含めることは禁じられています。

参照ループが発生する可能性があるからです。例として、次の書き換えルールに jdoe@siroe.siroenet というアドレスが一致した場合を考えてみます。

まず、一般データベースで siroe というテキスト文字列が検索され、その結果 (見つかった場合) が書き換えルールのテンプレートとして用いられます。ここで、siroe の検索結果を $u%eng.siroe.com@siroenet とします。この場合、テンプレートの出力は jdoe@eng.siroe.com (すなわち、ユーザー名 = jdoe、ホストまたはドメイン仕様 = eng.siroe.com) になり、ルーティングシステムは siroenet になります。

一般データベースは、正しい操作を行うためにだれでも読み取り可能でなければなりません。

指定マッピングの適用: ${...}

.SIROENET $($H) ${mapping,argument} 形式の置換シーケンスは、MTA マッピングファイルでマッピングを検索し、見つかったマッピングを適用するのに使用します。mapping フィールドにはマッピングテーブルの名前を指定し、argument フィールドにはマッピングへ渡す文字列を指定します。この置換シーケンスを使用するには、指定したマッピングが存在し、かつその出力に $Y フラグが設定されていなければなりません。マッピングが存在しなかったり、$Y フラグが設定されていない場合、書き換えは失敗に終わります。問題なく処置が行われた場合は、マッピングの結果がテンプレート内の同じ位置にマージされたあと、再び展開されます。

このメカニズムにより、さまざまな方法で MTA 書き換えプロセスを展開することができます。たとえば、アドレスのユーザー名部分を選択しながら分析したり変更したりすることができます。通常の MTA 書き換えプロセスに、このような機能はありません。

カスタマ指定ルーチンの置換: $[...]

$[image,routine,argument] 形式の置換シーケンスは、カスタマ指定ルーチンを検索して呼び出すのに使用します。UNIX では、MTA は dlopen および dlsym を使って、指定されたルーチンを共有ライブラリイメージからダイナミックにロードし、呼び出します。そのとき、そのルーチンは以下の引数を伴った関数として呼び出されます。

argument および result は、252 バイトの文字列バッファです。UNIX で、argument と result は文字列へのポインタ (例: C 言語の char*) として渡されます。arglength と reslength は、参照によって渡される符号付きの long 型整数です。入力時に argument には書き換えルールテンプレートからの引数文字列が含まれ、arglength にはその文字列の長さが含まれます。値を返すときには、result に結果文字列が入り、reslength にその長さが入ります。次にこの結果文字列は書き換えルールテンプレートで "$[image,routine,argument]" に置換されます。routine は、書き換えルールが失敗した場合には 0 を返し、成功した場合には -1 を返します。

このメカニズムによって、書き換えプロセスの複雑な展開が可能になります。たとえば、あるタイプのネームサービスに対して呼び出しを実行し、その結果を使ってアドレスを変化させることができます。次の書き換えルールを使って、ホスト siroe.com に対して前方を探すアドレス (例: To: アドレス) のディレクトリサービス検索が次のように実行されることがあります。$F を指定すると、この書き換えルールを前方を探すアドレスだけに使用することができます。詳細は、「方向および位置に固有の書き換えルール ($B、$E、$F、$R)」を参照してください。

jdoe@siroe.com という前方を探すアドレスがこのルールに一致すると、メモリ内に LOOKUP_IMAGE (UNIX の共有ライブラリ) がロードされ、argument パラメータとして jdoe を使って LOOKUP ルーチンが呼び出されます。その後、LOOKUP ルーチンは、John.Doe%eng.siroe.com などの別のアドレスを result パラメータに入れ、書き換えルールが適用されたことを示す値 (-1) を返します。結果文字列にパーセント記号 (「繰り返し書き換えテンプレート: A%B」を参照) が使用されていると、アドレスを書き換えるものとして John.Doe@eng.siroe.com を使った書き換えプロセスが再開されます。

UNIX システムでは、サイト提供の共有ライブラリイメージはだれでも読み取り可能でなければなりません。

単一フィールドの置換: $&、$!、$*、$#

単一フィールド置換シーケンスは、書き換えるホストまたはドメイン仕様からサブドメイン部分を 1 つ抽出するためのものです。表 11-6 に、使用可能な単一フィールド置換シーケンスを一覧にして示します。

表 11-6 単一フィールドの置換シーケンス
コントロールシーケンス	使用目的
$&n	ホスト仕様 (ワイルドカードに一致しなかったまたは一致した部分) 内の n 番目の要素を表します (n=0,1,2,..,9)。要素はドット文字で区切られており、もっとも左にあるものが「要素 0」となります。要求された要素が存在しない場合は、書き換えは失敗します。
$!n	ホスト仕様 (ワイルドカードに一致しなかったまたは一致した部分) 内の n 番目の要素を表します (n=0,1,2,..,9)。要素はドット文字で区切られており、もっとも右にあるものが「要素 0」となります。要求された要素が存在しない場合は、書き換えは失敗します。
$*n	ドメイン仕様 (パターンで指定されているテキストに一致した部分) 内の n 番目の要素を表します (n=0,1,2,...,9)。要素はドット文字で区切られており、もっとも左にあるものが「要素 0」となります。要求された要素が存在しない場合は、書き換えは失敗します。
$#n	ドメイン仕様 (パターンで指定されているテキストに一致した部分) 内の n 番目の要素を表します (n=0,1,2,...,9)。要素はドット文字で区切られており、もっとも右にあるものが「要素 0」となります。要求された要素が存在しない場合は、書き換えは失敗します。

jdoe@eng.siroe.com というアドレスが次の書き換えルールに一致したとします。

この場合、テンプレートからは「mailhub.siroe.com をルーティングシステムとして使った jdoe@eng.siroe.com」という結果が得られます。

固有文字列の置換

$W コントロールシーケンスは、大文字の英数字からなる繰り返し不可能な固有のテキスト文字列を挿入します。$W は、繰り返されないアドレス情報を作成するような場合に便利です。

ソースチャネル固有の書き換えルール ($M、$N)

特定のソースチャネルに関してのみ動作する書き換えルールを作成することができます。これは、短形式の名前に 2 つの意味が含まれるような場合に便利です。

ソースチャネル固有の書き換えは、使用中のチャネルプログラムと、rules や norules というチャネルキーワードに関連しています。書き換えを実行する MTA コンポーネントに関連付けられたチャネルに norules が指定されている場合、チャネル固有の書き換えルールチェックは行われません。そのチャネルに rules が指定されている場合は、チャネル固有の書き換えルールチェックが行われます。デフォルトのキーワードは rules です。

ソースチャネル固有の書き換えは、指定されたアドレスに一致するチャネルとは関係がありません。このタイプの書き換えは、書き換えを実行する MTA コンポーネントとそのコンポーネントのチャネルテーブルエントリにのみ依存します。

チャネル固有の書き換えルールチェックは、ルールのテンプレート部分に $N または $M コントロールシーケンスがある場合に実行されます。$N や $M に続く文字は、アットマーク (@)、パーセント記号 (%) または、後続の $N、$M、$Q、$C、$T、または$? までチャネル名と解釈します。

たとえば、$M チャネルを使用したときにチャネルが現在書き換えを行なっているチャネルでない場合は、ルールが適用されません。また、$N チャネルを使用したときにチャネルが書き換えを行なっている場合も、ルールが適用されません。複数の $M および $N 句を指定することもできます。複数の $M 句を使用した場合は、そのうちの 1 つでも一致すれば、ルールが適用されます。複数の $N 句を使用している場合は、そのうちの 1 つでも一致すれば、ルールの適用は失敗に終わります。

宛先チャネル固有の書き換えルール ($C、$Q)

メッセージをキューに入れるチャネルに依存する書き換えルールを作成することができます。これは、あるホストに対して名前が 2 つあるような場合に便利です。つまり、1 つのホストグループに認識されている名前と、別のホストグループに認識されている名前とが異なる場合です。異なるチャネルを使って各グループにメールを送ることにより、各グループに知られている名前を使ってホストを参照するようにアドレスを書き換えることができます。

宛先チャネル固有の書き換えは、メッセージを取り出して処理するチャネルと、そのチャネルに関する rules および norules キーワードに関連しています。宛先チャネルに norules が指定されている場合、チャネル固有の書き換えルールチェックは行われません。宛先チャネルに rules が指定されている場合は、チャネル固有の書き換えルールチェックが行われます。デフォルトのキーワードは rules です。

宛先チャネル固有の書き換えは、指定されたアドレスに一致するチャネルとは関係がありません。このタイプの書き換えは、メッセージのエンベロープ To: アドレスのみに依存します。メッセージがキューに入ると、まずそのエンベロープ To: アドレスが書き換えられ、メッセージの送り先チャネルが決定されます。エンベロープ To: アドレスの書き換え中、$C コントロールシーケンスや $Q コントロールシーケンスはすべて無視されます。エンベロープ To: アドレスが書き換えられ、宛先チャネルが決まると、メッセージに関連するほかのアドレスが書き換えられる際に $C および $Q コントロールシーケンスが考慮されます。

宛先チャネル固有の書き換えルールチェックは、ルールのテンプレート部分に $C または $Q コントロールシーケンスがあると実行されます。$C または $Q に続く文字は、アットマーク (@) やパーセント記号 (%) または、後続の $N、$M、$C、$Q、$T、または $? までチャネル名と解釈します。

たとえば、$Q チャネルを使用したときにチャネルが宛先チャネルでない場合は、ルールが適用されません。また、$C チャネルを使用したときにチャネルが宛先である場合にも、ルールは適用されません。複数の $Q および $C 句を指定することもできます。複数の $Q 句を使用した場合は、そのうちの 1 つでも一致すれば、ルールが適用されます。複数の $C 句を指定した場合は、そのうちの 1 つでも一致すれば、ルールの適用は失敗に終わります。

方向および位置に固有の書き換えルール ($B、$E、$F、$R)

エンベロープアドレスにのみ適用される書き換えルール、またはヘッダーアドレスにのみ適用される書き換えルールを指定したい場合があります。$E コントロールシーケンスを使うと、書き換えるアドレスがエンベロープアドレスでない場合、書き換えを実行することができなくなります。$B コントロールシーケンスを使うと、書き換えるアドレスがメッセージのヘッダーまたは本文からのものでない場合、書き換えを実行することができなくなります。これらのシーケンスはこのような効果を得る目的でのみ使用され、書き換えルールテンプレート内の任意の場所に含めることができます。

アドレスは、方向によって分類することもできます。前方を探すアドレスは、To:、Cc:、Resent-to:、または宛先を参照するほかのヘッダー行またはエンベロープ行に関して生じるアドレスです。また、後方を探すアドレスは、From:、Sender:、または Resent-From: といったソースを参照するものです。$F コントロールシーケンスを使うと、前方を探すアドレスである場合に書き換えルールが適用されます。$R コントロールシーケンスを使うと、後方を探すアドレスである場合に書き換えルールが適用されます。

ホストの位置に固有の書き換え ($A、$P、$S、$X)

アドレス内のホスト名の位置に基づいて適用されるようなルールを必要とする場合があります。アドレス内のホスト名は、以下の位置にくることが考えられます。

通常ホスト名は、それがどこに位置するかに関係なく、同じように処理されます。ただし、特別な処理を必要とする場合もあります。

アドレス内のホスト名の位置に基づいてマッチング動作を制御するには、以下の 4 つのコントロールシーケンスを使用できます。

ホスト名が指定した位置にない場合は、ルールの適用が失敗に終わります。これらのシーケンスは、1 つの書き換えルール内で組み合わせることもできます。たとえば、$S と $A を指定すると、ルールはソースルート内のホスト名またはアットマークの右側にあるホスト名のいずれかに一致します。これらのシーケンスをすべて指定したのと、どれも指定しないのとは同じことです。すなわち、ルールはホスト名の位置に関係なく一致します。

現在のタグ値の変更 ($T)

現在の書き換えルールタグを変更するには、$T コントロールシーケンスを使用します。書き換えルールタグはすべての書き換えルールパターンの先頭に付けられ、その後、設定ファイルやドメインデータベースで書き換えルールパターンの検索が行われます。$T の直後からアットマーク、パーセント記号、$N、$M、$Q、$C、$T、または $? までの間のテキストが新しいタグとして扱われます。

タグは、特定のコンポーネントが検出されたときにアドレスの特性全体が変わるような、特殊なアドレス形式を処理する場合に便利です。たとえば、ソースルート内で internet という特別なホスト名が見つかったときに、そのホスト名をアドレスから削除し、削除後のアドレスを強制的に TCP-DAEMON チャネルにマッチングするとします。

これは、以下のようなルールを使って実行できます (ローカルホストの正式な名前を localhost とする)。

最初のルールは、ソースルート内で internet という特別なホスト名が見つかった場合、そのホスト名に一致します。その後、ローカルチャネルと internet とのマッチングが行われ、アドレスから internet が削除されます。そして、書き換えタグが設定されます。書き換えプロセスは続けられますが、タグに対して通常のルールが一致することはありません。最後に、デフォルトのルールがタグとともに試され、2 番目のルールに移ります。このルールでは、ほかの条件に関係なく、アドレスが強制的に TCP-DAEMON チャネルに対してマッチングされます。

書き換えに関連するエラーメッセージの制御 ($?)

MTA には、書き換えとチャネルの照合に失敗したときに表示されるデフォルトのエラーメッセージがあります。これらのメッセージは、特定の条件下で変更することができます。たとえば、だれかが Ethernet ルーターボックスにメールを送信しようとした場合などは、「不正なホストまたはドメインが指定されています」というより「ルーターがメールを受け入れられません」というメッセージを表示した方がより適切です。

特殊なコントロールシーケンスを使って、ルールの適用に失敗した場合に印刷されるエラーメッセージを変更することができます。エラーメッセージを指定するには、$? シーケンスを使用します。$? の直後からアットマーク (@)、パーセント記号 (%)、$N、$M、$Q、$C、$T、または $? までの間のテキストがエラーメッセージのテキストとして扱われます。このエラーメッセージは、書き換えの結果がどのチャネルにも一致しなかった場合に印刷されます。エラーメッセージの設定は記憶され、書き換えプロセスを通じて有効となります。

$? を含むルールもほかのルールと同じように動作します。特別なケースとして、$? だけを含むルールには注意してください。この場合、アドレスのメールボックスまたはホスト部分は変更されずに書き換えプロセスが終了し、ホストがそのままチャネルテーブル内で検索されます。この検索は失敗に終わり、その結果としてエラーメッセージが返されます。

たとえば、MTA 設定ファイル内に、次に示すような最終的な書き換えルールがあるとします。

この例で、認識されないホストまたはドメイン仕様は、その失敗のプロセスにおいて、Unrecognized address; contact postmaster@siroe.com というエラーメッセージを生成します。

多数の書き換えルールを扱う

MTA は常に imta.cnf ファイルからすべての書き換えルールを読み取り、メモリ内のハッシュテーブルにそれらのルールを保存します。コンパイルした設定を使用すると、情報が必要になるたびに設定ファイルを読み取るという作業を省くことができます。この場合でも、メモリ内にすべての書き込みルールを保存するためにハッシュテーブルが使われます。この方法は、書き換えルールがあまり多くない場合に適しています。サイトによっては 10,000 個以上の書き換えルールが必要になる場合もあります。このような場合には、かなり多くのメモリを費やさなければなりません。

MTA では、補助的なインデックス付きデータファイルに多数の書き換えルールを保存するオプションの機能を使って、この問題を解決することができます。通常の設定ファイルが読み取られるたびに、MTA はドメインデータベースがあるかどうかを調べます。データベースがある場合は、設定ファイルのルールが照合に失敗するたびにそのデータベースが開かれ、その内容が調べられます。ドメインデータベースが調べられるのは、指定されたルールが設定ファイル内に見つからなかったときだけです。そのため、ルールはいつでも設定ファイルに追加することができ、それによってデータベース内のルールが無効になります。デフォルトでは、ドメインデータベースはホストしているドメインに関連する書き換えルールを保存するために使用されます。IMTA_DOMAIN_DATABASE 属性は imta_tailor ファイルに保存されています。このデータベースのデフォルトの場所は msg_svr_base/data/db/domaindb.db です。


注	このファイルは手作業で編集しないでください。

書き換えルールをテストする

書き換えルールをテストするには imsimta test -rewrite コマンドを使用します。-noimage 修飾子を使うと、新しい設定をコンパイルする前に、設定ファイルに加えた変更内容をテストすることができます。

このユーティリティと -debug 修飾子を使って少数のアドレスを書き換えると便利かもしれません。この場合、ステップバイステップ形式でアドレスの書き換えが行われます。たとえば、以下のコマンドを実行します。

imsimta test -rewrite ユーティリティの詳細については、『Messaging Server Reference Manual』を参照してください。

書き換えルールの例

以下に、書き換えルールの例とそれらのルールによってサンプルアドレスがどのように書き換えられるかを示します。

SC.CS.SIROE.EDU システムの設定ファイルに、次の例で示す書き換えルールが含まれているとします。

表 11-7 に、サンプルアドレスと、それらの書き換え結果およびルートを示します。

表 11-7 サンプルアドレスと書き換え結果
最初のアドレス	書き換え後	ルート
user@sc	user@sc.cs.siroe.edu	sc.cs.siroe.edu
user@sc1	user@sc1.cs.siroe.edu	sc1.cs.siroe.edu
user@sc2	user@sc2.cs.siroe.edu	sc2.cs.siroe.edu
user@sc.cs	user@sc.cs.siroe.edu	sc.cs.siroe.edu
user@sc1.cs	user@sc1.cs.siroe.edu	sc1.cs.siroe.edu
user@sc2.cs	user@sc2.cs.siroe.edu	sc2.cs.siroe.edu
user@sc.cs.siroe	user@sc.cs.siroe.edu	sc.cs.siroe.edu
user@sc1.cs.siroe	user@sc1.cs.siroe.edu	sc1.cs.siroe.edu
user@sc2.cs.siroe	user@sc2.cs.siroe.edu	sc2.cs.siroe.edu
user@sc.cs.siroe.edu	user@sc.cs.siroe.edu	sc.cs.siroe.edu
user@sc1.cs.siroe.edu	user@sc1.cs.siroe.edu	sc1.cs.siroe.edu
user@sc2.cs.siroe.edu	user@sc2.cs.siroe.edu	sc2.cs.siroe.edu
user@sd.cs.siroe.edu	user@sd.cs.siroe.edu	sd.cs.siroe.edu
user@aa.cs.siroe.edu	user@aa.cs.siroe.edu	ds.adm.siroe.edu
user@a.eng.siroe.edu	user@a.eng.siroe.edu	cds.adm.siroe.edu
user@a.cs.sesta.edu	user@a.cs.sesta.edu	gate.adm.siroe.edu - route inserted
user@b.cs.sesta.edu	user@b.cs.sesta.edu	gate.adm.siroe.edu - route inserted
user@[1.2.3.4]	user@[1.2.3.4]	gate.adm.siroe.edu - route inserted

基本的に、これらの書き換えルールの内容は次のとおりです。ホスト名が短形式の名前 (sc、sc1、または sc2) の 1 つである場合、またはフルネーム (sc.cs.siroe.edu など) の 1 つである場合は、その名前をフルネームに展開し、ユーザーに送ります。cs.cmu.edu を 1 つの部分からなる短形式の名前に追加し、再試行します。.cs が後ろに続く 1 つの部分を .cs.siroe.edu が後ろに続く 1 つの部分に変換し、もう一度試行します。また、.cs.siroe も .cs.siroe.edu に変換し、もう一度試行します。

名前が sd.cs.siroe.edu (ユーザーが直接接続するシステム) である場合は、それを書き換えて、そこに送ります。ホスト名が cs.siroe.edu サブドメイン内のほかのものである場合は、それを ds.cs.siroe.edu (cs.siroe.edu サブドメインのゲートウェイ) に送ります。ホスト名が siroe.edu サブドメイン内のほかのものである場合は、それを cds.adm.siroe.edu (siroe.edu サブドメインのゲートウェイ) に送ります。ホスト名が .edu トップレベル内のほかのものである場合は、それを gate.adm.siroe.edu (メッセージを適切な宛先に送ることが可能) に送ります。ドメインリテラルが使用されている場合は、それも gate.adm.siroe.edu に送ります。

上記の例のように、書き換えルールによってアドレスのユーザー名 (またはメールボックス) 部分が変更されることはほとんどありません。アドレスのユーザー名部分を変更する機能は、MTA が RFC 822 に準拠しないメールソフトウェア (ホストまたはドメイン仕様をアドレスのユーザー名部分に詰め込む必要があるメールソフトウェア) へのインタフェースとして使われる場合に使用されます。この機能を使用する際には、十分な配慮が必要です。

前へ目次索引次へ
Sun Java System Messaging Server 6 2005Q1 管理ガイド