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

第 9 章 MTA のアドレス変換とルーティング

Messaging Server 6 2003Q4 より前の Messaging Server では、LDAP サーバーに保存された情報からコンパイルされたデータベースより、すべてのユーザー、ドメイン、およびグループデータにアクセスしていました。LDAP サーバーでディレクトリ情報が更新されると、データベース情報は dirsync というプログラムによって同期化されていました。Messaging Server MTA は、LDAP ディレクトリに直接アクセスします。この章では、ダイレクト LDAP データアクセスを使用する MTA 内のデータフローについて説明します。この章には、次の節があります。

ダイレクト LDAP のアルゴリズムと実装

ここでは、ダイレクト LDAP 処理について説明します。

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

アドレスの変換とルーティングのプロセスでは、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 がこのようなチャネルを処理していない場合、ルールは打ち切られて正常に終了します。その結果、再処理チャネルへのアドレスは書き換えられます。

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

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

  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 でした。


LDAP 結果を処理する

LDAP エイリアス結果は、順序依存性のあるいくつかの段階で処理されます。次の各項で、これらの段階について説明します。

オブジェクトクラスチェック

エイリアス検索が成功した場合、エントリのオブジェクトクラスがチェックされ、ユーザーまたはグループに適したオブジェクトクラスのセットを含んでいることが確認されます。ユーザーおよびグループに必要なオブジェクトクラスのセットは、通常、どのスキーマがアクティブであるかよって異なります。これは、local.imta.schematag 設定で決定されます。

表 9–1 に、さまざまな schematag 値から得られるユーザーおよびグループのオブジェクトクラスを示します。

表 9–1 さまざまな schematag 値から得られるオブジェクトクラス

schematag

ユーザーオブジェクトクラス 

グループオブジェクトクラス 

sims40

inetMailRouting+inetmailuser

inetMailRouting+inetmailgroup

nms41

mailRecipient + nsMessagingServerUser

mailGroup

ims50

inetLocalMailRecipient+inetmailuser

inetLocalMailRecipient + inetmailgroup

この表の情報は、ほかのスキーマタグの処理と同様に、ハードコード化されています。ただし、option.dat ファイルには、LDAP_USER_OBJECT_CLASSESLDAP_GROUP_OBJECT_CLASSES の 2 つの MTA オプションがあり、前者はユーザー用、後者はグループ用に、別のオブジェクトクラスのセットを指定するように設定することが可能です。

たとえば、ims50,nms41 のスキーマタグ設定は、次のオプション設定と同等です。

LDAP_USER_OBJECT_CLASSES=inetLocalMailRecipient+inetmailuser, mailRecipient+nsMessagingServerUser

LDAP_GROUP_OBJECT_CLASSES=inetLocalMailRecipient+inetmailgroup, mailGroup

LDAP 結果にユーザーまたはグループに適した正しいオブジェクトクラスのセットがない場合、LDAP 結果は無視されます。MTA は、ユーザーまたはグループを処理しているかどうかを判断し、この情報を保存します。保存された情報は、あとで繰り返し使用されます。

ここで説明したオブジェクトクラス設定は、ユーザーまたはグループに適した正しいオブジェクトクラスがエントリにあるかどうかをチェックするために使用できる、実際の LDAP 検索フィルタを構築するためにも使用されます。このフィルタは、$K メタキャラクタを経由してアクセスできます。また、コマンド imsimta cnbuild -option が使用されたときの LDAP_UG_FILTER と同様、チャネルプログラムで使用するために MTA の設定に内部的に保存され、MTA オプションファイル option.dat に書き込まれます。このオプションは、ファイルに書き込むだけです。MTA がオプションファイルから読み取ることはありません。

エントリステータスチェック

次のエントリのステータスがチェックされます。2 つのステータス属性があり、1 つは一般的なエントリ用、もう 1 つはメールサービス専用です。

表 9–2 に、有効化されているスキーマに応じてチェック対象になる、スキーマタグエントリ内の一般およびメール固有のユーザー属性またはグループ属性を示します。

表 9–2 チェック対象の属性

schematag

タイプ 

一般 

メール固有 

sims40 

ユーザー 

inetsubscriberstatus

mailuserstatus

sims40 

グループ 

なし 

inetmailgroupstatus

nms41 

ユーザー 

なし 

mailuserstatus

nms41 

グループ 

なし 

なし 

Messaging Server 5.0 

ユーザー 

inetuserstatus

mailuserstatus

Messaging Server 5.0 

グループ 

なし 

inetmailgroupstatus

必要に応じて、option.dat ファイルにある LDAP_USER_STATUS および LDAP_GROUP_STATUS MTA オプションを使用して、前者はユーザー用、後者はグループ用に、別の一般ステータス属性を選択することができます。メール固有のユーザーおよびグループのステータス属性は、LDAP_USER_MAIL_STATUS および LDAP_GROUP_MAIL_STATUS の各 MTA オプションで制御します。

このチェックで使用されるもう 1 つの要素は、ドメイン自体のステータス (LDAP_DOMAIN_ATTR_STATUS および LDAP_DOMAIN_ATTR_MAIL_STATUS) です。全部で 4 つのステータス属性があります。これらのステータスは、次に示す順序で考慮されることによって組み合わせられます。

  1. ドメインステータス

  2. ドメインメールステータス

  3. ユーザーまたはグループのステータス

  4. メールユーザーまたはメールグループのステータス

これらのうち、「active」以外のステータスを示す最初のステータスは、ほかのステータスより優先されます。これ以外に許容されるステータス値は、「inactive」、「deleted」、「removed」、「disabled」、「hold」、および「overquota」です。「hold」、「disabled」、および「removed」ステータスは、メールドメイン、メールユーザー、またはメールグループのみに指定されます。「overquota」ステータスは、メールドメインステータスまたはメールユーザーステータスとしてのみ指定されます。

特定のステータス属性が存在しない場合、すべてのステータスはデフォルトの「active」になります。不明なステータス値は、「inactive」として解釈されます。

4 つのステータスが組み合わせられると、ユーザーまたはグループに次のステータスが可能になります。「active」、「inactive」、「deleted」、「removed」、「disabled」、「hold」、および「overquota」。active ステータスの場合、エイリアス処理が続行されます。inactive または overquota ステータスの場合、4xx (一時的) エラーが発生し、アドレスはただちに拒否されます。deleted、removed、および disabled ステータスの場合、5xx (永続的) エラーが発生し、アドレスはただちに拒否されます。hold ステータスの場合、ステータス処理に関しては active として扱われますが、内部フラグが設定されます。これによって、あとで配信オプションが考慮される際、既存のオプションはいずれも、単一の「hold」エントリが含まれているオプションリストで上書きされます。

UID チェック

次に必要な処理は、エントリの UID を考慮することです。UID はさまざまな目的で使用されます。UID はユーザーエントリの一部である必要があり、グループエントリに含まれていることもあります。UID がないユーザーエントリは無視され、このエイリアス URL の処理はエラー終了します。ホストしているドメインのエントリの UID は、実 UID、区切り文字、およびドメインで構成できます。MTA では実 UID のみを必要とするので、ほかの構成要素が存在する場合は、option.dat ファイルにある LDAP_DOMAIN_ATTR_UID_SEPARATOR MTA オプションで取得したドメイン区切り文字を使用して削除されます。

あまりないことですが、uid 以外の属性で UID が保存される場合には、別の属性を使用するように LDAP_UID MTA オプションで設定できます。

メッセージの取得

次に、メッセージ取得アドレスを指定するために使用される LDAP 属性がチェックされます。この目的で使用される属性は、LDAP_CAPTURE MTA オプションで指定されている必要があります。デフォルトはありません。この属性の値はアドレスとして扱われます。特殊な「取得」通知が生成され、このアドレスに送信されます。この通知には、現在のメッセージが添付されています。また、取得アドレスは、アドレスが以後、エンベロープ from: アドレスとして表示される場合に、アドレスリバースキャッシュをシードするために使用されます。

リバースキャッシュをシードする

次に、プライマリアドレスおよびユーザーエントリに添付されたエイリアスが考慮されます。この情報は、アドレスリバースキャッシュをシードするために使用されます。この情報は、現在のアドレス変換プロセスでは使用されません。最初に、プライマリアドレス、個人名、受取人制限、受取人の遮断、およびソースブロック制限の各属性が考慮されます。プライマリアドレスは通常、「mail」属性に保存されていますが、LDAP_PRIMARY_ADDRESS MTA オプションを適切に設定することによって別の属性を指定できます。当然、プライマリアドレスはそれ自身にリバースされます。これ以外の属性には、デフォルトの属性はありません。これらの属性を使用する場合は、LDAP_PERSONAL_NAME (「不在返信メッセージの自動返信の属性」を参照)、LDAP_RECIPIENTLIMITLDAP_RECIPIENTCUTOFF (「メッセージの受取人を制限する」を参照) 、および LDAP_SOURCEBLOCKLIMIT (「絶対的なメッセージサイズ制限を指定する」を参照) の各 MTA オプションで指定する必要があります。このときに、対応するドメインレベルの受取人制限、受取人の遮断、ソースブロック制限の各属性も考慮されます。ユーザーレベルの設定は、ドメインレベルの設定より完全に優先されます。

次に、セカンダリアドレスが考慮され、各セカンダリアドレスのキャッシュエントリが作成されます。セカンダリアドレスには 2 種類あります。アドレスリバースの対象になるものと、ならないものです。アドレスリバースキャッシュを適切にシードするためには両者とも考慮する必要があります。メッセージ取得要求があるかどうかをあらゆる場合にチェックする必要があるためです。

リバース対象になるセカンダリアドレスは通常、mailAlternateAddress 属性に保存されています。別の属性は、LDAP_ALIAS_ADDRESSES MTA オプションで指定できます。リバース対象にならないセカンダリアドレスは通常、mailEquivalentAddress 属性に保存されています。別の属性は、LDAP_EQUIVALENCE_ADDRESSES MTA オプションで指定できます。

メールホストおよびルーティングアドレス

ここでは、mailhost および mailRoutingAddress の各属性が考慮されます。考慮される実際の属性は、LDAP_MAILHOST および LDAP_ROUTING_ADDRESS の各 MTA オプションで変更できます。これらの属性は同時に機能し、現時点でアドレスを有効化するべきかどうか、または別のシステムに転送するべきかどうかを決定します。

最初に、mailhost がこのエントリにとって有効であるかどうかが判断されます。エントリに対してアクティブな配信オプションの事前チェックは、エントリがメールホスト固有であるかどうかを確認するために実行されます。メールホスト固有でない場合、mailhost チェックは省略されます。このチェック方法については、「配信オプションの処理」を参照し、特に # フラグについての説明を確認してください。

ユーザーエントリの場合、mailhost 属性を有効にするには、この属性がローカルシステムを特定している必要があります。mailhost 属性は、local.hostname configutil パラメータの値および local.imta.hostnamealiases configutil パラメータによって指定されている値のリストと比較されます。mailhost 属性は、これらのいずれかと一致した場合、ローカルホストを特定していると見なされます。

一致が見つかった場合、エイリアスをローカルで有効にすることができ、エイリアス処理は続行されます。一致が見つからない場合、メッセージを有効にするには、メールホストに転送する必要があります。次の形式の新しいアドレスが構築されます。

@mailhost:user @domain

これがエイリアス展開操作の結果になります。

欠落している mailhost 属性の処理は、エントリがユーザーであるかグループであるかによって異なります。ユーザーの場合、メールホストは不可欠であり、mailhost 属性が存在しない場合は次の形式の新しいアドレスが構築されます。

@smarthost: user@domain

このとき、 LDAP_DOMAIN_ATTR_SMARTHOST MTA オプションによって決定されたドメインのスマートホストが使用されます。ドメインのスマートホストが存在しない場合は、エラーが表示されます。

グループの場合、メールホストは必須ではなく、メールホストの欠落は、任意の場所でグループが拡張可能であるという意味に解釈されます。したがって、エイリアス処理は続行されます。

mailRoutingAddress 属性によって、最後に 1 つ問題が追加されます。この属性が存在する場合、エイリアス処理は mailRoutingAddress を結果として終了します。ただし、メールホストが存在する場合、そのメールホストが mailRoutingAddress にソースルートとして追加されます。

その他の属性のサポート

次に、mailMsgMaxBlocks 属性が考慮されます。最初に、この属性は、LDAP_DOMAIN_ATTR_BLOCKLIMIT MTA オプションから返されたドメインのブロック制限で最小化されます。現在のメッセージのサイズが制限を超過していると認識された場合、エイリアス処理はサイズ超過エラーで終了します。サイズが不明である場合、または制限を超過していない場合、この制限は保存され、あとでメッセージ自体がチェックされるときに再チェックされます。mailMsgMaxBlocks の使用は、LDAP_BLOCKLIMIT MTA オプションで変更できます。

次に、いくつかの属性に対してアクセスと保存が行われます。最終的には、これらの属性はキューファイルエントリに書き込まれ、ims_master チャネルプログラムによって使用されます。このプログラムはその後、この属性を使用してストアのユーザー情報キャッシュを更新します。個々のユーザーの属性が見つからない場合、ドメインレベルの属性を使用してデフォルトを設定できます。

この処理は、LDAP エントリがユーザーではなくグループのものである場合、または LDAP エントリが LDAP ディレクトリではなくエイリアスキャッシュに由来する場合は、スキップされます。後者の基準の背後にある論理は、この情報を頻繁に更新することは不必要であるということと、エイリアスキャッシュを使用すれば、更新が行われるべき時期についての合理的な基準が提供されるということです。取得される属性の名前は、さまざまな MTA オプションによって設定されます。

表 9–3 に、取得されるディスク制限容量とメッセージ制限容量の各属性を設定する MTA オプションを示します。

表 9–3 取得されるディスク制限容量とメッセージ制限容量の各属性を設定する MTA オプション

MTA オプション 

属性 

LDAP_DISK_QUOTA

mailQuota

LDAP_MESSAGE_QUOTA

mailMsgQuota

次に、いくつかの属性があとでメタキャラクタの置換との関連で使用できるように保存されます。

表 9–4 に、MTA オプション、デフォルトの属性、およびメタキャラクタを示します。

表 9–4 MTA オプション、デフォルトの属性、メタキャラクタ

MTA オプション 

デフォルトの属性 

メタキャラクタ 

LDAP_PROGRAM_INFO

mailProgramDeliveryInfo

$P

LDAP_DELIVERY_FILE

mailDeliveryFileURL

$F

LDAP_SPARE_1

デフォルトなし 

$1E $1G $E

LDAP_SPARE_2

デフォルトなし 

$2E $2G $G

LDAP_SPARE_3

デフォルトなし 

$3E $3G

LDAP_SPARE_4

デフォルトなし 

$4E $4G

LDAP_SPARE_5

デフォルトなし 

$5E $5G

追加の属性用のスペアスロットが含まれています。これらを使用することによってカスタマイズされたアドレス拡張機能を構築できます。

次に、mailconversiontag 属性に関連付けられている値がすべて、現在の変換タグのセットに追加されます。この属性の名前は、LDAP_CONVERSION_TAG MTA オプションで変更できます。ドメインの mailDomainConversionTag 属性に値が関連付けられている場合は、その値も同様に追加されます。

配信オプションの処理

次に、mailDeliveryOption 属性がチェックされます。この属性の名前は、LDAP_DELIVERY_OPTION MTA オプションで変更できます。これは複数の値を指定できるオプションであり、この値によってエイリアス変換プロセスで生成されたアドレスが決まります。また、許可される値は、ユーザーとグループで異なります。両者に許可される値は、programforward、および hold です。ユーザーにのみ許可される値は、mailboxnativeunix、および autoreply です。グループにのみ許可される値は、membersmembers_offline、および file です。

mailDeliveryOption 属性から適切なアドレスへの変換は、DELIVERY_OPTIONS MTA オプションによって制御されます。このオプションは、許可される mailDeliveryOption 値それぞれがどんなアドレスを生成するかだけではなく、mailDeliveryOption に許可される値は何か、またそれぞれの値がユーザー、グループ、あるいはその両方に該当するかどうかを指定します。

このオプションの値は、deliveryoption=template ペアのコンマ区切りのリストで構成され、各ペアにはオプションの単一文字のプレフィックスが 1 つまたは複数付いています。

DELIVERY_OPTIONS オプションのデフォルト値は次のとおりです。

DELIVERY_OPTIONS=*mailbox=$M%$\\$2I$_+$2S@ims-ms-daemon, \
     &members=*,                                           \
     *native=$M@native-daemon,                             \
     /hold=@hold-daemon:$A,                                \
     *unix=$M@native-daemon,                               \
     &file=+$F@native-daemon,                              \
     &@members_offline=*,                                  \
     program=$M%$P@pipe-daemon,                            \
     #forward=**,                                          \
     *^!autoreply=$M+$D@bitbucket

各配信オプションは、可能な mailDeliveryOption 属性値に対応します。対応するテンプレートは、URL 処理の場合と同じメタキャラクタの置換スキームを使用して結果のアドレスを指定します。

表 9–5 に、DELIVERY_OPTIONS オプションで使用可能な単一文字のプレフィックスを示します。

表 9–5 DELIVERY_OPTIONS MTA オプション内のオプションで使用する単一文字のプレフィックス

文字プレフィックス 

説明 

@

メッセージを再処理チャネルにリダイレクトする必要があることを示すフラグを設定します。現在のユーザーやグループの処理は中止されます。再処理チャネルから発信されるメッセージについては、このフラグは無視されます。 

*

ユーザーに適用される配信オプションです。 

&

グループに適用される配信オプションです。 

$

このユーザーまたはグループの展開は遅延されることを示すフラグを設定します。 

^

不在期間の開始と終了をチェックして配信オプションが有効化されているかどうかを確認する必要があることを示すフラグを設定します。 

#

エントリの指定メールホストに対してこの配信オプションの展開を行う必要がないことを示すフラグを設定します。つまり、続くエントリはメールホストとは無関係です。これによって、MTA は、指定されたユーザーまたはグループのすべての配信オプションがメールホストと無関係かどうかを確認します。無関係である場合、MTA はメールホストにメッセージを送信する必要はなく、エントリで即座に動作できます。 

/

この配信オプションによって生成されたすべてのアドレスを保留にするフラグを設定します。これらの受取人アドレスが記述されているメッセージファイルには、.HELD 拡張が追加されます。

!

自動返信が MTA によって内部的に処理される必要があることを示すフラグを設定します。このプレフィックスは、自動返信の配信オプションに使用した場合にのみ意味を持ちます。このオプションの値は、メッセージを bitbucket チャネルに送信するものである必要があります。 

*& のいずれも存在しない場合、配信オプションは、ユーザーとグループの両方に適用されるものと見なされます。

配信オプションで使用するその他のメタキャラクタ

MTA の URL テンプレート機能の新しい使用方法をサポートするために、その他のメタキャラクタがいくつか追加されています。次のようなタスクがあります。

表 9–6 に、配信オプションで使用するその他のメタキャラクタとその説明を示します。

表 9–6 配信オプションで使用するその他のメタキャラクタ

メタキャラクタ 

説明 

$\

後続のテキストを小文字にします。 

$^

後続のテキストを大文字にします。 

$_

後続のテキストの大文字と小文字を変換しません。 

$nA

アドレスの n 番目の文字を挿入します。最初の文字は文字 0 です。n が省略されている場合は、アドレス全体が置換されます。このメタキャラクタは、自動返信ディレクトリパスを構築するために使用されます。

$D

アドレスのドメイン部分を挿入します。 

$nE

n 番目のスペア属性の値を挿入します。n が省略されている場合は、最初の属性が使用されます。

$F

配信ファイル名 (mailDeliveryFileURL 属性) を挿入します。

$nG

n 番目のスペア属性の値を挿入します。n が省略されている場合は、2 番目の属性が使用されます。

$nH

元のアドレスのドメインの、0 から数えて n 番目のコンポーネントを挿入します。n が省略されている場合、デフォルトは 0 です。

$nI

エイリアスに関連付けられているホストしているドメインを挿入します。このメタキャラクタは、整数パラメータ n を受け入れます。このパラメータのセマンティクスについては、表 9–7 を参照してください。

$nJ

ホストドメインの、0 から数えて n 番目の部分を挿入します。n のデフォルトは 0 です。

$nO

現在のアドレスに関連付けられているソースルートを挿入します。このメタキャラクタは、整数パラメータ n を受け入れます。このパラメータのセマンティクスについては、表 9–7 を参照してください。

$K

ユーザーまたはグループのオブジェクトクラスと一致する LDAP フィルタを挿入します。出力専用の MTA オプション LDAP_UG_FILTER の説明を参照してください。

$L

アドレスのローカル部分を挿入します。 

$nM

UID の n 番目の文字を挿入します。最初の文字は文字 0 です。n が省略されている場合は、UID 全体が置換されます。

$P

プログラム名 (mailProgramDeliveryInfo 属性) を挿入します。

$nS

現在のアドレスに関連付けられているサブアドレスを挿入します。このメタキャラクタは、整数パラメータ n を受け入れます。このパラメータのセマンティクスについては、表 9–7 を参照してください。

$nU

現在のアドレスのメールボックス部分から引用符が削除された形式での、n 番目の文字を挿入します。最初の文字は文字 0 です。n が省略されている場合は、引用符なしのメールボックス全体が置換されます。 

$nX

メールホストの n 番目のコンポーネントを挿入します。n が省略されている場合は、メールホスト全体が挿入されます。

表 9–7 に、各整数パラメータに対応する $nI および $nS のメタキャラクタの動作を示します。

表 9–7 $nI および $nS のメタキャラクタの動作変更を制御する整数

整数 

動作の説明 

0

値が使用不可である場合に失敗します (デフォルト)。 

ある値が使用可能である場合に値を挿入します。それ以外の場合は何も挿入しません。 

ある値が使用可能である場合に値を挿入します。それ以外の場合は何も挿入せず、前の文字を削除します (この特殊な動作は、ims-ms チャネルによって必要とされる)。

ある値が使用可能である場合に値を挿入します。それ以外の場合は何も挿入せず、後続の文字を無視します。 

メタキャラクタに加えて、表 9–8 で示すように、2 つの特殊なテンプレート文字列があります。

表 9–8 特殊なテンプレート文字列

特殊なテンプレート文字列 

説明 

*

グループの拡張を実行します。この値はユーザーエントリに対しては無効です。 

**

LDAP_FORWARDING_ADDRESS MTA オプションによって指定されている属性を拡張します。これによってデフォルトの mailForwardingAddress になります。

たとえば、グループ拡張の場合、ユーザーの mailDeliveryOption 値が mailbox に設定されていると、UID、パーセント記号 (適用可能な場合はこのあとにホストしているドメインが続く)、プラス記号 (指定されている場合はこのあとにサブアドレスが続く)、および @ims-ms-daemon で構成される新規アドレスが作成されます。

配信オプションのデフォルト

この時点でアクティブな配信オプションのリストが空である場合、リストの最初のオプション (通常はメールボックス) がユーザー用にアクティブ化され、リストの 2 番目のオプション (通常はメンバー) がグループ用にアクティブ化されます。

開始日と終了日のチェック

配信オプションリストが読み取られた後、開始日と終了日のチェックが実行されます。それぞれの属性名は、LDAP_START_DATE (デフォルトは vacationStartDate ) および LDAP_END_DATE (デフォルトは vacationEndDate) の各 MTA オプションで制御します。1 つ以上のアクティブな配信オプションで ^ プレフィックス文字を指定した場合、これらのオプションの値は、現在の日付と照らしてチェックされます。現在の日付がこれらのオプションで指定されている範囲に含まれていない場合、プレフィックス ^ 付きの配信オプションは、アクティブなセットから削除されます。詳細は、「不在返信メッセージの自動返信の属性」を参照してください。

Optin 属性と Presence 属性

LDAP_OPTIN MTA オプションを使用すると、スパムフィルタの opt-in 値のリストを含んでいる LDAP 属性を指定できます。このオプションが指定されている場合で、かつ属性が存在する場合は、現在のスパムフィルタの opt-in リストに追加されます。LDAP_DOMAIN_ATTR_OPTIN MTA オプションで設定されているドメインレベルの属性によって設定されている値もリストに追加されます。

LDAP_PRESENCE MTA オプションを使用すると、ユーザーの存在情報を返すように解決可能な URL を指定できます。このオプションが指定されている場合で、かつ属性が存在する場合、その値は Sieve による存在テストに関連して使用できるように保存されます。LDAP_DOMAIN_ATTR_PRESENCE MTA オプションによって設定されるドメインレベル属性は、ユーザーエントリの値がない場合に、この URL のソースとして使用されます。

Sieve フィルタの処理

次に、このエントリに適用される Sieve フィルタがあるかどうかについて mailSieveRuleSource 属性がチェックされます。この属性が存在する場合、属性はこの時点でパースされ、保存されます。この属性の値としては、完全な Sieve スクリプトが含まれている単一の値または各値に 1 個の Sieve スクリプトが含まれている複数の値の 2 つの形式が可能です。後者の形式は、Web フィルタ作成インタフェースによって作成されます。それぞれの値を順番に並べて適切につなげるための特別なコードが使用されます。

mailSieveRuleSource 属性の使用は、LDAP_FILTER MTA オプションで変更できます。

据え置き処理の制御

次に、mailDeferProcessing 属性がチェックされます。この属性は、LDAP_REPROCESS MTA オプションで変更できます。この属性が存在し、no に設定されている場合、処理は通常どおりに続行されます。属性が yes に設定されていて、現在のソースチャネルが再処理チャネルではない場合、このエントリの拡張は異常終了し、元の user@domain アドレスが再処理チャネルのキューに入れられます。この属性が存在しない場合、配信オプションの処理に関連付けられている据え置き処理の文字プレフィックスの設定がチェックされます。「配信オプションの処理」を参照してください。ユーザーのデフォルトは no です。グループのデフォルトは、MTA オプション DEFER_GROUP_PROCESSING で制御されます。このオプションのデフォルトは 1 (yes) です。この時点で、ユーザーエントリのエイリアス処理は終了します。

グループ拡張属性

その他のいくつかの属性はグループ拡張に関連付けられており、この時点で処理される必要があります。これらの属性の名前はすべて、さまざまな MTA オプションで設定可能です。

表 9–9 に、デフォルトの属性名、属性名を設定する MTA オプション、および MTA による属性の処理方法を示します。この表での要素の順序は、各グループ属性が処理される順序を示しています。正しく動作するには、この順序が不可欠です。

表 9–9 グループ拡張のデフォルト属性および設定用 MTA オプション

デフォルトの属性 

(属性名を設定する MTA オプション) 属性の処理方法 

mgrpMsgRejectAction

(LDAP_REJECT_ACTION) 後続のアクセスチェックのいずれかが失敗した場合の処理を制御する単一値の属性。1 つの値 TOMODERATOR だけが定義されており、設定すると、mgrpModerator 属性で指定したモデレータにアクセスのエラーをすべてリダイレクトするように MTA に指示します。デフォルト (およびこの属性のほかの値すべて) では、エラーを報告し、メッセージは拒否されます。

mailRejectText

(LDAP_REJECT_TEXT) この属性の最初の値に格納された最初の行が保存されます。後続の認証属性のいずれかが原因でメッセージが拒否された場合、このテキストが返されます。テキストは SMTP 応答に表示されるため、現在のメッセージング規格に準拠するには、値は US-ASCII に制限する必要があります。

mgrpBroadcasterPolicy

(LDAP_AUTH_POLICY) グループへの送信を行うために必要な認証のレベルを指定します。可能なトークンは SMTP_AUTH_REQUIRED または AUTH_REQ であり、どちらも、グループへの送信を行う場合に差出人を特定するために SMTP AUTH コマンドを使用する必要があることを意味します。また、PASSWORD_REQUIREDPASSWD_REQUIRED、または PASSWD_REQ も可能なトークンであり、これらはどれも、mgrpAuthPassword 属性で指定されているリストのパスワードがメッセージの Approved: ヘッダーフィールドに存在する必要があることを意味します。OR は、このリストの OR_CLAUSES MTA オプションの設定を 1 に変更します。AND は、このリストの OR_CLAUSES MTA オプションの設定を 0 に変更します。NO_REQUIREMENTS は演算を行いません。複数の値を指定でき、各値を、コンマ区切りのトークンのリストにすることも可能です。

SMTP AUTH が呼び出された場合は、後続の認証チェックが、MAIL FROM アドレスではなく、SASL レイヤーによって提供された電子メールアドレスに照らして実行されることも意味します。 

mgrpAllowedDomain

(LDAP_AUTH_DOMAIN) このグループへのメッセージの送信を許可されたドメイン。OR_CLAUSES MTA オプションが 0 (デフォルト) に設定されているとき、一致がない場合はアクセスチェックが失敗したことを意味し、後続のテストはすべて省略されます。OR_CLAUSES MTA オプションが 1 に設定されているとき、一致がない場合は「failure pending」フラグが設定されます。アクセスチェックが成功するためには、ほかのいくつかのアクセスチェックが成功する必要があります。送信者が LDAP_AUTH_URL と一致することがすでに確認されている場合、このチェックは省略されます。複数の値を指定でき、グローバルな形式のワイルドカードも使用できます。

mgrpDisallowedDomain

(LDAP_CANT_DOMAIN) このグループへのメッセージの送信を許可されていないドメイン。一致がある場合は、アクセスチェックが失敗したことを意味し、後続のテストはすべて省略されます。送信者が LDAP_AUTH_URL と一致することがすでに確認されている場合、このチェックは省略されます。複数の値を指定でき、グローバルな形式のワイルドカードも使用できます。

mgrpAllowedBroadcaster

(LDAP_AUTH_URL) このグループへのメールの送信を許可されているメールアドレスを特定する URL。複数の値を指定できます。各 URL はアドレスのリストに拡張され、各アドレスは現在のエンベロープ from: アドレスに照らしてチェックされます。OR_CLAUSES MTA オプションが 0 (デフォルト) に設定されているとき、一致がない場合はアクセスチェックが失敗したことを意味し、後続のテストはすべて省略されます。OR_CLAUSES MTA オプションが 1 に設定されているとき、一致がない場合は「failure pending」フラグが設定されます。アクセスチェックが成功するためには、ほかのいくつかの許可されているアクセスチェックが成功する必要があります。一致がある場合は、後続のドメインアクセスチェックも省略されます。実行される展開は、すべてのアクセス制御チェックを無効にした場合の SMTP EXPN に似ています。

mgrpDisallowedBroadcaster

(LDAP_CANT_URL) このグループへのメールの送信を許可されていないメールアドレスを特定する URL。複数の値を指定できます。各 URL はアドレスのリストに拡張され、各アドレスは現在のエンベロープ from: アドレスに照らしてチェックされます。一致がある場合は、アクセスチェックが失敗したことを意味し、後続のテストはすべて省略されます。実行される展開は、すべてのアクセス制御チェックを無効にした場合の SMTP EXPN に似ています。

mgrpMsgMaxSize

(LDAP_ATTR_MAXIMUM_MESSAGE_SIZE) グループへ送信できる最大のメッセージサイズ (バイト数)。この属性は廃止されましたが、下位互換性を保つためにサポートされています。代わりに新しい mailMsgMaxBlocks 属性を使用する必要があります。

mgrpAuthPassword

(LDAP_AUTH_PASSWORD) リストに投稿するために必要なパスワードを指定します。mgrpAuthPassword 属性が存在することによって、再処理は通過します。メッセージが再処理チャネルのキューに入れられると、ヘッダーからパスワードが取得され、エンベロープに配置されます。その後、再処理中に、パスワードはエンベロープから取得され、この属性に照らしてチェックされます。また、実際に使用されているパスワードのみがヘッダーフィールドから削除されます。

OR_CLAUSES MTA オプションは、この属性に対しても、ほかのアクセスチェック属性に対する場合と同様に機能します。 

mgrpModerator

(LDAP_MODERATOR_URL) この属性によって指定される URL のリスト。一連のアドレスに拡張されます。このアドレスリストの解釈は、LDAP_REJECT_ACTION MTA オプションの設定によって異なります。LDAP_REJECT_ACTIONTOMODERATOR に設定されている場合、この属性によって、アクセスチェックのいずれかが失敗した場合のメッセージ送信先となるモデレータのアドレスが指定されます。LDAP_REJECT_ACTION が設定されていない場合、または別の値が設定されている場合は、アドレスリストはエンベロープ from アドレスと比較されます。一致が存在する場合、処理は続行されます。一致が存在しない場合、メッセージはこの属性で指定されているすべてのアドレスに再送信されます。この属性の拡張は、この属性の値をグループの URL リストにすることによって実装されます。RFC822 アドレスのリストまたはグループに関連付けられた DN のリストはすべて消去され、グループ用の配信オプションは、members に設定されます。また、この表にリストされている後続のグループ属性は無視されます。

mgrpDeliverTo

(LDAP_GROUP_URL1) URL のリストであり、展開すると、メーリングリストのメンバーのアドレスが一覧表示されます。

memberURL

(LDAP_GROUP_URL2) URL のリストであり、展開すると、メーリングリストのメンバーのアドレスが一覧表示されます。

uniqueMember

(LDAP_GROUP_DN) グループメンバーの DN のリスト。DN はサブツリー全体を示す場合があります。一意のメンバー DN は、LADP URL に埋め込むことによって拡張されます。使用する URL は、GROUP_DN_TEMPLATE MTA オプションで正確に指定します。このオプションのデフォルト値は、次のとおりです。ldap:///$A?mail?sub?(mail=*)

$A は、uniqueMember DN の挿入点を指定しています。

mgrpRFC822MailMember

(LDAP_GROUP_RFC822) このリストのメンバーのメールアドレス。

rfc822MailMember

(LDAP_GROUP_RFC822) rfc822MailMember は下位互換性のためにサポートされています。任意の指定グループで rfc822MailMember または mgrpRFC822MailMember のいずれかを使用できますが、両方同時には使用できません。

mgrpErrorsTo

(LDAP_ERRORS_TO) エンベロープ発信元 (MAIL FROM) アドレスを、属性によって指定されている任意の値に設定します。

mgrpAddHeader

(LDAP_ADD_HEADER) 属性で指定されているヘッダーを、ヘッダートリミング ADD オプションにします。

mgrpRemoveHeader

(LDAP_REMOVE_HEADER) 指定されているヘッダーを、ヘッダートリミング MAXLINES=-1 オプションにします。

mgrpMsgPrefixText

(LDAP_PREFIX_TEXT) 指定テキストがある場合は、それをメッセージテキストの先頭に追加します。

mgrpMsgSuffixText

(LDAP_SUFFIX_TEXT) 指定テキストがある場合は、それをメッセージテキストの末尾に追加します。

No Default

(LDAP_ADD_TAG) 指定されたテキストが件名に存在するかどうかをチェックします。存在しない場合は、テキストを件名のフィールドの先頭に追加します。

次の最終的な属性は、SMTP の EXPN コマンドの一部として、特殊なグループ拡張の場合にチェックされます。mgmanMemberVisibility または expandable です。LDAP_EXPANDABLE MTA オプションを使用すると、チェック対象としてさまざまな属性を選択できます。指定可能な値は次のとおりです。anyone (だれでもグループを拡張できる)、all または true (ユーザーは SASL で認証されていないと、拡張が許可されない)、および none (拡張は許可されていない) です。認識不能な値は、none と解釈されます。属性が存在しない場合、EXPANDABLE_DEFAULT MTA オプションによって拡張を許可するかどうかが制御されます。

エイリアスエントリは、ドメインエントリと似た方法でキャッシュされます。エイリアスキャッシュを制御する MTA オプションは、ALIAS_ENTRY_CACHE_SIZE (デフォルト 1000 エントリ) および ALIAS_ENTRY_CACHE_TIMEOUT (デフォルト 600 秒) です。このエイリアス用に LDAP から返される値は、キャッシュに保管されます。

エイリアスエントリのネガティブキャッシングは、ALIAS_ENTRY_CACHE_NEGATIVE MTA オプションで制御します。ゼロ以外の値の場合、エイリアス一致エラーのキャッシュが有効になります。値がゼロの場合は無効になります。デフォルトでは、エイリアスエントリのネガティブキャッシングは無効になっています。無効なアドレスが繰り返し指定されることは、実際は頻繁には起こり得ないという理論です。また、ネガティブキャッシングが実行されることによって、ディレクトリに追加された新規ユーザーをタイムリーに認識できなくなる場合があります。ただし、バニティードメインが多用されている状況では、サイトはエイリアスのネガティブキャッシングを有効にすることを検討する必要があります。ALIAS_URL0 で指定されている URL によって実行される検索は、成功する可能性が低くなります。

アドレスリバース

ダイレクト LDAP を使用してアドレスリバースを実行するには、まず、USE_REVERSE_DATABASE の値を 4 に設定します。これによってリバースデータベースの使用が無効になります。その後、前述したルーティング機能を使用します。以前のバージョンでは、次の形式のリバース URL の指定からアドレスリバースが開始されました。

REVERSE_URL=ldap:///$V?mail?sub?$Q

$V メタキャラクタについては、すでにエイリアス URL の関連で説明したとおりです。ただし、$Q メタキャラクタは、エイリアス URL で使用される $R メタキャラクタと非常によく似ていますが、アドレスリバース専用に使用されます。$R とは異なり、$Q では、アドレスリバースの候補であるアドレスを含んでいる属性を検索するフィルタが生成されます。検索対象になる属性のリストは、MTA オプション LDAP_MAIL_REVERSES で指定します。このオプションが設定されていない場合は、local.imta.schematag configutil パラメータが調べられ、その値に応じて適切なデフォルト属性のセットが選択されます。

表 9–10 に、local.imta.schematag の値と選択されるデフォルト属性を示します。

表 9–10 local.imta.schematag の値と属性

スキーマタグ値 

属性 

sims40

mail,rfc822mailalias

nms41

mail,mailAlternateAddress

ims50

mail,mailAlternateAddress

ただし、$Q の使用は、現在は不適切になっています。メッセージの取得やその他の機能を正しく実行するために、アドレスリバースの機能は向上されており、一致があるという事実に加えて、一致した属性に注意を払うようになっています。つまり、$Q の代わりに $R を使用してフィルタを指定する必要があります。また、$N メタキャラクタが追加されていますが、これはアドレスリバース対象の属性のリストを返します。結果のオプション値は、次のとおりです。

REVERSE_URL=ldap:///$V?$N?sub?$R

local.imta.schematag はコンマ区切りのリストにできます。複数のスキーマがサポートされている場合は、組み合わせて重複を削除した属性のリストが使用されます。

また、フィルタは、最初に指定されたアドレスを検索するだけではなく、同じローカル部分を持ちながらドメインツリーで実際に見つかったドメインを含むアドレスも検索します。このドメインは 「書き換えルールの機能」の手順 2 で保存されたものです。ドメインツリー検索の反復性は、この 2 つのアドレスが異なる可能性があることを意味します。

たとえば、ドメイン siroe.com がドメインツリーに存在し、MTA によって次のアドレスが認識されたと仮定します。

u@host1.siroe.com

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


     (|(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))

リバース URL によって、正規化されたアドレスを含んでいる属性が明示的に指定されています。これは通常、メール属性です。

URL が構築された後、LDAP 検索が実行されます。検索が成功した場合、最初に返された属性値によって元のアドレスが置き換えられます。検索が失敗した場合、またはエラーが発生した場合は、元のアドレスは変更されません。

アドレスリバース処理が実行される頻度、特にメッセージヘッダーに表示されるアドレスの数および必要なディレクトリ照会による負担を考慮すると、否定的な結果と肯定的な結果の両方をキャッシュする必要があります。これは、開鎖型の、動的に拡張されたメモリ内ハッシュテーブルを使用して実装します。キャッシュの最大サイズは REVERSE_ADDRESS_CACHE_SIZE MTA オプションで設定します (デフォルトは 100000)。キャッシュ内のエントリのタイムアウトは REVERSE_ADDRESS_CACHE_TIMEOUT MTA オプションで設定します (デフォルトは 600 秒)。実際は、キャッシュにはアドレス自体が保存され、LDAP URL や LDAP 結果は保存されません。

非同期 LDAP 動作

非同期検索では、パフォーマンス問題の原因となる可能性のある大きな LDAP 結果全体をメモリ内に保存する必要がありません。MTA では、さまざまなタイプの検索を非同期で実行するための機能が提供されます。

非同期 LDAP 検索の使用は、MTA オプション LDAP_USE_ASYNC で制御します。このオプションはビットエンコードされた値です。各ビットは、設定されている場合、MTA 内の特定の LDAP の使用と連動して、非同期 LDAP 検索の使用を有効にします。

表 9–11 に、option.dat ファイルの LDAP_USE_ASYNC MTA オプションに設定するビットと値を示します。

表 9–11 LDAP_USE_ASYNC MTA オプションの設定

ビット 

値 

LDAP の具体的な使用法 

LDAP_GROUP_URL1 (mgrpDeliverTo) URL

LDAP_GROUP_URL2 (memberURL) URL

LDAP_GROUP_DN (UniqueMember) DN

auth_listmoderator_listsasl_auth_list、および sasl_moderator_list の非定位置リストパラメータ URL

16 

cant_listsasl_cant_list 非定位置リストパラメータ URL

32 

originator_reply 非定位置リストパラメータ URL

64 

deferred_listdirect_listhold_listnohold_list 非定位置リストパラメータ URL

128 

username_auth_listusername_moderator_listusername_cant_list 非定位置リストパラメータ URL

256 

エイリアスファイルリストの URL 

512 

エイリアスデータベースリストの URL 

10 

1024 

LDAP_CANT_URL (mgrpDisallowedBroadcaster) 外部レベル URL

11 

2048 

LDAP_CANT_URL 内部レベル URL

12 

4096 

LDAP_AUTH_URL (mgrpAllowedBroadcaster) 外部レベル URL

13 

8192 

LDAP_AUTH_URL 内部レベル URL

14 

16384 

LDAP_MODERATOR_URL (mgrpModerator) URL

LDAP_USE_ASYNC MTA オプションのデフォルトは 0 です。つまり、非同期 LDAP 検索はデフォルトでは無効です。

設定のまとめ

ダイレクト LDAP を有効にするには、次の MTA オプションを設定する必要があります。


ALIAS_MAGIC=8764
ALIAS_URL0=ldap:///$V?*?sub?$R
USE_REVERSE_DATABASE=4
USE_DOMAIN_DATABASE=0
REVERSE_URL=ldap:///$V?mail?sub?$Q

バニティードメインをサポートする場合は、次のような追加のオプションを設定する必要があります。


DOMAIN_MATCH_URL=ldap:///$B?msgVanityDomain?sub? \
(msgVanityDomain=$D)
ALIAS_URL1=ldap:///$B?*?sub? (&(msgVanityDomain=$D)$R) 
ALIAS_URL2=ldap:///$1V?*?sub?(mailAlternateAddress=@$D)

これらのオプションのうち最後のものは、ホストドメインとバニティードメインの両方で、ローカル部分にワイルドカードが指定されているケースも処理することに注意してください。ワイルドカードが指定されたローカル部分のサポートが必要であり、バニティードメインのサポートが不要な場合は、次のオプションを代わりに使用してください。

ALIAS_URL1=ldap:///$V?*?sub?&(mailAlternateAddress=@$D)

filter ssrd:$A 節は、MTA 設定ファイル (imta.cnf) 内の ims-ms チャネル定義から削除する必要があります。