Postfix-389DS  
  HOME Next
オフィシャルサイト： The Postfix Home Page, Dovecot,
389 Directory Server (Open Source LDAP)

Postfix + LDAP 時々 Dovecot - 389DS版

以前、同じテーマを OpenLDAP との組み合わせでやったが、今回は、LDAPサーバソフトウェアを 389 Directory Server (389 DS, かつての Fedora DS) に換えてページを再構成してみた。OpenLDAP も素直でいいのだが、実際の運用面では、設定用 GUI ツールを標準で備えている 389 DS のほうが使い勝手に優れている。また、手元の Dovecot も 0.99.11 から 1.0.7 にバージョンが上がり、機能の向上とともに設定ファイルの記述法が少々変わった。さらに、今回は Postfix の SMTP AUTH、それに、Dovecot と Postfix の TLS の設定も盛り込んだ。

このページでは、Postfix を LDAP と連携させ、且つ、メールユーザを非システムアカウントとして効率的に管理する方法を述べる。メールの読み取りには POP3 を利用する前提に立つので、この構築方法と協調するための POP3デーモン Dovecot の設定も網羅する。Postfix の設定はオフィシャルサイトのリファレンスページで充分に詳説されており、解説し始めたらキリがないので、説明は当実装に関係のある部分に絞り込む。LDAPサーバには 389 Directory Server (389 DS) を使用するが、ここで述べる手順や方法は他の LDAPサーバソフトウェアとの併用でも活用できるだろう。また、この方法は、ユーザメールデータを共有ディスクに配置しておき複数のメールサーバで冗長構成を組む時にも役に立つ。

内容は基本的に、CentOS 5.4 上での Postfix 2.3.3, Dovecot 1.0.7 での検証に基づいている。389 DS は 1.1.3。

LDAP連携は、3つのデーモン、設定ディレクティブの一片一遍、ファイルシステムが複雑に協調してはじめて動作が成り立つので、つまみ食いせずに全体を斜め読みしてから構築にあたることをお勧めする。

Table of Contents

実装概要

当実装では、一般メールユーザを LDAP ディレクトリで管理し、UNIXシステムユーザをほとんど使用せずに、Postfix 及び Dovecot のバーチャル機能を介してバーチャルなメールユーザとして運用する。Postfix-LDAP 連携というと、Postfix のごく基本的な設定情報から何から何まで LDAP に持たせたがる人が多く見受けられるが、筆者は賛同できない。LDAPサービスが不通になった時の Postfix の挙動がコントロールしにくいからだ。当実装では、LDAP ディレクトリにはユーザアカウント情報だけを持たせるようにする。

※ LDAP の "ディレクトリ" という語彙はファイルシステムの "ディレクトリ" と区別しにくいため、これ以降、敢えて「データベース」と呼ぶことにする。

使用する LDAP データベースはたったひとつ。389 DS の備える mailRecipient オブジェクトクラスを利用する。このデータベースは、uid、パスワード、ホームディレクトリ、転送先メールアドレスなど様々な属性を持ち、Postfix の複数の機能からも Dovecot からも、そして SMTP AUTH のための SASL からも参照させる。LDAP との通信は TCP で行われるので、当然、LDAPサービスは別マシン上で稼働させても構わない。

左図は、当ページで紹介する実装の仕組みを略図にしたもの。かなり簡略化してあり、現実には virtual_alias_maps や recipient_bcc_maps の前にも virtual_mailbox_maps が参照されるなど流れはもう少し複雑だ。

マシンにメールがやってくると、Postfix は設定値 mydestination 及び virtual_mailbox_domains に照らしてそのメールが実メールドメイン宛かバーチャルメールドメイン宛か判断する。実ドメイン宛てだった場合は、alias_maps で指定された参照先 /etc/aliases を参照して転送先アカウントがあるかどうか判断し、最終的に passwd ファイルからそれらユーザのホームディレクトリを特定して配送を行う。こちらは logwatch や cron などがローカル上で管理者宛に送ってくるごく限られたメールだけが対象となるわけだが、受信メール配送の仕組みの基本形なので先に述べておいた。

mydestination と virtual_mailbox_domains の規定から、宛先がバーチャルメールドメイン、つまりメールアカウント管理上にだけ存在する非システムユーザだと判断された場合には、まず、実アカウントの時の alias_maps にあたる virtual_alias_maps によってメール転送先の割り出しが行われる。virtual_alias_maps にはふたつの役割を持たせる。ひとつは、バーチャルメールアカウントから別のメールアドレスへのフォワード (リダイレクト)。通常ならユーザ各々の .forward ファイルで管理するところだが、これも件の LDAP データベースで一括管理する。もうひとつの役割は、バーチャルメールドメイン内の postmaster や root など特別なアカウントを実システムユーザへ振り向けなおすことだ。これに加えて、recipient_bcc_maps 機能を使ってオート BCC も実現し、その情報も同じ LDAP データベースで管理する。recipient_bcc_maps がフォワードと異なるのは、やって来たメールが転送先だけでなく元の宛先アカウントにも配送されるという点だ。そして最終的に、virtual_mailbox_maps ディレクティブで規定した方法で LDAP データベースが検索され、そこから割り出されたメール書き込み先ディレクトリへと配送が行われる。バーチャルメールボックスへのメール配送は、常にひとつのシステムユーザ mailadmin の権限で行わせる。読み書きの権限がひとつの UNIXユーザに絞られるという点は、メールボックスを共有ディスクに置いて NFS マウントして使用する場合に、セキュリティ面や、バックアップ/リストア、データ移行の面で大きなメリットをもたらす。

POP3 デーモン Dovecot も、Postfix と同じデータベースを使用する。主なディレクティブとしては、POP3 ログイン認証のためのアカウント名/パスワードの検索スキームを規定する passdb と、メールファイルの読み出し元を割り出す時の userdb がある。メールボックスの読み書きは、Postfix の配送時と同様、常に mailadmin の権限で行わせる。なお、POP3 でメールを読めるのはバーチャルメールアカウントだけであり、root など実システムアカウントは、ローカルログインするか SSH を通じてログインして mutt などのローカルメールリーダーで読むこととする。

Postfix を送信メールサーバとして使う時には、SMTP認証を求めるようにする。認証は、Postfix が SASL (Simple Authentication and Security Layer) に問い合わせ <-> SASL が LDAP にユーザ名とパスワードの妥当性を問い合わせ、という構造で成り立つ。上図の緑の線で示したように、SASL の実装方法としては、Cyrus SASL を使う方法と、Dovecot 内蔵の SASL 機能を使う方法とがある。当ドキュメントでは一応両方を説明するが、最終的な選択は読者にお任せする。

なお、前書きでも少し触れたように、LDAP によるメールアカウント一括管理はメールサーバの冗長化にも大きなメリットをもたらす。その際には、上図の Mail Box の中の /var/vmail/ を共有ディスク上に置くことになる。その時にファイルロックの問題で悩まずにすむよう、メールボックスのタイプは 1メール/1ファイル管理の Maildir 方式にしておく。 1ユーザ/1ファイルの mbox 方式と異なり、基本的にファイルロックが不要だからだ。Active-Active 構成だろうが Active-Standby 構成だろうが、各メールファイルは一意なファイル名で作成されるため、最近の Postfix ではまず衝突は起きない。ただし、メールキューの共用は御法度だ。root など実ユーザに送られてくるメールの内容はそのマシン固有の問題や報告なので、実ユーザのメールボックスも各マシン上に置いておくのがよいと筆者は考える。

当ページでの説明は、以下の基本パラメータに基づいて行う。
postfix, dovecot パッケージは既にインストールしてあるものとする。389 DS のインストールに関しては次のページで述べる。

システム基本情報
マシンのフルホストネーム penguin.hoge.1 IP はプライベートアドレスにする
マシンのホストドメイン hoge.1  
バーチャルメールドメイン hoge.cxm こちらがメールサーバ運営上の本命のドメイン名
メールサーバとしての公開ホスト名 mail.hoge.cxm インターネットへの公開FQDN
常用保守管理UID hoshu ホームディレクトリ： /home/hoshu
root や postmaster 宛のメールも彼に集める
バーチャルユーザメールの配送/読み書き専用UID mailadmin ホームディレクトリ： /var/vmail
シェル： /sbin/nologin
Dovecotの認証プロセス専用UID dovecotauth ホームディレクトリ： /usr/libexec/dovecot
バーチャルメールボックス基底ディレクトリ /var/vmail/<Domain> 各ユーザのメールボックスは /var/vmail/<Domain>/<UserName>/Maildir/ となる
LDAP Directory (データベース) 基本情報
Suffix dc=hoge,dc=cxm
実際のデータ格納Directory ou=People,dc=hoge,dc=cxm
root DN cn=Directory Manager
メールアカウント情報読取り専用DN cn=userretriever,dc=hoge,dc=cxm
メールアカウント情報編集用DN cn=usermanager,dc=hoge,dc=cxm
パスワード格納形式 SMD5
メールクライアントに求める設定
SMTPサーバ mail.hoge.cxm
POP3サーバ 同上
POP3アカウント名 user@hoge.cxm の形式。ただし、user だけでも認証できるようにする
SMTP AUTHアカウント名 user@hoge.cxm の形式。ただし、user だけでも認証できるようにする

OSの環境整備

マシンドメインの設定

この実装では、一般のメールユーザをバーチャルメールボックスで扱う。Postfix は、受信メールの宛先が実ユーザなのかバーチャルユーザなのか判断するにあたって、ドメイン、つまりメールの宛先アドレスの @ 以降を判断基準にする (※)。よって、このメールシステムには「バーチャルでない」ドメインとバーチャルドメインのふたつが必要ということになる。「バーチャルでない」ドメインのユーザとは、このサーバマシンの実 UNIXアカウントのこと。実ユーザのメールなどほとんど用がないと思うかもしれないが、ここで問題となるのがローカルマシン上の cron や logwatch などから管理者宛に 1日数通送られてくる報告メールだ。それらはローカルマシン上の実ユーザのメールボックスに配送したい。

そこで、OS にはどうでもいいローカルなホスト名を付け、そちらを Postfix の名目上の主取り扱いドメインにする。具体的に言えば；

※ 判断基準となるのは、より正確に言えば「アドレスリライティング処理後の @ 以降」。

システムユーザの作成

実行権限を分離するため、保守・構築作業一般に使うユーザをはじめ、幾つかのユーザを作成する。

保守ユーザ

普通にログインできる保守ユーザ。後で、root や postmaster 宛のメールをこのユーザが受け取るようメールエイリアスを施す。

root# useradd -u 501 hoshu
root# passwd hoshu
バーチャルメール管理ユーザ

バーチャルメールドメインへのメール配送、POP3 の際のメールの読み書きを一手に引き受ける。安全のため、ログイン不能とし、パスワードも設定できないようにしておく。(名前は任意)

root# useradd -u 1025 -d /var/vmail -s /sbin/nologin \
 -m -k /dev/null mailadmin

/etc/shadow ファイルのパスワードフィールドを潰しておく；

mailadmin:*:13900:0:99999:7:::
Dovecot の認証プロセス用ユーザ

POP3 認証プロセス権限を分離するためのユーザ。ホームディレクトリ /usr/libexec/dovecot/ は Dovecot の実行ファイル群のあるディレクトリ。UID は 1025 以上の適当なもの。パスワードは与えない。

root# useradd -M -u 5001 -d /usr/libexec/dovecot dovecotauth

syslogの調整

RedHat 系デフォルトの syslog.conf では Postfix の SMTP のログも Dovecot の POP3 のログも /var/log/maillog ファイルに書かれてしまい、いざという時に解析がしにくい。そのため /etc/syslog.conf を修正する。Dovecot 1.0.7 やそれ以降では、設定ファイルの syslog_facility ディレクティブでログファシリティを変更できるようになっているので、Dovecot のログは /var/log/dovecot.log に書かれるようにする。Postfix のほうはデフォルトのまま。Dovecot の syslog ファシリティは後で dovecot.conf で変える。ファイル名の前の `-' は、「書込み毎にいちいちファイルシステムバッファをフラッシュするな」の意味。

*.info;mail.none;authpriv.none;cron.none;local6.none	/var/log/messages
 
# Postfix log.
mail.*			-/var/log/maillog
 
# Dovecot log.
local6.*		-/var/log/dovecot.log

編集後 syslogd を再起動する；

root# service syslog restart

dovecot.log に関しては、logrotate の設定もするべきだが、ここでは触れない。logrorateのページ参照のこと。

バーチャルメールボックス基底ディレクトリの作成

バーチャルメールユーザのメールボックスの基底となるディレクトリを作成する。一切の読み書きを引き受けることになる mailadmin の所有物にし、それ以外では読み書きできないようにしておく。基底ディレクトリ /var/vmail/ は UNIXアカウント mailadmin の作成時にできているはず。 

root# mkdir -p /var/vmail/hoge.cxm
root# cd /var/vmail
root# chown -R mailadmin:mailadmin .
root# chmod 755 .
root# chmod 750 hoge.cxm

なお、/var/vmail/ を別のファイルサーバに置き NFS マウントして使用する場合には、メールサーバローカル上のマウントポイント /var/vmail/ のパーミッションを root:root 0755 にしておき、マウント後の実体だけを上記のパーミッションにしておくと、きちんとマウントできている時にだけ mailadmin が書き込みを行えるようになる。マウントされていない状態で Postfix がメールを受信すると、メールはローカルのキューにプールされ、共有ファイルシステムが復活したら然るべきタイミングでメールボックスへ書かれるという理想的な動作が得られる。このようにしておかないと、マウントされていない時にメールを受信したりPOP3アクセスがあったりすると、Postfix や Dovecot がローカルファイルシステム上の /var/vmail/ 配下にサブディレクトリを自動的に作ってしまう。

  TOP Next
  HOME LDAPデータベースの構築