ドメインローカリティーの判別

アドレスの変換とルーティングのプロセスでは、user@domain という形式のアドレスを元に、domain がローカルであるかどうかが最初にチェックされます。

書き換えルールの機能

MTA の書き換えルールには、提示された文字列がローカルで処理する必要のあるドメインであるかどうかをチェックする機能が追加されています。この新機能は、メタキャラクタ $V または $Z によってアクティブ化されます。これらの新しいメタキャラクタは、その後にパターン文字列が続くという点で、構文的には従来のメタキャラクタ $N、$M、$Q、および $C と同様です。$N、$M、$Q、および $C の場合、パターンはソースチャネルまたは宛先チャネルのいずれかと照合されます。$V および $Z の場合、パターンはドメインであり、チェック内容はそのドメインがローカルであるかどうかです。$V によってローカルドメインでない場合にルールエラーが発生し、$Z によってローカルドメインの場合にルールエラーが発生します。

これらのメタキャラクタの処理は、次の手順で実装します。

1. Messaging Server は、現在のドメインがディレクトリ内の有効なドメインエントリと一致するかどうかをチェックします。エントリが存在しない場合は、手順 3 に進みます。

2. そのドメインのエントリがディレクトリ内にある場合、LDAP_DOMAIN_ATTR_ROUTING_HOSTS MTA オプション (デフォルトは mailRoutingHosts) で指定されている属性がドメインエントリから取得されます。この属性が存在する場合、このドメイン内のユーザーを処理できるホストの一覧が示されます。この一覧は、local.hostname configutil パラメータで指定されているホストおよび local.imta.hostnamealiases configutil パラメータで指定されているホストの一覧と比較されます。これらのオプションはそれぞれ、LDAP_LOCAL_HOST および LDAP_HOST_ALIAS_LIST の各 MTA オプションで指定変更できます。一致するものがある場合またはドメインに属性が存在しない場合、ドメインはローカルです。一致するものがない場合、ドメインはローカルではありません。

   mailRoutingHosts 属性が原因でローカルでないと見なされるドメインの処理は、ROUTE_TO_ROUTING_HOST MTA オプションの設定によって異なります。このオプションが 0 (デフォルト) に設定されている場合、アドレスはそのままローカルでないものとして扱われ、MTA の書き換えルールを使用してルーティングが決定されます。このオプションが 1 に設定されている場合、LDAP_DOMAIN_ATTR_ROUTING_HOSTS MTA オプションで最初にリストされている値から成るソースルートがアドレスの先頭に追加されます。

3. ドメインエントリが見つからない場合、ドメインの左側の構成要素が削除され、手順 1 に戻ります。残っている構成要素がない場合は、手順 4 に進みます。

   ドメインツリーの上位にさかのぼった結果、siroe.com がローカルとして認識された場合、siroe.com のサブドメインはすべてローカルとして認識されます。この方法では望ましくない状況が発生する可能性もあるため、この動作を制御する MTA オプション DOMAIN_UPLEVEL が提供されています。具体的には、DOMAIN_UPLEVEL のビット 0 (値 = 1) を設定解除すると、ドメインの構成要素を削除して再試行する動作は無効になります。DOMAIN_UPLEVEL のデフォルト値は 0 です。

4. この時点で、バニティードメインのチェックを実行する必要があります。バニティードメインにはドメインエントリがありません。代わりに、特殊なドメイン属性を 1 つまたは複数のユーザーエントリに付加することで、バニティードメインを指定します。バニティードメインのチェックは、DOMAIN_MATCH_URL MTA オプションで指定されている LDAP URL を使用して LDAP 検索を開始することによって実行されます。このオプションの値は次の値に設定する必要があります。

   ldap:///$B?msgVanityDomain?sub?(msgVanityDomain=$D)

   $B によって local.ugldapbasedn configutil パラメータの値が置き換えられます。これはディレクトリ内のユーザーツリーのベースです。LDAP_USER_ROOT MTA オプションを使用すると、この MTA 専用の configutil オプションの値を変更できます。

   この検索で実際に返される値は重要ではありません。重要なのは、返される値があるかどうかです。返される値がある場合は、ドメインはローカルであると見なされます。返される値がない場合は、ドメインはローカルではないと見なされます。

ドメインローカリティーのドメインマップの判別

ディレクトリ内の有効なドメインエントリを検索するためにどのような処理が実行されるかを知っておくことも有益です。処理はスキーマレベルに固有です。Sun LDAP Schema 1 の場合は、次のとおりです。

1. ドメインをドメインツリーのベース DN に変換します。これは、ドメインを一連の dc コンポーネントに変換し、ドメインルートサフィックスを追加することによって実行されます。デフォルトのサフィックスは、service.dcroot configutil パラメータから取得されます。デフォルトのサフィックスは o=internet です。a.b.c.d という形式のドメインは一般に、dc=a,dc=b,dc=c,dc=d,o=internet に変換されます。service.dcroot configutil パラメータは、LDAP_DOMAIN_ROOT MTA オプションを設定することで無効にできます。

2. 手順 1 で見つかったベース DN を持ち、inetDomain または inetDomainAlias のいずれかのオブジェクトクラスを持つエントリを検索します。このために使用される検索フィルタは、LDAP_DOMAIN_FILTER_SCHEMA1 MTA オプションを設定することで無効にできます。このオプションを使用すると、デフォルトの (|(objectclass=inetDomain)(objectclass=inetdomainalias)) に戻ります。

3. 何も見つからない場合は、エラー終了します。

4. エントリのオブジェクトクラスが見つかり、それが inetDomain である場合、ドメインエントリに関連付けられた inetDomainBaseDn 属性が存在するかどうかをチェックします。存在する場合は、あとでユーザーエントリの検索に使用できるように保存され、処理は終了します。存在しない場合、エントリはドメインエイリアスであると見なされ、処理は手順 5 に進みます。MTA オプション LDAP_DOMAIN_ATTR_BASEDN を使用すると、inetDomainBaseDN の使用が無効になります。

5. エントリはドメインエイリアスであるはずなので、aliasedObjectName 属性によって参照されている新規エントリを検索し、手順 4 に戻ります。aliasedObjectName 属性が存在しない場合、処理はエラー終了します。aliasedObjectName 属性の使用に代わる手段は、MTA オプション LDAP_DOMAIN_ATTR_ALIAS を使用して指定することができます。

   処理が手順 4 に戻るのは、1 回だけです。ドメインエイリアスでさらにドメインエイリアスを参照することは許されていません。

Sun LDAP Schema 2 で実行される処理は、上記の処理より簡単です。ディレクトリ内でオブジェクトクラス sunManagedOrganization を持つエントリが検索されます。ここではドメインは sunPreferredDomain 属性または associatedDomain 属性のいずれかの値として示されています。この目的のための sunPreferredDomain および associatedDomain の各属性の使用は、必要に応じてそれぞれ、MTA オプション LDAP_ATTR_DOMAIN1_SCHEMA2 および LDAP_ATTR_DOMAIN2_SCHEMA2 で無効にできます。検索は、service.dcroot configutil パラメータで指定されているルートの下で実行されます。service.dcroot configutil パラメータは、LDAP_DOMAIN_ROOT MTA オプションを設定することで無効にできます。また、Schema 2 のドメインエントリに inetDomainBaseDn 属性は必須ではありません。ドメインエントリにこの属性がない場合、ユーザーツリーのベース自身がドメインエントリであると見なされます。

ドメインローカリティー情報のキャッシュ

ドメイン書き換え処理が実行される頻度とディレクトリ照会 (特にバニティードメインチェック) の負担から、ドメインについての情報は、否定的なものと肯定的なものの両方をキャッシュする必要があります。これは、開鎖型の、動的に拡張されたメモリ内ハッシュテーブルを使用して実装します。キャッシュの最大サイズは DOMAIN_MATCH_CACHE_SIZE MTA オプションで設定します (デフォルトは 100000)。キャッシュ内のエントリのタイムアウトは DOMAIN_MATCH_CACHE_TIMEOUT MTA オプションで設定します (デフォルトは 600 秒)。

エラー処理

サーバーエラーが発生すると、ドメインがローカルであるかどうかを判別することができなくなるため、このプロセス時の一時的なサーバーエラーには慎重に対処する必要があります。このような場合、一般的に次の 2 つの結果がもたらされる可能性があります。

1. 一時 (4xx) エラーをクライアントに返し、あとでそのアドレスを使用して再試行するように指示する。

2. アドレスを受け入れるが、再処理チャネルのキューに入れ、あとでローカルで再試行できるようにする。

上記の選択肢はいずれも、すべての場合に適切であるとは限りません。たとえば、結果 1 は、リモート SMTP リレーと通信している場合に適切です。一方、結果 2 は、ローカルユーザーからの SMTP 送信を処理している場合に適切です。

同じパターンを持つ複数のルールを使用して一時エラーを処理することは理論的には可能ですが、このような照会を繰り返すことによるオーバーヘッドは、キャッシュが配置されている場合であっても容認できるものではありません。したがって、ドメイン書き換えでは、成功または失敗して次のルールに進むという単純な照合方式は不適切です。ドメイン検索が失敗した場合は、代わりに、MTA オプション DOMAIN_FAILURE で指定されている特殊なテンプレートが使用されます。$V の処理が失敗すると、このテンプレートが、現在処理されている書き換えルールテンプレートの残りの部分の代わりに使用されます。

ドメインチェック書き換えルールのパターン

このドメインチェックは、ほかの書き換えルールが起動する前に実行される必要があります。この順序は、ルールの左側に特別な $* を配置することによって確保されます。$* パターンは、ほかのどのルールよりも先にチェックされます。

すべてのメカニズムを統合する

上記に示したすべての機能を考慮すると、imta.cnf で必要とされる新しい書き換えルールは次のようになります。

$*     $E$F$U%$H$V$H@localhost

また、option.dat ファイルの DOMAIN_FAILURE MTA オプションの値は、次のように設定されている必要があります。

reprocess-daemon$Mtcp_local$1M$1~-error$4000000?Temporary lookup failure

この書き換えルールでは、localhost はローカルチャネルに関連付けられているホスト名です。ここで示した DOMAIN_FAILURE オプションの値は、デフォルト値であるので、通常の状況では option.dat に記述する必要はありません。

ここでの順序付けは特に複雑です。MTA は、アドレスが再構築された後、ただしルートが追加される前に $V をチェックします。これによって、MTA は、一時的な検索エラーが発生した場合にルートを変更することができます。保留中チャネルの一致チェックは、挿入ポイントが変更されるたびに適用されます。これにより、2 番目の $H に続く @ がチェックを開始します。このチェックが成功した場合、テンプレートの残りの部分が適用され、書き換え処理が終了します。このチェックが失敗した場合、書き換えは失敗し、次の適用可能な書き換えルールで書き換えが続行されます。一時的なエラーが原因でチェックが実行できない場合、テンプレート処理は、DOMAIN_FAILURE MTA オプションで指定されている値を使用して続行されます。このテンプレートの値によって、まずルーティングホストが reprocess-daemon に設定されます。次に、MTA が何らかの再処理チャネルまたは tcp_local を処理しているかどうかがチェックされます。MTA がこのようなチャネルを処理している場合、ルールは継続し、ルーティングホストが無効とされ、一時的なエラーが結果として示されます。MTA がこのようなチャネルを処理していない場合、ルールは打ち切られて正常に終了します。その結果、再処理チャネルへのアドレスは書き換えられます。