Postfix は以下の検索のソースとして LDAP ディレクトリを使うことができます: aliases(5)、 virtual(5)、 canonical(5)など。これによりメールサービスに 対する情報を、きめ細かいアクセス制御を持つ複製されたネットワーク データベースに保持することができます。情報をメールサーバにローカルに保管 しないことで、管理者はどこからでも管理でき、ユーザはあなたが適切だと思う 一部の情報を制御できます。特に面倒なこともなく、情報の各サーバへのコピーが 遅れることもなしに、同じ情報を使って複数のメールサーバを持つことができます。
このドキュメントがカバーしている話題:
注意 1: Postfix はすでに LDAP バージョン 1 インターフェースをサポート していません。
注意 2: Debian GNU/Linux の Postfix で LDAP を使うには、postfix-ldap パッケージをインストールするだけで終わりです。Postfix を再コンパイルする 必要はありません。
LDAP ライブラリとインクルードファイルがシステムのどこかにインストール されている必要があり、またそれに合わせて Postfix Makefile を設定する必要が あります。
例えば、Postfix で使用するために (つまり LDAP クライアントコードだけで) OpenLDAP ライブラリをビルドするには、以下のようなコマンドを使います:
% ./configure --without-kerberos --without-cyrus-sasl --without-tls \ --without-threads --disable-slapd --disable-slurpd \ --disable-debug --disable-shared
UM distribution (http://www.umich.edu/~dirsvcs/ldap/ldap.html) または OpenLDAP (http://www.openldap.org) のライブラリを 使うのであれば、Postfix ソースツリーのトップレベルで次のようにします:
% make tidy % make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \ AUXLIBS="-L/usr/local/lib -lldap -L/usr/local/lib -llber"
Solaris 2.x では、ランタイムリンク情報を指定する必要があるかもしれません。 そうしないと、ld.so はシェアードライブラリの一部を見つけられないでしょう:
% make tidy % make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \ AUXLIBS="-L/usr/local/lib -R/usr/local/lib -lldap \ -L/usr/local/lib -R/usr/local/lib -llber"
'make tidy' コマンドは以前に Postfix を LDAP サポートなしにビルドした 場合にのみ必要です。
'/usr/local' の代わりに LDAP インクルードファイルやライブラリの実際の 場所を指定します。異なるバージョンの LDAP インクルードファイルや LDAP ライブラリを混ぜないように気をつけてください!!
LDAP ライブラリが Kerberos サポート付きでビルドされていたら、この行に Kerberos ライブラリも含める必要があります。KTH Kerveros IV ライブラリは dns_lookup を定義している Postfix の lib/libdns.a と競合するかもしれないので 注意してください。いずれにせよ Kerberos の LDAP サーバへのバインドを サポートしないため、競合が起こったら、Postfix をビルドするためだけに Kerberos サポートなしの LDAP ライブラリとリンクしたいと思うかもしれません。 ご迷惑をおかけします。
Netscape LDAP SDK のどれかを使うのであれば、AUXLIBS 行を libldap10.so や libldapssl30.so か持っているものを向くように変更する必要があり、また実行 ファイルが実行時にそれを見つけることができるように、適切なリンカオプション (e.g. '-R') を使う必要があります。
LDAP 検索を使うには、少なくとも一つの LDAP ソースを main.cf の検索 テーブルとして定義します。例:
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
/etc/postfix/ldap-aliases.cf には LDAP SSL や STARTTLS を有効にする ようなパラメータを含めて、大量のパラメータを指定することができます。 完全な記述はldap_table(5) マニュアルページを 参照してください。
ここでは local(8) エイリアスを検索するのに LDAP を使う基本的な例を示します。 main.cf に次のような行があるとします:
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
そして ldap:/etc/postfix/ldap-aliases.cf は以下のようになっているとします:
server_host = ldap.my.com search_base = dc=my, dc=com
/etc/aliases データベースに見つからないローカルアドレス "ldapuser" 宛のメールを受け取ると、Postfix はldap.my.com のポート 389 で待っている LDAP サーバを検索します。匿名でバインドし、mailacceptinggeneralid 属性が "ldapuser" であるディレクトリエントリを検索し、見つかったものの "maildrop" 属性を読み込み、メッセージが配送される RFC822 アドレスとして 扱われる maildrop のリストを構築します。
バーチャル検索の情報をディレクトリに保存したい場合は、少々複雑です。 まず Postfix がバーチャルドメインについて知っているかを確かめる必要が あります。その簡単な方法は、ドメインをディレクトリのいずれかのエントリの mailacceptinggeneralid 属性に加えることです。次に、全てのバーチャル受信者の mailacceptinggeneralid 属性がバーチャルドメインの完全修飾になっていることを 確かめます。最後に、あるディレクトリエントリをバーチャルドメインのデフォルト ユーザとして指したいのであれば、そのエントリにさらに "@virtual.dom" の mailacceptinggeneralid (またはディレクトリの同等のもの)を与えます。そう、 ユーザ部分はありません。なんでも受け取るユーザがいらなければ、このステップを 省略すると、そのドメインの知らないユーザは単にバウンスされます。
まとめると、このように見えるバーチャルドメインの全てのアドレスを 受け入れるユーザを持つかもしれません:
dn: cn=defaultrecipient, dc=fake, dc=dom objectclass: top objectclass: virtualaccount cn: defaultrecipient owner: uid=root, dc=someserver, dc=isp, dc=dom 1 -> mailacceptinggeneralid: fake.dom 2 -> mailacceptinggeneralid: @fake.dom 3 -> maildrop: realuser@real.dom
1: Postfix は fake.dom を探して何か (maildrop) が返ってきたときに これが有効なバーチャルドメインであることを知ります。
2: このことにより、fake.dom の知らないユーザ宛のいかなるメールも このエントリに行きます...
3: ... そして maildrop に行きます。
普通のユーザは単に一つの mailacceptinggeneralid と maildrop 、つまり "normaluser@fake.dom" と "normaluser@real.dom" を持つでしょう。
このドキュメントに使われているちょっとしたスキーマや属性名は単なる 例です。いくつかが LDAP 設定パラメータのデフォルトであるという以外は特に 意味がありません。好きなスキーマを使って、それに合わせて Postfix を設定して ください。
mailacceptinggeneralids がユニークであることや、誰もが postmaster や root として指定できるわけではないことを確認したいかもしれません。
1つのエントリは任意の数の mailacceptinggeneralids または maildrops を 持つことができます。maildrops はカンマで区切られたアドレスのリストも 使えます。それらは全て検索により見つけられ、返されます。例えば、次のような メーリングリストとして使うためのエントリを定義できます (警告! この例だけのために作られたスキーマです):
dn: cn=Accounting Staff List, dc=my, dc=com cn: Accounting Staff List o: my.com objectclass: maillist mailacceptinggeneralid: accountingstaff mailacceptinggeneralid: accounting-staff maildrop: mylist-owner maildrop: an-accountant maildrop: some-other-accountant maildrop: this, that, theother
LDAP マップをエイリアス以外の検索に使うのであれば、検索に意味が あることを確かめなければいけないかもしれません。virtual 検索の場合、 メールアドレス以外の maildrops は、Postfix がプログラムやファイル配送の 所有者をセットする方法を知ることが出来ないので、ほとんど意味がありません。 query_filter はおそらく次のようにすべきでしょう:
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")(maildrop="*:*")(maildrop="*/*"))))
そしてこの問題に関して、特にエイリアスに対しても、プログラムや include などとしてユーザが maildrops を指定できないようにしたいかも しれません。これは典型的には UNIX ローカルアカウントを持たずに LDAP と Cyrus だけにユーザが存在する、密閉されたサーバに適切かもしれません。 管理者アカウントが所有するディレクトリエントリだけに楽しいことを許可 したいかもしれませんし、その結果、仮にオブジェクトがそれ自身の maildrop としてのプログラムを持っていて "cn=root" により所有されていないとしても、 有効なローカルユーザとして返されることはありません。このことにより、 あなたの部分に安全に実装するために、このタイプの配送から派生する問題に 対していくらかの考慮が必要です。LDAP 検索の無駄を許す煩わしさに価値が なく、これを query_filter で禁止し、majordomo リストのローカルエイリアス データベースのように維持しようと決めるかも知れません。
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")(maildrop="*:*")(maildrop="*/*"))(owner=cn=root, dc=your, dc=com)))
LDAP 検索はローカル DB や DBM 検索よりも遅いです。ほとんどの サイトではこれがボトルネックとなることはないでしょうが、ディレクトリ サービスを調整する方法を知っておくのはよい考えです。
以下のクエリ関連パラメータのみが異なる場合、複数の LDAP マップが同じ LDAP 接続を共有します: base、scope、query_filter など。これを活用するには、 LDAP マップの定義で誤った違いを避けてください: ホストの選択順序、 バージョン、bind、tls パラメータ、... これらはできるだけ常に複数のマップで 同じにすべきです。
質問があれば、postfix-users@postfix.org に送ってください。それには あなたの Postfix セットアップに関連した情報を含めてください: postconf の LDAP 関連の出力、ビルドに使った LDAP ライブラリの種類、使っている ディレクトリサーバ。質問にディレクトリの内容が含まれるのであれば、 ディレクトリエントリのうち当てはまるものも含めてください。