前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



第 7 章   書き換え規則を設定する


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

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

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


注

imta.cnf ファイル内の書き換え規則を変更する場合は、imsimta start コマンドを使って起動するときに設定データを 1 回だけ読み込むようなプログラムまたはチャネルを再起動する必要があります (例 : SMTP サーバ)。コンパイルされた設定を使用する場合は、設定を再コンパイルしたあとにプログラムを再起動する必要があります。

設定情報のコンパイルおよびプログラムの再起動については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。




書き換え規則の構造


書き換え規則は MTA 設定ファイル imta.cnf の前半にあります。設定ファイルに、各規則が 1 行ごとに記述されています。規則間にコメントを記述することは可能ですが、空白行を挿入することはできません。書き換え規則の最後には空白行が挿入され、その後ろにチャネルの定義が続きます。図 7-1 に、設定ファイル内の書き換え規則を示します。

図 7-1   
! test.cnf - 設定ファイルの例。
!
! これは、単に設定ファイルの例です。It serves
! no useful purpose and should not be used in a real system.
!
a.com   $U@a-host
b.org   $U@b-host
c.edu   $U%c@b-daemon
d.com   $U%d@a-daemon

! 以下、チャネルの定義が続きます。
設定ファイルの例 - 書き換え規則

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

pattern

検索の対象となるドメイン名内の文字列です。図 7-1 では、パターンは a.com、b.org、c.edu、および d.com です。

パターンがアドレスのドメイン部分に一致すると、その書き換え規則がアドレスに適用されます。パターンの後ろには空白文字を挿入して、テンプレート部分を区別できるようにします。パターンのシンタックスについては、「書き換え規則のパターンとタグ」を参照してください。

template

以下のいずれかの形式を使って指定します。

UserTemplate%DomainTemplate@ChannelTag[controls]

UserTemplate@ChannelTag[controls]

UserTemplate%DomainTemplate[controls]

UserTemplate@DomainTemplate@ChannelTag[controls]

UserTemplate@DomainTemplate@SourceRoute@ChannelTag[controls]

UserTemplate

アドレスのユーザ部分をどのように書き換えるかを指定します。元のアドレスの一部またはデータベース検索の結果を表すために置換シーケンスを使用することもできます。置換シーケンスは、アドレスを書き換える際に、それが表す本来の文字列に置き換えられます。図 7-1 では、$U という置換シーケンスが使用されています。詳細は、「テンプレートの置換シーケンスと書き換え規則コントロールシーケンス」を参照してください。

DomainTemplate

アドレスのドメイン部分をどのように書き換えるかを指定します。UserTemplate と同様に、DomainTemplate にも置換シーケンスを含めることができます。

ChannelTag

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

controls

コントロールを使って、規則の適用度を制限できます。コントロールシーケンスの中には、規則の前に置くものと、規則の後ろに置くものとがあります。コントロールについては、「テンプレートの置換シーケンスと書き換え規則コントロールシーケンス」を参照してください。

テンプレートのシンタックスについては、「書き換え規則のテンプレート」を参照してください。



書き換え規則のパターンとタグ


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

一般に、書き換え規則のパターンは、特定のホスト名 (そのホスト名だけに一致) またはサブドメインパターン (サブドメイン全体における任意のホスト / ドメインに一致) のいずれかで構成されます。

たとえば、次の書き換え規則のパターンには、特定のホスト名が含まれています。このパターンは、この指定したホスト名だけに一致します。

host.siroe.com

次の書き換え規則のパターンには、サブドメインパターンが含まれています。このパターンは、サブドメイン全体における任意のホストまたはドメインに一致します。

.siroe.com

ただし、このパターンは 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 (server-instance/imta/config/internet.rules) ファイル内の設定に含められます。

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

  • トップレベルのインターネットドメインに一致するパターンを含んだ書き換え規則

  • そのようなパターンに一致するアドレスを書き換える、送信 TCP/IP チャネルに対するテンプレート

!    Ascension Island
.AC                                     $U%$H$D@TCP-DAEMON
. [簡潔にするため
.    テキストを
.             省略]
!    Zimbabwe
.ZW                                     $U%$H$D@TCP-DAEMON

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

[1.2.3.4]

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

[1.2.3.]

ホストあるいはサブドメイン名を使った一般的な書き換え規則パターンのほかに、特殊なパターンを使用することもできます。これらの特殊なパターンについては、表 7-1 およびそのあとの説明を参照してください。

表 7-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 はドット文字 1 個「.」に展開します。したがって、全一致規則のテンプレートでは、$D の使用が制限されます。



タグ付き書き換え規則セット

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

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

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



書き換え規則のテンプレート


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

表 7-2    書き換え規則のテンプレート形式

テンプレート

ページ

使用目的

A%B  

170  

A は新しいユーザ / メールボックス名になり、B は新しいホスト / ドメイン仕様になる。繰り返して書き換える  

A@B  

170  

A%B@B として扱われる  

A%B@C  

170  

A は新しいユーザ / メールボックス名になり、B は新しいホスト / ドメイン仕様になる。ホスト C に関連したチャネルに送る  

A@B@C  

171  

A@B@C@C として扱われる  

A@B@C@D  

171  

A は新しいユーザ / メールボックス名になり、B は新しいホスト / ドメイン名になる。C をソースルートとして挿入し、ホスト D に関連したチャネルに送る  


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

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

UserTemplate%DomainTemplate@ChannelTag[controls]

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

UserTemplate@ChannelTag[controls]


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

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

UserTemplate%DomainTemplate[controls]

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

.removable      $U%$H

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


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

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

UserTemplate@DomainTemplate@Source-Route
    @ChannelTag[controls]

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

UserTemplate@DomainTemplate@ChannelTag[controls]

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

com1 $U@com1@siroe.com


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

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

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

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

unix.siroe.com    $¥$U$_%unix.siroe.com



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


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

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

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

    jdoe%hostname@siroe.com.

  2. 最初のホスト名またはドメイン名を識別したあと、そのホスト名またはドメイン名に一致するパターンが含まれている書き換え規則を検索します。

  3. 一致する書き換え規則が見つかると、MTA により、その規則のテンプレート部分に従ってアドレスが書き換えられます。

  4. 最後に、チャンネルタグと各チャネルに関連するホスト名が比較されます。

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

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

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



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

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

  1. ソースルートのホスト (左から右へ読み取り)

  2. 単価記号 (@) の右側にあるホスト

  3. 最後のパーセント記号 (%) の右側にあるホスト

  4. 最初の感嘆符 (!) の左側にあるホスト

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

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


表 7-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 では、特に大文字と小文字を区別しませんが、可能な限り元の状態が維持されます。

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

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

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

  • ホスト / ドメイン仕様が比較文字 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つの仕様があります。

  1. アドレスの新しいユーザ名

  2. アドレスの新しいホスト / ドメイン仕様

  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.]、[]、[*.*.*.*]、そして最後に全一致規則 「.」という順に検索が実行されます。



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


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

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

$U@siroe.com

コントロールシーケンスは、書き換え規則を適用するうえで、さらに条件を加えるためのものです。すなわち、書き換え規則のパターン部分がホスト / ドメイン仕様に一致しなければならないだけでなく、書き換えるアドレスのほかの要素がコントロールシーケンスの条件を満たしていなければなりません。たとえば、$E コントロールシーケンスは、書き換えるアドレスがエンベロープアドレスでなければならないことを意味します。また、$F コントロールシーケンスは、そのアドレスが前方を探すアドレスでなければならないことを意味します。以下の書き換え規則は、user@siroe.com 形式の (書き換え) エンベロープの To: アドレスにのみ適用されます。

siroe.com $U@mail.siroe.com$E$F

ホスト / ドメイン仕様は書き換え規則のパターン部分に一致するが、テンプレート内のコントロールシーケンスに指定されている条件がすべて満たされない場合、その書き換え規則は失敗に終わり、ほかの適用可能な規則が検索されます。

表 7-4 に、テンプレートの置換シーケンスとコントロールシーケンスを示します。


表 7-4    テンプレート置換シーケンスとコントロールシーケンス 

置換シーケンス

置き換える内容

$D  

一致したドメイン仕様の部分  

$H  

ホスト / ドメイン仕様の不一致部分。パターン内のドットの左側  

$L  

ドメインリテラルの不一致部分。パターンリテラル内のドットの右側  

$U  

元のアドレスのユーザ名  

$0U  

元のアドレスのローカル部分 (ユーザ名)。サブアドレスは含まない  

$1U  

元のアドレスのローカル部分 (ユーザ名) にあるサブアドレス (存在する場合のみ)  

$$  

ドル記号 ($) を挿入  

$%  

パーセント記号 (%) を挿入  

$@  

単価記号 (@) を挿入  

$¥  

小文字にする  

$^  

大文字にする  

$_  

元の大文字 / 小文字を使用  

$W  

ランダムに選択される固有文字列の置換  

$]...[  

LDAP クエリの URL 検索  

$ (テキスト)  

一般データベースの置換。検索に失敗すると、規則も失敗する  

${...}  

与えられた文字列に指定マッピングを適用  

$[...]  

カスタマ提供のルーチンを起動する。結果の置換  

$&n  

一致しなかった (またはワイルドカードを使った) ホストの n 番目の部分。0 から始まり、左から右へ数える  

$!n  

一致しなかった (またはワイルドカードを使った) ホストの n 番目の部分。0 から始まり、右から左へ数える  

$*n  

一致したパターンの n 番目の部分。0 から始まり、左から右へ数える  

$#n  

一致したパターンの n 番目の部分。0 から始まり、右から左へ数える  

$nD  

一致したドメイン仕様の一部。左側の 0 から n 番目までの部分が残される  

$nH  

一致しなかったホスト / ドメイン仕様の一部。左側の 0 から n 番目までの部分が残される  

コントロールシーケンス  

書き換え規則における効果  

$1M  

チャネルが内部再処理チャネルの場合にのみ適用される  

$1N  

チャネルが内部再処理チャネルでない場合にのみ適用される  

$1~  

保留状態のチャネルの照合チェックを実行する。チェックに失敗した場合、現在の書き換え規則テンプレートの処理は正常に終了する  

$A  

ホストが単価記号 @ の右側にある場合に適用される  

$B  

ヘッダー / 本文アドレスにのみ適用される  

$C channel  

channel へ送る場合は適用されない  

$E  

エンベロープアドレスにのみ適用される  

$F  

前方を探すアドレス (例 : To: ) にのみ適用される  

$M channel  

channel がアドレスを書き換える場合にのみ適用される  

$N channel  

channel がアドレスを書き換える場合は適用されない  

$P  

ホストがパーセント記号の右側にある場合に適用される  

$Q channel  

channel へ送る場合に適用される  

$R  

後方を探すアドレス (例 : From: ) にのみ適用される  

$S  

ホストがソースルートからのものである場合に適用される  

$Tnewtag  

書き換え規則タグを newtag に設定する  

$Vhost  

ホスト名が 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 は number/ 1000000 (1 桁目)

  • b は (number/1000) 残り 1000 (2 桁目から 4 桁目の値)

  • c は number の残り 1000 (最後の 3 桁の値)

以下の例では、エラーコードを 3.45.89 に設定する

$3045089?the snark is a boojum  


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

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

テンプレート内にある $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 置換シーケンスの一覧を示します。

表 7-5    LDAP URL 置換シーケンス 

置換シーケンス

説明

$$  

リテラル $ 文字  

$~ account  

ユーザアカウントのホームディレクトリ  

$A  

アドレス  

$D  

ドメイン名  

$H  

ホスト名 (完全なドメイン名の最初の部分)  

$L  

~ または _ などの特別な先頭文字を除くユーザ名  

$S  

サブアドレス  

$U  

ユーザ名  


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

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

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

例として、次の書き換え規則に jdoe@siroe.siroenet というアドレスが一致した場合を考えてみます。

.SIROENET $($H)

まず、一般データベースで 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 を指定すると、この書き換え規則を前方を探すアドレスだけに使用することができます。詳細は 「方向および位置に固有の書き換え規則($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 システムでは、サイト提供の共有ライブラリイメージはだれでも読み取り可能でなければなりません。


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

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

表 7-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 というアドレスが次の書き換え規則に一致したとします。

*.SIROE.COM      $U%$&0.siroe.com@mailhub.siroe.com

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


固有文字列の置換

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


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

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

  1. 名前が 1 つのチャネルに届くメッセージ内にある場合

  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 を使用します。

  • 規則を単価記号 @ の右側にあるホストに一致させるには、$A を使用します。

  • 規則を % 記号の右側にあるホストに一致させるには、$P を使用します。

  • 規則を感嘆符 (!) の左側にあるホストに一致させるには、$X を使用します。

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


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

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

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

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

internet               $S$U@localhost$Tmtcp-force|

mtcp-force|.           $U%$H@TCP-DAEMON

最初の規則は、ソースルート内で 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 ファイルに保存されています。このデータベースのデフォルトの場所はserver-instance/imta/db/domaindb.db です。

注

このファイルは手作業で編集しないでください。Directory Server でホストドメインが作成されると、dirsync プロセスが既存のドメインデータベースを上書きします。そのため、カスタム編集した内容は失われてしまいます。




書き換え規則をテストする


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

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

% imsimta test -rewrite -debug joe@siroe.com

imsimta test -rewrite ユーティリティの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。



書き換え規則の例


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

SC.CS.SIROE.EDU システムの設定ファイルに、図 7-2 に示す書き換え規則が含まれているとします。

図 7-2    書き換え規則の例

sc                     $U@sc.cs.siroe.edu
sc1                    $U@sc1.cs.siroe.edu
sc2                    $U@sc2.cs.siroe.edu
*                      $U%$&0.cs.siroe.edu
*.cs                   $U%$&0.cs.siroe.edu
*.cs.siroe             $U%$&0.cs.siroe.edu
*.cs.siroe.edu         $U%$&0.cs.siroe.edu@ds.adm.siroe.edu
sc.cs.siroe.edu        $U@$D
sc1.cs.siroe.edu       $U@$D
sc2.cs.siroe.edu       $U@$D
sd.cs.siroe.edu        $U@sd.cs.siroe.edu
.siroe.edu             $U%$H.siroe.edu@cds.adm.siroe.edu
.edu                   $U@$H$D@gate.adm.siroe.edu
[]                     $U@[$L]@gate.adm.siroe.edu


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

表 7-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 に準拠しないメールソフトウェア (ホスト / ドメイン仕様をアドレスのユーザ名部分に詰め込む必要があるメールソフトウェア) へのインタフェースとして使われる場合に使用されます。この機能を使用する際には、十分な配慮が必要です。


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日