前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



付録 B   MTA ダイレクト LDAP 操作


iPlanet Messaging Server の 5.2 以前のリリースでは、MTA が使用するユーザおよびグループに関するディレクトリ情報は、多数のファイルやデータベースからアクセスされていました。これらのファイルにあるデータは dirsync プロセスによって更新されており、このプロセスがディレクトリへの変更をモニタし、ファイルとデータベースのデータを適宜更新していました。バージョン 5.2 のデフォルトの動作は以前と同じですが、新しいオプションにより、MTA でディレクトリと直接やりとりすることができるようになりました。このオプションをダイレクト LDAP モードと言います。

MTA をダイレクト LDAP モードで作動させるように設定すると、dirsync プロセスとそのデータベースは使われません。その代わり、MTA は同等の LDAP コールを行い、ドメインが MTA のホストドメインかどうかをまず確認してから、必要な配信情報にアクセスします。ダイレクト LDAP モードが設定可能でメカニズムがより透過的になることを除き、操作を dirsync モードからダイレクト LDAP モードに変更しても、アドレス変換にはほとんど効果はありません。ただし、ホストドメインの動作には変化があり、システムの動作にも大きな影響があります。詳細は、「ダイレクト LDAP モードに変更する意味」を参照してください。

この章には、以下の節があります。



ダイレクト LDAP モードを有効にするには

ダイレクト LDAP モードを有効にするには、標準 MTA 設定を以下のように変更します。

  1. .../imta/config/imta.cnf ファイルの書き換えセクションに次の行を追加します。

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

    localhost は、MTA のプライマリホスト名です。

    たとえば、MTA が island.siroe.com に呼び出される場合、.../imta/config/imta.cnf の書き換えセクションの先頭を以下のように変更します。

    ! Rules to select   local users
    $*                  $E$F$U%$H$V$H@island.siroe.com
    island.siroe.com    $U%$D@island.siroe.com
    siroe.com           $U%$D@island.siroe.com

  2. .../imta/config/imta.cnf の ims-ms チャネルの定義を変更して、filter ssrd:$A を削除します。

    ims-ms チャネル定義が以下のような場合、

    ! ims-ms
    ims-ms defragment subdirs 20 notices 1 7 14 21 28      ¥
     backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" ¥
     maxjobs 1 pool IMS_POOL fileinto $U+$S@$D filter ssrd:$A
    ims-ms-daemon

    以下のように変更します。

    ! ims-ms
    ims-ms defragment subdirs 20 notices 1 7 14 21 28     ¥
     backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" ¥
     maxjobs 1 pool IMS_POOL fileinto $U+$S@$D
    ims-ms-daemon

  3. .../imta/config/option.dat ファイルに以下の行を追加します。

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

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

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

  4. .../imta/config/job_controller.cnf から以下の行を削除します。

    [PERIODIC_JOB=dirsync_incr]
    command=IMTA_TABLE:../../imsimta dirsync
    time=/00:10
    !
    [PERIODIC_JOB=dirsync_full]
    command=IMTA_TABLE:../../imsimta dirsync -F
    time=02:00/24:00
    !

  5. .../imta/config/mappings ファイルの末尾にある SEND_ACCESS マッピングから以下の行を削除します。

    *|*|inactive|*  $X4.2.1|$NMailbox$ temporarily$ disabled
    *|*|deleted|*   $X5.1.6|$NRecipient$ no$ longer$ on$ server

  6. 以下の MTA データベースを削除するか、または移動します。

    .../imta/db/aliasesdb.db
    .../imta/db/domaindb.db
    .../imta/db/reversedb.db

  7. 変更した MTA 設定をコンパイルします。これは、MTA 設定を有効にする前に行う必要があります。



ダイレクト LDAP モードでの操作

MTA の宛先電子メールアドレスの処理には、基本的に変更はありません。簡単に言うと、MTA はまず書き換え規則を使用して、1) ドメインが認識されるかどうかを確認し、2) 必要に応じてアドレスを書き換え、3) メッセージを該当のチャネルにルーティングします。メッセージが l チャネルにルーティングされると、アドレスはエイリアス検索プロセス (「ダイレクト LDAP エイリアス解決」を参照) を使用して変換され、変換されたアドレスは、エイリアスと関連するチャネルにルーティングされるように、書き換え規則を使用して再度書き換えられます。通常これは、ims-ms チャネル、auto_reply チャネル、またはその他の標準 MTA チャネルのいずれかです。

ダイレクト LDAP モードで操作すると、アドレス処理の書き換え規則フェーズとエイリアスフェーズが変更されます。これらの変更については、以下の節で説明します。


ダイレクト LDAP 書き換え規則 ($V) でアドレスを解決する

MTA では、最初にアドレスのドメイン部分 (@ の右の部分) を書き換え規則と照らし合わせてチェックすることによって、アドレスを解決します。書き換え規則は、.../imta/config/imta.cnf ファイルの最初の半分にあります。一致するものが見つかると、書き換え規則がメールのルーティング先チャネルを指定します。たとえば、送信インターネットトラフィックまたはローカルチャネルの場合、メールは tcp_local にルーティングされ、ディレクトリに規定されているユーザの場合、メールは l にルーティングされます。

MTA が dirsync モードに設定されていると、規則の評価プロセスはドメインデータベースの情報を使用します。このデータベースは、dirsync プロセスが維持するデータベースの 1 つです。MTA がダイレクト LDAP モードに設定されていると、特殊な「try me first」書き換え規則が使われます。この規則は以下のように記述されています。

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

この規則の左側にある $* パターンは、この規則を最初に、かつすべてのアドレス上で試みることを意味します。右側の意味は以下のとおりです。

  • $E - エンベロープアドレスのみで使用する

  • $F - 前方を探す (To:) アドレスのみで使用する

  • $U%$H - アドレスを user@host の形式に「書き換える」 (この規則は、実際には未変更の元のアドレスが使用されることを指定する)

  • $V$H - アドレスのホスト部分 (アドレスの @ 記号の右の部分) がディレクトリに定義されているドメインと一致する場合にのみ、この規則を適用する

  • @localhost - l チャネルにルーティングする


LDAP ドメイン検索のしくみ

書き換え規則プロセスの新しい部分として、$V 照合パラメータがあります。$V は、アドレスがローカルかどうかを確認し、ローカルの場合はディレクトリツリー内でその場所を探すために使われます。$V にはパラメータが必要で、この場合はアドレスのホスト部分である $H です。$V タグは、多くの LDAP 検索を利用します。このプロセスは、DC ツリー内でアドレスのドメイン部分を検索して、ユーザおよびグループツリーの該当するサブツリーを探します。たとえば、以下のアドレスを検索する場合、

robinson.crusoe@desert.island.siroe.com

最初にドメイン desert.island.siroe.com がチェックされ、それに失敗すると、island.siroe.com、siroe.com、および com がチェックされます。この LDAP 検索はディレクトリ内の DC ツリーで行われます (iPlanet Messaging Server ネームスペースと DIT 構造の詳細は、『iPlanet Messaging Server プロビジョニングガイド』を参照)。このツリーは、service.dcroot configutil 属性で指定した場所にルーティングされています。デフォルト値は o=internet です。検索は、以下のような識別名を持つエントリに対して行われます。

dc=desert,dc=island,dc=siroe,dc=com,o=internet
dc=island,dc=siroe,dc=com,o=internet
dc=siroe,dc=com,o=internet
dc=com,o=internet

ドメイン検索は、見つかったエントリに inetDomain オブジェクトクラスと inetDomainBaseDn 属性、あるいは inetDomainAlias オブジェクトクラスと aliasedObjectName 属性のいずれかがある場合にのみ、成功とみなされます。

上位ドメインをチェックしない場合は、最下位ビットの DOMAIN_UPLEVEL オプションをクリアして、チェックしないようにすることができます (この例では上位ドメインは island.siroe.com、siroe.com、および com)。DOMAIN_UPLEVEL は .../imta/config/option.dat に指定されています。デフォルト値は 1 です。このため、上位レベルをチェックしない場合は、

DOMAIN_UPLEVEL=0 という行を

.../imta/config/option.dat に追加します。

また、$Z という新しいタグがあります。このタグには、$V と正反対の意味があります。ホストがディレクトリ内にある場合は $V が規則を照合し、ホストがディレクトリ内にない場合は $Z が規則を照合します。


バニティドメイン検索
ユーザに対してバニティドメイン (ホストドメインではない) を定義している場合は、これらに対する LDAP チェックも有効にする必要があります。バニティドメインのチェックは、デフォルトでは無効になっています。これを有効にするには、.../imta/config/option.dat に以下の行を追加します。

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

バニティドメインのチェックは、ホストドメインのチェックに失敗した場合にのみ行われます。


ドメイン検索キャッシュ
ディレクトリ内のすべてのドメインに対してバニティドメインのチェックを行うには、メールの送信先のインターネットドメインを含むすべてのドメインをチェックする必要があるため、非常にコストがかかります。そこで、コスト削減のために、検索の結果が MTA によってキャッシュに書き込まれます。デフォルトでは、最大 600 秒で、最大 100,000 回の検索結果 (成功または失敗) がキャッシュに書き込まれます。このキャッシュは、.../imta/config/option.dat にある以下のオプションによって設定を制御できます。

DOMAIN_MATCH_CACHE_SIZE=100000
DOMAIN_MATCH_CACHE_TIMEOUT=600


アドレス書き換え中に LDAP エラーを管理する

ディレクトリ内のドメイン検索の結果には、以下の 4 つが考えられます。

  • ドメインが見つかり、それが適正である

  • ドメインが見つかり、それが不正である

  • ドメインが見つからない

  • 検索が失敗した (LDAP エラー)

最初のケースは問題ありません。2 番目と 3 番目は同じものとして扱われ、$V 規則は失敗します。最後のケースは、少し難しい状況です。MTA がこのケースの場合に行う適切なアクションには、以下の 2 つがあります。

  1. 400 Temporary lookup failure という SMTP 応答でアドレスを拒否する

  2. あとで処理するために reprocess チャネルにメールをリダイレクトする

最初のアクションは、メールがリモート MTA から来たものであれば当然のアクションで、正しいアクションです。2 番目のアクションは、メールがユーザエージェントの送信メールであれば、妥当なアクションです。MTA は、この 2 つのアクションの違いを識別し、それに応じて動作する必要があります。これを有効にするメカニズムが、MTA の DOMAIN_FAILURE オプションです。DOMAIN_FAILURE は、ドメイン検索が失敗した場合に、書き換え規則の未使用部分を置換するための文字列を指定します。このため、DOMAIN_FAILURE のデフォルト値が

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

であり、処理されている書き換え規則が標準の

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

である場合、$V$H 句によるドメイン検索が失敗すると、処理は書き換え規則が以下のとおりであるかのように続行します。

$*      $E$F$U%$H$V$H@reprocess-daemon$Mtcp_local$1M$1~-error$4000000?Temporary lookup failure

この結果の規則の処理は、以下のようになります。

  • $E - エンベロープアドレスのみで使用する

  • $F - 前方を探す (To:) アドレスのみで使用する

  • $U%$H - アドレスを user@host の形式に「書き換える」 (この規則は、実際には未変更の元のアドレスが使用されることを指定する)

  • $V$H - アドレスのホスト部分 (アドレスの @ 記号の右の部分) がディレクトリに定義されているドメインと一致する場合にのみ、この規則を適用する。これにより LDAP エラーが発生し、変更された規則が生成される

  • @reprocess-daemon - 再処理チャネルにルーティングする

  • $Mtcp_local - ソースチャネルが tcp_local でない場合に「失敗」する。このエラーは、ここまでの処理の結果である。規則の処理は続行する

  • ($1M) - チャネルが reprocess または conversion などの内部再処理チャネルでない場合に「失敗」する

  • $~ - 規則が現在失敗している場合に、照合が成功した処理を停止する

  • -error - 宛先チャネルを無効なチャネル reprocess-daemon-error に変更する

  • $4000000?Temporary lookup failure - SMTP 拡張エラーコードを 4.0.0 に設定し、エラーテキストを「Temporary lookup failure」に設定する

このため、ソースチャネルが tcp_local (リモート MTA からの接続がすべて可能な場所) であっても、reprocess-daemin-error のチャネルが存在していない場合、アドレスは拒否され、規則に指定されている 400 error code で拒否されます。

ソースチャネルが tcp_intranet (おそらくはユーザエージェント) の場合、規則は reprocess チャネルへのメッセージのルーティングのあとに続きます。

DOMAIN_FAILURE オプションとそれから作成される有効な書き換え規則は、いくつかの新しい書き換えタグを使用します。

$1M は既存の $Mchannel タグと同じで、ソースチャネルが再処理チャネルの場合は規則が失敗します。これは $Mreprocess$Mprocess$Mdefragment$conversion とほとんど同等です。

$~ は、$M または $1M (あるいは $M または $1N) タグに指定されているチャネル照合チェックを実行し、これが失敗した場合は、すぐに処理を正常終了します。

$abbbccc?text は、エラーのイベントで使用するエラーコードとエラーテキストを指定します。エラーコードは、実際には a、bbb、ccc という 3 桁の数字で、a.bbb.ccc という拡張 SMTP 結果コードを生成します。


ダイレクト LDAP エイリアス解決

エイリアス解決の目的は、メッセージの受信アドレス (エイリアス) を取得し、チャネルにメッセージを配信するための電子メールアドレスを生成することです。このアドレスは配信アドレスと呼ばれ、通常その形式は uid@channel_name です。

書き換え規則は、アドレスの @ 記号の右の部分だけを調べます。ただし、エイリアス解決は、アドレスの全体を調べることがあります。アドレス解決で使われるメカニズムは、.../imta/config/option.dat の ALIAS_MAGIC オプションによって制御されます。aliases ファイル内で一致をチェックしてから、aliases データベースで一致をチェックするのがデフォルトの動作です。このデータベースは dirsync プロセスによって保守されます (「エイリアス」を参照)。

ダイレクト LDAP 操作を有効にするには、.../imta/config/option.dat に以下の行を追加します。

ALIAS_MAGIC=8764

これによりエイリアス解決は、aliases ファイル (通常はサイトポストマスターだけに使用される) を使用して試行され、次に LDAP ディレクトリで試行されます。LDAP エイリアス解決は、配信チャネルを生成する前に、いくつかのステップを通過します。そのステップは次のとおりです。

  1. LDAP ディレクトリ内のアドレスのユーザ/グループエントリを探します。

  2. エントリタイプ (ユーザまたはグループ) を判別します。

  3. エントリのステータス (たとえば、active、inactive、deleted、hold) を抽出します。

  4. uid 属性を抽出します。

  5. ユーザの場所を探します。

  6. メッセージのサイズが指定した上限を超えていないことを確認します。

  7. mailDeliveryOption 属性 (たとえば、メールボックス、自動返信、プログラム、転送) に基づいて、配信アドレスを生成します。

以下の節で、上記のステップの詳細について説明します。


LDAP ディレクトリ内のユーザ/グループエントリを探す

エイリアスアドレスのユーザ/グループエントリを探す LDAP クエリは、以下のオプションによって .../imta/config/option.dat に定義されている URL で定義されます。

ALIAS_URL0
ALIAS_URL1
ALIAS_URL2

バニティドメインをサポートしていないかぎり、ALIAS_URL0 だけが使用されます。このオプションは以下のように設定することをお勧めします。

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

$V タグの処理は、「LDAP ドメイン検索のしくみ」に記載されている $V タグと同じです。アドレスのドメイン部分の検索が成功した場合、URL の中の $V は、見つかったエントリ内の inetDomainBaseDn または aliasedObjectName 属性がポイントする DN と置き換えられます。検索が失敗すると、エイリアス展開は失敗します。(利用可能な $V タグの変形として $1V があります。これは、検索が失敗した場合にユーザおよびグループのツリーの最上部の DN (local.ugldapbasedn の値) を返します。)

$R は、configutil パラメータの local.imta.schematag で定義されるように、スキーマに適したフィルタによって置き換えられます。一致する電子メールアドレスを検索するために指定できるスキーマ値と属性は、以下のとおりです。

ims50    mail,mailalternateAddress,mailEquivalentAddress
nms41    mail,mailalternateAddress
sims40   mail,rfc822mailalias

local.imta.schematag で、これらの値のうちの複数をカンマで区切って指定できます。複数のスキーマを指定すると、この属性の和集合の一致が検索されます。ディレクトリスキーマがこれらのスキーマのいずれかと完全に一致しない場合は、configutil にパラメータ local.imta.mailaliases を指定して、検索する属性のリストを変更することができます。たとえば、以下のようになります。

local.imta.mailaliases=mail,mailAlternateAddresses,email

これにより、mail、mailAlternateAddresses、および email 属性に対して一致が検索されます。

デフォルトでは、$R タグによって生成されるフィルタだけが指定したアドレスを検索します。ただし、上位レベルのドメインにエイリアスを含めたい場合もあります。このため、desert.island.siroe.com ドメインに robinson.crusoe を規定している場合でも、ドメインツリー内のすべてのドメインにあるユーザ名を照合したい場合もあるでしょう。したがって、書き換え規則の評価で一致したドメインが siroe.com の場合、ディレクトリ内で以下のアドレスが検索されることになります。

robinson.crusoe@desert.island.siroe.com
robinson.crusoe@island.siroe.com
robinson.crusoe@siroe.com

これを実行するには、次のものを DOMAIN_UPLEVEL オプションの最下位ビットに設定する必要があります。これは、たとえば .../imta/config/option.dat ファイルに以下の行を追加することによって設定します。

DOMAIN_UPLEVEL=3


非標準のディレクトリでのドメイン検索
ユーザおよびグループツリーとは別の DC ツリーで標準の iPlanet ディレクトリ構造を使用できない場合は、エイリアスを検索するツリーのベースを検索するための別のメカニズムを利用することができます。前述のように ALIAS_URL0 の $V を使用する代わりに、マッピングを実行することができます。これを実行するシンタックスでは、URL に、$V ではなく以下のように指定します。

$|/mapping-name/mapping-argument|

| はコールアウトの始まりと終わりを示します。$| の直後の文字はマッピング名と引数の間の区切り文字で、マッピング名または引数に使用される文字と一致しないものを選ぶ必要があります。mapping name は、ドメイン検索マッピングテーブルの名前です。mapping-argument はドメインの名前です。たとえば、$D はドメインの名前になります。


バニティドメインエイリアスのドメイン検索
バニティドメインエイリアスをサポートするには、.../imta/config/option.dat に以下のような追加の URL を定義する必要があります。

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


エイリアス解決中の LDAP エラー
ディレクトリ内のエイリアス検索の結果は、何も返されない場合も、1 つまたは複数返される場合もあります。複数のエントリが一致すると、結果が返されなかった場合と同様に検索は失敗したものとみなされ、アドレスは無効として拒否されます。何らかの理由により設定されているディレクトリに達することができない場合、あるいは LDAP クエリでエラーが発生した場合、一時的なエラー (SMTP では 4xx エラー) が表示されてアドレスが拒否されます。送信側の MTA はあとでメールを再試行し、ディレクトリの問題が解決されるまでこの再試行を続けます。


エントリタイプを判別する

ディレクトリ内で一度エントリが見つかったあとであれば、そのエントリを処理して、適切なチャネルにメールを配信することができます。エントリ処理の最初のステップは、そのエントリがユーザ、グループ、またはそれ以外の認識不可能なもののいずれであるかを判別することです。エントリがユーザまたはグループであることがわかった場合、処理は適切に続きます。エントリがユーザでもグループでもない場合、エントリとその結果として処理されるアドレスは、警告なしで無視されます。

エントリタイプは、エントリが属するオブジェクトクラスを確認することによって判別されます。ユーザとグループの必須オブジェクトクラスは、local.imta.schematag の設定で定義されるように、ディレクトリ用のスキーマに含まれます。さまざまなスキーマのユーザまたはグループとしてエントリを定義するために指定するオブジェクトクラスは、以下のとおりです。

ims50:       ユーザ :     inetLocalMailRecipient + inetmailuser
             グループ :     inetLocalMailRecipient + inetmailgroup

nms41:       ユーザ :     mailRecipient + nsMessagingServerUser
             グループ :     mailGroup

sims40:      ユーザ :     inetMailRouting + inetmailuser
             グループ :     netMailRouting + inetmailgroup

ディレクトリスキーマがこれらのスキーマと完全には一致しない場合は、ユーザとグループのディレクトリエントリの違いを見分けるために、独自の判別要因を定義することができます。MTA オプションの LDAP_USER_OBJECT_CLASSES と LDAP_GROUP_OBJECT_CLASSES を使用して、それぞれユーザまたはグループに分類されるエントリを示すオブジェクトクラスを指定することができます。たとえば、.../imta/config/option.dat ファイルに以下の行を追加します。

LDAP_USER_OBJECT_CLASSES=inetLocalMailRecipient+inetmailUser,mailRecipient+nsMessagingServerUser

LDAP_GROUP_OBJECT_CLASSES=inetLocalMailRecipient+inetmailgroup,mailGroup

local.imta.schematag=ims50,nms41 の設定と同じです。つまり、エントリにオブジェクトクラス inetLocalMailRecipient と inetmailUser、またはオブジェクト mailRecipient と nsMessagingServerUser がある場合、そのエントリはユーザであると判別されます。


配信アドレスの作成に使用する属性を抽出する

アドレスのエントリタイプを判別したあと、MTA は、ドメインとユーザまたはグループのエントリから属性セットを抽出して、配信アドレスと配信メッセージを作成する必要があります。ドメインとユーザまたはグループのエントリから、表 B-1、表 B-2、および表 B-3 に示すいくつか、またはすべての属性が抽出されます。以下の表に、使用される必須のデフォルト属性の名前と、それぞれの属性名を選択する際に使用できる MTA オプションを示します。通常、これらのオプションは、標準スキーマに対応するデフォルト値としては設定されません。ただし、ディレクトリでこれらの属性の 1 つ以上に別の属性名を使用する場合は、.../imta/config/option.dat に適切なオプションを設定して変更することができます。

表 B-1    デフォルトのドメイン属性と優先指定オプション

LDAP 属性名

MTA 優先指定オプション

domainUidSeparator  

LDAP_DOMAIN_ATTR_UID_SEPARATOR  

mailDomainCatchallAddress  

LDAP_DOMAIN_ATTR_CATCHALL_ADDRESS  

mailDomainConversionTag  

LDAP_DOMAIN_ATTR_CONVERSION_TAG  

mailDomainMsgMaxBlocks  

LDAP_DOMAIN_ATTR_BLOCKLIMIT  

mailDomainReportAddress  

LDAP_DOMAIN_ATTR_REPORT_ADDRESS  

mailDomainSieveRuleSource  

LDAP_DOMAIN_ATTR_FILTER  

mailDomainStatus  

LDAP_DOMAIN_ATTR_STATUS  

mailRoutingHosts  

LDAP_DOMAIN_ATTR_ROUTING_HOSTS  

mailRoutingSmarthost  

LDAP_DOMAIN_ATTR_SMARTHOST  


表 B-2    デフォルトのユーザ属性と優先指定オプション 

LDAP 属性名

MTA 優先指定オプション

mailConversionTag  

LDAP_CONVERSION_TAG  

mailDeliveryFileURL  

LDAP_PROGRAM_INFO  

mailDeliveryOption  

LDAP_DELIVERY_OPTION  

mailhost  

LDAP_MAILHOST  

mailMsgMaxBlocks  

LDAP_BLOCKLIMIT  

mailMsgQuota  

LDAP_MESSAGE_QUOTA  

mailProgramDeliveryInfo  

LDAP_PROGRAM_INFO  

mailQuota  

LDAP_DISK_QUOTA  

mailRoutingAddress  

LDAP_ROUTING_ADDRESS  

mailSieveRuleSource  

LDAP_FILTER  

UID  

LDAP_UID  

 

LDAP_SPARE_1*  

 

LDAP_SPARE_2*  

* この 2 つの予備の LDAP オプションは、配信オプションパターンに置き換えるときに使用できるため、重要なものです。これについては、後述の配信オプションの処理に関する節で説明しています。


表 B-3    デフォルトのグループ属性と優先指定オプション 

LDAP 属性名

MTA 優先指定オプション

mailRejectText  

LDAP_REJECT_TEXT  

memberURL  

LDAP_GROUP_URL2  

mgrpAddHeader  

LDAP_ADD_HEADER  

mgrpAllowedBroadcaster  

LDAP_AUTH_URL  

mgrpAllowedDomain  

LDAP_AUTH_DOMAIN  

mgrpAuthPassword  

LDAP_AUTH_PASSWORD  

mgrpBroadcasterPolicy  

LDAP_AUTH_POLICY  

mgrpDeliverTo  

LDAP_GROUP_URL1  

mgrpDisallowBroadcaster  

LDAP_CANT_URL  

mgrpDisallowDomain  

LDAP_CANT_DOMAIN  

mgrpErrorsTo  

LDAP_ERRORS_TO  

mgrpMsgMaxSize  

LDAP_ATTR_MAXIMUM_MESSAGE_SIZE  

mgrpMsgPrefixText  

LDAP_PREFIX_TEXT  

msgpMsgSuffixText  

LDAP_SUFFIX_TEXT  

mgrpModerator  

LDAP_MODERATOR_URL  

mgrpRemoveHeader  

LDAP_REMOVE_HEADER  

mgrpRFC822MailMember*  

LDAP_GROUP_RFC822  

rfc822MailMember*  

LDAP_GROUP_RFC822  

uniqueMember  

LDAP_GROUP_DN  

* デフォルトでは mgrpRFC822MailMember と rfc822MailMember のいずれかを使用できますが、2 つを一緒に使用することはできません。


ユーザ/グループのステータスを抽出する
生成された配信アドレスを制御する主要な属性の 1 つは、ユーザ/グループとドメインのステータスです。mailDomainStatus によって定義されているドメインのステータスが inactive または deleted の場合、これがユーザのステータスとして使用され、ユーザのステータスはチェックされません。ドメインのステータスが active の場合、ユーザまたはグループのエントリのステータスが使用されます。エントリのステータスの定義に使用される属性は、使用するスキーマによって異なります。これは、以下のようになります。

ims50:     ユーザ   :     inetuserstatus または mailuserstatus
           グループ :     inetmailgroupstatus
nms41:     ステータス属性なし
sims40:    ユーザ   :     inetsubsscriberstatus
           グループ :     inetmailgroupstatus

ユーザとグループのステータスの判別に使われる属性名は、必要に応じて無効にすることができます。ユーザのステータスに使われる属性を指定するときは LDAP_USER_STATUS オプションを使用でき、グループのステータスに使われる属性を指定するときは LDAP_GROUP_STATUS オプションを使用することができます。ユーザまたはグループのステータスがいったん判別されると、ステータスは active、inactive、deleted、または hold のいずれかになります。

active - ユーザまたはグループのステータスがアクティブであることがわかると、「ユーザの場所」に記載されているように処理が続行します。

inactive - ユーザまたはグループのステータスが inactive であることがわかると、アドレスは一時的なエラーステータス (4xx SMTP エラーコード) によってすぐに拒否されます。

deleted - ユーザまたはグループのステータスが deleted であることがわかると、アドレスは永久的なエラーステータス (5xx SMTP エラーコード) によってすぐに拒否されます。

hold - ユーザまたはグループのステータスが hold であることがわかると、アドレスが保留チャネルに再度書き込まれるように、エイリアスが生成されます。生成されるエイリアスは、MTA オプションの HOLD_TEMPLATE で指定されたパターンによって制御されます。このテンプレートのデフォルト値は、以下のとおりです。

$M?$2I@hold-daemon

パターン内のタグの意味については、「DELIVERY_OPTIONS を使用して配信アドレスを生成する」で説明しています。アドレスが以下のように指定されていて、

robinson.crusoe@desert.island.siroe.com

一致するエントリが island.siroe.com のホストドメインにある rcrusoe の UID を指定した場合、以下のようなエイリアスが生成されます。

rcusoe?island.siroe.com@hold-daemon

このアドレスは、.../imta/config/imta.cnf 内の書き換え規則に一致します。

hold-daemon $U%$H@hold-daemon

これは、一致はしてもアドレスを変更しないため、メールは保留チャネルに配信されます。


UID を抽出する
ディレクトリ内のすべての有効なユーザエントリには、uid 属性が含まれている必要があります。グループエントリには、uid 属性が含まれていなくてもかまいません。uid は、配信アドレスを生成するために使用されます。ユーザエントリに uid 属性がない場合、このエントリは無視されます。ユーザエントリに複数の uid 属性がある場合は、最初のエントリだけが使用されます。

ディレクトリ内の uid 属性には、必要以上の情報が含まれていることもあります。たとえば、ホストドメイン内のエントリの形式は、実際の uid、区切り文字 (domainUidSeparator 属性で定義)、次にドメイン (例 : uid=walter@siroe.com) になります。uid の中に区切り文字がある場合、エイリアスの作成に使われるのは区切り文字の前の部分だけです。

配信アドレスの uid として uid 以外の属性を使用する必要がある場合は、LDAP_UID オプションを使用してその他の属性名を指定することができます。


ユーザの場所

ユーザまたはグループがいったんアクティブなユーザとして識別された場合、MTA はそのユーザがこの MTA に対してローカルなユーザであることをチェックする必要があります。ローカルとみなすためには、エントリに、local.hostname configutil 属性、またはlocal.imta.hostnamealiases configutil 属性で指定されている名前のいずれか 1 つと一致する mailhost 属性がなければなりません。ユーザがローカルの場合、MTA は次のステップに進みます。次のステップは、メッセージのサイズの上限を超えないようにすることです。

メールホストをこの MTA の名前と照合できない場合、

@mailhost:user@domain

という形式の新しいアドレスが生成されます。これはソースルートされた RFC822 アドレスであり、書き換え規則を使って処理されます。ソースルートされたアドレスの場合、書き換え規則はドメイン部分ではなくソースルートアドレスを調べます。

ユーザエントリに mailhost 属性がない場合、生成されるアドレスは以下のドメインと関連する mailRoutingSmarthost を使用します。

@smarthost:user@domain

ユーザエントリに mailhost 属性がなく、ドメインに mailRoutingSmartHost がない場合、アドレスは破棄され、5xx エラーが報告されます。

グループエントリに mailhost 属性がない場合、グループはローカルで処理されます。この明らかな矛盾は重要です。それは、グループが特定のサーバ上ではなく受信リレー MTA 上で展開されることがあるからです。


サイズの上限を抽出する

配信アドレスが作成されるまで (ユーザの場合)、またはグループが展開されるまでに MTA が実行する必要のある、最終的なチェックがあります。この最終チェックでは、メールメッセージが単体でユーザの mailMsgMaxBlocks 属性を超えていないかどうかを確認します。この属性が設定されていない場合は、ドメインの mailDomainMsgMaxBlocks 属性を超えていないかどうかを確認します。メッセージが大きすぎると、アドレスは 5xx サイズ超過エラーによって拒否されます。


DELIVERY_OPTIONS を使用して配信アドレスを生成する

見つかったエントリがユーザエントリの場合はそのまま、書き換え規則を使ってメールを適切なチャネルに返信するための、ユーザの配信アドレスを生成できます。配信アドレス生成の処理はグループの場合も行われますが、グループの場合、その他のいくつかの注意事項があります。これについてはあとの節で説明しています。

配信アドレスは 1 組のパターンによって生成されます。使用されるパターンは、mailDeliveryOption 属性に定義されている値によって異なります。配信アドレスは、有効な mailDeliveryOption ごとに生成されます。パターンは MTA オプションの DELIVERY_OPTIONS によって定義されます。このオプションは .../imta/config/option.dat に定義することができます。DELIVERY_OPTIONS のデフォルト値を以下に示します。

DELIVERY_OPTIONS=*mailbox=$M%$2I+$2S@ims-ms-daemon,
       &members=*,
       *native=$M@native-daemon,
       *unix=$M@native-daemon,
       &file=+$F@native-daemon,
       hold=$M?$2I@hold-daemon,
       &$members_offline=*,
       program=$M%$P@pipe-daemon,
       forward=**,
       *autoreply=$M@autoreply-daemon

DELIVERY_OPTIONS の値は、カンマで区切られた規則のセットです。各規則の左側は配信方法の名前 (たとえば、mailbox、unix、forward) で、右側は配信アドレス作成のためのパターンです。それぞれの規則の前には、1 つ以上の特殊なフラグ文字を指定することもできます。これは、規則がいつ、どのように適用されるかに影響します。フラグ文字は以下のとおりです。

*              この規則はユーザのみに適用されます。

&            この規則はグループのみに適用されます。

$             このタグはメッセージを reprocess チャネルのキューに入れるため、拡張をオフラインで行うことができます。

このため、ユーザが使用できる配信方法は、mailbox、native、unix、および autoreply だけです。グループが使用できる配信方法は members と members_offline だけで、ユーザとグループの両方が使用できる配信方法は program と forward です。

右側は、単純な代替テキストと、さまざまな LDAP 属性の値を挿入するタグで構成されています。「置換タグ (大文字小文字を区別します)」を参照してください。


配信アドレスを生成する - 例
例として、以下のアドレスに送信されたメッセージについて検討します。

robinson.crusoe+goats@desert.island.siroe.com

また、この例では、ディレクトリエントリに以下の属性が含まれていると仮定します。

UID: rcrusoe@desert.island.siroe.com
mail: robinson.crusoe@desert.island.siroe.com
mailDeliveryOption: mailbox
mailDeliveryOption: native
mailDeliveryOption: program
mailDeliveryOption: forward
mailDeliveryOption: autoreply
mailProgramDeliveryInfo: capriform.msg
mailForwardingAddress: friday@desert.island.siroe.com
mailForwardingAddress: hulahula@londonbank.siroe.com

これにより、元のアドレスは 6 つのエイリアス (配信方法 mailbox、native、program、および autoreply にそれぞれ 1 つずつ、配信方法 forward に 2 つ) を生成します。

mailbox のパターン $M%$2I+$2S@ims-ms-daemon は、より複雑なものの 1 つです。


表 B-4    配信オプション mailbox のパターン拡張

パターンの要素

動作

結果

$M  

rcrusoe を生成する  

rcrusoe  

%  

% を生成する  

rcrusoe%  

$2I  

desert.island.siroe.com を生成する  

rcrusoe%desert.island.siroe.com  

+  

+ を生成する  

rcrusoe%desert.island.siroe.com+  

$2S  

goats を生成する  

rcrusoe%desert.island.siroe.com+goats  

@ims-ms-daemon  

@ims-ms-daemon を生成する  

rcrusoe%desert.island.siroe.com+goats@ims-ms-daemon  

この結果として生成されるアドレスには ims-ms チャネルのチャネルタグと完全に一致するドメイン部分があるため、より詳細な書き換えを行わなくてもそのチャネルにルーティングされます。

native のパターン $M@native-daemon は、より単純なものです。

配信オプション native のパターン拡張

表 B-5    配信オプション native のパターン拡張 

パターンの要素

動作

結果

$M  

rcrusoe を生成する  

rcrusoe  

@native-daemon  

@native-daemon を生成する  

rcrusoe@native-daemon  

この結果として生成されるアドレスにはパイプチャネルのチャネルタグと完全に一致するドメイン部分があるため、より詳細な書き換えを行わなくてもそのチャネルにルーティングされます。

自動返信のパターン $M@autoreply-daemon は、非常に単純なものです。


表 B-6    配信オプション autoreply のパターン拡張

パターンの要素

動作

結果

$M  

rcrusoe を生成する  

rcrusoe  

@autoreply-daemon  

@autoreply-daemon を生成する  

rcrusoe@autoreply-daemon  

この結果として生成されるアドレスには自動返信チャネルのチャネルタグと完全に一致するドメイン部分があるため、より詳細な書き換えを行わなくてもそのチャネルにルーティングされます。

program のパターン $M%$P@pipe-daemon は、ほとんど同じものです。


表 B-7    配信オプション program のパターン拡張 

パターンの要素

動作

結果

$M  

rcrusoe を生成する  

rcrusoe  

%  

% を生成する  

rcrusoe%  

$P  

prog を生成する  

rcrusoe%prog  

@pipe-daemon  

@pipe-daemon を生成する  

rcrusoe%prog@pipe-daemon  

この結果として生成されるアドレスにはパイプチャネルのチャネルタグと完全に一致するドメイン部分があるため、より詳細な書き換えを行わなくてもそのチャネルにルーティングされます。

forward のパターン ** は、使用されている mailForwardingAddress 属性の値になるだけです。結果として、以下のアドレスが生成されます。

friday@desert.island.siroe.com
hulahula@londonbank.siroe.com

このため、robinson.crusoe に送信されたメッセージが以下の配信アドレスを生成し、以下のチャネルに配信されます。

rcrusoe%desert.island.siroe.com+goats@ims-ms-daemon      ims-ms
rcrusoe@native-daemon                                    native
rcrusoe@autoreply-daemon                                 autoreply
rcrusoe%prog@pipe-daemon                                 pipe
friday@desert.island.siroe.com
hulahula@londonbank.siroe.com


SIEVE 規則

ユーザのエントリから取得される最終的な LDAP 属性は、mailSieveRuleSource です。これには、ユーザ用の SIEVE フィルタ規則が含まれています。メッセージが配信チャネルのキューに入れられるポイントに来るまで、これらの規則は適用されません。つまり、MTA がエイリアスを展開している間に SIEVE フィルタが取得されても、結果として生成される配信アドレスが展開されて、ims-ms、native、autoreply、またはパイプチャネルに送信されるまで、SIEVE は使用されません。これは dirsync 以外のモードの操作において変更された動作です。dirsync 以外のモードでは、SIEVE 規則を使って処理されるのは ims-ms チャネルに配信されたメールだけでした。


グループエントリを処理する

グループに利用できる 4 つのプログラム配信オプションがあります。program、forward、members、および members_offline です。

program と forward は、ユーザ用の場合と同様に処理されます。

members と members_offline のパターンは両方とも * です。これは、以下の節で説明するグループ展開処理を最大限に活用します。

members_offline の規則の前には $ が付きます。これは、グループ展開が reprocess チャネルで行われることを意味します。メッセージがキューに入れられるチャネルが reprocess チャネル以外のチャネルの場合 (ほとんどの場合、最初にメッセージがキューに入れられるチャネルは tcp_ チャネルの 1 つ)、アドレスの処理は停止し、元のアドレスが受け入れられ、メッセージは reprocess チャネルのキューに入れられます。reprocess チャネルが実行されるときは、アドレスの処理と同じロジックが関与しますが、メッセージがキューに入れられるチャネルは reprocess チャネルであるため、members_offline とその $ は members とまったく同様に処理されます。

原則として、グループの処理は単純明快です。グループのメンバーを電子メールアドレスか識別名のいずれかとして一覧表示するいくつかの属性があります。どちらの場合も、アドレスはグループ展開の結果の一部として使用されます。

実際には、グループの処理は奥が深く、グループエントリの処理に影響する属性は多数あります。


グループエントリの処理の詳細
MTA は、さまざまなグループ処理オプションをそれぞれ順番に考慮することによって、グループエントリを処理します。オプションが処理される順番は重要です。グループ属性は、おおまかに以下の 3 つのタイプに分割できます。

  • mailRejectText などの処理のためのパラメータを備えた属性。この属性は、何を実行できるか、または何を実行できないかには影響しませんが、プロセスへの入力を行います。

  • どの環境でメールをリストに送信できるかを制御する属性。これには、mgrpAllowDomain のような属性も含まれます。この属性は、メッセージをグループに送信できるドメインを指定します。これらの属性は、以下の表に記載されている順番で処理されます。

  • リストの実際のメンバーを指定する属性。

以下の表に、グループ処理属性を示します。


表 B-8    グループ処理のパラメータを提供する属性 

属性

説明

mailRejectText  

グループに関連する認証メカニズムによってメッセージが拒否される場合に、SMTP 応答として返されるテキストを指定します。この属性は、通常は SMTP のプロトコル規則に準拠する US-ASCII のみの単一値属性です。属性が複数値の場合、最初の属性だけが使用されます。値が複数行の場合、最初の行だけが使用されます。  

mgrpMsgMaxSize  

旧バージョンの属性。代わりに、エントリ処理のはじめの方でチェックされる mailmsgMaxBlocks を使用する必要があります。メッセージがこのサイズ (バイト単位で指定) を超えると、メッセージは「メッセージが大きすぎます」というエラーによって拒否されます。  

mgrpAuthPassword  

グループのパスワードを指定し、指定した mgrpBroadcasterPolicy にパスワードが必要な場合に使われます。  

mgrpErrorsTo  

これが指定されている場合は、エンベロープの発信元 (MAIL FROM) アドレスがこの属性の値に設定されます。これが指定されていない場合は、メッセージのエンベロープ発信元は変更されません。  

mgrpAddHeader  

(現在はまだサポートされていません)  

mgrpRemoveHeader  

(現在はまだサポートされていません)  

mgrpMsgPrefixText  

(現在はまだサポートされていません)  

mgrpMsgSuffixText  

(現在はまだサポートされていません)  


表 B-9    メールグループアクセス制御属性 

属性

説明

mgrpBroadcasterPolicy  

グループにメッセージを送信するために必要な認証レベルを指定します。指定可能な値は以下のとおりです。

SMTP_AUTH_REQUIRED または AUTH_REQ のいずれか。グループに送信する前に SMTP の AUTH コマンドを使用して差出人を識別する必要があることを意味します。

PASSWORD_REQUIRED、PASSWD_REQUIRED、または PASSWD_REQ のいずれか。mgrpAuthPassword 属性で指定したリストのパスワードが、メッセージの Approved: header フィールドに表示されている必要があることを意味します。

NO_REQUIREMENTS。属性が指定されていないことと同じで、特別な要件がないことを意味します。  

mgrpAllowedDomain  

複数値。ユーザがメッセージをグループに送信できるドメインを一覧表示します。指定されていない場合、任意のドメインのユーザがグループに送信できます。  

mgrpDisallowedDomain  

複数値。ユーザがメッセージをグループに送信できないドメインを一覧表示します。  

mgrpAllowedBroadcaster  

展開されたときに、リストに送信できるアドレスのリストを生成する URL。URL の展開の結果として生成されるアドレスがグループの場合、そのグループは展開されてより詳細なリストを生成しますが、これは MTA が URL を展開する限界です。メッセージのエンベロープ From アドレスは、この展開によって生成されるアドレスごとにチェックされ、一致するものがある場合にのみメッセージが許可されます。  

mgrpDisallowedBroadcaster  

展開されたときに、リストに送信できないアドレスのリストを生成する URL。URL の展開の結果として生成されるアドレスがグループの場合、そのグループは展開されてより詳細なリストを生成しますが、これは MTA が URL を展開する限界です。メッセージのエンベロープ From アドレスは、この展開によって生成されるアドレスごとにチェックされ、何も一致しない場合にのみメッセージが許可されます。  

mgrpModerator  

展開されたときに、リストに送信できるアドレスのリストを生成する URL。URL の展開の結果として生成されるアドレスがグループの場合、そのグループは展開されてより詳細なリストを生成しますが、これは MTA が URL を展開する限界です。メッセージのエンベロープ From アドレスは、この展開によって生成されるアドレスごとにチェックされます。

エンベロープ From アドレスがこれらのアドレスのいずれかと一致する場合、メッセージはモデレータからのものであり、グループへの送信が許可されます。

エンベロープ From アドレスがこれらのアドレスと一致しない場合、メッセージは展開されたばかりのモデレータアドレスのリストに送信され、グループには一切配信されません。つまり、以下のグループメンバー表にある属性はすべて無視され、program または forward 配信オプションは無視されます。  


表 B-10    メールグループ展開属性 

属性

説明

mgrpDeliverTo  

展開されたときに、アドレスのリストを生成する URL。URL の展開の結果として生成されるアドレスがグループの場合、そのグループは展開されてより詳細なリストを生成します。重複するアドレスは削除されますが、それぞれのアドレスを指すグループが作成されて無限再帰が発生することがあります。MTA はこれを解決するために、入れ子にされたリストの展開を 10 レベルまで許可します。  

memberURL  

mgrpDeliverTo と同じ方法で展開される、もう 1 つの URL のリスト。  

uniqueMember  

グループメンバーの識別名。それぞれの DN はユーザエントリ、グループエントリ、またはディレクトリのサブツリーのいずれかを指します。ディレクトリのサブツリーの場合、そのツリー内のすべてのエントリが展開されています。  

mgrpRFC822MailMember、rfc822MailMember  

これらの属性の値は、グループのメンバーのメールアドレスです。指定されているエントリのうち、これらの属性の 1 つだけが許可されます。rfc822MailMember は、Netscape Messaging Server との下位互換のためだけにサポートされています。  


エイリアスのキャッシング

すべての LDAP アクティビティは、MTA のパフォーマンスに重大な影響を与えることがあります。これを緩和するために、MTA プロセスは LDAP 検索の結果をキャッシュに書き込みます。このキャッシングは、以下のオプションによって制御されます。示されている値はデフォルト値です。

ALIAS_ENTRY_CACHE_SIZE=1000
ALIAS_ENTRY_CACHE_TIMEOUT=600
ALIAS_ENTRY_CACHE_NAGATIVE=0

これは、保持されるキャッシュエントリの最大数が 1,000、エントリが保持される時間の最大の長さが 10 分 (600 秒) であることを意味します。キャッシュエントリはドメインキャッシュエントリより大きくなりますが、システムに十分なメモリがあればキャッシュサイズを増やすだけの価値があるかもしれません。ALIAS_ENTRY_CACHE_NEGATIVE は、エイリアス一致エラーをキャッシュに書き込むかどうかを制御します。デフォルトでは、これらはキャッシュに書き込まれません。エラーをキャッシュに書き込まなければ、新しいユーザの起動は高速になります。また、システムのパフォーマンスに影響するような頻度で、同じユーザへの配信試行が繰り返して失敗する可能性はなくなります。


逆アドレス変換

通常、From: ヘッダーなどの逆アドレスは、MTA でのフローに従って標準化されます。(標準化とは、ヘッダーアドレス内で個人名が前に移動し、コメントが後ろに移動することを意味します。さらに、From: アドレスの場合は、そのアドレスが検索され、mailalternateaddress として見つかると、代わりにそのメールアドレスが使われます。) ユーザのディレクトリエントリにリストされている最初のメールアドレスが使用すべきアドレスであるという原則が適用されます。このプロセスは、DC ツリー内でアドレスのドメイン部分を検索して、アドレスを検索するユーザおよびグループツリーのサブツリーを見つけてから、指定したものと一致する電子メールアドレスを含むエントリを検索し、そのエントリにある最初のメールアドレスを返します。これは、エイリアス処理と非常によく似たプロセスです。

ダイレクト LDAP アドレス変換は、.../imta/config/option.dat に設定されている以下の 2 つのオプションに依存します。

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

USE_REVERSE_DATABASE=4 は、MTA が古いリバースデータベースを使用せず、ダイレクト LDAP メカニズムを使用することを指定します。REVERSE_URL は、「LDAP ディレクトリ内のユーザ/グループエントリを探す」 で説明している ALIAS_URL0 URL と非常によく似ています。$V タグは、その節で説明する方法で展開されます。$Q タグは標準の ALIAS_URL0 で使用されている $R タグと似ていますが、このタグは、MTA が照合しようとしている逆アドレスと一致するアドレスを含む属性を検索するフィルタを生成します。$R で生成されるフィルタは、以下の local.imta.schematag configutil オプションの設定によって異なります。

ims50         mail,mailalternateAddress
nms41         mail,mailalternateAddress
sims40        mail,rfc822mailalias

あとから MTA オプションの LDAP_MAIL_REVERSES に指定して、検索に使用する属性を無効にすることができます。

実際に生成される検索は、エイリアス検索に使用する $R タグで生成される検索と非常によく似ています。この検索では、最初に指定したアドレスだけを検索するのではなく、代替の DC ツリーで実際に見つかったドメインを含むアドレスも検索します。手順については、「LDAP ディレクトリ内のユーザ/グループエントリを探す」を参照してください。

逆アドレス検索が失敗すると、逆アドレスには変更は加えられません。

ほかの LDAP 検索と同様、逆アドレス検索の結果はキャッシュに書き込まれます。このキャッシュのサイズとタイムアウトは、以下のオプションによって制御されます。下記の値はデフォルト値です。

REVERSE_ADDRESS_CACHE_SIZE=10000
REVERSE_ADDRESS_CACHE_TIMEOUT=600



ダイレクト LDAP モードに変更する意味


MTA アドレス変換の場合、プロセスが設定可能でメカニズムがより透過的になることを除き、操作を dirsync モードからダイレクト LDAP モードに変更してもほとんど効果はありません。ただし、ホストドメインの動作には変化があります。dirsync モードではホストドメインのすべてのサブドメインが暗黙的に所有されますが、ダイレクト LDAP モードでは DOMAIN_UPLEVEL=3 を設定することで所有されます。ただし、ダイレクト LDAP モードの DOMAIN_UPLEVEL=0 の設定とは異なり、原則的にドメインに所有されるのは実際に設定するドメインだけです。この二分化された操作モードは、ダイレクト LDAP モードでは使用できません。ドメインの所有権をどちらにするかは、ユーザが決める必要があります。どちらを選んでも違いが生じることはないと思われますが、念のため承知しておいてください。

システムの動作全体には、明らかに影響があります。影響を受けた内容は以下のとおりです。

  • LDAP に対する負荷が変化した

  • データベースでの冗長性が削減された

  • 全体的なメールのスループットが変化した


LDAP に対する負荷が変化した

dirsync プロセスが LDAP ディレクトリに対して作成するクエリは、数は少ないですが、サイズが非常に大きいことがありました。ダイレクト LDAP モードでは、MTA がディレクトリに多数の小さいクエリを作成します。これによる実質的な効果として、キャッシングが使用されていなければ、スループットの大幅な削減が可能です。しかし、ディレクトリに課せられる負荷はよりいっそう標準的なものになってきており、システムはよりスケーラブルになっています。dirsync では MTA を 600 万人以上のユーザに拡大することは困難でしたが、ダイレクト LDAP モードでは、1000 万人のユーザに提供することが可能になっています。


データベースでの冗長性が削減された

dirsync モードでは、MTA は、操作のために多数のデータベース (特に、エイリアスとドメインのデータベース) に依存していました。これらのデータベースはディスク構造が複雑で、システムに突然障害が発生すると破壊されてしまうことがあります。これは、高可用性システムの問題であることが判明しています。ダイレクト LDAP モードでは、MTA はデータベースにはほとんど依存しません。


全体的なメールのスループットが変化した

ディレクトリの使用が増えてデータベースの使用が減ると、スループットに大きく影響します。情報をディレクトリから抽出し、それを必要な形式に処理することは、単にデータベース内の結果を検索するよりも費用がかかります。しかし、エントリがキャッシュ内にあれば、全体的な費用はデータベース内を検索するよりも少なくなります。つまり、ほとんどのメールがエントリをキャッシュに書き込んでいる 2、3 人のユーザに対して処理されるのであれば、スループットは増大します。メールが大規模なユーザ組織全体で分散されるのであれば、スループットは低減します。


ダイレクト LDAP モードのメールスループットのパフォーマンス調整

システムのパフォーマンスは、ALIAS_ENTRY_CACHE_SIZE で設定するエイリアスキャッシュのサイズに影響を受けやすくなっています。エイリアスキャッシュのサイズのデフォルト値は 1000 ですが、おそらくこれはほとんどのシステムには少なすぎるでしょう。これらのキャッシュエントリは大きく (約 2K バイト) なることがあります。このデフォルト値は、小規模な評価システムが過負荷にならないようにするために設定されたものです。この値は 10,000 まで増やすことをお勧めします。大規模なシステムでは 50,000 まで増やします。この変更を有効にするためには、dispatcher.cnf の MAX_LIFE_CONNS の値を増やすことも重要です。キャッシュを有効にするためには、MAX_LIFE_CONNS を ALIAS_ENTRY_CACHE_SIZE の最低 2 倍、通常は 4 倍にする必要があります。アドレス変換については、設定可能になってメカニズムがより透過的になることを除き、操作を dirsync モードからダイレクト LDAP モードに変更してもほとんど効果はありません。


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日