内部形式から公的な形式にアドレスを変換するには

アドレスは、アドレスリバースデータベース (リバースデータベースとも呼ばれる) と REVERSE マッピングテーブルを使って内部形式から公的なアドバタイズ形式に変換することができます。たとえば、uid@mailhost.siroe.com は、siroe.com ドメイン内では有効なアドレスであっても、外部に公開するには適切なアドレスではない場合があります。この場合は、firstname.lastname@siroe.com のような公式アドレスを使用することをお勧めします。

Messaging Server には、aliases ファイルや特殊化されたマッピングテーブルなど、アドレス操作のためのその他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換えルールを使用するようにしてください。第 11 章「書き換えルールの設定」を参照してください。

リバースデータベースでは、各ユーザーの公式アドレスはディレクトリ内のユーザーエン トリのmail 属性で指定されています。プライベートアドレスや内部アドレスは、mailAlternativeAddress 属性で指定されています。配布リストについても同様です。

リバースデータベースには、有効なアドレスと公式アドレスとの間のマッピングが含まれています。通常、リバースデータベースは MTA データベースディレクトリにあります。このデータベースは、msg_svr_base/config/imta_tailor ファイルの IMTA_REVERSE_DATABASE オプションで名前が指定されているファイルで構成されます。特に設定を変更しない限り、これらのファイルは msg_svr_base/data/db/reversedb.* です。

データベース内でアドレスが見つかった場合は、そのデータベースの対応する右側部分がアドレスとして置き換えられます。アドレスが見つからなかった場合は、mappings ファイルで REVERSE という名前のマッピングテーブルが検索されます。このマッピングテーブルが存在しない場合、またはマッピングテーブル内に一致するエントリがない場合には、置換は行われず、書き換えは通常どおりに終了します。

REVERSE マッピングテーブルが mappings ファイル内にあり、アドレスがマッピングエントリと一致し、そのエントリが $Y を指定している場合は、結果の文字列によってアドレスが置き換えられます。$N を指定している場合は、マッピングの結果が破棄されます。マッピングエントリが $Y のほかに $D を指定している場合は、結果の文字列を使ってもう一度リバースデータベースがスキャンされます。一致するエントリが見つかった場合は、データベースのテンプレートによってマッピングの結果 (つまりアドレス) が置き換えられます。一般的な REVERSE マッピングテーブルエントリ (すべてのチャネルに適用されるエントリ) の形式は、以下のとおりです。フラグは、新しいアドレスの前または後ろに指定できます。

REVERSE

   OldAddress        $Y[Flags]NewAddress

      

チャネル固有のエントリ (特定のチャネルから渡されるメッセージ上でのみ実行されるマッピング) の形式は、次のとおりです。チャネル固有のエントリを機能させるには、option.dat で use_reverse_database を 13 に設定する必要があります。

REVERSE

   source-channel|destination-channel|OldAddress  $Y[Flags]NewAddresS

      

REVERSE マッピングテーブルのフラグを表 10–7 に示します。

アドレスリバース制御を設定するには

reverse チャネルキーワードと noreverse チャネルキーワード、および MTA の USE_REVERSE_DATABASE オプションと REVERSE_ENVELOPE オプションを使用して、アドレスリバースを適用する時期や方法などの指定を制御できます。デフォルトでは、アドレスリバース操作は、後方を探すアドレスだけではなく、すべてのアドレスに適用されます。

アドレスリバースは、REVERSE_ENVELOPE システムオプションの値を設定することによって (デフォルト: 1-on、0-off)、有効または無効にすることができます。

宛先チャネル上の noreverse は、アドレスリバースがメッセージ内のアドレスに適用されないことを指定します。reverse は、アドレスリバースが適用されることを指定します。詳細は、「チャネル固有のリバースデータベースの使用を有効にする」を参照してください。

USE_REVERSE_DATABASE は、MTA が置換アドレスとしてアドレスリバースデータベースとREVERSE マッピングを使用するかどうかを制御します。値 0 は、アドレスリバースがどのチャネルでも使われないことを示します。値 5 (デフォルト) は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけではなく、すべてのアドレスに適用されることを指定します。値 13 は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけでなく、reverse チャネルキーワードを含むアドレスに適用されることを意味します。また、USE_REVERSE_DATABASE オプションのビット値を設定して、アドレスリバース操作の単位を指定することもできます。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Option File Format and Available Options」を参照してください。

REVERSE_ENVELOPE オプションは、メッセージヘッダーアドレスとともにエンベロープ From アドレスにもアドレスリバースを適用するかどうか制御します。

これらの効果の詳細については、『Sun Java System Messaging Server Administration Reference』の各オプションおよびキーワードの説明を参照してください。

一般的なリバースマッピングの例

一般的な REVERSE マッピングの例を次に示します。この例では、siroe.com の内部アドレスの形式が user@mailhost.siroe.com であると仮定しています。ただし、ユーザーのネームスペースでは、user@host1.siroe.com と user@host2.siroe.com が siroe.com のすべてのホストで同じユーザーを指定しています。次の REVERSE マッピングは、アドレスリバースデータベースとともに使用できます。

REVERSE

   *@*.siroe.com        $0@siroe.com$Y$D
            

この例では、name@anyhost.siroe.com という形式のアドレスが name@siroe.com に変換されています。$D メタキャラクタでは、アドレスリバースデータベースが参照されるようになります。アドレスリバースデータベースには、以下の形式のエントリが含まれています。

user@mailhost.siroe.com     first.last@siroe.com

            

チャネル固有のリバースマッピングの例

デフォルトでは、ルーティングの範囲がメールサーバードメインに設定されている場合に、アドレスリバースデータベースが使用されます。チャネル固有の REVERSE マッピングテーブルエントリの例を以下に示します。

REVERSE

   tcp_*|tcp_local|binky@macho.siroe.com    $D$YRebecca.Woods@siroe.com
            

このエントリは、MTA に対して、ソースチャネル tcp_* から宛先チャネル tcp_local に送信されるすべてのメールのアドレス形式を、binky@macho.siroe.com から Rebecca.Woods@siroe.com に変更するように指示します。

チャネル固有のリバースマッピングを有効にするには、option.dat の USE_REVERSE_DATABASE オプションを 13 に設定する必要があります (デフォルト =5)。

正引き検索テーブルと FORWARD アドレスのマッピング

アドレスリバースは、エンベロープ To: アドレスには適用されません。これは、エンベロープ To: アドレスは、メッセージがメールシステムで処理される過程で次々と書き換えられ、変更されるからです。ルーティングの目的は、エンベロープ To: アドレスをシステムまたはメールボックス固有のフォーマットに変換していくことです。アドレスリバースの正規化機能は、エンベロープ To: アドレスには不適切です。

MTA では豊富な機能が使用でき、エンベロープ To: アドレスの置換が実行できます。エイリアスファイル、エイリアスデータベース、および一般検索テーブルによって、この機能が提供されます。

MTA では、正引き検索テーブルや FORWARD マッピングも提供されており、パターンに基づく転送、ソース固有の転送、アドレスの自動登録などの特殊な転送に使用されます。ただし、正引き検索テーブルや FORWARD マッピングは、特殊なアドレス転送のための機能であることに注意してください。ほとんどのアドレス転送には、MTA のほかの転送機構を使用したほうがパフォーマンスは向上します。

エンベロープ To: アドレス用のさまざまな置換機構では、リバース検索テーブルと同等の機能が提供されますが、リバースマッピングと同等の機能は現時点ではありません。エンベロープ To: アドレス用のマッピング機能が必要とされる状況が発生することもあります。

FORWARD マッピングテーブル

FORWARD マッピングテーブルでは、パターンに基づいた転送を行うための機能が提供されます。また、ソース固有の転送を行うための機構も提供されます。マッピングファイル内に FORWARD マッピングテーブルがある場合、それは各エンベロープ To: アドレスに適用されます。このマッピングテーブルがない場合や一致するエントリがマッピングテーブルにない場合、変更は行われません。

アドレスに一致するマッピングエントリがある場合は、マッピングの結果がテストされます。エントリが $Y を指定している場合は、エンベロープ To: アドレスは結果の文字列で置き換えられ、エントリが $N を指定している場合は、マッピングの結果が破棄されます。このほかのフラグの一覧は、表 10–8 を参照してください。

FORWARD マッピングが存在する場合は、正引き検索テーブルの検索が行われる前に参照されます。FORWARD マッピングが一致し、フラグ $G が付いていれば、FORWARD マッピングの結果は正引き検索テーブルに対してチェックされます。ただし、USE_FORWARD_DATABASE が適切に設定されていて正引き検索テーブルの使用が有効になっている必要があります。チャネル固有の正引き検索テーブルの使用が指定されている場合は、正引き検索テーブルの検索が行われる前に、ソースアドレスとソースチャネルが FORWARD マッピングの結果の前に付けられます。一致する FORWARD マッピングエントリが $D を指定している場合、FORWARD マッピング (およびオプションの正引き検索テーブルの検索) の結果を使用して MTA アドレス書き換えプロセスが再び実行されます。一致する FORWARD マッピングエントリが $H を指定している場合、それ以上の FORWARD マッピングまたはデータベースの検索は、$D を使用したことによる後続のアドレス書き換えプロセスの間に実行されません。

以下に、複雑な REVERSE マッピングおよび FORWARD マッピングの使用例を示します。mr_local チャネルに関連付けられている am.sigurd.innosoft.com というシステム (仮のドメイン) が、次の一般的な形式の RFC 822 アドレスを生成すると仮定します。

"lastname, firstname"@am.sigurd.example.com

または

"lastname,firstname"@am.sigurd.example.com

これらのアドレスは完全に正しいものですが、RFC 822 の構文ルールに完全準拠していないほかのメーラー (たとえば、引用符で囲まれたアドレスを適切に処理しないメーラー) では混乱が生じることがあります。そのため、引用を必要としないアドレス形式のほうが、多くのメーラーで機能する傾向があります。次はその一例です。

firstname.lastname@am.sigurd.example.com

複雑な FORWARD マッピングおよび REVERSE マッピングの例

REVERSE

 *|mr_local|"*,$ *"@am.sigurd.example.com $Y"$1,$ $2"@am.sigurd.example.com
 *|mr_local|"*,*"@am.sigurd.example.com   $Y"$1,$ $2"@am.sigurd.example.com
 *|*|"*,$ *"@am.sigurd.example.com        $Y$3.$2@am.sigurd.example.com
 *|*|"*,*"@am.sigurd.example.com          $Y$3.$2@am.sigurd.example.com
 *|mr_local|*.*@am.sigurd.example.com     $Y"$2,$ $1"@am.sigurd.example.com
 *|*|*.*@am.sigurd.example.com            $Y$2.$3@am.sigurd.example.com

FORWARD

 "*,$ *"@am.sigurd.example.com            $Y"$0,$ $1"@am.sigurd.example.com
 "*,*"@am.sigurd.example.com              $Y"$0,$ $1"@am.sigurd.example.com
 *.*@am.sigurd.example.com                $Y"$1,$ $0"@am.sigurd.example.com

上記の例では、サンプルのマッピングテーブルの目的には 3 段階あります。(1) 上記の 3 種類のアドレス形式をすべて使用可能にする。(2) 必要に応じて形式を変換し、元の形式のアドレスのみを mr_local チャネルに提示する。(3) 必要に応じて形式を変換し、新しい引用府なしの形式のアドレスのみをほかのすべてのチャネルに提示する (例で示した REVERSE マッピングでは、MTA オプション USE_REVERSE_DATABASE のビット 3 が設定されていると仮定)。

正引き検索テーブル

アドレス転送を自動登録またはソース固有にする必要がある場合には、正引き検索テーブルを使用します。通常、単純なメッセージの転送に正引き検索テーブルを使用することは適切ではありません。このような転送には、aliases ファイルまたはエイリアス検索テーブルを使用するほうが効率的です。デフォルトでは、正引き検索テーブルは一切使用されません。使用するには、USE_FORWARD_DATABASE オプションを使用して明示的に有効にする必要があります。正引き検索テーブルの検索は、アドレス書き換えの後、エイリアス展開が実行され、FORWARD マッピングがチェックされた後で実行されます。正引き検索テーブルの検索が成功した場合、結果の置換済みアドレスを使用して MTA アドレス書き換えプロセスが初めからやり直されます。

正引き検索テーブルに使用できる機構には、メモリ内ハッシュテーブルと従来のデータベースの 2 つがあります。テーブルのサイズが極端に大きい場合を除いて、ハッシュテーブルを使用することをお勧めします (1,000 はそれほど大きいとされない。100,000 が目安)。ハッシュテーブルは、use_text_database オプションにビット 3 (値 34) を設定すること、および use_forward_database を設定することによって有効になります。ハッシュテーブルは、msg_svr_base/configure/forward.txt から読み込まれ、設定の再読み込み可能な部分にコンパイルされます。imsimta reload コマンドを使用すると、これをアクティブな MTA プロセスに再読み込みできます。

正引きデータベースは、crdb ユーティリティーを使用してソーステキストファイルから作成された MTA crdb データベースです。デフォルトでは、ソーステキストファイルは次のような形式になっています。

user1@domain1 changedmailbox1@changeddomain1
user2@domain2 changedmailbox@changeddomain2

ただし、USE_FORWARD_DATABASE オプションでビット 3 が設定されていてソース固有の正引きデータベースの使用が有効になっている場合は、ソーステキストファイルの形式は次のようになります。

source-channel|source-address|original-address changed-address

たとえば、次のようなエントリがあるとします。

tcp_limited|bob@blue.com|helen@red.com  “helen of troy”@siroe.com

この例では、To: アドレス helen@red.com が “helen of troy”@siroe.com にマッピングされます (メッセージの差出人が bob@blue.com で、キューに入れられるチャネルが tcp_limited であると仮定した場合)。