test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

ローカルアドレスのエイリアス展開

アドレスがローカルチャネルに関連付けられていると判別されると、アドレスのエイリアス展開が自動的に実行されます。エイリアス展開プロセスでは、大量の情報ソースを調べます。これには次の情報ソースが含まれます。

  1. エイリアスファイル (コンパイルされた設定の一部)。

  2. エイリアスデータベース。

  3. エイリアス URL。

正確にどのエイリアスソースがチェックされるか、およびチェックされる順序については、option.dat ファイルの ALIAS_MAGIC MTA オプションによって決まります。ダイレクト LDAP では、このオプションを 8764 に設定します。これによって、ALIAS_URL0 MTA オプションで指定されている URL が先にチェックされ、以降は ALIAS_URL1 MTA オプションで指定されている URL、ALIAS_URL2 MTA オプションで指定されている URL、エイリアスファイルの順序でチェックされます。エイリアスデータベースは、この設定がアクティブな場合はチェックされません。

LDAP URL を使用するエイリアスチェック

LDAP のエイリアスチェックは、2 つの特殊な LDAP URL をエイリアス URL として指定することで実装されます。最初の URL では通常のユーザーとグループが処理され、後続のエイリアス URL ではバニティードメインが処理されます。最初の URL を ALIAS_URL0 として、次のように指定します。

ALIAS_URL0=ldap:///$V?*?sub?$R

$V メタキャラクタ

メタキャラクタの展開は、URL 検索より先に実行されます。ALIAS_URL0 値に使用されている 2 つのメタキャラクタは $V と $R です。

$V メタキャラクタは、アドレスのドメイン部分をベース DN に変換します。これは、前出の 「書き換えルールの機能」で説明されている、$V 書き換えルールメタキャラクタによって実行される最初の処理と似ています。$V 処理では、次の手順が実行されます。

  1. 現在のドメインのユーザーエントリのベース DN を取得します。

  2. 現在のドメインに関連付けられている標準ドメインを取得します。Sun LDAP Schema 1 では、ドメインエントリの inetCanonicalDomainName 属性が存在する場合、この属性で標準ドメイン名が指定されています。この属性がない場合、標準ドメイン名は実際のドメインエントリの DN から率直な方法で構築された名前になります。この名前は、実際のドメインがエイリアスである場合、実際のドメインとは異なります。標準ドメイン名を保存するために使用される名前属性は、option.dat ファイルの LDAP_DOMAIN_ATTR_CANONICAL MTA オプションで無効にできます。

    Sun LDAP Schema 2 では、標準名は SunPreferredDomain 属性の値です。

  3. ベース DN が存在する場合は、URL でベース DN が $V と置き換えられます。

  4. この時点で、このエントリの適用可能なすべてのホストしているドメインが判別されます。これは、標準ドメイン (DOMAIN_UPLEVEL のビット 2 (値 = 4) が設定解除されている場合) または現在のドメイン (DOMAIN_UPLEVEL のビット 2 (値 = 4) が設定されている場合) のいずれかを service.defaultdomain configutil パラメータと比較することによって実行されます。一致しない場合、エントリはホストしているドメインのメンバーです。service.defaultdomain configutil パラメータは、option.dat ファイルにある LDAP_DEFAULT_DOMAIN MTA オプションを設定することで無効にできます。

  5. ベース DN の判別が失敗した場合、ドメインの左側の構成要素が削除され、手順 1 に戻ります。構成要素が残っていない場合、置換は失敗します。

$V は、オプションの数値引数も受け入れます。1 に設定されている場合 (たとえば、$1V)、ドメインツリーのドメイン解決が失敗したことは無視され、local.ugldapbasedn configutil オプションで指定されたユーザーツリーのベースが返されます。

ドメインのベース DN の取得に成功すると、MTA はあとで必要になるいくつかのドメイン属性も取得します。取得される属性の名前は、option.dat ファイルにある次の MTA オプションで設定します。

URL からマッピングを呼び出す

ドメインからベース DN へのマッピングを別の方法で実行するまれなケースが発生する場合があります。このようなケースに対応するために、URL 解決プロセスには、MTA マッピングを呼び出す機能があります。これは、次の一般的な形式の一連のメタキャラクタ列を使用して実行されます。

$|/mapping-name/mapping-argument|

二重引用符 (“) はコールアウトの始まりと終わりを示します。$ の直後の文字は、マッピング名と引数の間の区切り文字であり、マッピング名または引数のいずれかで使用される文字ではないものを選択する必要があります。

$R メタキャラクタ

$R メタキャラクタは、URL 用に適切なフィルタを提供します。目的は、特定のユーザーまたはグループの電子メールアドレスを含んでいる可能性のあるすべての属性を検索するフィルタを生成することです。検索対象になる属性のリストは、configutil パラメータ local.imta.mailaliases で指定します。このパラメータが設定されていない場合は、configutil パラメータ local.imta.schematag が調べられ、その値に応じて適切なデフォルト属性の集合が次のように選択されます。

sims401 mail,rfc822mailalias

nms41 mail,mailAlternateAddress

ims50 mail,mailAlternateAddress,mailEquivalentAddress

local.imta.schematag の値はコンマ区切りのリストにできます。複数のスキーマがサポートされている場合は、組み合わせて重複を削除した属性のリストが使用されます。LDAP_SCHEMATAG MTA オプションは、MTA 専用の local.imta.schematag の設定を無効にするために使用できます。

また、フィルタは、最初に指定されたアドレスを検索するだけではなく、同じローカル部分を持ちながらドメインツリーで実際に見つかったドメインを含むアドレスも検索します。このドメインは 「$V メタキャラクタ」の手順 2 で保存されたものです。ドメインツリー検索の反復性は、この 2 つのアドレスが異なる可能性があることを意味します。この追加チェックは、option.dat ファイルにある DOMAIN_UPLEVEL MTA オプションのビット 1 (値 = 2) によって制御されます。このビットを設定すると、追加アドレスチェックが有効になります。DOMAIN_UPLEVEL のデフォルト値は 0 です。

たとえば、ドメイン siroe.com がドメインツリーに表示されると仮定します。Sun LDAP Schema 1 が有効であり、次のアドレスを検索すると仮定します。

u@host1.siroe.com

$R および ims50 schematag の展開の結果から得られるフィルタは、次のようになります。

(|(mail=u@siroe.com)
    (mail=u@host1.siroe.com)
    (mailAlternateAddress=u@siroe.com)
    (mailAlternateAddress=u@host1.siroe.com) 
    (mailEquivalentAddress=u@siroe.com)
    (mailEquivalentAddress=u@host1.siroe.com))

また、DOMAIN_UPLEVEL が 3 ではなく 1 に設定されている場合、フィルタは次のようになります。

(|(mail=u@host1.siroe.com)
       (mailAlternateAddress=u@host1.siroe.com)
       (mailEquivalentAddress=u@host1.siroe.com))

フェッチする属性を決定する

返される属性のリストとして * が URL で指定されている場合、アスタリスクを MTA が使用できる属性のリストで置き換えます。このリストは、MTA が使用するオプションを指定する、各種の MTA オプション設定から動的に生成されます。

LDAP エラーを処理する

この時点で、結果の URL を使用して LDAP 検索が実行されます。何らかの LDAP エラーが発生した場合、処理は一時的なエラー (4xx error in SMTP) を示して終了します。LDAP 操作は成功したものの、結果の生成に失敗した場合は、LDAP_DOMAIN_ATTR_CATCHALL_ADDRESS MTA オプションから取得される、ドメインのキャッチオールアドレス属性がチェックされます。この属性が設定されている場合は、その値で現在のアドレスが置き換えられます。

キャッチオールアドレス属性が設定されていない場合は、LDAP_DOMAIN_ATTR_SMARTHOST MTA オプションから取得される、ドメインのスマートホスト属性がチェックされます。この属性が設定されている場合、次の形式のアドレスが作成されます。

@smarthost: user@domain

エイリアス処理はこの結果で正常終了します。また、LDAP_DOMAIN_ATTR_CONVERSION_TAG MTA オプションから取得する、ドメインの変換タグ (存在する場合) がアドレスに追加されます。これによって、スマートホストへの転送前に変換が実行されます。ドメインのキャッチオールアドレスまたはスマートホストがない場合は、このエイリアス URL の処理はエラー終了します。

LDAP 結果のサニティーチェック

LDAP 検索の結果が返された後、検索結果に 1 つのエントリのみが存在することを確認するチェックが実行されます。複数のエントリが存在する場合は、各エントリがユーザーまたはグループにとって正しいオブジェクトクラスを持っているか、deleted ステータスになっていないか、ユーザーの場合は UID があるかどうかがチェックされます。このチェックに合格しないエントリは無視されます。このチェックによって複数のエントリが 1 つに絞られた場合、処理は続行されます。それ以外の場合は、重複するディレクトリまたはあいまいなディレクトリであることを示すエラーが返されます。

バニティードメインのサポート

ALIAS_URL0 チェックは、標準的なユーザーまたはホストしているドメイン内のユーザーのためのチェックです。このチェックが失敗すると、バニティードメインチェックも実行されます。これは、次のエイリアス URL を使用して実行されます。

ALIAS_URL1=ldap:///$B?*?sub?(&(msgVanityDomain=$D)$R)

キャッチオールアドレスのサポート

@host という形式のキャッチオールアドレスのチェックは、mailAlternateAddress 属性で設定する必要があります。この形式のワイルドカード指定は、ホストしているドメインおよびバニティードメインの両方で許可されています。この場合の適切なエイリアス URL は次のとおりです。

ALIAS_URL2=ldap:///$1V?*?sub?(mailAlternateAddress=@$D)

注 –

+* サブアドレス置換メカニズムは、常にダイレクト LDAP モードでキャッチオールアドレスとともに動作していましたが、置換される文字列はローカル部分全体ではなく、サブアドレスのみでした。このメカニズムは変更されて、元のアドレスのローカル部分全体がサブアドレスとしてキャッチオールアドレスにプラグインされるようになりました。

たとえば、foo+bar@domain.com という形式のアドレスを想定する場合、domain.com ドメインにはローカルユーザー foo は存在せず、domain.com のキャッチオールアドレスが bletch+*@example.com である場合、結果としてアドレスは bletch+foo+bar@example.com となります。これは、以前は bletch+bar@example.com でした。