Postfixを導入しよう
以下のテキストは、執筆時当時の情報を元に書いたものであり、
現在の情勢にそぐわないことを含む場合があるので注意されたい。
また、テキストは最終提出原稿で校正を経る前のものなので、実際にUNIXUSER
本誌に記載されたものとは異なる。誤字脱字等そのままである。
致命的な誤り以外は加筆修正等は行なわないので情報の鮮度に気をつけつつ
利用して欲しい。
→目次
Part II Posifixを導入しよう
■Postfixの特長
Postfixはその第一の目標が、現在最大シェアを誇るsendmailプログラムの置き
換えとなることである。したがって、sendmailの実装に依存した多くの仕様も継
承される形となっている。たとえば、aliasファイルの置き場所や書式、ユーザ
毎のaliasファイルが ~/.forward という名前であることなども同様である。こ
れらsendmailがメッセージやアドレス定義ファイルの位置といったシステムに対
するインタフェースだけでなく、動作定義ファイルで設定可能な項目もsendmail
が持っていたものに対応する体系となっている。このため、設定可能な項目が非
常に多くなっているが、それまでsendmailを利用していた管理者にとっては項目
の連想が働きやすく、比較的楽に移行ができるという傾向がある。sendmailとの
互換性が高いといっても、主たる定義ファイルである main.cf は、難解な[註わ]
sendmail.cf の書式とは全く違い、変数に値を代入して行く形式の「人間でも読
み書きできる」独自のものとなっている。sendmail管理でたとえるなら、CF用の
定義ファイルを変換せずそのまま使えるような手軽さであるといえよう。
--[註わ]----------------------------------------------------
というより人間が書くことは実質的に不可能に近い。
------------------------------------------------------------
また、インタフェースはsendmailと互換としながらも、内部構造は図(あ)のよう
に機能ごとに細分化され、各モジュールが及ぼす影響範囲を小さくするようになっ
ている。一般的にプログラムは神ではなく人間が作るものであるから、そのプロ
グラムにバグをいれてしまう確率はプログラム自体の複雑さが増すにつれて大き
くなる。機能毎にモジュールを細分化することは、各プログラムの動作の影響範
囲を絞ることとともに各プログラムの複雑さを軽減し、プログラミング時の間違
いを減らすことにもつながっている。このことの実効性は、実際に sendmail の
RELEASE_NOTEの中にあるバグ修正の記述の数と、Postfixのそれを比較してみれ
ば分かるだろう。
図(あ)------------------------------------------------------------
http://www.muine.org/postfix/big-picture.html の図
------------------------------------------------------------------
■Postfixへの乗り換え
本稿は、多くの管理者に苦行と潜在的な危険を与え続けているsendmailから解放
され、一日も早く安寧の日々を得ることを目的とするため、現在運用している
sendmail環境からの移行というストーリーを基本として解説を進める。
●共有スプールの危険性
Postfixでは、メイルに関するファイルの置き場などはsendmailの仕様を踏襲
している。これにより、メイルスプールをアクセスする多くの周辺プログラム
がそのまま利用できるようになっている。この部分がもっとも管理者にとって
ありがたい部分であるが、セキュリティ向上という観点からどうしても考えな
おさなければならないことがある。メイルスプールのもつ潜在的危険性である。
sendmailではメッセージを受信者に配送する最終形態として、その人に来たメッ
セージ全てを単一ファイルに結合して格納する mbox 形式をとっている。また、
それらのファイルは (たとえば) /var/mail/ のように、全ての人が同
じディレクトリを共有する形で置かれている。一部のOSを除きこれらのスプー
ルディレクトリは実行例(あ)で示したように sticky bit が立っていて、ファ
イルの所有者(とroot)以外は勝手にファイルを消せないようになっている。
--実行例(あ)------------------------------------------------
funduro{yuuji}% ls -lFd /var/mail
drwxrwxrwt 2 root wheel 512 Jun 30 2000 /var/mail/
------------------------------------------------------------
しかし、どんなユーザでも書き込みができるディレクトリに mbox 形式ファイ
ルを置くことは、ほんの少しの悪戯心を持った一般ユーザの手で別のユーザへ
のメイルが簡単に届かなくすることを可能にする。これは「信頼できるメイル
システム」とは程遠い状態である(註[い])。また、Postfix ではスプールディ
レクトリを誰でも書き込める状態ではなくして運用することもできるのだが、
この場合 Venema 自身の主張である
No Postfix program is set-uid. Introducing the concept was the
biggest mistake made in UNIX history. Set-uid (and its weaker
cousin, set-gid) causes more trouble than it is worth.
という方針に反した運用となるので注意が必要である。もっとも、mboxファイ
ルを書くための setgid プログラムはroot権限をとるわけでもなく、仕事も単
純なので深刻な問題を招く可能性は低いのではないかとも言えるが、次に述べ
るmbox形式ファイルの弱点があるため、結局のところ /var/mail/ にメッ
セージを保存することは賢明でないといえる。
--註[い]----------------------------------------------------
http://www.postfix.org/security.html あるいは
http://cr.yp.to/maildisasters/postfix.19981221 を読むとその危険性が分
かるだろう。
------------------------------------------------------------
●mbox形式の脆さ
mbox 形式では、複数のメッセージを単一ファイルに格納している。各メッセー
ジどうしの境界は、ファイル中に現われる行頭から始まる "From " というパ
ターンによって認識される。つまり、一つのメッセージはある位置の 「行頭
"From "」から始まり、次に現われる「行頭 "From "」の前まで、またはファ
イル末尾までとなっている。メッセージの置き場所が単一ファイルである場合、
MTAなどによるmboxファイルへの追記操作と、popperやmboxファイルを直接見
るMUAなどによるメッセージの読み出し/削除操作が競合しないように、通常は
ファイルロックを行う。これが理想的に働けばあらゆるmboxファイルは安全に
メッセージの追加と取り出しが施されることになるのだが、現実はそうは行か
ない。第一に、ファイルロックは対象ファイルを利用する全てのプログラムで
必ず同一のロック機構を利用しなければ意味がないという点がある。残念なが
ら全てのプログラムが同一の機構を利用していることは保証できない。
仮に複数のプログラムでのmboxファイルロックが正常に機能したとしても、書
き込み途中にファイルシステムの容量オーバーや、システムクラッシュが起き
たとしたらまちがいなくmboxファイルの大部分、つまり多くのメッセージを失
うことになる。
また、ファイルロックはNFSでは有効に機能しないという面もある。最近では
POPなどの利用が一般的となったので、NFSでのmboxファイルの直接アクセスと
いう形態はあまりないだろうが、筆者がかつて利用していた環境ではmboxファ
イルに直接アクセスするMUAをメイルサーバ以外のホストでNFSを介して利用し
ていたため、メイルが届く瞬間などにあわてて取り込み作業を行ってはしばし
ばいくつかのメッセージを消失させてしまったものだった。NFSを利用するこ
との是非はともかく、仮にNFSを利用したとしても絶対にメッセージを消失す
ることがないメイルボックス形態があるとしたらそれを選択するのが正しい判
断といえよう。それが次に述べる Maildir 形式である。
●Maildir形式
Maildir形式は qmail の作者 D.J.Bernstein によって提案され、qmailで実装
されたメイルボックス形態である。Maildir形式では一つのメッセージは一つ
のファイルに保存される。メッセージ書き込みは複数のホスト複数のプロセス
で同時に同一ディレクトリにメッセージを保存しようとしても競合しないよう
な手順で行われるため、たとえNFS上にメイルボックスを配置しても安全にメッ
セージが保存される。
きわめて高い安全性を持つMaildir形式は、Postfixでもサポートされている。
最終配送形態としてMaildir形式を選択することでメイル配送システムの信頼
性が格段に高まるといえよう。
●Postfixの基本的導入
前置きが長くなったが、もし各ユーザのメイルボックスをsendmail時代と変え
ず共有スプールにmbox形式で置くことにこだわるのだったら、敢えてsendmail
以外のMTAに乗り換える意義の半分は消えるといっても過言ではない。最近で
はメッセージをPOPやIMAPを介して取得することが主流なので、Maildir形式に
対応したPOPデーモン/IMAPデーモンを入れておけば、クライアント側からはメ
イルサーバのシステムが変ったことは意識せずに利用できる。このような観点
から、本稿では最終的にメイルスプールをMaildir形式で運用することを目標
とする。Part4でMaildir形式に対応したPOP/IMAPサーバの導入について解説す
る。
Postfixのインストールは概ね以下の流れで行う。
* ソースのコンパイルとインストール
* 動作定義ファイルの設定
* sendmailの停止とPostfixの起動
以後順を追って解説しよう。
・ソースアーカイブの入手とコンパイル
本稿では、コンパイル作業は各種PC-UNIXを想定して解説を進める。ただし、
NetBSD と Vine Linux などではOS標準状態で既にPostfix がインストール
されているので確認してみてほしい。もし利用しているOSに既に装備されて
いるようなら以下で説明するインストール過程は省くことができるので適宜
読み飛ばしてほしい。
本稿執筆時の最新版は snapshot-20010201 である。これは、
ftp://ring.aist.go.jp/pub/net/mail/postfix/index.html から入手するか、
今月号付録CD-ROM中の snapshot-20010201.tar.gz をコピーして欲しい。
また、Perl互換の正規表現ライブラリを組み込んでおくと、フィルタリング
などで利用できるパターンファイルが非常に書きやすくなるので余裕があれ
ば利用したい。この機能を提供するPCRE(Perl-Compatible Regular
Expression) ライブラリは、
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-xxx.tar.gz
から最新版が入手できる。執筆時の最新版 pcre-3.4.tar.gz を付録CD-ROM
に収録したのでこれを利用してほしい。
コンパイルに先立ち、Postfixの動作に必要な UID と GID の設定を行う必
要がある。Postfix ではデーモン群の動作するUIDと、Maildrop ディレクト
リを保持するGID(こちらはなくても動く)を利用する。まずは前者のための
ユーザアカウントである`postfix' を作成する。繰り返しになるが、既に
`postfixユーザ' がpasswdファイルに登録されているOSもあるので確認して
から登録作業を行ってほしい。ここでは、グループとして `postfix',
`maildrop'、そしてユーザとして `postfix' を追加する。登録は NetBSD,
Linux, Solaris2 などの場合、以下のようにする。
# groupadd postfix
# groupadd maildrop
# useradd -s /etc/nologin -d /var/spool/postfix -g postfix \
-c 'Postfix pseudo-user' postfix
useraddコマンドで処理できない場合などは、直接グループファイル、パス
ワードファイルに追加する。
# vi /etc/group (以下を追加。GIDは他と重複しないもの)
maildrop:*:11:
postfix:*:12:
# vipw (以下を追加。UIDは他と重複しないもの
GIDはpostfixグループのもの)
postfix:*:12:12::0:0:Postfix pseudo-user:/var/spool/postfix:/sbin/nologin
UID/GIDの登録が済んだらいよいよコンパイル作業に入る。Postfixのソース
を展開し、さらにそこに PCRE ライブラリのソースを展開する。
# tar zxpf snapshot-20010201.tar.gz
# cd snapshot-20010201
# tar zxpf ../pcre-3.4.tar.gz
まずは、PCREライブラリのコンパイル。もし、Postfix以外にPCREライブラ
リを利用する予定がなければmakeするだけで(インストールしなくても)かま
わない。
# cd pcre-3.4
# ./configure && make
# cd ..
Postfix本体で、PCREライブラリを利用するように指定してmakeする。
# make -f Makefile.init makefiles \
CCARGS='-DHAS_PCRE -I../../pcre-3.4' \
AUXLIBS=../../pcre-3.4/.libs/libpcre.a
# make
これで正常にコンパイルが終了したらインストールを行う。ちなみに、PCRE
ライブラリのコンパイルがどうしてもうまく行かない場合、それは必須では
ないので省略してしまって構わない。PCRE無しでPostfixのコンパイルを行
う場合は、
# make -f Makefile.init makefiles
# make
だけで良い。続いてインストール。Postfix固有のファイルのインストール
だけでなく、OS標準のsendmail, mailq, newaliasesコマンドの置き換えも
ここで発生する。デフォルトでは各コマンドを直接置き換えるようにファイ
ルが配置されるが、のちのちOSのアップグレードを行うような場合、せっか
く入れたPostfixのsendmailラッパーがまたOS標準のsendmailによって書き
換えられてしまったりして、余分な手間が発生しやすいので、ここでは分か
りやすく Postfix の全てのコマンド群は /usr/local/postfix にインストー
ルすることを前提に解説を行う。実際のインストールは
# make install
と起動し、質問に答えていくことで進められる。make install で聞いて来
る質問のうち [ ] の中に表示されるものはデフォルト値で、リターンキー
のみを押すと [ ] 内の値が採用される。
* install_root: [/]
インストールする際にルートディレクトリとみなすディレクトリを指定す
る。Postfix自体を chroot 環境内で動かしたい場合はそのchroot環境の
ルートディレクトリを指定する。ここで / 以外のディレクトリを入力す
ると、以後の質問で入力するディレクトリは全て install_root をルート
とみなした相対パスとみなされることになる。ここでは通常のファイルシ
ステムで動かすのでルートディレクトリは / とする(リターンのみ)。
* tempdir: [/usr/home/yuuji/make/postfix/snapshot-20010201]
作業ディレクトリの指定。デフォルトのままで良いだろう。
* config_directory: [/etc/postfix]
動作定義ファイルを置くディレクトリを指定する。今回はデフォルトの
/etc/postfix とした。
* daemon_directory: [/usr/libexec/postfix] /usr/local/postfix
~~~~~~~~~~~~~~~~~~
Postfixのデーモンプログラムを置くディレクトリを指定する。今回のイ
ンストール先である /usr/local/postfix を指定する。
* command_directory: [/usr/sbin] /usr/local/postfix
~~~~~~~~~~~~~~~~~~
Postfixのコマンド群を置くディレクトリを指定する。今回は
/usr/local/postfix とした。
* queue_directory: [/var/spool/postfix]
メッセージのキューを管理するディレクトリを指定する。これはデフォル
トのまま利用した。
* sendmail_path: [/usr/sbin/sendmail] /usr/local/postfix/sendmail
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Postfix の sendmail ラッパープログラムの位置を指定する。デフォルト
ではシステム標準の sendmail プログラムと同じパス名が示されるが、後
の管理しやすさを考慮して /usr/local/postfix に置くこととする。ここ
に置いた sendmail ラッパーを常に機能させるための設定に関しては後述
する。
* newaliases_path: [/usr/bin/newaliases] /usr/local/postfix/newaliases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sendmail_path と同様、newaliasesの置き換えとなるコマンドの位置を指
定する。これも /usr/local/postfix 内とする。
* mailq_path: [/usr/bin/mailq] /usr/local/postfix/mailq
~~~~~~~~~~~~~~~~~~~~~~~~
mailqコマンドの置き換えの指定。上記と同様これも
/usr/local/postfix に。
* mail_owner: [postfix]
メッセージキューの所有者となるユーザアカウントの指定を行う。先ほど
作成したアカウントである postfix を指定する。この場合デフォルトの
ままで良い。
* setgid: [no] maildrop
デフォルトでは送信メッセージを一時的に落とすディレクトリを誰でも書
き込み可能にするのだが、これをやめて専用のGIDでしか書けないように
するときにはそのGIDを指定する。ここでは先ほど作成した maildrop グ
ループを指定する。
* manpages: [/usr/local/man]
マニュアルページのインストール場所を指定する。これはデフォルトのま
までよかろう。
これらの値の入力を終えると必要なファイルが指定した位置にインストール
される。
・動作定義ファイルの設定
どんなMTAの管理を行うにせよ、もっとも重要なのが、その動作を定義する
設定作業である。確かに Postfix の設定は sendmail に比べれば楽である
が、それでも基本的な設定ファイル main.cf には数多くの設定項目が(サン
プルのものも入れて)含まれている。この部分で手抜きをしては安全なメイ
ルサーバは構築できない。じっくり腰を落ち着けて慎重に作業してほしい。
とはいえ、これだけ項目の多いものを全て把握して設定するのでは労力も多
大で、移行作業の途中で挫折、もしくは時間切れになってしまうこともあり、
せっかくの決意が無駄になってしまう可能性も否定できない。そこで今回は、
「他人様に迷惑を掛けない程度に安全な設定」ということを目標に必要最低
限の項目にしぼって解説を行う。設定すべき項目の少なさに驚くかもしれな
いが、純粋に必要なのはそれだけであると再認識するだろう。また、最初は
最低限の設定しかせずとも、しばらく運用し管理のツボが分かって来れば自
ずとその他の設定方法も理解しやすくなることだろう。より詳しい設定項目
に関しては、本誌2000年10月号、11月号に解説があるのでそちらも参照する
と良いだろう。
さて、今回のインストール作業では Postfix のデフォルトのまま
/etc/postfix に動作定義ファイルを置くことにした。ここに移動して多く
のファイルがインストールされていることを確認しよう(実行例 あ)。
--実行例 あ : /etc/postfix にインストールされるファイル群 ---------------------
ballius{yuuji}% ls [/etc/postfix]
LICENSE regexp_table sample-rate.cf
access relocated sample-regexp.cf
aliases sample-aliases.cf sample-relocated.cf
canonical sample-auth.cf sample-resource.cf
install.cf* sample-canonical.cf sample-rewrite.cf
main.cf sample-debug.cf sample-smtp.cf
main.cf.default sample-filter.cf sample-smtpd.cf
master.cf sample-flush.cf sample-transport.cf
pcre_table sample-ldap.cf sample-virtual.cf
postfix-script* sample-lmtp.cf transport
postfix-script-diff sample-local.cf virtual
postfix-script-nosgid* sample-misc.cf
postfix-script-sgid* sample-pcre.cf
------------------------------------------------------------------------------
このうちもっとも基本的な設定を行うのが main.cf ファイルである。その
他のほとんどのファイルはサンプル的な意味合いで置かれているものなので、
空いた時間に読めば Postfix で設定できることの全体像が理解できよう。
これらのファイルを見ると分かるように、Postfix の定義ファイルの書式は
パラメータ = 値 [, 値2 [, 値3 … ]]
のようにパラメータに値を代入する形式となっている。値が複数あるときは
空白、またはカンマで区切って次の値を書く(カンマは省略可能)。値が長く
なるときは次の行に続きを書くこともでき、この場合は行頭からではなく、
空白文字を入れてインデントして書く。値を代入したパラメータは、別箇所
で $パラメータ (または ${パラメータ}) という書式によって参照できる。
MTAにおいて最低限設定しなければならないのは以下の項目である。
* サーバ自身の(送信時に付加する)メイルドメイン名
* サーバがローカル配送すべきメイルドメイン名
* SMTPリレーを許可するドメイン(またはIPアドレス)
まずは上記三点を定義しよう。ここでは例として
* サーバ名 = mail.foo.ymzk.org
* メイルドメイン = foo.ymzk.org
* 同一ネットワーク(LAN)のアドレス(リレー許可を出す) = 10.0.250.0/24
を想定して定義するものとする。これらの情報を定義するために main.cf
を編集する。
# cd /etc/postfix
# vi main.cf
サーバ自身のメイルドメイン名は myorigin パラメータで決定する。これは
サーバ上から直接メイルを送信する場合に自動的に補われるメイルドメイン
名となる。
myorigin = foo.ymzk.org
により設定される(註ろ)。
---[註ろ]---------------------------------------------------------------------
デフォルトでコメントアウトされている myorigin = $mydomain を有効にする
と、FQDNホスト名のうち最初のドットまでを取り去ったものが myorigin とな
る。
------------------------------------------------------------------------------
続いて、このメイルサーバでローカル配送すべきドメイン名を
mydestination に定義する(複数可)。myoriginで指定したものに加え、ホス
ト名やlocalhostといった特殊名も定義しておく。
mydestination = $myhostname, localhost.$mydomain, $mydomain
次にSMTP接続をしてきたクライアントのうち、$mydestination 以外のドメ
インへの送信を許可する(つまりリレー許可する)ホストを定義する。これは
mynetworks に定義する。
mynetworks = 10.0.250.0/24, 127.0.0.0/8
これまで管理に苦労して来た場合はあまりに簡単で驚くかもしれないが、他
人に迷惑を掛けないという意味での最低限の設定はこれだけで完了である。
実際に Postfix を起動して試験を行うための手順に移る。
・sendmailの停止
これまでsendmailを利用していたサーバの場合、Postfixを起動する前に
sendmailを停止する必要がある。まずは、現在稼動中のsendmailの停止から。
# kill `sendmailのpid'
によりsendmailを止めた後で、キューに残っているメッセージがないか確認
する。
# sendmail -q
# sendmail -bp
として、キューが捌けたことを確認したらシステムの起動スクリプトから
sendmail の起動部分を除去する。また、sendmailに依存した管理コマンド
を一通り置き換える必要がある。置き換える必要のあるコマンドは
* sendmail 直接送信モード
* mailq キューに溜っているメッセージの確認
* newaliases /etc/aliasesのdbm形式変換
である。もっとも単純なのは /usr/local/postfix/ 内の同名のコマンドへ
シンボリックリンクを張る方法である。
# cd /usr/sbin (Solarisの場合/usr/lib)
# mv sendmail sendmail.ORIG
# chmod 0 sendmail.ORIG
# ln -s /usr/local/postfix/sendmail
# cd /usr/bin
# mv mailq mailq.ORIG
# chmod 0 mailq.ORIG
# ln -s /usr/local/postfix/mailq
# mv newaliases newaliases.ORIG
# chmod 0 newaliases.ORIG
# ln -s /usr/local/postfix/newaliases
システムにmailwrapper(コラム参照)がインストールされている場合はその
定義ファイルである mailer.conf を修正することで全ての置き換えを統合
的に管理することもできる。
/etc/mailer.conf(OpenBSD, NetBSDの場合)、または
/etc/mail/mailer.conf(FreeBSDの場合) を次のように変更する。
sendmail /usr/local/postfix/sendmail
send-mail /usr/local/postfix/sendmail
mailq /usr/local/postfix/sendmail
newaliases /usr/local/postfix/sendmail
--[コラム mailwrapper]------------------------------------------------------
かつてはMTAといえばsendmailだけであり、それ以外のシステムは考えなくても
良かった。時代は移り変わり、多くの管理者がsendmail以外のMTAを選択して運
用できるようになった。しかし置き換えに関する事情は単純ではなかった。こ
れまで使われてきたMUAはsendmailのインタフェースを想定したものがほとんど
であるため、それらがこれまでどおりメイル送信が行えるように、新しいMTAは
sendmail互換インタフェースを用意した。管理者はそれらをつねに正しい場所
に配置するように気をつけなければならない。OSのバージョンアップなどでも
その配置が崩れないように注意し続けることはなかなかたいへんな作業である。
mailwrapperは、この置き換え作業の負担を軽減するために設計されたPerry
E. Metzger によるプログラムである。sendmailベースの各種コマンドを置き換
える代わりに mailer.conf ファイルに置き換えるべきプログラム名と、実際に
すり替えで起動するプログラムのパス名を既述しておけば良いようになってい
る。*BSD ではいずれでも利用できる。mailer.conf の格納ディレクトリはOSに
よって異なるので manpage を参照して確認してほしい。
----------------------------------------------------------------------------
Postfixのsendmailラッパープログラム自身も、プログラム起動名(argv[0])
によって動作を切り替えるように設計されているので mailer.conf には
sendmailラッパーだけを列挙すれば良い。
・Postfix の起動
Postfixの起動や停止、定義ファイルの読み直しなどは全て主プログラムで
ある postfix プログラムにより制御可能である。引数無しで postfix プロ
グラムを起動すると、指定できるコマンド一覧が表示される。
# postfix
postfix-script: fatal: usage: postfix start (or stop, reload, abort, flush, or check)
postfixプログラムの引数に与えるコマンドの意味は以下の通り。
* check Postfixシステムのインストール状態を検査する。オー
ナーの違うファイルやディレクトリがあれば警告表示
する。
* start Postfixメイルシステムを起動する。起動時には上記
のcheckと同様の検査が行われる。
* stop Postfixメイルシステムを停止する。Postfixの定義ファ
イルを変更した場合は stop/start を連続的に行うの
ではなく、後述の reload を用いるようにする。
* abort Postfixメイルシステムを強制終了させる。
* flush 直ちにキューに溜っているメッセージの再送を試みる。
* reload 動作定義ファイルの再読み込みを行う。
日常的な運用では、これらのコマンドを利用すれば十分だろう。さて、早速
Postfix を起動しよう。
# /usr/local/postfix/postfix start
起動したら、ローカルユーザにメッセージが届くかどうか確認する。ここで
は `testuser' というローカルユーザが存在するものとして例示する。
# tail -f /var/log/maillog & (配送ログの表示)
# echo 'This is test.' | Mail -s test testuser
これにより、/var/mail/testuser にメイルが届いていればインストール成
功である。もし、配送がうまく行かないときは、インストール手順を見直し
て慎重にやりなおそう。この実検例では、配送目的に Mail コマンドを利用
したが、これはsendmailプログラムを利用しているので、各種ラッパープロ
グラムへの置き換えに不備がある場合には配送が行なわれないのでこの点も
含めて作業を見直すと良い。
次に不正リレーを防ぐ設定になっているか確認しよう。SMTPサーバが Open
Relay になっているかの検査をおこなってくれるWebページがあるのでこれ
を利用すると良い。たとえば、
http://www.kyoto.wide.ad.jp/mta/relaycheck.html にアクセスすると特定
のSMTPサーバの検査をしてもらえるのでこれを利用するのも手である。ここ
では、telnet を利用して試験を行う方法を示そう。この場合外部のサイト
にアカウントをもっている必要がある。リレーを許可しないはずのネットワー
クに位置するマシンから、今回設定したメイルサーバに接続して以下のよう
に操作する。
リレー不許可ホスト(ext)% telnet mail.foo.ymzk.org smtp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trying to 10.0.250.25...
Connected to mail.foo.ymzk.org.
Escape character is '^]'
220 mail.foo.ymzk.org ESMTP Postfix
helo ext.example.com (外部のホスト名をheloで宣言する)
~~~~~~~~~~~~~~~~~~~~
250 mail.foo.ymzk.org
mail from:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
250 Ok
rcpt to:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
554 : Recipient address rejected: Relay access denied
最後に表示されたメッセージのように、"Relay access denied" という答が
返されれば Open Relay になっていないことが確認できる。もし denied で
はなく、
250 Ok
が返って来てしまったらそれは Open Relay になっていることを意味する。
早急に定義ファイル(main.cf)のなかの mydestination, mynetworks を確認
しよう。Postfixの場合パラメータ名を間違えていた場合も致命的なエラー
で停止したりはせずデーモンが起動してしまうので綴り間違えには気をつけ
たい。また、自分で定義したパラメータが有効になっているかを確認するた
めには、
# /usr/local/postfix/postconf | less
のように、postconf コマンドが利用できる。
・再起動後に有効にする
配送とリレー禁止の設定がうまく行っていることを確認したら、次回起動後
にもPostfixが稼動するように、システムのスタートアップファイル
(/etc/rc*など)から sendmail の起動部分をコメントアウトし、代わりに
"/usr/local/postfix/postfix start" を書き入れよう。
●より安全なPostfixの設定
ここまでの設定でとにかく「他人に迷惑を掛けない」程度のメイルサーバが構
築できた。この状態を表現すれば、「動いているプログラムがsendmailから
Postfixに変わっただけ」の状態である。せっかく乗り換えるのなら、もう一
頑張りして、自分のサイトの利用者の幸福度が向上するように設定しよう。
・Maildir形式の利用
ローカルユーザ個人に届いたメッセージのデフォルトの格納先は
/var/mail/USER となっている。このような共有スプールに置く mbox 形式
メイルボックスの危険性は先に述べた通りである。これをやめて、きわめて
安全度の高いMaildir形式を利用しよう。
Postfixはもちろん簡単にMaildir 形式への格納を指定できる。定義ファイ
ル main.cf に以下の項目を追加する。
home_mailbox = Maildir/
パラメータの右辺にはローカルユーザのホームディレクトリを基準にしたメ
イルボックスへのパス名を書く。Maildir 形式にするためには必ず最後をス
ラッシュ(/)にする必要があり、上の例の場合は各ユーザの ~/Maildir/ が
デフォルトの配送先Maildirとして利用される。
main.cfファイルを書き換えたら動作中のPostfixに知らせよう。
# /usr/local/postfix/postfix reload
つづいてローカルユーザへの配送が Maildir/ に行くか確認する。実験する
ユーザのホームディレクトリに .forward ファイルがないことを確認した上
で以下の操作を試みる。
# tail -f /var/log/maillog & (配送ログの表示)
# echo 'This is test.' | Mail -s test testuser
このとき maillog にあらわれるメッセージに maildir に配送した旨表示さ
れるはずである。
Feb 2 22:32:03 mail postfix/qmgr[13813]: E0542B1:
from=, size=329, nrcpt=1 (queue active)
Feb 2 22:32:04 mail postfix/local[14058]: E0542B1:
to=, relay=local, delay=1, status=sent (maildir)
このように表示されれば ~testuser/Maildir/new/ にメッセージが届いて
いる。ディレクトリを確認しよう。
# ls -lF ~testuser/Maildir/new/
-rw------- 1 testuser 391 Feb 2 23:40 981124816.14117_0.mail.foo.ymzk.org
このように、一つのメッセージが一つのファイルに保存される形式が
Maildir である。実験的にもう一通メイルを送ってみて、二つのメッセージ
が別々のファイルに格納されることを確認すると良いだろう。
ローカルユーザがメイルボックスを直接参照するMUAを利用する場合、つま
りUnixマシンにログインしてメイルを読むような場合、Maildirに対応した
MUAを利用する必要がある。現在日本のUnix利用者で広く利用されているMUA
のMewとWanderlustは[註は]どちらも Maildir 形式に対応しているので、ユー
ザにはこれらの利用を促進すると良いだろう。ただ、Unixマシンが主体の歴
史あるサイトでは、どうしても古くからのユーザがいて現在でもMailコマン
ドや、古い版のMHを利用してメイルを読んでいることがあり[註に]、移行作
業で一番悩む点かもしれない。そのような場合も、まずは現状に即したMUA
への移行をしっかりとした事情の説明とともにお願いしてみて、それでも難
しい場合はそのユーザだけ旧来の /var/mail/USER (mbox形式)に配送すると
いった対処も可能である。この場合、該当ユーザの ~/.forward ファイルに
mboxファイル名を書けば良い。
---[註は]---------------------------------------------------------------------
Mew: http://www.mew.org/
Wanderlust: http://www.gohome.org/wl/
---[註に]---------------------------------------------------------------------
そういうユーザは大抵とても高位な方でお願いしづらいことも多いのが世の常
である。
------------------------------------------------------------------------------
・簡単なUBEフィルタリング
メイルサーバの運用が安定期に入ると気になり始めるのがUBE(Unsolicited
Bulk E-mail; いわゆるSPAM)である。UBE拒否のための設定にはいくつかの
方針がある。代表的なものとしては
* MAPS RBLなどのデータベースを利用した Open Relay SMTP サーバの
接続拒否
* DNSレコードなどの情報をしっかり登録していない(身元不明の)サー
バの接続拒否
* 差出人やヘッダなどが特定のパターンに一致する場合の受信拒否
などがある。Postfixでも上記のもの全ての判断基準をもとにフィルタリン
グができる。結論からいうと、完ぺきなUBEフィルタリングはできない。な
ぜなら送って来たものがゴミメイルなのかどうかは、最終的には人間が読ま
なければ分からないからだ。もし、特定のパターンを拒否するようなフィル
タリングが広まれば、ずるがしこい送信者はそれをかいくぐるような形式で
送って来るだろう。要するにいたちごっこである。フィルタリングすること
にあまりに神経質になることは、逆に届くべきメイルを拒否してしまうこと
にもなりかねないし、なにより貴重な時間の浪費となる。意識すべき事は、
なるべく小さな管理コストで、なるべく多くの「典型的」なゴミメイルを弾
く、そのバランス点である。ここで、最近のUBE動向について考えてみたい。
UBEがネットワーク社会的問題として取り上げられ始めた頃には、典型的な
UBE送信手段として用いられたのが Open Relay 状態の SMTP サーバである。
悪意ある送信者は、どこから送信したのかを欺くために Open Relay のSMTP
サーバを探しては、それらを多段に利用したりして不特定多数の人間にUBE
を送りつけた。初期の頃はそのような設定不備のSMTPサーバがとても多く、
そうしたサーバから送られて来るUBEも多かった。
時代は進み、RBLなどのデータベースが普及し、sendmailのデフォルトが
Open Relay でなくなったあたりから、まずい設定のSMTPサーバも減って来
た(なくなってはいないが…)。すると悪意ある送信者は他所のサーバを悪用
するのではなく、自分でなんとかする必要がでてきた。その時期に出現した
方法の一つとしては、手許のPCにメイルサーバをセットアップし、できるだ
けマシン情報を特定されにくいダイヤルアップ回線につないで発信するとい
うものがあった。これはやがて問題視され、プロバイダによってはダイヤル
アップ回線から直接外部に投げるSMTPを禁止したり、あるいは受け側もダイ
ヤルアップと分かるホストからの接続を拒否するような設定を行うところも
現れた。しかしこの送信方法は予想以上には広まらなかったように思う。送
信者側にも負担がかかるからだろうか。
そして現在になって目立ち始めたのが「フリーメイルアドレス」の利用であ
る。あらかじめ誤解が生じないように断っておくが、無料で使えるメイルア
ドレスを供給してくれる企業は悪くない。感謝してしかるべきだ。悪いのは
それを悪用する人間で、たっぷりと無料アカウントを取得しては送信アドレ
スをとっかえひっかえUBEを送って来る。アドレスもSMTPサーバも正規のも
のだけに、これは固定的なフィルタリングでは拒否できない。ドメイン名で
拒否してしまうと、今度はそのフリーメイルサービスを利用している善意の
ユーザからのメイルが全て届かなくなってしまう。メッセージに含まれるパ
ターンでフィルタリングしてもいたちごっこだ。このような場合選べる手段
は二つである。一つは、無視すること。送信するほうも意味がないと分かれ
ば無駄な努力はやめるものだ。UBE全体の比率からすると、この種のものは
一部に過ぎないので、そこまで神経質になるのは損だともいえる。そしても
う一つは、(残念だが)送信元となっているフリーメイルアドレスドメインご
と受信拒否してしまうことである。無料アドレスを大量に取りやすいという
ことはそれだけ悪徳利用もしやすいということである。それでは「同じドメ
インの善意の利用者が困るのでは」と思うかもしれないが、もし本当に電子
メイルを利用したコミュニケーションを重要だと考えるのなら、自分のアイ
デンティティに結びつくシンボルの一つである電子メイルのアカウントには
相応の料金を払っても良いのではないだろうか。もはや携帯電話でもメイル
アドレスが持てる時代、大事なメッセージは大事なアドレスから送る心構え
が広まってほしい。
さて、前置きが長くなったが、UBEフィルタリングでもっとも重要なのは拒
否する/無視する方針である。自分の管理するサイトでどの程度行うかを良
く考えてから設定したい。現在、顕著に見られるUBEのうち、拒否する手が
かりとして考えられるものにはたとえば以下のものがある。
1. 接続クライアントホストのアドレス(Open Relay ホストなどか)
2. でたらめな差出人アドレス
3. でたらめではないが何度もUBEを送って来る特定の差出人アドレス
4. メッセージ中に含まれるUBE特定のありがちなパターン
このうち1〜3については、まずまちがいなくUBEと判定して良いケースであ
る。1と2は善意の送信者が送ったものに該当する可能性もあるがそれは、
1 → サーバの設定不備なので相手管理者に直してもらう
2 → MUAの送信者アドレスの設定間違いなので直してもらう
のが筋だろう。3に関しては、偽りの差出人アドレスに注意する必要がある。
悪意ある送信者が、無関係な実在する(しそうな)アドレスを詐称して差出人
を設定するケースもある[註ほ] ので、送られて来たUBEがもつ差出人アドレ
スが本当にその発信源と関係するものなのかどうかを確認してからブラック
リストに追加するように注意したい。
---[註ほ]---------------------------------------------------------------------
実在するアドレス、またはドメインを詐称するUBEは、その名を語られたほうも
被害者である。そうと知らずFromアドレスに含まれるアドレスを鵜のみにして
そこに苦情をいってくる受信者も多い。詐称を止めることは現時点では不可能
である。それは、自分の知らないところで知らない人が自分の名を語って
「俺は○×だが財布忘れたからツケにしといて」と飲み屋で発言するのを禁止
するのと同じくらい解決策がない。こういったケースでは、飲み屋の主(メイル
でいえば受信サイトの管理者)が本当にその名前があっているのか、分かる範囲
で確認するよう気をつけてもらうしかない。
------------------------------------------------------------------------------
4に関しては、本来受信すべきものを拒否してしまう可能性が一番高いので
とくに慎重に(控えめに)設定したい。それぞれのフィルタリングをPostfix
で行うための設定は以下の通りである。
1. 接続要求クライアントによる受信拒否
smtpd_client_restrictions パラメータで指定する。特定のホストからのメ
イルを拒否できるのに加え、Postfixでは、デフォルトで MAPS RBL を参照
した受信拒否ができる。次のパラメータ指定を例に取ろう。
smtpd_client_restrictions = hash:/etc/postfix/badclient,
reject_maps_rbl
hash:/etc/postfix/badclient はクライアントホストのパターンと、
それにマッチしたときのアクションを定義するhash形式のファイルを利用す
ることを意味する。具体的には /etc/postfix/badclient ファイルに、
パターン アクション
という行の羅列を書く。たとえば、
evil.example.com REJECT
kusemono.example.net REJECT
192.168.99.99 REJECT
tomodachi.example.org OK
のように書けば左項にマッチしたクライアントからの送信を拒否(REJECT)、
または許可(OK)することができる。なお、badclient ファイルを編集したら
# /usr/local/postfix/postmap hash:/etc/postfix/badclient
によってhash形式ファイルに反映させる必要がある。この書式のよりくわし
い説明はPostfix付属のマニュアル access(5) を参照してほしい。
reject_maps_rbl という指定は、公開されているブラックホールリストの利
用を宣言する。データベースサーバの指定は別のパラメータ
maps_rbl_domains で行う。たとえば、
maps_rbl_domains = rbl.maps.vix.com
と書けばデータベースとして rbl.maps.vix.com を利用し、これに登録され
ているホストからの受信を拒否することになる。
2,3. 差出人アドレスによる拒否
smtpd_sender_restrictions パラメータで指定する。たとえば、
smtpd_sender_restrictions = reject_unknown_sender_domain,
hash:/etc/postfix/access
という指定では、reject_unknown_sender_domainによって存在しないドメイ
ンが差出人アドレス書かれているものを拒否する。また、
hash:/etc/postfix/access で拒否したい具体的なアドレスを指定でき
る。/etc/postfix/access ファイルは先述の badclient ファイルと同じ書
式でパターン&アクションを書く。やはりこのファイルも修正後は
# /usr/local/postfix/postmap hash:/etc/postfix/access
を行う必要がある。なお、smtpd_sender_restrictions で指定できる拒否法
式は多数あり、/etc/postfix/sample-smtpd.cf 内に説明があるので参照し
てほしい。
4. メッセージに含まれるパターンによる拒否
メッセージのヘッダのパターンによって受信拒否を行う場合は
header_checks パラメータで指定する。これも上記の拒否アドレス指定のよ
うに hash:ファイル名 という指定もできるが、照合したいパターンが複雑
になるので正規表現マップを指定すると良いだろう。
header_checks = regexp:/etc/postfix/header_check
とすると /etc/postfix/header_check ファイルを正規表現マップとして参
照するようになる。正規表現マップは
正規表現 アクション
という行の羅列で記述する。左項に正規表現を利用する点を除いてhashマッ
プと同じだと考えて良い。たとえば、Subjectヘッダに "money" というパター
ンが含まれるものを拒否したい場合には、
/^Subject: .*money.*/ REJECT
とすれば良い。しかし、これだと moneyless という単語でもREJECTしてし
まう。単語境界などを指定したい場合はPCREライブラリを利用するほうが便
利である。PCRE込みでのインストールに成功している場合は、
header_checks = pcre:/etc/postfix/header_check
と書けば正規表現をPerlと同様に指定できる。"money" という「単語」を含
むものだけを拒否したいときは
/^Subject: .*\.*/ REJECT
とすれば良いことになる。Perlの正規表現は強力で、これを利用すると簡単
に拒否パターンを指定できる。効果が分かりやすいので管理している充実感
が得られやすく、ついあれこれパターンを書いてしまいがちだがその裏では
善意のメッセージを拒否する可能性も上げていることに注意する必要がある。
メッセージのパターンによるフィルタリングには誤判定がつき物だというこ
とを強く心に留めてほどほどにしたいものである。
・設定の反映
以上で説明した設定を反映させるために postfix reload することを忘れな
いように注意してほしい。
●クライアントホストの設定
これまで説明した設定は、メイルサーバとなるホストのものである。クライア
ントホストの設定もそのほとんどが共通である。違う点は
* ローカルアドレスの指定
* リレーサーバの指定
である。クライアントでは、そのメイルドメイン宛のメッセージを受け取って
はならないので main.cf 内、mydestination パラメータを変更する。デフォ
ルト値である
mydestination = $myhostname, localhost.$mydomain
だけにしておく。また、クライアントマシンのローカルユーザから受け取った
外部宛のメッセージ配送をメイルサーバホストに託す場合は relayhost パラ
メータに指定する。今回の例の場合
relayhost = mail.foo.ymzk.org
とすればよい。このパラメータに関しては、ポリシーにより設定する必要のな
いサイトもあるだろう。
●まとめ
少々長くなったが、今一度ざっと読み返して説明文中の具体的な設定項目が少
ないことを確認してみてほしい。今までsendmailの管理をまめに行なっていた
管理者は、作業の負担がかなり減ることが実感できたのではなかろうか。
Postfix は Vine Linux で標準MTAに採用されたことなどもあり、今後さらに
メジャーになり、情報も得やすくなっていくものと思われる。しかし安易に
sendmailからの移行をはかる前に考えてほしい。Postfix を紹介する文言とし
て「sendmailとの互換性が高いのが特長」などのものがあるが、はたしてそう
だろうか。確かに、管理者から見れば移行の手間が削減できるといメリットは
ある。しかし、互換性が高いということは、sendmailのもつ「まずい仕様」を
も継承しているということでもある。そういう観点では、sendmailとの互換性
の高さは「特長」ではなく「特徴」に過ぎない。本当に安全で快適なメイルサー
バを構築するためには、Postfixの与えてくれているおおらかな互換性に甘え
ず、切り捨てられる部分は捨てる努力を惜しまないでほしい。
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