 |
 |
|
 |
|
|
|---|---|---|
| このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 | ||
|
|
|
|
|
|
|---|---|---|
| このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 | ||
使用する LDAP データベースはたったひとつ。Qmail-LDAPプロジェクトの築き上げてくれたスキーマを活用して作成する。このデータベースは、uid, cnの他、パスワード, ホームディレクトリ, 転送先メールアドレスのリスト, アカウントの有効/無効など様々な属性を持ち、Postfix の複数の機能からも Dovecot からも参照させる。LDAP との通信は UDP で行われるので、当然、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 ログイン認証のためのアカウント名/パスワードの検索スキームを規定する auth_passdb と、メールファイルの読み出し元を割り出す時の auth_userdb がある。メールボックスの読み書きは、Postfix の配送時と同様、常に mailadmin の権限で行われる。なお、POP3 でメールを読めるのはバーチャルメールアカウントだけであり、root など実システムアカウントは、ローカルログインするか SSH を通じてログインして mutt などのローカルメールリーダーで読むこととする。
なお、前書きでも少し触れたように、LDAP によるメールアカウント一括管理はメールサーバの冗長化にも大きなメリットをもたらす。その際には、上図の Mail Box の中の /var/vmail/ を共有ディスク上に置くことになる。その時にファイルロックの問題で悩まずにすむよう、メールボックスのタイプは1メール/1ファイル管理の Maildir 方式にしておく。1ユーザ/1ファイルの mbox 方式と異なり、基本的にファイルロックが不要だからだ。Active-Active 構成だろうが Active-Standby 構成だろうが、各メールファイルは一意なファイル名で作成されるため、最近の Postfix ではまず衝突は起きない。ただし、メールキューの共用は御法度だ。root など実ユーザに送られてくるメールの内容はそのマシン固有の問題や報告なので、実ユーザのメールボックスも各マシン上に置いておくのがよいと筆者は考える。
当ページでの説明は、以下の基本パラメータに基づいて行う。
postfix, dovecot, openldap-servers パッケージは既にインストールしてあるものとする。LDAPデータベースの保守やデバグのために openldap パッケージ (OpenLDAPクライアントアプリケーション群) もインストールしておこう。
| マシンのフルホストネーム | 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/users | 各ユーザのメールボックスは /var/vmail/users/<UserName>/Maildir/ となる |
| Suffix | o=hoge,dc=cxm |
| 実際のデータ格納Directory | ou=mail,o=hoge,dc=cxm |
| root DN | cn=Manager,o=hoge,dc=cxm |
| メールアカウント情報読み取り専用DN | cn=mailadmin,ou=mail,o=hoge,dc=cxm |
| SMTPサーバ | mail.hoge.cxm |
| POP3サーバ | 同上 |
| POP3アカウント名 | user@hoge.cxm の形式 |
| その他 | SSL/TLS、APOP、SMTP-AUTH、ハッシュパスワード認証などについては、ドキュメントの的を絞るため触れない |
root# useradd -u 501 hoshu root# passwd hoshu
root# useradd -u 1025 -d /var/vmail -s /sbin/nologin \
-m -k /dev/null mailadmin
/etc/shadow ファイルのパスワードフィールドを潰しておく‥
mailadmin:*:13900:0:99999:7:::
root# useradd -r -u 105 -d /usr/libexec/dovecot dovecotauth
# Dovecot log. mail.* /var/log/maillog # Postfix log. local6.* /var/log/smtp.log編集後 syslogd を再起動する‥
root# service syslog restart
root# mkdir -p /var/vmail/users root# cd /var/vmail root# chown -R mailadmin:mailadmin . root# chmod 755 . root# chmod 750 usersなお、/var/vmail/ を別のファイルサーバに置き NFS マウントして使用する場合には、メールサーバローカル上のマウントポイント /var/vmail/ のパーミッションを root:root 0755 にしておき、マウント後の実体だけを上記のパーミッションにしておくと、きちんとマウントできている時にだけ mailadmin が書き込みを行えるようになる。マウントされていない状態で Postfix がメールを受信すると、メールはローカルのキューにプールされ、共有ファイルシステムが復活したら然るべきタイミングでメールボックスへ書かれるという理想的な動作が得られる。このようにしておかないと、マウントされていない時にメールを受信すると Postfix がローカルファイルシステム上の /var/vmail/ 配下にサブディレクトリを自動的に作ってしまう。