sendmailからの移行レシピ
以下のテキストは、執筆時当時の情報を元に書いたものであり、
現在の情勢にそぐわないことを含む場合があるので注意されたい。
また、テキストは最終提出原稿で校正を経る前のものなので、実際にUNIXUSER
本誌に記載されたものとは異なる。誤字脱字等そのままである。
致命的な誤り以外は加筆修正等は行なわないので情報の鮮度に気をつけつつ
利用して欲しい。
→目次
Part IV sendmailからの移行
Part II, III で説明したようにPostfixもqmailもソフトウェアの置き換えは非
常に簡単に行なうことができる。しかし実際に既に運用しているメイルサーバを
置き換える場合は話は単純ではない。MTAの種類を変えるか否かにかかわらず、
メイルサーバの置き換えをする場合には、利用者へのアナウンス、メイルボック
スの移行、関連ソフトウェアのインストールとカスタマイズ、などなど、利用者
にとってスムーズな移行を行なうためにいろいろ為すべきことは多い。
Part IV では既に運用しているメイルドメインでメイルサーバの移行を行なう場
合に考慮すべきことがらと、行なうべき作業の流れについて解説する。以下で述
べる手順はエッセンスだけを取り出したものである。各々の手順をそのまま実行
するのではなく、それが意味していることが読者のサイト事情にどう対応してい
るかを考えながら読んで欲しい。
■メイルサーバの移行
いざsendmailから別のMTAに移行すると決断したとしても、既存ユーザがいる場
合はそのタイミングが難しい。移行作業中はメイルサービスが一時的に止まるの
で、あらかじめ通達しなければならない。通達に時間がかかったりすることを考
慮して、サーバ移行作業は余裕をもって計画的に行なうのが重要である。このよ
うに大きな作業となるので、移行作業に踏み切るタイミングは慎重に選ぶ必要が
ある。一時的な不通状態による影響をできるだけ小さくすることを考えると、次
のような時が好期として挙げられる。
* サーバのハードウェアリプレイスのタイミング
* 現サーバのセキュリティホールなどの修正の必要が出たとき
* 長期休暇/停電など利用率の下がる時期
一般利用者に対しては、移行時期はメイルの送受信を控えてもらったり、多かれ
少なかれ生ずる移行後の利用環境変化に対応してもらうことをお願いする必要が
ある。そのため、スムーズな移行作業を行なうためには利用者の協力を得ること
も重要な要素となってくる。移行アナウンスをする場合、移行にともなってセキュ
リティが向上することや、MTAの変更による利便の向上などをしっかりと伝える
ようにして、移行が利用者自身のメリットにもつながることを理解してもらわな
ければ本質的な協力を得ることは難しい。
ここで、サーバ移行の条件として、
* サーバマシン自体のリプレイスも含む
* 現サーバは mail.foo.ymzk.org(10.0.250.25)
新サーバは newmta.foo.ymzk.org(10.0.250.24) とする
* sendmail から Postfix または qmail への移行
* mbox形式から Maildir 形式へ
というものを想定して、移行作業の進行をシミュレートしてみよう。
アナウンスを含めた移行作業の長期的な流れは以下のようになる。
(事前の前提条件)
1. 移行をスムーズにするためのDNSレコードの設定
(一週間〜一ヶ月程度前)
2. 利用者への移行アナウンス
3. 移行時用セカンダリメイルサーバのセットアップとMXレコードの変更
4. 新サーバへのMTAのインストール
5. 新サーバへのpopperなどのインストール
(移行実施日)
6. 旧MTAの停止
7. メイルボックスの移行
8. 2で設定したセカンダリサーバの新サーバへのリレー設定
9. 新サーバの本格稼動
それぞれのポイントを解説しよう。
(1) 移行をスムーズにするためのDNSレコードの設定
メイル利用者のクライアントPCに設定する項目としては、POP/IMAP サーバのホ
スト名と、SMTPサーバのホスト名がある。これらにサーバの本名を指定させてし
まうと、のちのちサーバを変更するときに全てのクライアントのメイル関連情報
を変更してもらわなければならなくなってしまうので、なるべく機能を表す別名
で登録してもらうのが望ましい。たとえば、メイルサーバ、POPサーバが
mercury.example.com(10.0.0.25)
だったとしても、これをそのままクライアントPC用のSMTPサーバ/POPサーバとし
て登録させるのではなく、
;;(BINDの場合)
smtp IN A 10.0.0.25
pop IN A 10.0.0.25
------------------------------------------
# (djbdnsの場合)
+smtp.example.com:10.0.0.25:86400
+pop.example.com:10.0.0.25:86400
といった別名レコードを登録した上で、smtp.example.com, pop.example.com を
それぞれSMTPサーバ、POPサーバとしてクライアントPCのMUAに登録しておいても
らうようにする。多くのサイトではこのようにしていると思われるが、もしサー
バの本名をMUAに登録してしまっているような場合は、事前に変えておいてもら
うと移行時の混乱が少なくてよい。
(2) 利用者への移行アナウンス
余裕をもって一ヶ月程度前には、メイルサーバの移行があることを通達しておき
たい。この際、移行を決定するに至った要因、移行後の利用者のメリットなどを
もらさずに伝えるようにする。管理者側としては、アナウンスをメイルで行なっ
て安心してしまいがちだが、長期出張などで移行作業の日までメイルが読めない
人には全く連絡が行かないことになってしまうので、適宜メイル以外の手段(紙
など)を利用して伝えることを怠らないように気をつけたい。
移行作業日当日には具体的に何時から何時まで、メイルサービスが停止するとい
うことも含め、何が起きるのかが利用者に伝わりやすいように注意して案内文を
作成する。
(3) 移行時用セカンダリメイルサーバのセットアップとMXレコードの変更
サーバ移行当日のメイルの配送をできるだけ途切れさせないように行なうために
は、事前に緩衝役となるセカンダリメイルサーバを立てておくと良い。こうして
おくことで外部から到達するメイルの最終到着点を、手許のマシンでコントロー
ルすることができるようになり、置き換えのタイミングの自由度が増す。もしこ
のようなサーバを調達できない場合はなくてもサーバ移行は可能だが、用意でき
る場合は次の手順により緩衝サーバを設定しよう。
ネットワーク的に外部(インターネット)と直接通信できる位置にあるホストを一
台選んでメイルサーバをセットアップしよう。Postfix, qmail いずれでも良い
ので、Part2, Part3 を参考に基本的なメイルサーバとしての機能を構築し、さ
らに現在の主メイルサーバ宛のメッセージを受けられる状態にする。たとえば、
運用中のメイルドメインが @foo.ymzk.org で、主メイルサーバが
mail.foo.ymzk.org(10.0.250.25) だったと仮定しよう。このドメインへのメイ
ルをいったん別の緩衝サーバで受けてから主メイルサーバに流すようにする。こ
の緩衝サーバを cushion.foo.ymzk.org(10.0.250.26) とする。ここに入れるメ
イルサーバでは、
A このメイルドメイン(foo.ymzk.org)宛のメイルは受理する
B ただしローカル配送はせず mail.foo.ymzk.org に転送する
という動作にする必要がある。このための設定は以下のようになる。
[qmailの場合]
A : /var/qmail/control/rcpthosts に
foo.ymzk.org
を追加
B : /var/qmail/control/smtproutes に
foo.ymzk.org:mail.foo.ymzk.org
と記述する
[Postfixの場合]
A : /etc/postfix/main.cf に
relaydomain = $mydestination, foo.ymzk.org
と記述(foo.ymzk.orgを追加)
B : /etc/postfix/main.cf に
transport_maps = hash:/etc/postfix/relay
と記述し、/etc/postfix/relay に
foo.ymzk.org smtp:[mail.foo.ymzk.org]
と記述する。さらに
# postmap hash:/etc/postfix/relay
により変換を行なう。
最後に
# postfix reload
する。
この設定により、@foo.ymzk.org 宛の全てのメイルが mail.foo.ymzk.org に直
接リレーされるか確認しよう(qmailの場合)。
cushion# tail -f /var/log/maillog &
cushion# echo 'This is test.' | Mail -s relaytest testuser@foo.ymzk.org
Feb 5 21:23:04 cushion qmail: 981375784.342141 info msg 7253: bytes 253 from qp 2556 uid 0
Feb 5 21:23:04 cushion qmail: 981375784.344272 starting delivery 5: msg 7253 to remote testuser@foo.ymzk.org
Feb 5 21:23:04 cushion qmail: 981375784.364771 status: local 0/10 remote 1/20
Feb 5 21:23:05 cushion qmail: 981375785.375679 delivery 5: success: 10.0.250.25_accepted_message./Remote_host_said:_250_ok_981384392_qp_374/
問題なくリレーできていることを確認できたら、@foo.ymzk.org のDNS MXレコー
ドを変更しよう。
;;(BINDの場合) [foo.zone]
foo.ymzk.org. IN MX 0 cushion.foo.ymzk.org.
IN MX 10 mail.foo.ymzk.org.
------------------------------------------
# (djbdnsの場合)
@foo.ymzk.org::cushion.foo.ymzk.org.:0:10800
@foo.ymzk.org::mail.foo.ymzk.org.:10:10800
新しいMXレコードがインターネットに行き渡る時間を考慮して、レコード変更は
充分に余裕を見て数日前に完了するようにする。また、移行作業に関係するレコー
ドはTTLを短めに設定しておくと効果的である。
MXレコード変更後、外部から @foo.ymzk.org へのメッセージが、緩衝サーバ経
由で届いていることが確認できれば移行本番時のメッセージの流れの制御がしや
すくなる。
(4) 新サーバへのMTAのインストール
おそらく移行作業より前に実験的なインストールは済ませていることだろう。実
際の移行日の数日前には新しいMTAのソフトウェア的インストールは済ませ、定
義ファイルの準備も済ませておきたい。この作業手順に関しては、Part2, part3
で説明したものがそのまま適用できる。
(5) 新サーバへのpopperなどのインストール
MTAだけでなく、クライアントからのメッセージ取り出しに必要なPOPサーバ、
IMAPサーバなどもインストールする。もし新しいサーバでもsendmail時代と同じ
共有スプールを使うなら同じものを、Maildir形式を利用するのならそれ対応の
ものをインストールする。Maildir対応のPOPサーバのインストールについては次
節で解説する。
(6) 旧MTAの停止
さて、移行作業日当日。手際よく、慎重に作業を進めなければならない。まず最
初に、現在主メイルサーバで稼動しているsendmailをkillする。そして、メッセー
ジキューに溜っているものを全て吐き出させる。念のため、この段階でシステム
のスタートアップファイル(/etc/rc*)からsendmailの起動部分をコメントアウト
しておくようにする。移行作業中、何かのトラブルでサーバマシンをリブートし
たときにまたsendmailが起動してしまうと、それまで緩衝サーバに溜っていた
(本来新サーバに行くはずの)メッセージが流れ込んで来てしまって作業が振り出
しに戻る可能性がある。
(7) メイルボックスの移行
これが一番大きな作業であろう。ここでは新サーバでMaildir形式を利用するも
のと仮定して、古いサーバの /var/mail/* を新サーバの各ユーザの ~/Maildir/
に一括移行する手順を説明する。その作業に先立ち、ユーザアカウントは新サー
バへのコピーが終わっているものと仮定する。
1. /var/mail/* のコピー
旧サーバにあった全てのユーザのメイルボックスをコピーする。これはリ
モートシェルを用いたコピーでも良いし、安全性が確保できればNFSマウン
トで済ますのでも良い。新サーバの /var/mail/* に移行作業までに届いた
全てのメッセージが見える状態にする。このとき、ファイルのUIDが失われ
ていないことをしっかりと確認する。
2. Maildir形式への変換
mbox形式のメッセージをMaildirに一括変換するスクリプトがあるのでこれ
を利用する。http://www.qmail.org/mbox2maildir から、もしくは今月号
付属CD-ROMからこのスクリプトをコピーしよう。これを利用して既存ユー
ザ全てのmboxを変換する手順の一例を示そう。
ここでは mbox2maildir スクリプトを /usr/local/bin に置き、sudo コマ
ンド[註い] がインストールされているものと仮定する。また以下の作業の
ときのrootのシェルは /bin/sh で、各ユーザのメイルボックスのあるディ
レクトリが、/var/mail であるとする。
--[註い]------------------------------------------------------------
一時的にUIDを変更してコマンドを実行できるユーティリティ。
http://www.courtesan.com/sudo/
多くのシステムにある su でも今回の作業は行なえるが、OSによって
suコマンドの仕様がまちまちなのでsudoコマンドで説明を行なう。
--------------------------------------------------------------------
# unset MAILDIR
# for u in `cat /etc/passwd | awk -F: '{print $1}'`
> do
> if [ -f /var/mail/$u ]; then
> MAIL=/var/mail/$u sudo -u $u -H \
> sh -c 'MAILDIR=$HOME/Maildir' perl /usr/local/bin/mbox2maildir
> fi
> done
これにより既にmboxファイルを持つユーザのホームディレクトリにMaildir
形式でメッセージが蓄えられる。ただ、上記の方法では、これまで一通も
メイルを受け取ったことのないユーザのホームディレクトリにMaildirが作
られない。もしMaildirのないユーザが残っているようなら、適宜ユーザの
ホームディレクトリを持つパーティションで
# cd /home
# for u in */
> do
> sudo -u $u /var/qmail/bin/maildirmake $u/Maildir
> done
などとすると良い。なお、後者の作業はqmailのデフォルトの配送メイルボッ
クスを ./Maildir/ にする場合にのみ必要である。
(8) 2で設定したセカンダリサーバの新サーバへのリレー設定
ユーザのメイルボックス移行が完了したら、本格的に新サーバの稼動を始め
て良い。新サーバで新しいMTAを起動する。
[qmailの場合]
新# csh -cf '/var/qmail/rc &'
[Postfixの場合]
新# /usr/local/postfix/postfix start
念のため、そのサーバのローカルユーザ(管理者自身の一般ユーザとしての
アカウントなど)宛にメッセージを送信してみて新MTAでの配送がうまくいっ
ていることを確認してみると良いだろう[註ろ]。問題なければいよいよ外部
からのメッセージが新サーバに流れ込むように緩衝サーバの設定を変更する。
--[註ろ]------------------------------------------------------------
さらりと書いているがこの部分がもっとも重要な確認作業である。外部から新
サーバのアドレスを直接指定してメイルを送ってみたりしてどこからも受信で
きることを慎重に確認したい。
--------------------------------------------------------------------
まず緩衝サーバに溜っているメッセージを新サーバに流し込もう。人工的な
配送経路の変更を行なう。移行作業前に設定した
A このメイルドメイン(foo.ymzk.org)宛のメイルは受理する
B ただしローカル配送はせず mail.foo.ymzk.org に転送する
という動作のBを
B ただしローカル配送はせず newmta.foo.ymzk.org に転送する
~~~~~~~
に変更する。このための変更は以下のようにする。
[qmailの場合]
1. 緩衝サーバのqmailを止める
# tail -f /var/log/maillog & (Solarisなら/var/log/syslog)
# kill `qmail-sendのPID'
2. maillogに
Feb 7 18:20:42 cushion qmail: 981537642.371423 status: exiting
という終了メッセージが表示されるのを待つ[註は]。
3. メッセージの転送先ホストの設定を変更する。
/var/qmail/control/smtproutes の
foo.ymzk.org:mail.foo.ymzk.org
を
foo.ymzk.org:newmta.foo.ymzk.org
に変更する。
4. 緩衝サーバのqmailを起動する
# csh -cf '/var/qmail/rc &'
--[註は]------------------------------------------------------------
実は終了させなくてもメッセージの転送先は変更できるが、変わったことの確
認がややこしくなるので一度終了させるという手順で説明する。シグナルを送っ
た後も旧サーバに送ろうとしているメッセージがあると、これらがタイムアウ
トするまで時間がかかる。このタイムアウト時間を短くしたいときはあらかじ
め/var/qmail/control/timeoutconnect に短めの秒数を設定しておけば良い。
--------------------------------------------------------------------
[Postfixの場合]
1. 緩衝サーバのPostfixを止める
# tail -f /var/log/maillog &
# /usr/local/postfix/postfix stop
2. maillogに
Feb 7 18:20:42 cushion postfix/master[24004]: terminating on signal 15
というメッセージが表示されるのを待つ[註]。
3. メッセージの転送先ホストの設定を変更する。
main.cf に設定したtransport_mapsファイルである
/etc/postfix/relay を
foo.ymzk.org smtp:[mail.foo.ymzk.org]
から
foo.ymzk.org smtp:[newmta.foo.ymzk.org]
に変更する。さらに
# /usr/local/postfix/postmap hash:/etc/postfix/relay
により変換を行なう。
4. 緩衝サーバのPostfixを起動する。
# /usr/local/postfix/postfix start
--[註は]------------------------------------------------------------
これも終了させなくても転送先の変更は可能だが、qmailと同様の理由により
一度終了させるという手順で説明する。待ち時間を少なくするためにタイムア
ウト時間を変更する場合はあらかじめ main.cf で
smtp_connect_timeout = 10s
などとしておけば良い。
--------------------------------------------------------------------
qmail, Postfix いずれの場合も、手順4の起動と同時にキューに溜っているメッ
セージを新サーバに送り込んで行くはずである。
(9) 新サーバの本格稼動
ここまでの手順が全て順調に進んだら、最後にMXレコードを新サーバに向けて作
業完了となる。
;;(BINDの場合) [foo.zone]
foo.ymzk.org. IN MX 0 newmta.foo.ymzk.org.
IN MX 10 cushion.foo.ymzk.org.
------------------------------------------
# (djbdnsの場合)
@foo.ymzk.org::newmta.foo.ymzk.org.:0:10800
@foo.ymzk.org::cushion.foo.ymzk.org.:10:10800
レコード変更が伝播するまでしばらく時間がかかるので緩衝サーバをセカンダリ
サーバとして将来使わない場合でも、しばらく上げておいた方が混乱が少ないだ
ろう。
■virtual domainを利用したサーバの移行
これまで説明したのは、一つのメイルサーバを新しいサーバに移行する方法であ
るが、もともと Postfix, qmail の稼動している既存サーバがある場合は、その
サーバでvirtual domain を設定してそこに移行するという方法も有効である。
複数のドメインを一個のサーバで集中管理できたり、利用頻度の減ったメイルド
メインを統廃合する場合にも利用できるので virtual domain の設定方法を説明
しておきたい。virtual domain に属するユーザアカウントを管理する方法とし
て、MySQLを利用する方法なども存在するが、特にアカウント情報をデータベー
ス化して管理する必要性がなければSQL化する意味はないだろう。ここでは、
Postfix, qmail どちらでも同様の方法で管理できる virtual domain でのメイ
ルアカウント管理方法について解説する。
●virtual domainの設定(qmail)
qmailがデフォルトで用意している virtual domain スキーマは簡便、かつ利
便性が非常に高いのでまずこの設定方法について解説しておこう。後半では
Postfix で同様のスキーマを導入する方法を解説するのでPostfix利用者も仕
組みを理解して欲しい。
qmailでは /var/qmail/control/virtualdomains ファイルに
DomainName:MailPrefix
と書くことにより、anyname@DomainName 宛のメイルをサーバ上の本来のドメ
インに存在する MailPrefix-anyname という宛先に配送する。つまり、通常な
ら ~MailPrefix/.qmail-anyname ファイルに書かれている内容にしたがって配
送が行なわれる[註を]。たとえば古いサーバで運営しているメイルドメインが
@old.foo.ymzk.org であるとして、このドメインを qmail による新サーバの
一つの virtual domain で吸収する場合を考えよう。まず、ドメインを引き受
けるユーザアカウントを作成する。ここでは、そのユーザ名を oldfoo とし、
ホームディレクトリを /home/virtual/old.foo.ymzk.org とする。
--[註を]----------------------------------------------------------------------
もし MailPrefix が user-suffix という形式なら
~user/.qmail-suffux-anyname ファイルに書かれている内容に配送される。
------------------------------------------------------------------------------
# useradd -d /home/virtual/old.foo.ymzk.org -m oldfoo
そして旧メイルサーバのユーザリストをもとに、新サーバの virtual domain
内アドレスを定義する。次の作業例は、全てのユーザがローカルメイルボック
スを持つようなドメインのユーザ一覧がCSV形式(先頭カラムがユーザ名)で
userlist ファイルに格納されている場合を想定したものである。
sh# OLD=/home/virtual/old.foo.ymzk.org
sh# cd $OLD
sh# for u in `awk -F, '{print $1}' userlist`
> do
> echo $OLD/maildir-$u/ > .qmail-$u
> /var/qmail/bin/maildirmake maildir-$u
> done
もし、旧サーバのユーザ x が ~/.forward ファイルを持っていて、メイル転
送しているようなら、新サーバの ~oldfoo/.qmail-x ファイルもそれに応じて
変更すればよいし、~/.forward ファイルがかなりの数に上るなら、適宜シェ
ルスクリプトなどを使って対処できよう。
●Postfix での qmail 互換の virtual domain 設定
qmail型の virtual domain が有用であることが分かったので、それと同じも
のを Postfix で実現する設定をしてみよう。
まず、virtual domain 機能が有効になるように、main.cf に virtual_maps
を宣言する。
virtual_maps = regexp:/etc/postfix/virtualdomains
そして /etc/postfix/virtualdomains を作成する。
/^old\.foo\.ymzk\.org$/ hoge
/^(.*)@old\.foo\.ymzk\.org$/ oldfoo+$1
このマップ[註に]により qmail と同じ仕組みの書き換えが起こり、
anyname@old.foo.ymzk.org 宛のメイルがサーバ上の本来のドメ
インに存在する oldfoo+anyname という宛先に配送される。つまり、
~oldfoo/.forward+anyname ファイルに定義されている場所に配送されること
になる。
--[註に]------------------------------------------------------------------
一行目の正規表現の右項はどんな単語でも良い。
--------------------------------------------------------------------------
このようにして ~oldfoo/maildir- ディレクトリに格納されたメイルは
後述する WU-IMAPD 拡張パックの virtual domain 対応機能により各ユーザ毎
にPOPによる取り出しを行なうことができる。
■周辺ツールの移行
ここまでの説明は純粋にMTAとメイルボックスの移行に絞ったものであるが、
実際はMUAやPOP/IMAPサーバのセットアップも併行して進めておく必要がある。
もし、ユーザのメイルボックスを /var/mail/USER のままにするのなら多くの周
辺ツールは変更する必要がない。しかしそれがあまり前向きでないことは繰り返
し説明したとおりである。ここでは、Maildir形式に移行する場合の各種ツール
の移行の考え方について解説する。
●ローカルメイルリーダなどの移行
Part2で少し触れたように、Mailコマンドや古いMHを直接使ってメイルを読んで
いるような場合、これら古いMUAを Maildir 形式に対応することは現実的でない。
それらを利用しているユーザにはしっかりと理由を説明して Mew や Wanderlust
のような up-to-date なMUAに移行してもらう方が良いだろう。どうしても不可
能な場合は、そのユーザだけ /var/mail/USER にメイルを落とすようにしてもら
うしかない。
比較的良く問い合わせを受けるものに vacation の利用がある。vacationは不在
のときに個人的に送られたメッセージに対して、しばらく留守にすることを自動
的に返送するユーティリティだが、最近は携帯電話やモバイル通信機器などによ
り連絡がつくことなどもあり既に役割を終えた感もある。それでもどうしても使
いたいという場合、Postfixではsendmailのときと同じ方法で使うことができる。
qmailでは、Maildir配送のときにかぎり、いわゆる "UNIX From" を前置しない
のだが、vacationではこれを利用するので少し工夫が必要である。たとえば、ロー
カルMaildirへの配送と vacation 利用両方を行なう場合は、~/.qmail に次のよ
うに記述する。
./Maildir/
| (echo $SENDER `date`; cat) | /usr/bin/vacation user
ただ、この記述にミスがあったりすると、配送エラーなどのトラブルが留守中ずっ
と続くことになるので、管理者側としてはよほどの事情がない限り勧めたくはな
いのが本当のところである。
●Maildir対応POPサーバ
Maildir形式を扱えるものにはいくつかあり、その中でqmail, Postfix特有の
virtual domainに属するメッセージの取り出しをサポートしているものの一例と
してWU-IMAPD(imap-2000)に筆者が機能追加を行なったパッケージ[註に]を今回
紹介する。これは2000年12月号で紹介した時点ではqmailを主眼に置いた仕様で
あったが、のちに Postfix の拡張アドレスでも使えるように修正を加えたので、
これからPostfixを入れる予定の人も試してみてほしい。
--[註に]------------------------------------------------------------
http://www.gentei.org/~yuuji/software/imapext/
--------------------------------------------------------------------
ここで説明するPOPサーバのインストールは、メイルサーバの移行作業日以前に
済ませておかなければならないことに注意する。
・imap-2000 + 拡張パック
本誌付録CDROM中の imap-2000a-qmav20010128.tar.gz は、WU-IMAPD 2000 を
ベースに、以下の機能を追加したものである。
* Maildir 対応
* ~/.qmail-* による拡張アドレス対応
(Postfixの場合は ~/.forward+*)
* virtualdomain アカウント対応
* APOP対応
* メイルパスワードのUNIXパスワードとの分離
* POP3許可ドメインの限定
* POP before SMTP 機構
このPOP/IMAPサーバプログラムのインストールは以下の流れで行なう。
1. サーバプログラムのコンパイルとインストール
2. inetd.conf への登録
3. POP before SMTP の設定
それぞれの手順について個々に解説する。
1. コンパイルとインストール
WU-IMAPではmakeのときに、利用プラットフォームを表すシンボルをあたえ
ることになっている。まずはソースアーカイブを展開しREADMEとMakefile
に目を通そう。
# tar imap-2000a-qmav20010128.tar.gz
# less README Makefile
代表的なプラットフォームとmakeにあたえるシンボルは[表ほ]のようになっ
ている。
--[表ほ]-----------------------------------------
FreeBSD bsf
BSD/i386 bsi
OpenBSD bso
GCC Solaris gso
Linux lnx, sl4, sl5, slx
NetBSD neb
-------------------------------------------------
このパッケージではデフォルトではMTAとしてqmailを利用することを前提
としているが、もしPostfixを利用する場合は最上位の Makefile の
EXTRACFLAGS に -DPOSTFIX を指定する。
EXTRACFLAGS=-DQMAIL -DRESTRICT_POP
↓
EXTRACFLAGS=-DQMAIL -DRESTRICT_POP -DPOSTFIX
このコンパイル変数は、ユーザの拡張メイルボックス(Maildir形式)の指定
を行なうファイル名として ~/.qmail-* ではなく ~/.forward+* を利用す
ることを定義する。その他POPの動作に関連するコマンドなどの置き場所と
してWU-IMAPD拡張パックがもつデフォルト値は[表へ]のようになっている。
--[表へ]-----------------------------------------
機能 デフォルト値
クライアントアドレスによる生POP制限 ON
ユーザのメイル専用パスワードファイル名 ~/.apop
パスワードファイルデコードプログラム /usr/local/sbin/deapop
POP before SMTPのフックコマンド /usr/local/etc/pop3-record
-------------------------------------------------
これらのデフォルト値を変更する場合は README.qmailapop ファイルを参
考に Makefile 等を修正してからmakeする。以下の例では FreeBSD で作業
を行なうものとして解説する。
# make bsf
コンパイルが終了するとできている ipopd/ipop3d がPOPサーバプログラム
である。これをインストールする
# install -cs ipopd/ipop3d /usr/local/etc
ここではサーバプログラムを /usr/local/etc にインストールすると仮定
した。また、POP before SMTP のためのコマンドなど、本拡張パック固有
のツールをインストールする。
# cd APOPtools
# install -c -m 700 deapop /usr/local/sbin
# install -c -m 755 apoppasswd /usr/local/bin
# install -c -m 700 pop3-record /usr/local/etc (←qmailの場合)
# install -c -m 700 pop3-record.postfix /usr/local/etc/pop3-record
(↑Postfixの場合)
# ln -s pop3-age /usr/local/etc/pop3-update
# ln -s pop3-age /usr/local/etc/pop3-record
2. inetd.conf への登録
外部からの接続要求時に自動的にPOPサーバが起動するように
/etc/inetd.conf に以下の記述を追加する。もし、システムのinetdに
tcp_wrappers(libwrap)が組み込まれてる場合は
pop3 stream tcp nowait root /usr/local/etc/ipop3d ipop3d
とし、組み込まれていない場合は、tcp_wrappersの主プログラムである
tcpdを挟んで起動するようにする。
pop3 stream tcp nowait root /usr/sbin/tcpd /usr/local/etc/ipop3d
書き換えが終わったら動作中のinetdにHUPシグナルを送る。
----------------------------------------------------------------------------
コラム APOP推進計画
WU-IMAPD 拡張パックでは素のPOP3での接続を特定のネットワークからだけに制
限する機能がついている。周知の通りPOP3ではパスワードを平文のままネットワー
クに流してしまう。これをサイト外部のネットワークから利用されたらパスワー
ドを盗んでくださいと言わんばかりである。「別に見られて困るようなやりとり
はしてないしなあ…」などとパスワード漏洩の影響が自分だけにとどまると勘違
いする利用者もいる。現在普及している多くのPOPデーモンでは、UNIXパスワー
ドをそのまま利用しているので、POP3パスワードはログインパスワードと共通し
ている。これが漏洩すると、クラッカーはシステムに楽々ログインして、いろい
ろな設定ファイルを盗み見ることが可能になる場合もある。
APOPを利用することには二つの利点がある。一つはパスワードの暗号化(MD5符号
化)による盗聴からの保護。もう一つは、ログインパスワードとの分離である。
利用者の立場で単純化すれば、メイル取り込み時のパスワードのやりとりを盗聴
されても現実的に解読不可能で、仮に盗まれたとしても被害が自分のメイルにし
か及ばない(他人に迷惑を掛けない)ということである。パスワード漏洩の危険度
からいえば、素のPOP3とは雲泥の差である。ほとんどのMUAでは標準でAPOPに対
応しているが、Windowsで最もユーザが多いと思われる Outlook Express(ver??
まで)(以下の説明ではOE) とNetscape Messanger(以下NM) がAPOP非対応であり、
これらがネックになってAPOP のみに絞れないサーバ管理者もいることだろう。
しかしそんな管理者への福音となる機能がUNIXで有名な「Delegate」にあるので
紹介しよう。
まず、DelegateのWindows版実行ファイルを入手する。
ftp://ftp.etl.go.jp/pub/DeleGate/?????/
もしくは、今月号付録CD-ROMに執筆時当時の最新版があるのでこれをコピーしよ
う。ここでは Windows??? 環境の
"c:\Program Files\Delegate\dg7_0_1.exe" にインストール
したものと仮定して説明する。システムの基本サービスとして登録する。次の内
容のファイルを拡張子 .reg のファイルとして保存する。
[例:dgstart.reg]
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\run]
"Delegate"="\"C:\\Program Files\\Delegate\\dg7_0_1.exe\" -P110 SERVER=pop ADMIN=youremail@address.on.that.machine"
保存できたらそのファイルをダブルクリックするとサービスに登録され、リブー
ト後にDelegateによるPOP→APOP変換サービスが有効になる。
一方、OEやNMの方ではアカウント登録情報を書き換える。元のアカウント情報が、
[POPアカウント]
アカウント名: user
POP3サーバ名: pop.yourprovider.ne.jp
だったとすればこれを
[POPアカウント]
アカウント名: user@pop.yourprovider.ne.jp
POP3サーバ名: localhost
に書き換えるだけで良い。Delegateとレジストリファイルをまとめて利用者に渡
してあげることでもっと手軽に導入してもらうことができるだろう。これでAPOP
非対応のMUAを気にせず、生POP3を駆逐することができる。
----------------------------------------------------------------------------
3. POP before SMTP の設定
Part2, Part3いずれの場合も、メイルサーバのSMTPを利用して任意の送信
先アドレスにメッセージを送ることができるのは、メイルサーバと同一LAN
に属するクライアントだけになるように限定して設定した。サーバの利用
が必ずオフィス内で行なわれるのであればこれでも構わないが、出先や自
宅からダイヤルアップアクセスポイントなどを経由してサーバを利用する
場合は工夫が必要となる。
POPによるメイル取り込みを行なったクライアントマシンのユーザは、SMTP
サービスを利用する権利を持つ者である、との仮定にもとづきPOP認証に成
功したホストのIPアドレスをSMTPリレー許可リストに追加する仕組が POP
before SMTP である。同じことを目的としたものに、SMTP-AUTH というも
のがあり、これはそのものずばりSMTPによるリレーを要求する場合に、認
証を必要とするものである。ただしこちらは対応しているMUAを選ぶことと、
MTAに依存した設定が必要となるので今回は紹介を見送った。POP before
SMTP と相反するサービスではないので興味を持った読者は試してみてほし
い。
POP before SMTP を実現するためには、qmail, Postfix いずれの場合もリ
レー許可を制御するファイルを自動的に更新する仕組が必要となる。
WU-IMAPD拡張パックの場合、そのために ipop3d が認証成功後に呼び出す
コマンドが /usr/local/etc/pop3-record である。
[qmailの場合]
pop3-record は、/etc/host.allow.src をベースに、それにPOP認証成功し
たクライアントIPアドレスを追加して /etc/hosts.allow を生成するよう
になっている[図と]。
--[図と]-----------------------------------------------------------------
[POPクライアント] x.y.z.w
↓認証成功 /etc/hosts.allow.src
[POPサーバ] ↓
環境変数RELAYCLIENT=x.y.z.w → pop3-record
↓
/etc/hosts.allow
(tcp-env : x.y.z.w : setenv = RELAYCLIENT
が先頭に追加される)
--------------------------------------------------------------------------
生成元となる hosts.allow.src は現在の hosts.allow ファ
イルをコピーして作成する。
# cd /etc
# cp hosts.allow hosts.allow.src
以後、手動で編集するのは hosts.allow.src ファイルとし、編集結果
を hosts.allow に反映させるためには /usr/local/etc/pop3-update
コマンドを利用する。
続いて、ipop3dが起動するときに、クライアントのIPアドレスが環境変
数RELAYCLIENTに渡るようにする。hosts.allow.src に以下の行を追加する。
ipop3d: ALL : setenv RELAYCLIENT %h
そして書き換えを /etc/hosts.allow に反映させる。
# /usr/local/etc/pop3-update
これにより、以後POP3/APOP認証を通過したクライアントがSMTPリレー可能
になる。ただし、永遠にリレー可能にしてはまずいので、一定時間毎に
RELAYCLIENT情報を捨ててゆく。このためのスクリプトが pop3-age で、こ
れをcronで、たとえば10分置きに起動するように設定する。
# crontab -e
(以下の行を追加)
0,10,20,30,40,50 * * * * root /usr/local/etc/pop3-age
(システムによっては以下の記法でも良い)
*/10 * * * * root /usr/local/etc/pop3-age
[Postfixの場合]
PostfixではSMTP接続してきたクライアントに外部ドメインへのリレーを許
可するかの方法をいくつか設定できる。smtpd_client_restrictions パラ
メータでその方法を指定する。特定のクライアント(群)にリレー許可を出
す場合は check_client_access メソッドを利用する。まず、main.cf に以
下の記述を追加する。
smtpd_recipient_restrictions =
permit_mynetworks
check_relay_domains
check_client_access hash:/etc/postfix/client_access
permit_mynetworks と check_relay_domains は
smtpd_recipient_restrictions を明示的に定義しない場合にデフォルトで
有効になっているメソッドなのでこれらも同時に設定しないとそれまでと
は挙動が変わってしまうので注意する。check_client_access にはリレー
許可を与えるクライアントのデータベースの形式とファイル名を与える。
今回の場合は/etc/postfix/client_access にhash形式で保存するものとす
る。このファイルに自動的にクライアント情報を追加するためのスクリプ
トがWU-IMAPD 拡張パックに同梱された pop3-record.postfix である。デ
フォルトではPostfix システムのインストールディレクトリを
/usr/libexec/postfix と仮定しているのでこれを環境に合わせて変更する。
具体的にはスクリプトの先頭部分にある
POSTFIXBIN=/usr/libexec/postfix
の右辺を変更する。
そして、ipop3dが起動するときに、クライアントのIPアドレスが環境変
数RELAYCLIENTに渡るようにする。hosts.allow に以下の行を追加する。
ipop3d: ALL : setenv RELAYCLIENT %h
これにより ipop3d は認証通過したクライアントのIPアドレスを
pop3-record に通知し、pop3-recordはこのアドレスを
hash:/etc/postfix/clientaccess.db に登録する[図ち]。
--[図ち]-----------------------------------------------------------------
[POPクライアント] x.y.z.w
↓認証成功
[POPサーバ]
環境変数RELAYCLIENT=x.y.z.w
↓
+---- pop3-record(Postfix用) ----------+
| 1. /etc/postfix/client_access に |
| x.y.z.w OK |
| を追加 |
| 2. postmap を起動して |
| /etc/postfix/client_access.db |
| を生成 |
+--------------------------------------+
--------------------------------------------------------------------------
qmailでの場合と同様、一定時間毎にリレー許可情報を捨てるようにcronに
登録する。
# crontab -e
(以下の行を追加)
0,10,20,30,40,50 * * * * root /usr/local/etc/pop3-age
ここで起動する pop3-age は Postfix 用の pop3-record へのシンボリック
リンクであることを確認する。
・POP専用パスワードの管理
WU-IMAPD拡張パックではUNIXアカウントのパスワードとは独立したパスワー
ドを設定できる。これを設定するためのユーティリティが拡張パックに同梱
された APOPtools/apoppasswd スクリプトである。メイルサーバ上にシェル
アカウントのあるユーザの場合は、このスクリプトを直接利用してパスワー
ド設定を行なう。
user% apoppasswd
~~~~~~~~~~
Enter APOP passwd: **********
Again APOP passwd: **********
もし、シェルアカウントを与えていない場合、もしくは利用者にCUIでのコ
マンド操作が難しいような場合はCGIでのメイルパスワード変更のインタフェー
スが用意されている。これが APOPtools/apopcall.c である。本稿のテーマ
と外れる説明が多くなるので具体的な手順は省略するが、これを利用する場
合に管理者がなすべき作業は以下のようになる。
1. SSL対応apache(apache+mod_sslまたはssl-apache)のインストール
2. apopcall.c のコンパイル
3. apopcallのインストール(make install-cgi)
4. apopcallをインストールしたディレクトリのCGI有効化(in httpd.conf)
この設定が完了すると[図り]のような画面を利用してメイル専用パスワード
の変更が可能となる。
---[図り]--------------
(apopcall.png)
-----------------------
なお、このパスワード変更CGIでは virtualdomain メイルアカウントのパス
ワード変更も可能なので、是非活用してほしい。そのための設定に関しては
パッケージ付属の README.qmailapop ファイルおよびWU-IMAPD拡張パックの
Webページを参照して頂きたい。
yuuji@
Fingerprint16 = FF F9 FF CC E0 FE 5C F7 19 97 28 24 EC 5D 39 BA
HIROSE Yuuji -
ASTROLOGY /
BIKE
/
EPO /
GUEST BOOK
/
YaTeX