ubuntu 10.04 をメールサーバーに (グレイリスティング – Postgrey)

先日の記事で、Postfix にグレイリスティングの組み込んで spam 対策を行なうことを決めた。
とりあえず milter-greylist パッケージを使って、これを実現しようとしたが、うまく行かなかったことも報告した。

そこでグレイリスティングを実現するために、以前から使っていて実績がある postgrey を採用することにする。

先日の記事でインストールした milter-greylist は、sudo aptitude purge milter-greylist コマンドを使って、完全に削除してある。
また、/etc/postfix/main.cf ファイルについても、先日の記事で編集した箇所は、以前の通りに戻してある。
つまり先日の記事の直前の状態 (ウィルスチェックを組み込んだ 8 月 12 日の記事の状態) になっているはずだ。
この状態を元に、postgrey をインストール、設定していこう。

まずは ubuntu の標準リポジトリから postgrey をインストールするために sudo aptitude update; sudo aptitude install postgrey コマンドを実行する。
続いて postgrey の設定をするのだが、やることは何もない。
強いて言えば、明らかに信頼できる送信元のサーバーや、送信元のメールアドレスなどを postgrey の動作対象外にするための登録 (ホワイトリストの登録) があるくらいだろう。

いくつかの送信元が、グレイリスティングの動作が原因で、受信できないことが分かっており、それらをホワイトリストに登録しておく必要がある。
これについては、記事の最後に書く。

postgrey の設定は何もないので、素直に Postfix の設定を行う。
Postfix の設定も非常に簡単で、/etc/postfix/main.cf ファイルの smtpd_recipient_restrictions エントリに 'check_policy_service inet:[127.0.0.1]:10023' を追加するだけのことだ。
実際にこれを追加した箇所を以下に揚げる。

Postfix で SMTP 認証」の記事でも書いたように、smtp_recipient_restrictions エントリのパラメーターは、記述した順に評価される。
このため smtp_recipient_restrictions エントリの最後に追加した postgrey によるグレイリスティングは、mynetwork エントリに記されたネットワークや SMTP 認証で承認された接続で送られてきたメールには適用されない。
また、それ以外の接続、つまり第三者のメールサーバーから送られてきたメールの内、mydestination エントリに記されたドメインおよび PostfixAdmin で登録されているドメイン、メールアドレス宛てでないものは、reject_unauth_destination パラメーターによって拒否される。
つまり、第三者のメールサーバーから送られてきた、mydestination エントリに記されたドメインおよび PostfixAdmin で登録されているドメイン、メールアドレス宛てのメールだけが、グレイリスティングの対象になる。

最後に Postfix に修正した設定を読み込ませるために sudo service postfix restart コマンドを実行する。
Postgrey はインストールと同時に自動的に起動しているし、設定の修正もしていないので、Postgrey の起動や再読込の必要は無い。

以上で Postgrey を使ったグレイリスティングが Postfix に組み込まれた。

ところで、実はある特定のドメインから送られてくるメールに限っては、グレイリスティングと非常に相性が悪い。
先日の「グレイリスティング – milter-greylist で失敗」の記事でも書いたが、送信先のメールサーバーが一時エラーのときは一定時間後にメールを送り直すというのが、通常のメールサーバーの動作だ。
一時エラーで送信できなかったメールを送り直すまでの時間は、ほとんどのメールサーバーが 10 分以上の間隔を空けている (Postfix をメールサーバーにした場合は、明示的に指定していなければ最低でも 1000 秒≒約 17 分の間隔を空けて送り直す。)
グレイリスティングでは、一時エラーの後に余りにも短時間でメールを送り直してくるようなサーバーは、spam を送信しているのだと判断して、以後の受信を拒否するようになっている。 Postgrey の場合、明示的に指定していなければ 300 秒≒ 5 分以下の間隔で送り直してきたときに、spam を送信しようとしていると判定する。

上で挙げた特定のドメインのメールを送信してくるサーバーは、一時エラーの後の送り直しが、なんと 1 分の間隔しか空けていない。
まるで spam 送信サーバーかと見まがうばかりの間隔だ。
そうは言っても、送り直しの間隔がどこかに規定されているわけでもないので、当該サーバーの管理者に文句を言うのも筋違いだろう。
Postgrey が想定している 5 分以上の間隔というのも、単に、そのような動作をするメールサーバーが多いという、希望的観測を前提にしているだけに過ぎない。

このように想定外に短い間隔でメールを送り直してくる場合は、そのメールを送ってくるメールサーバーか送信元のメールアドレスを、グレイリスティングの対象から外すように指定しておく。
このようなグレイリスティングの対象から外すための登録を、ホワイトリストに登録すると言う。
ホワイトリストには上記のように、送り直しが 5 分 (Postgrey の指定した短すぎると判定する時間間隔) よりも短い間隔で行われるサーバーだけでなく、きちんとした管理がされているため spam を送ってこないと確証が持てるサーバーを登録しておくと良い。
実際には Postgrey のインストールと同時にある程度のサーバーが、既にホワイトリストに登録されている。

上で挙げた特定のドメインは、Postgrey のインストール時からのホワイトリストには登録されていないので、自分で登録しなくてはならない。
インストール時に登録されているホワイトリストは、/etc/postgrey/whitelist_clients ファイルと /etc/postgrey/whitelist_recipients ファイルだが、これらのファイルを編集するのは進められない。
追加して登録するときは、サーバーは /etc/posgtrey/whitelist_clients.local ファイルに、メールアドレスは /etc/postgrey/whitelist_recipients.local ファイルに行う。

例えば上で挙げようなメールを送ってくるサーバーが、example.com ドメインに属するサーバーだと仮定する (大手企業などでは負荷分散のために mail1.example.com、mail2.example.com、... のように、メールを送ってくる可能性のあるサーバーが複数あることも多い。)
この場合、メールサーバーの共通部分にあたる example.com を、以下のように /etc/postgrey/whitelist_clients.local ファイルに追加する。

/etc/postgrey/whitelist_clients.local ファイルや /etc/postgrey/whitelists_recipients.local ファイルを編集したら、 sudo service postgrey restart コマンドを実行して、Postgrey に編集したホワイトリストを読み込ませておく。

「ubuntu 10.04 をメールサーバーに (グレイリスティング – Postgrey)」への2件のフィードバック

  1. 再送間隔はRFCで決められています。(RFC5321)

    http://www.hde.co.jp/rfc/rfc5321.php?page=66
    一般的に、リトライ間隔は少なくとも 30 分はとるべきです(SHOULD)

    一応MUSTではなくSHOULDなので、1分後のリトライでも「RFCに違反してる」とまでは言えませんけども、文句を言うのが筋違いということはないと思います。
    なので、postgreyの5分は別に希望的観測というわけではなくて、RFC的には30分以上だけど、現状を見て十分良心的な設定にされていると思います。

    milter-greylistの件ですが、僕もmilter-greylist使ってないのであれですが、もしかしたらmilter-managerを利用してmilter-greylist使うとうまくいくかも?です。
    確かmilterの問題でうまく動かない部分もmilter-managerが吸収してくれるらしいので。

  2. stealthinu さん、コメントありがとうございます

    再送間隔はRFCで決められています。(RFC5321)

    やはりそうですよね
    気になって一通り探しては見たのですが、見つけられなかったのでこの情報に大変感謝します
    再送間隔が極端に短い某ドメインは、製品登録のための登録確認メールで利用しただけで、その後 メールが送られてくる可能性は低いので、まぁいいかなと whitelist に登録だけして後は放置です (そのサイトのログインパスワードを忘れるとお世話になる可能性が大)

    milter-managerを利用してmilter-greylist使うとうまくいくかも?

    milter-greylist のエラーについても、仰せの通りに milter-manager を使うとそちらで吸収してもらえそうな気がします
    milter の設定練習のつもりで、今は milter-manager を使わないようにしていますが、一通り試したら改めて milter-manager で設定し直す予定です (あくまでも予定)
    設定し直しまでに期間が空きすぎて、そのときには、milter-greylist の方だけで何とかできていたりする可能性もありますが...

コメントを残す