Sun Java System Messaging Server 6 2004Q2 管理ガイド |
第 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 によってローカルドメインの場合にルールエラーが発生します。
これらのメタキャラクタの処理は、次の手順で実装します。
- Messaging Server は、現在のドメインがローカルであることを確認します。
- ベース DN の判別が成功した場合、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 オプションで最初にリストされている値から成るソースルートがアドレスの先頭に追加されます。
- ベース DN の判別が失敗した場合、ドメインの左側の構成要素が削除され、手順 1 に戻ります。残っている構成要素がない場合は、手順 4 に進みます。
ドメインツリーの上位にさかのぼった結果、domain.com がローカルとして認識された場合、domain.com のサブディレクトリはすべてローカルとして認識されます。この方法が不適当な状況が発生する可能性もあるため、この動作を制御する MTA オプション DOMAIN_UPLEVEL が提供されています。具体的には、DOMAIN_UPLEVEL のビット 0 (値 = 1) を設定解除すると、ドメインの構成要素を削除して再試行する動作は無効になります。DOMAIN_UPLEVEL のデフォルト値は 0 です。
- この時点で、バニティドメインのチェックを実行する必要があります。このチェックは、DOMAIN_MATCH_URL MTA オプションで指定されている LDAP URL を使用して LDAP 検索を開始することによって実行されます。このオプションの値は次の値に設定する必要があります。
ldap:///$B?msgVanityDomain?sub?(msgVanityDomain=$D)
$B によって local.ugldapbasedn configutil パラメータの値が置き換えられます。これはディレクトリ内のユーザーツリーのベースです。LDAP_USER_ROOT MTA オプションを使用すると、この MTA 専用の configutil オプションの値を変更できます (ドメインツリーのベースで置換を行うために、新しい $C メタキャラクタも追加されている)。
この検索で実際に返される値は重要ではありません。重要なのは、返される値があるかどうかです。返される値がある場合は、ドメインはローカルであると見なされます。返される値がない場合は、ドメインはローカルではないと見なされます。
ドメインローカリティのドメインマップの判別
ドメインローカリティを判別するためにどのような処理が実行されるかを知っておくことも有益です。処理はスキーマレベルに固有です。Sun LDAP Schema 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 オプションを設定することで無効にできます。
- 手順 1 で見つかったベース DN を持ち、inetDomain または inetDomainAlias のいずれかのオブジェクトクラスを持つエントリを検索します。このために使用される検索フィルタは、LDAP_DOMAIN_FILTER_SCHEMA1 MTA オプションを設定することで無効にできます。このオプションを使用すると、デフォルトの (|(objectclass=inetDomain)(objectclass=inetdomainalias)) に戻ります。
- 何も見つからない場合は、エラー終了します。
- エントリのオブジェクトクラスが見つかり、それが inetDomain である場合、ドメインエントリの属性 inetDomainBaseDn の値を返します。Messaging Server は、inetDomainBaseDn 属性が存在するかどうかをチェックします。存在する場合はこの属性が使用されます。存在しない場合は、エントリはドメインエイリアスであると見なされます。MTA オプション LDAP_DOMAIN_ATTR_BASEDN を使用すると、inetDomainBaseDN の使用が無効になります。
- エントリのオブジェクトクラスが見つかり、それが inetDomainAlias である場合、aliasedObjectName 属性によって参照されているエントリを検索します。この新しいエントリは、inetDomainBaseDN 属性のオブジェクトクラスを持っている必要があります。aliasedObjectName 属性の使用に代わる手段は、MTA オプション LDAP_DOMAIN_ATTR_ALIAS を使用して指定することができます。
- エイリアスエントリの検索が成功した場合、新しいエントリの inetDomainBaseDn 属性の値が返されます。
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 オプションを設定することで無効にできます。
ドメインローカリティ情報のキャッシュ
ドメイン書き換え処理が実行される頻度とディレクトリ照会 (特にバニティドメインチェック) の負担から、ドメインについての情報は、否定的なものと肯定的なものの両方をキャッシュする必要があります。これは、開鎖型の、動的に拡張されたメモリ内ハッシュテーブルを使用して実装します。キャッシュの最大サイズは DOMAIN_MATCH_CACHE_SIZE MTA オプションで設定します (デフォルトは 100000)。キャッシュ内のエントリのタイムアウトは DOMAIN_MATCH_CACHE_TIMEOUT MTA オプションで設定します (デフォルトは 600 秒)。
エラー処理
サーバーエラーが発生すると、ドメインがローカルであるかどうかを判別することができなくなるため、このプロセス時の一時的なサーバーエラーには慎重に対処する必要があります。このような場合、一般的に次の 2 つの結果がもたらされる可能性があります。
上記の選択肢はいずれも、すべての場合に適切であるとは限りません。たとえば、結果 1 は、リモート SMTP リレーと通信している場合に適切です。一方、結果 2 は、ローカルユーザーからの SMTP 送信を処理している場合に適切です。
同じパターンを持つ複数のルールを使用して一時エラーを処理することは理論的には可能ですが、このような照会を繰り返すことによるオーバーヘッドは、キャッシュが配置されている場合であっても容認できるものではありません。したがって、ドメイン書き換えでは、成功または失敗して次のルールに進むという単純な照合方式は不適切です。ドメイン検索が失敗した場合は、代わりに、MTA オプション DOMAIN_FAILURE で指定されている特殊なテンプレートが使用されます。$V の処理が失敗すると、このテンプレートが、現在処理されている書き換えルールテンプレートの残りの部分の代わりに使用されます。
$V および $Z 以外にも、次に示すいくつかの新しいメタキャラクタが書き換えルール機能に追加されています。
ドメインチェック書き換えルールのパターン
このドメインチェックは、他の書き換えルールが起動する前に実行される必要があります。この順序は、ルールの左側に特別な $* を配置することによって確保されます。$* パターンは、他のどのルールよりも先にチェックされます。
すべてのメカニズムを統合する
上記に示したすべての機能を考慮すると、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 がこのようなチャネルを処理していない場合、ルールは打ち切られて正常に終了します。その結果、再処理チャネルへのアドレスは書き換えられます。
ローカルアドレスのエイリアス展開
アドレスがローカルチャネルに関連付けられていると決定されると、アドレスのエイリアス展開が自動的に実行されます。エイリアス展開プロセスでは、大量の情報ソースを調べます。これには次の情報ソースが含まれます。
正確にどのエイリアスソースがチェックされるか、およびチェックされる順序については、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 処理では、次の手順が実行されます。
- 現在のドメインのベース DN を取得します。
- 現在のドメインに関連付けられている標準ドメインを取得します。Sun LDAP Schema 1 では、ドメインエントリの inetCanonicalDomainName 属性が存在する場合、この属性で標準ドメイン名が指定されています。この属性がない場合、標準ドメイン名は実際のドメインエントリの DN から率直な方法で構築された名前になります。この名前は、実際のドメインがエイリアスである場合、実際のドメインとは異なります。標準ドメイン名を保存するために使用される名前属性は、option.dat ファイルの LDAP_DOMAIN_ATTR_CANONICAL MTA オプションで無効にできます。
Sun LDAP Schema 2 では、標準名は SunPreferredDomain 属性の値です。
- ベース DN が存在する場合は、ベース DN が URL の $V と置き換えられます。
- この時点で、このエントリの適用可能なすべてのホストしているドメインが判別されます。これは、標準ドメイン (DOMAIN_UPLEVEL のビット 2 (値 = 4) が設定解除されている場合) または現在のドメイン (DOMAIN_UPLEVEL のビット 2 (値 = 4) が設定されている場合) のいずれかを service.defaultdomain configutil パラメータと比較することによって実行されます。一致しない場合、エントリはホストしているドメインのメンバーです。service.defaultdomain configutil パラメータは、option.dat ファイルにある LDAP_DEFAULT_DOMAIN MTA オプションを設定することで無効にできます。
- ベース DN の判別が失敗した場合、ドメインの左側の構成要素が削除され、手順 1 に戻ります。構成要素が残っていない場合、置換は失敗します。
$V は、オプションの数値引数も受け入れます。1 に設定されている場合 (たとえば、$1V)、ドメインツリーのドメイン解決が失敗したことは無視され、ユーザーツリーのベースが返されます。
ドメインのベース DN の取得に成功すると、MTA は後で必要になるいくつかのドメイン属性も取得します。取得される属性の名前は、option.dat ファイルにある次の MTA オプションで設定します。
- LDAP_DOMAIN_ATTR_UID_SEPARATOR (デフォルト domainUidSeparator)
- LDAP_DOMAIN_ATTR_SMARTHOST (デフォルト mailRoutingSmartHost)
- LDAP_DOMAIN_ATTR_CATCHALL_ADDRESS (デフォルト mailDomainCatchallAddress)
- LDAP_DOMAIN_ATTR_BLOCKLIMIT (デフォルト mailDomainMsgMaxBlocks)
- LDAP_DOMAIN_ATTR_REPORT_ADDRESS (デフォルト mailDomainReportAddress)
- LDAP_DOMAIN_ATTR_STATUS (デフォルト inetDomainStatus)
- LDAP_DOMAIN_ATTR_MAIL_STATUS (デフォルト mailDomainStatus)
- LDAP_DOMAIN_ATTR_CONVERSION_TAG (デフォルト mailDomainConversionTag)
- LDAP_DOMAIN_ATTR_FILTER (デフォルト mailDomainSieveRuleSource)
- LDAP_DOMAIN_ATTR_DISK_QUOTA (デフォルトなし)
- LDAP_DOMAIN_ATTR_MESSAGE_QUOTA (デフォルトなし)
- LDAP_DOMAIN_ATTR_AUTOREPLY_TIMEOUT (デフォルトなし)
- LDAP_DOMAIN_ATTR_OPTIN (デフォルトなし)
- LDAP_DOMAIN_ATTR_PRESENCE (デフォルトなし)
- LDAP_DOMAIN_ATTR_RECIPIENTLIMIT (デフォルトなし)
- LDAP_DOMAIN_ATTR_RECIPIENTCUTOFF (デフォルトなし)
- LDAP_DOMAIN_ATTR_SOURCEBLOCKLIMIT (デフォルトなし)
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))ALLOW_UNQUOTED_ADDRS_VIOLATE_RFC2798 MTA オプション
MTA のなかには、アドレス引用と正規化についてのチェックが非常にゆるいものもあります。そのような MTA では、a..b@siroe.com などの不適切なアドレスが許可されます。さらに問題なのは、そのような MTA では、必要な引用符が追加されず、ディレクトリでアドレスの検索が行われる前にアドレスを有効な形式である "a..b"@siroe.com にできないことです。
option.dat ファイルにある ALLOW_UNQUOTED_ADDRS_VIOLATE_RFC2798 MTA オプションは、この標準違反に対応します。このオプションを 1 に設定すると、さらなるフィルタ条件が追加され、引用符付きのアドレスの、構文的に無効である引用符がない形式が検索されます。たとえば、"a..b"@siroe.com の検索によって次の形式のフィルタが生成されます。
(|(mail="a..b"@siroe.com)
(mail=a..b@siroe.com)
(mailAlternateAddress="a..b"@siroe.com)
(mailAlternateAddress=a..b@siroe.com)
(mailEquivalentAddress="a..b"@siroe.com)
(mailEquivalentAddress=a..b@siroe.com))このオプションでは、不適切なアドレスの使用による問題は解決されません。電子メールとディレクトリの標準は、アドレスのローカル部分に許可される形式について限定しています。さまざまなメッセージングコンポーネントに構文的に不適切なアドレスが提示された場合、それぞれが異なる動作をする可能性があります。各コンポーネントは、不適切なアドレスを引用符で囲んで有効な形式にしたり、変更せずに渡したり、拒否したりします。あるいは、まったく予測できない動作をする可能性もあります。したがって、エンドユーザーにこのような不適切なアドレスが与えられた場合、そのアドレスは他のベンダー提供のメッセージングシステムに受信されたとき機能しない結果になる可能性があります。
フェッチする属性を決定する
返される属性のリストとして * が URL で指定されている場合、アスタリスクを 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 結果を処理する
LDAP エイリアス結果は、順序依存性のあるいくつかの段階で処理されます。以下の項目で、これらの段階について説明します。
オブジェクトクラスチェック
エイリアス検索が成功した場合、エントリのオブジェクトクラスがチェックされ、ユーザーまたはグループに適したオブジェクトクラスのセットを含んでいることが確認されます。ユーザーおよびグループに必要なオブジェクトクラスのセットは、通常、どのスキーマがアクティブであるかよって異なります。これは、local.imta.schematag 設定で決定されます。
表 9-1 に、さまざまな schematag 値から得られるユーザーおよびグループのオブジェクトクラスを示します。
この表の情報は、他のスキーマタグの処理と同様に、ハードコード化されています。ただし、option.dat ファイルには、LDAP_USER_OBJECT_CLASSES と LDAP_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 に、有効化されているスキーマに応じてチェック対象になる、schematag エントリ内の一般およびメール固有のユーザー属性またはグループ属性を示します。
必要に応じて、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 つのステータス属性があります。これらのステータスは、次に示す順序で考慮されることによって組み合わせられます。
これらのうち、「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_RECIPIENTLIMIT、LDAP_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-4 に、MTA オプション、デフォルトの属性、およびメタキャラクタを示します。
追加の属性用のスペアスロットが含まれています。これらを使用することによってカスタマイズされたアドレス拡張機能を構築できます。
次に、mailConversionTag 属性に関連付けられている値がすべて、現在の変換タグのセットに追加されます。この属性の名前は、LDAP_CONVERSION_TAG MTA オプションで変更できます。ドメインの mailDomainConversionTag 属性に値が関連付けられている場合は、その値も同様に追加されます。
配信オプションの処理
次に、mailDeliveryOption 属性がチェックされます。この属性の名前は、LDAP_DELIVERY_OPTION MTA オプションで変更できます。これは複数の値を指定できるオプションであり、この値によってエイリアス変換プロセスで生成されたアドレスが決まります。また、許可される値は、ユーザーとグループで異なります。両者に許可される値は、program、forward、および hold です。ユーザーにのみ許可される値は、mailbox、native、unix、および autoreply です。グループにのみ許可される値は、members、members_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 オプションで使用可能な単一文字のプレフィックスを示します。
* と & のいずれも存在しない場合、配信オプションは、ユーザーとグループの両方に適用されるものと見なされます。
配信オプションで使用するその他のメタキャラクタ
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
$K
ユーザーまたはグループのオブジェクトクラスと一致する LDAP フィルタを挿入する。出力専用の MTA オプション LDAP_UG_FILTER の説明を参照
$L
アドレスのローカル部分を挿入する
$M
現在のエイリアスに関連づけられた UID を挿入する
$P
プログラム名 (mailProgramDeliveryInfo 属性) を挿入する
$nS
現在のアドレスに関連付けられているサブアドレスを挿入する。このメタキャラクタは、整数パラメータ n を受け入れる。このパラメータのセマンティクスについては、表 9-7 を参照
$nU
現在のアドレスのメールボックス部分から引用符が削除された形式での、n 番目の文字を挿入する。最初の文字は文字 0。n が省略されている場合は、引用符なしのメールボックス全体が置換される
$nX
メールホストの n 番目のコンポーネントを挿入する。n が省略されている場合は、メールホスト全体が挿入される
表 9-7 に、各整数パラメータに対応する $nI および $nS のメタキャラクタの動作を示します。
メタキャラクタに加えて、表 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 オプションを使用すると、スパムフィルタの Optin 値のリストを含んでいる LDAP 属性を指定できます。このオプションが指定されている場合で、かつ属性が存在する場合は、現在のスパムフィルタの optin リストに追加されます。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 による属性の処理方法を示します。この表での要素の順序は、各グループ属性が処理される順序を示しています。正しく動作するには、この順序が不可欠です。
次の最終的な属性は、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 schematag の展開の結果から得られるフィルタは、次のようになります。
(|(|(mail=u@siroe.com)(mail=u@host1.siroe.com))
(|(mailAlternateAddress=u@siroe.com)
(mailAlternateAddress=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 オプションに設定するビットと値を示します。
LDAP_USE_ASYNC MTA オプションのデフォルトは 0 です。つまり、非同期 LDAP 検索はデフォルトでは無効です。
設定のまとめダイレクト LDAP を有効にするには、次の MTA オプションを設定する必要があります。
ALIAS_MAGIC=8764
ALIAS_URL0=ldap:///$V?*?sub?$R
USE_REVERSE_DATABASE=4
USE_DOMAIN_DATABASE=0REVERSE_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 チャネル定義から削除する必要があります。