| 前へ 目次 索引 次へ | |
| iPlanet Messaging Server 5.1 管理者ガイド | |
第 7 章 書き換え規則を設定する
この章では、imta.cnf ファイル内で書き換え規則を設定する方法について説明します。この章へ進む前に、第 6 章「MTA サービスと設定について」をお読みください。
書き換え規則の構造
Messaging Server のアドレス書き換え機能は、アドレスのホストまたはドメイン部分を操作および変更するのに欠かせない重要な機能です。Messaging Server には、エイリアス、アドレス置き換えデータベース、および特殊化されたマッピングテーブルといった他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換え規則を使用するようにしてください。それにより、最高のパフォーマンスを得ることができます。
書き換え規則の構造
書き換え規則は MTA 設定ファイル (imta.cnf) の前半部分にあり、各規則が 1 行ごとに記述されています。規則間にコメントを記述することは可能ですが、空白行を挿入することはできません。書き換え規則の最後には空白行が挿入され、その後にチャネルの定義が続きます。図 7-1 に、設定ファイル内の書き換え規則を示します。図 7-1
設定ファイルの例 - 書き換え規則
! test.cnf - 設定ファイルの例。
!
! これは、単に設定ファイルの例です。
! 実際のシステムで使用するためのものではありません。
!
a $U@a-host
b $U@b-host
c $U%c@b-daemon
d $U%d@a-daemon
! 以下、チャネルの定義が続きます。
書き換え規則は、2 つの部分から構成されています。最初にパターン、その後に同等の文字列またはテンプレートを指定します。これらの 2 つの部分は空白文字を挿入して区切る必要があります。ただし、パターンやテンプレート自体に空白文字を使用することはできません。書き換え規則の構造は、次のとおりです。
パターン テンプレート 検索の対象となるドメイン名内の文字列です。図 6-1 の例では、a、b、c、d がパターンです。
パターンがアドレスのドメイン部分に一致すると、その書き換え規則がアドレスに適用されます。パターンの後には空白文字を挿入して、テンプレート部分を区別できるようにします。パターンの構文については、「書き換え規則のパターンとタグ」を参照してください。
以下のいずれかの形式を使って指定します。テンプレートの構文については、「書き換え規則のテンプレート」を参照してください。
UserTemplate%DomainTemplate@ChannelTag[コントロール]
UserTemplate@ChannelTag[コントロール]
UserTemplate%DomainTemplate[コントロール]
UserTemplate@DomainTemplate@ChannelTag[コントロール]
UserTemplate@DomainTemplate@SourceRoute@ChannelTag[コントロール]
UserTemplate アドレスのユーザ部分をどのように書き換えるかを指定します。元のアドレスの一部またはデータベース検索の結果を表すために置換シーケンスを使用することもできます。置換シーケンスは、アドレスを書き換える際に、それが表す本来の文字列に置き換えられます。図 6-1 では、$U という置換シーケンスが使用されています。詳細については、「テンプレートの置換シーケンスと書き換え規則コントロールシーケンス」を参照してください。
DomainTemplate アドレスのドメイン部分をどのように書き換えるかを指定します。UserTemplate と同様に、DomainTemplate にも置換シーケンスを含めることができます。
ChannelTag このメッセージの送信先チャネルです (すべてのチャネル定義に、チャネルタグとチャネル名を含める必要があります。一般に、チャネルタグは書き換え規則とそのチャネル定義に記述されます)。
コントロール コントロールを使って、規則の適用度を制限できます。コントロールシーケンスの中には、規則の前に置くものと、規則の後に置くものとがあります。コントロールの詳細については、「テンプレートの置換シーケンスと書き換え規則コントロールシーケンス」を参照してください。
書き換え規則のパターンとタグ
一般に、書き換え規則のパターンは、特定のホスト名 (そのホスト名だけに一致) またはサブドメインパターン (サブドメイン全体における任意のホスト/ドメインに一致) のいずれかで構成されます。たとえば、次の書き換え規則のパターンには、特定のホスト名が含まれています。このパターンは、この指定したホスト名だけに一致します。
次の書き換え規則のパターンには、サブドメインパターンが含まれています。このパターンは、サブドメイン全体における任意のホストまたはドメインに一致します。
ただし、このパターンはsiroe.com というホスト名には一致しません。siroe.com も対象に含める場合は、siroe.com という別のパターンが必要です。
MTA は、特定のホスト名に一致するものからホスト/ドメイン名を書き換えていき、より不特定のパターンへと処理を進めます。つまり、特定のパターンは、不特定のパターンよりも優先して使用されることになります。たとえば、設定ファイルに、以下の書き換え規則パターンが記述されているとします。
hosta.subnet.siroe.com
.subnet.siroe.com
.siroe.comこの場合、まず 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 (サーバ-インスタンス/imta/config/internet.rules) ファイル内の設定に含められます。
インターネット宛先(より特定の書き換え規則を通じて処理されたインターネットホスト宛先を除く) へのメッセージが正しく書き換えられ、送信 TCP/IP チャネルに送られるようにするには、imta.cnf ファイルに以下の内容を含めます。
! Ascension Island
.AC $U%$H$D@TCP-DAEMON
. [簡潔にするため
. テキストを
. 省略]
! Zimbabwe
.ZW $U%$H$D@TCP-DAEMON同様に、IP ドメインリテラルの場合も階層に基づいて照合が行われます。ただし、左から右ではなく、右から左へ照合が行われます。たとえば、次のパターンは [1.2.3.4] という IP リテラルにのみ一致します。
次のパターンは 1.2.3.0 サブネット内の任意の IP リテラルに一致します。
ホスト/サブドメイン名を使った一般的な書き換え規則パターンのほかに、特殊なパターンを使用することもできます。これらの特殊なパターンについては、表 7-1 およびその後の説明を参照してください。
パターン
説明/使用方法
これらの特殊パターンに加え、Messaging Server には、書き換え規則のパターン内で使われるタグの概念もあります。これらのタグは、アドレスが複数回にわたって書き換えられる場合に使用されます。その場合、それぞれの書き換えを区別する必要があります。この区別は、直前に行われた書き換えに基づき、どの書き換え規則がアドレスに一致するかを制御することによって行います。詳細については、「タグ付き書き換え規則セット」を参照してください。
パーセントハックに一致する規則
MTA が A%B 形式のアドレスを書き換えようとして失敗した場合は、そのアドレスが A%B@localhost として扱われる前に、もう 1 つの規則が適用されます (これらのアドレス形式の詳細については、「書き換え規則のテンプレート」を参照してください)。この規則がパーセントハック規則です。パターンは $% で、これが変わることはありません。この規則は、パーセント記号を含むローカル部分が他のすべての方法 (後で説明する全一致規則を含む) で書き換えに失敗した場合にのみアクティブになります。パーセントハック規則は、パーセントハックアドレスに何らかの特別な意味を持たせる場合に便利です。
bang-style (UUCP) アドレスに一致する規則
MTA が B!A 形式のアドレスを書き換えようとして失敗した場合は、そのアドレスが B!A@localhost 形式のアドレスとして扱われる前に、もう 1 つの規則が適用されます。この規則がbang-style 規則です。パターンは $! で、これが変わることはありません。この規則は、感嘆符を含むローカル部分が他のすべての方法 (後で説明するデフォルトの規則を含む) で書き換えに失敗した場合にのみアクティブになります。bang-style 規則を使用すると、UUCP スタイルのアドレスが UUCP システムおよびルーティングに関する総合的な情報を備えたシステムを経由するように書き換えることができます。
任意のアドレスに一致する規則
特殊パターン「.」(ドット文字) は、他に一致する規則がない場合に、任意のホスト/ドメイン仕様に一致します。ただし、そのホスト/ドメイン仕様は、チャネルテーブル内で見つからないものに限ります。つまり、「.」規則は、アドレスの書き換えに失敗する前の最後の手段として使用されます。
注 置換シーケンスについては、全一致規則が一致し、そのテンプレートが展開される場合、$H はホストのフルネームに展開し、$D はドット文字 1 個「.」に展開します。したがって、全一致規則のテンプレートでは、$D の使用が制限されます。
タグ付き書き換え規則セット
書き換えプロセスを実行するにあたり、別の規則セットを追加するとうまくいく場合があります。別の規則セットを追加するには、書き換え規則タグを使用します。現在のタグは、設定ファイルまたはドメインデータベースでパターンが検索される前に、各パターンの前に付けられます。タグは、書き換え規則テンプレート内の $T という代替文字列を使って一致する書き換え規則により変更することができます (後述の説明を参照)。タグは、1 つのアドレスから抽出されたすべてのホストに対し、連続して適用されます。そのため、タグを使用した場合は、別の規則を指定する際にそれが正しいタグ値から始まるように注意してください。一般に、タグは特殊な目的でしか使用しないため、このことが問題になることはほとんどありません。アドレスの書き換えが完了すると、タグはデフォルトのタグ (空白文字列) にリセットされます。
規則により、すべてのタグ値には、その最後に縦棒 (|) が付けられます。この文字は通常のアドレスには使用されないため、パターンの残りの部分とタグとを区別することができます。
書き換え規則のテンプレート
以下の節では、書き換え規則のテンプレートについて詳説します。表 7-2 に、テンプレートの各形式を示します。
テンプレート
使用方法
A は新しいユーザ/メールボックス名になり、B は新しいホスト/ドメイン仕様になります。ホスト C に関連したチャネルに送ります。
A は新しいユーザ/メールボックス名になり、B は新しいホスト/ドメイン名になります。C をソースルートとして挿入し、ホスト D に関連したチャネルに送ります。
よく使われる書き換えテンプレート : A%B@C または A@B
以下に示すテンプレート形式は、最もよく使われるものです。規則は、アドレスのユーザ部分とドメイン部分に適用されます。その後、新しいアドレスがメッセージを特定のチャネル (ChannelTag で指定されたチャネル) へ送るために使用されます。UserTemplate%DomainTemplate@ChannelTag[コントロール]
以下に示すテンプレート形式は、上記のテンプレートと実質的に同じものです。ただし、この形式は、DomainTemplate と ChannelTag が同じ場合にしか使用できません。
UserTemplate@ChannelTag[コントロール]
繰り返し書き換えテンプレート : A%B
以下に示すテンプレート形式は、繰り返して適用する必要がある規則に使用されます。いったん規則が適用された後、その新しいアドレスに対して書き換えプロセス全体が繰り返されます (他の書き換え規則形式の場合は、いずれも規則が適用されたに書き換えプロセスが終了します)。UserTemplate%DomainTemplate[コントロール]
たとえば、以下に示す規則を使うと、.removable というドメイン名で終わるすべてのアドレスから .removable が削除されます。
繰り返し規則を使用する場合には、「規則ループ」が生じないよう特別な注意が必要です。そのため、特に必要がない限り、繰り返し書き換え規則の使用を控えるようお勧めします。繰り返し規則を使用する際には、imsimta test -rewrite コマンドを使って規則をテストするとよいでしょう。test -rewrite コマンドの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
指定ルート書き換えテンプレート : A@B@C@D または A@B@C
以下に示すテンプレート形式は、一般によく使われる形式 UserTemplate%DomainTemplate@ChannelTag (最初の区切り文字が異なります) と同じように機能します。ただし、ChannelTag はソースルートとしてアドレスに挿入されています。メッセージは ChannelTag に送られます。UserTemplate@DomainTemplate@Source-Route
@ChannelTag[コントロール]書き換えられたアドレスは @route:user@domain となります。また、次のテンプレートも使用できます。
UserTemplate@DomainTemplate@ChannelTag[コントロール]
たとえば、以下に示す規則を使うと、jdoe@com1 というアドレスが @siroe.com:jdoe@com1 というソースルートアドレスに書き換えられます。チャネルタグは siroe.com になります。
書き換え規則テンプレートにおける大文字と小文字の区別
書き換え規則内のパターンとは異なり、テンプレートでは大文字と小文字が区別されます。この機能は、大文字と小文字を区別するメールシステムへのインターフェースを提供するような書き換え規則を使用する場合に必要となります。アドレスから抽出された部分の代わりに使われる $U や $D などの置換シーケンスでも、大文字と小文字が区別され、元のアドレスと同じ状態が維持されます。UNIX システムでメールボックスを小文字にする場合など、代替部分に特定の大文字/小文字が使われるようにするには、テンプレートに特殊な置換シーケンスを使用します。たとえば、$\ は後に続く代替部分を小文字にし、$^ は後に続く代替部分を大文字にします。また、$_ は元と同じ状態を保ちます。
たとえば、以下の規則を使うと、unix.siroe.com のアドレスに対するメールボックスを小文字にすることができます。
unix.siroe.com $\$U$_%unix.siroe.com
MTA がアドレスに書き換え規則を適用する方法
以下に、MTA が指定アドレスに書き換え規則を適用する手順について説明します。
アドレスから最初のホスト仕様またはドメイン仕様を抽出します。
これらの動作の詳細については、後続の節を参照してください。
最初のホスト名またはドメイン名を識別した後、そのホスト名またはドメイン名に一致するパターンが含まれている書き換え規則を検索します。
- アドレスには、次のように 1 つ以上のホスト名またはドメイン名が指定されている場合があります。
- jdoe%hostname@siroe.com.
一致する書き換え規則が見つかると、その規則のテンプレート部分に従ってアドレスを書き換えます。
最後に、チャンネルタグと各チャネルに関連するホスト名とを比較します。
- 一致するものが見つかると、MTA は関連するチャネルへのメッセージをキューに入れます。一致するものが見つからない場合、書き換えプロセスは失敗に終わります。一致するチャネルがローカルチャネルの場合は、エイリアスデータベースやエイリアスファイルを検索することによって、さらにアドレスの書き換えが実行される場合があります。
注 既存のどのチャネルにも属さないチャネルタグを使用すると、この規則に一致するアドレスを持つメッセージが戻ってきます。すなわち、一致するメッセージが配信不能となります。
動作 1 最初のホスト/ドメイン仕様を抽出する
アドレスの書き換えプロセスは、アドレスから最初のホストまたはドメイン仕様を抽出することから始まります (以下の説明をより理解するために、RFC 822 アドレス規則について把握しておくことをお勧めします)。アドレス内のホスト/ドメイン仕様が検索される順序は、以下のとおりです。最後の 2 項目の順序は、アドレスの書き換えを行っているチャネルで bangoverpercent キーワードが有効になっているかどうかによって入れ替わります。すなわち、メッセージをキューに入れようとしているチャネルが bangoverpercent チャネルキーワードでマークされているかどうかによって順序が異なります。
表 7-3 に、アドレスと最初に抽出されるホスト名の例を示します。
RFC 822 には、アドレスにおける感嘆符 (!) およびパーセント記号 (%) の解釈が含まれていません。パーセント記号は慣例上 単価記号(@)と同じように解釈されます (単価記号 @がない場合)。この規則は Messaging Server MTA で採用されています。
パーセント記号をローカルユーザ名の一部として扱うために、繰り返しパーセント記号の解釈が使用されます。これは、外部メールシステムのアドレスを処理するような場合に便利です。感嘆符の解釈は、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)。
たとえば、dan@sc.cs.siroe.edu というアドレスを書き換える場合、MTA は以下に示すパターンを上から順番に検索します。比較文字列 spec_1 が設定ファイル内にある各書き換え規則のパターン部分と比較されます。一致するものが見つからない場合は、次にドメインデータベース内が調べられます。このマッチングプロセスは、一致するものが見つかった時点で終了します。
一致するものが見つからなかった場合は、spec_2 の最も左側の部分 (アスタリスク以外) がアスタリスクに変換されます。たとえば、a.b.c という spec_2 は *.b.c に、*.b.c という spec_2 は *.*.c に変換されます。このマッチングプロセスは、一致するものが見つかった時点で終了します。
一致するものが見つからなかった場合は、比較文字列 spec_1 の最初の部分 (先頭のアスタリスクを含む) が削除されます。spec_1 が 1 つの部分だけからなる場合 (たとえば、.c または c) は、ドット文字 1 個に置き換えられます。削除後の新しい spec_1 文字列の長さがゼロでない場合は、動作 1 に戻ります。削除後の新しい文字列の長さがゼロの場合 (たとえば、削除前の文字列が「.」だった場合) は、検索プロセスが失敗に終り、マッチングプロセスが終了します。
sc.cs.siroe.edu
*.cs.siroe.edu
.cs.siroe.edu
*.*.siroe.edu
.siroe.edu
*.*.*.edu
.edu
*.*.*.*
.
動作 3 テンプレートに従ってアドレスを書き換える
ホスト/ドメイン仕様が書き換え規則に一致すると、そのホスト/ドメイン仕様は規則のテンプレート部分を使って書き換えられます。テンプレートには、次の 3 つの仕様があります。
動作 4 書き換えプロセスを終了する
ホスト/ドメイン仕様が書き換えられると、次の 2 つの動作のうちどちらかが行われます。
チャネルタグがローカルチャネルまたは routelocal チャネルキーワードでマークされているチャネルのどちらにも関連付けられていない場合、またはアドレス内に他のホスト/ドメイン仕様がない場合は、書き換え後の指定が抽出された元の指定に置き換えられ、書き換えプロセスが終了します。
チャネルタグがローカルチャネルまたは routelocal でマークされたチャネルに一致し、かつアドレス内に他のホスト/ドメイン仕様がある場合は、書き換え後のアドレスが破棄され、アドレスから元 (最初) のホスト/ドメイン仕様が削除されます。そして、そのアドレスから新しいホスト/ドメイン仕様が抽出され、プロセス全体が繰り返されます。書き換えプロセスは、すべてのホスト/ドメイン仕様がなくなるか、あるいは非ローカルチャネルまたは非ルートローカルチャネルを介したルートが見つかるまで続けられます。MTA がソースルーティングをサポートできるのは、この反復メカニズムがあるからです。実際、ローカルシステムまたはルートローカルシステムを介した不必要なルートは、このプロセスによってアドレスから削除されます。
書き換え規則に一致しなかった場合
ホスト/ドメイン仕様がどの書き換え規則にも一致せず、デフォルトの規則もない場合には、「そのまま」の仕様が使われます。たとえば、元の仕様が新しい仕様およびルーティングシステムになります。アドレスに無意味なホスト/ドメイン仕様が含まれている場合、その仕様は、ルーティングシステムが任意のチャネルに関連付けられたどのシステム名にも一致しないときに検出され、メッセージが戻されます。
書き換え後の構文チェック
書き換え規則が適用された後のアドレスに対し、構文チェックは行われません。これは意図的なものです。構文チェックを行わないようにすることで、書き換え規則を使ってアドレスを RFC 822 に準拠しない形式に変換することができます。ただし、設定ファイル内に間違いがあると、MTA から送り出されるメッセージに不正なアドレスが含まれる可能性もあります。
ドメインリテラルの処理
ドメインリテラルは、特に書き換えプロセス中に処理されます。アドレスのドメイン部分にあるドメインリテラルが書き換え規則のパターンに一致しない場合、そのリテラルは、角括弧で囲まれ、ドット文字で区切られた文字列の集まりとして解釈されます。そして、最も右側にある文字列が削除され、検索が繰り返されます。それでも一致するものが見つからない場合は、角括弧だけが残るまで次々に文字列が削除されていきます。空白の角括弧を使った検索も失敗に終わった場合は、ドメインリテラル全体が削除され、ドメインアドレスの次の部分について書き換え処理が実行されます (次の部分が存在する場合)。ドメインリテラルの内部処理では、アスタリスクが使用されません。ドメインリテラル全体がアスタリスクに置き換えられた場合は、アスタリスクの数とドメインリテラル内の要素の数とが一致します。通常のホスト/ドメイン仕様の場合と同じように、ドメインリテラルの場合も指定した内容に最も近いものから順に検索が行われます。そして、パターンに一致した最初の規則を使って、ホスト/ドメイン仕様の書き換えが行われます。規則リスト内に同じパターンが 2 つある場合は、先に記述されている方の規則が適用されます。
たとえば、dan@[128.6.3.40] というアドレスを書き換えるとします。この場合、まず [128.6.3.40] の検索が行われ、その後 [128.6.3.]、[128.6.]、[128.]、[]、[*.*.*.*]、そして最後に全一致規則「.」という順に検索が実行されます。
ドメインリテラルとドメイン名が組み合わさっている場合は、検索試行の回数がかなり多くなります。この方法は一般的ではないため、この方法を使用することはお勧めしません。たとえば、dan@[1.2].a.[3.4].b というアドレスの場合は、以下に示す検索が実行されます。
[1.2].a.[3.4].b
[1.].a.[3.4].b
[].a.[3.4].b
[*.*].a.[3.4].b
.a.[3.4].b
[*.*].*.[3.4].b
.[3.4].b
[*.*].*.[3.].b
.[3.].b
[*.*].*.[].b
.[].b
[*.*].*.[*.*].b
.b
[*.*].*.[*.*].*
.
テンプレートの置換シーケンスと書き換え規則コントロールシーケンス
置換シーケンスは、書き換え後のアドレスに文字列を挿入することにより、ユーザ名またはアドレスを書き換えるために使用します。挿入される文字列は、使用している置換シーケンスによって決まります。たとえば、以下のテンプレートでは、$U が置換シーケンスです。この置換シーケンスを使用することにより、書き換えられるアドレスのユーザ名部分がテンプレートの出力に挿入されます。したがって、このテンプレートによって jdoe@mailhost.siroe.com が書き換えられる場合、その出力は jdoe@siroe.com となります。つまり、$U が元のアドレスの ユーザ名部分に置き換えられます。
コントロールシーケンスは、書き換え規則を適用するうえで、さらに条件を加えるためのものです。すなわち、書き換え規則のパターン部分がホスト/ドメイン仕様に一致しなければならないだけでなく、書き換えるアドレスの他の要素がコントロールシーケンスの条件を満たしていなければなりません。たとえば、$E コントロールシーケンスは、書き換えるアドレスがエンベロープアドレスでなければならないことを意味します。また、$F コントロールシーケンスは、そのアドレスが前方を探すアドレスでなければならないことを意味します。以下の書き換え規則は、user@siroe.com 形式の (書き換え) エンベロープ「To:」アドレスにのみ適用されます。
siroe.com $U@mail.siroe.com$E$F
ホスト/ドメイン仕様は書き換え規則のパターン部分に一致するが、テンプレート内のコントロールシーケンスに指定されている条件がすべて満たされない場合、その書き換え規則は失敗に終わり、他の適用可能な規則が検索されます。
表 7-4 に、テンプレートの置換シーケンスおよびコントロールシーケンスを示します。
表 7-4 テンプレートの置換シーケンスとコントロールシーケンス
置換シーケンス
置き換える内容
コントロールシーケンス
書き換え規則における効果
ユーザ名とサブアドレスの代替 : $U、$0U、$1U
テンプレート内にある $U はすべて、元のアドレスから抽出されたユーザ名 (RFC 822「ローカル部」) に置き換えられます。この場合、a."b" 形式のアドレスは "a.b" に置き換えられます。現在行われているインターネットの標準化では、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 というアドレスが以下の規則に一致したとします。
host.siroe.com $U%$1D@TCP-DAEMON
この規則が適用されると、出力チャネルに 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 のオプション部分を表しています。
ldap:///dn[?attributes[?scope?filter]]
dn は検索ベースを指定する名前で、この部分は必須です。URL のオプションである属性 (attributes)、範囲 (scope)、フィルタ (filter) は、戻される情報を指定するためのものです。書き換え規則の場合、戻される情報を指定するための属性として望ましいのは mailRoutingSystem 属性 (または同様の属性) です。範囲は、任意のベース (デフォルト)、one、または sub にすることができます。また、フィルタには、mailDomain の値が書き換えられるドメインに一致するオブジェクトを戻すようなリクエストを指定するとよいでしょう。
LDAP ディレクトリスキーマに mailRoutingSystem および mailDomain 属性が含まれている場合、指定アドレスの送り先となるシステムを決定する書き換え規則は、たとえば次のようになります。この例で、作成された LDAP クエリ内の LDAP URL 置換シーケンス $D は、現在のドメイン名に置き換えられます。
.siroe.com \ $U%$H$D@$]ldap:///o=siroe.com?mailRoutingSystem?sub? \
(mailDomain=$D)[この例で使われているバックスラッシュは、書き換え規則の 1 行が次の行に続いていることを示すためのものです。表 7-5 に、LDAP URL 置換シーケンスを示します。
置換シーケンス
説明
一般データベースの代替 : $(...)
$(テキスト) 形式の置換シーケンスは、特殊な方法で処理されます。テキスト部分は、特殊な一般データベースにアクセスするためのキーとして使われます。このデータベースは、/imta/config/imta_tailor ファイル内の IMTA_GENERAL_DATABASE オプションで指定されているファイル (通常、/imta/db/generaldb.db ファイル) で構成されています。このデータベースは、imta crdb ユーティリティを使って作成されます。「テキスト文字列」がデータベース内のエントリに一致すると、データベース内の対応するテンプレートがその文字列に置き換えられます。「テキスト文字列」がデータベース内のどのエントリにも一致しなかった場合は、書き換えプロセスが失敗に終わります。つまり、最初から何も一致しなかったのと同じ状態に戻ります。置き換えがうまくいくと、次にデータベースから抽出されたテンプレートに別の置換シーケンスが含まれていないかどうかが調べられます。ただし、抽出されたテンプレート内に別の $(テキスト) を含めることは禁じられています。参照ループが発生する可能性があるからです。
例として、次の書き換え規則に jdoe@siroe.siroenet というアドレスが一致した場合を考えてみましょう。
まず、一般データベースで siroe というテキスト文字列が検索され、その結果 (見つかった場合) が書き換え規則のテンプレートとして用いられます。ここで、siroe の検索結果を $u%eng.siroe.com@siroenet とします。この場合、テンプレートの出力は jdoe@eng.siroe.com (すなわち、ユーザ名 = jdoe、ホスト/ドメイン仕様 = eng.siroe.com) になり、ルーティングシステムは siroenet になります。
一般データベースは、正しい操作を行うために誰でも読み取り可能でなければなりません。
指定マッピングの適用 : ${...}
${mapping,argument} 形式の置換シーケンスは、MTA マッピングファイルでマッピングを検索し、見つかったマッピングを適用するのに使用します。mapping フィールドにはマッピングテーブルの名前を指定し、argument フィールドにはマッピングへ渡す文字列を指定します。この置換シーケンスを使用するには、指定したマッピングが存在し、かつその出力に $Y フラグが設定されていなければなりません。マッピングが存在しなかったり、$Y フラグが設定されていない場合、書き換えは失敗に終わります。問題なく処置が行われた場合は、マッピングの結果がテンプレート内の同じ位置にマージされた後、再び展開されます。このメカニズムにより、様々な方法で MTA 書き換えプロセスを展開することができます。たとえば、アドレスのユーザ名部分を選択しながら分析したり変更することができます。通常の MTA 書き換えプロセスに、このような機能はありません。
カスタマ指定ルーチンの代替 : $[...]
$[image,routine,argument] 形式の置換シーケンスは、カスタマ指定ルーチンを検索し、呼び出すのに使用します。UNIX において、MTA は dlopen および dlsym を使って動的に共有ライブラリイメージから指定したルーチンをロードし、呼び出します。そのとき、そのルーチンは以下の引数をともなった関数として呼び出されます。status := routine (argument, arglength, result, reslength)
argument および result は、252 バイトの文字列バッファです。UNIX 上で、argument と result は文字列へのポインタ (例、C 言語の char*) として渡されます。arglength と reslength は、参照によって渡される符号付の long 型整数です。入力時、argument には書き込み規則テンプレートからの引数文字列が含まれ、arglength にはその文字列の長さが含まれます。値を返すときには、result に結果文字列が入り、reslength にその長さが入ります。そして、結果的に得られた文字列が書き換え規則テンプレート内の "$[image,routine,argument]" に置き換わります。routine の値として 0 が返された場合には書き換え規則が有効になり、-1 が返された場合には書き換え規則が失敗に終わります。
このメカニズムによって、書き換えプロセスの複雑な展開が可能になります。たとえば、あるタイプの名前サービスに対して呼び出しを実行し、その結果を使って名前を変化させることができます。前方を探すアドレス (例、To: アドレス) のディレクトリサービス検索を siroe.com というホストに対して実行する場合には、以下のような書き込み規則を使用します。$F を使うことによって、この規則が前方を探すアドレスにのみ適用されるようになります。$F の詳細については、「方向および位置に固有の書き換え規則 ($B、$E、$F、$R)」を参照してください。
siroe.com $F$[LOOKUP_IMAGE,LOOKUP,$U]
jdoe@siroe.com という前方を探すアドレスがこの規則に一致すると、メモリ内に LOOKUP_IMAGE (UNIX の共有ライブラリ) がロードされ、jdoe を引数パラメータとしてともなった LOOKUP ルーチンが呼び出されます。その後、LOOKUP ルーチンは、結果パラメータ内の John.Doe%eng.siroe.com などの別の名前と書き換え規則が適用されたことを示す値 (-1) を返します。結果文字列内のパーセント記号 (「繰り返し書き換えテンプレート : A%B」 を参照) は、書き換えプロセスを繰り返すためのものです。この場合、書き換え元のアドレスには John.Doe@eng.siroe.com が使用されます。
UNIX システムでは、サイト提供の共有ライブラリイメージが誰でも読み取り可能でなければなりません。
注 この機能は、Messaging Server の機能をシステム全体に拡張するためのもので、一般ユーザが使用するものではありません。
単一フィールドの代替 : $&、$!、$*、$#
単一フィールド置換シーケンスは、書き換えるホスト/ドメイン仕様からサブドメイン部分を抽出するためのものです。表 7-6 に、使用可能な単一フィールド置換シーケンスを一覧します。
jdoe@eng.siroe.com というアドレスが次の書き換え規則に一致したとします。
*.SIROE.COM $U%$&0.siroe.com@mailhub.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、または $? までの間にある文字がチャネル名として解釈されます。
たとえば、$Mchannel を使用したときに channel が現在書き換えを行っているチャネルでない場合は、規則が適用されません。また、$Nchannel を使用したときに channel が書き換えを行っている場合も、規則が適用されません。複数の $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、または $? までの間にある文字がチャネル名として解釈されます。
たとえば、$Qchannel を使用したときに channel が宛先でない場合は、規則が適用されません。また、$Cchannel を使用したときに channel が宛先である場合にも、規則は適用されません。複数の $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 つのコントロールシーケンスを使用できます。
規則をソースルートから抽出されたホストに一致させるには、$S を使用します。
ホスト名が指定した位置にない場合は、規則の適用が失敗に終わります。これらのシーケンスは、1 つの書き換え規則内で組み合わせることもできます。たとえば、$S と $A を指定すると、規則はソースルート内のホスト名または単価記号 @の右側にあるホスト名のいずれかに一致します。これらのシーケンスをすべて指定したのと、どれも指定しないのとは同じことです。すなわち、規則はホスト名の位置に関係なく一致します。規則を単価記号 @の右側にあるホストに一致させるには、$A を使用します。
現在のタグ値の変更 ($T)
現在の書き換え規則タグを変更するには、$T コントロールシーケンスを使用します。書き換え規則タグはすべての書き換え規則パターンの先頭に付けられ、その後、設定ファイルやドメインデータベースで書き換え規則パターンの検索が行われます。$T の直後から単価記号 @、パーセント記号 %、$N、$M、$Q、$C、$T、または $? までの間のテキストが新しいタグとして扱われます。タグは、特定のコンポーネントが検出されたときにアドレスの特性全体が変わるような、特殊なアドレス形式を処理する場合に便利です。たとえば、internet という特別なホスト名が見つかったときに、そのホスト名をアドレスから削除し、削除後のアドレスを強制的に TCP-DAEMON チャネルにマッチングするとします。
これは、以下のような規則を使って実行できます (ローカルホストの正式な名前を localhost とします)。
internet $S$U@localhost$Tmtcp-force|
最初の規則は、ソースルート内で internet という特別なホスト名が見つかった場合、そのホスト名に一致します。その後、ローカルチャネルと internet とのマッチングが行われ、アドレスから internet が削除されます。そして、書き換えタグが設定されます。書き換えプロセスは続けられますが、タグに対して通常の規則が一致することはありません。最後に、デフォルトの規則がタグとともに試され、2 番目の規則に移ります。この規則では、他の条件に関係なく、アドレスが強制的に TCP-DAEMON チャネルに対してマッチングされます。
書き換えに関連するエラーメッセージの制御 ($?)
MTA には、書き換えとチャネルの照合に失敗したときに表示されるデフォルトのエラーメッセージがあります。これらのメッセージは、特定の条件下で変更することができます。たとえば、誰かが Ethernet ルータボックスにメールを送信しようとした場合などは、「不正なホスト/ドメインが指定されています」というより「ルータがメールを受け入れられません」というメッセージを表示した方がより適切です。特殊なコントロールシーケンスを使って、規則の適用に失敗した場合に印刷されるエラーメッセージを変更することができます。エラーメッセージを指定するには、$? シーケンスを使用します。$? の直後から単価記号 @、% 記号、$N、$M、$Q、$C、$T、または $? までの間のテキストがエラーメッセージのテキストとして扱われます。このエラーメッセージは、書き換えの結果がどのチャネルにも一致しなかった場合に印刷されます。エラーメッセージの設定は記憶され、書き換えプロセスを通じて有効となります。
$? を含む規則も他の規則と同じように動作します。特別なケースとして、$? だけを含む規則には注意してください。この場合、アドレスのメールボックスまたはホスト部分は変更されずに書き換えプロセスが終了し、ホストがチャネルテーブル内で検索されます。この検索は失敗に終り、その結果としてエラーメッセージが返されます。
たとえば、MTA 設定ファイル内に、次に示すような最終的な書き換え規則があるとします。
. $?Unrecognized address; contact postmaster@siroe.com
この例で、認識されないホスト/ドメイン仕様は、その失敗のプロセスにおいて、「Unrecognized address; contact postmaster@siroe.com」というエラーメッセージを生成します。
多数の書き換え規則を扱う
MTA は常に imta.cnf ファイルからすべての書き換え規則を読み取り、メモリ内のハッシュテーブルにそれらの規則を保存します。コンパイルした設定を使用すると、情報が必要になるたびに設定ファイルを読み取るという作業を省くことができます。この場合でも、メモリ内にすべての書き込み規則を保存するためにハッシュテーブルが使われます。この方法は、書き換え規則があまり多くない場合に適しています。サイトによっては 10,000 個以上の書き換え規則が必要になる場合もあります。このような場合には、かなり多くのメモリを費やさなければなりません。MTA では、補助的なインデックス付きデータファイルに多数の書き換え規則を保存するオプションの機能を使って、この問題を解決することができます。通常の設定ファイルが読み取られるたびに、MTA はドメインデータベースがあるかどうかを調べます。データベースがある場合は、設定ファイルの規則が照合に失敗するたびにそのデータベースが開かれ、その内容が調べられます。ドメインデータベースが調べられるのは、指定された規則が設定ファイル内に見つからなかったときだけです。そのため、規則はいつでも設定ファイルに追加することができ、それによってデータベース内の規則が無効になります。特に設定を変更しない限り、ドメインデータベースは、ホストドメインに関連する書き換え規則を保存するために使用されます。IMTA_DOMAIN_DATABASE 属性は imta_tailor ファイルに保存されています。このデータベースのデフォルトの場所は サーバ-インスタンス/imta/db/domaindb.db です。
注 このファイルは手作業で編集しないでください。Directory Server でホストドメインが Directory Server で作成されると、dirsync プロセスが既存のドメインデータベースを上書きします。そのため、カスタム編集した内容は失われてしまいます。
書き換え規則をテストする
書き換え規則をテストするには imsimta test -rewrite コマンドを使用します。-noimage 修飾子を使うと、新しい設定をコンパイルする前に、設定ファイルに加えた変更内容をテストすることができます。このユーティリティと -debug 修飾子を使って少数のアドレスを書き換えると便利かもしれません。この場合、ステップバイステップ形式でアドレスの書き換えが行われます。たとえば、以下のコマンドを実行します。
% imsimta test -rewrite -debug joe@siroe.com
imsimta test -rewrite ユーティリティの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
書き換え規則の例
以下に、書き換え規則の例とそれらの規則によってサンプルアドレスがどのうように書き換えられるかを示します。SC.CS.SIROE.EDU システムの設定ファイルに、図 7-2 に示す書き換え規則が含まれているとします。
図 7-2 書き換え規則の例
表 7-7 に、サンプルアドレスとそれらの書き換え結果およびルートを示します。
最初のアドレス
書き換え後
ルート
基本的に、これらの書き換え規則の内容は次のとおりです : ホスト名が短形式の名前 (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 に準拠しないメールソフトウェア (ホスト/ドメイン仕様をアドレスのユーザ名部分に詰め込む必要があるメールソフトウェア) へのインターフェースとして使われる場合に使用されます。この機能を使用する際には、十分な配慮が必要です。
前へ 目次 索引 次へ
Copyright (c) 2001 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2001 Netscape Communications Corp. All rights reserved.
最終更新日 2001 年 5 月 24 日