Postfixのsample-smtpd.cfファイルに次のような記述を見つけた。
# The maps_rbl_reject_code parameter specifies the SMTP server response
# when an SMTP client request is blocked by a reject_rbl or reject_rhsbl
# restriction.
#
# Do not change this unless you have a complete understanding of RFC 821.
#
maps_rbl_reject_code = 550
デフォルトの応答コードは「550」だと読み取れるが、実際のデフォルト値をpostconfコマンドで調べてみたら…
$ postconf | grep maps_rbl_reject_code
maps_rbl_reject_code = 554
前回の記事「「5xx」で蹴るなんて」で、DNSBLを全面的に信頼して「5xx」で蹴ることが信じられないと書いたが、なんとその元凶はPostfixのデフォルト値だった。
PostfixでDNSBLを利用している人は、ぜひmain.cfファイルに
maps_rbl_reject_code = 450
を追記してほしい。sample-smtpd.cfファイルには「RFC 821を完全に理解していない限り変えるな」と書いてあるが、びびることはない。
もちろん、まめにログを監視して、正当なメールサーバからのリトライアクセスを発見したらホワイトリスト登録するように運用すべきである。リトライアクセスを発見しやすくするためには、私の拒絶ログソーティングスクリプトが使える。あるいは、グレイリスティングに回してもよいが、どうやればよいのかは知らない。
下記のような設定で、S25Rに掛かったものだけをDNSBLに回すように出来ます。
返信削除S25Rに掛からないものは、普通のメールサーバである可能性が高く、もしDNSBLに引っかかっていてスパムメールが出されているにしても、同じメールサーバから正しいメールが届く可能性も高いため、このような設定にしたほうが良いと考えています。
こうするといろんな制限を掛けるときにもS25Rパターンを一度だけ書けばよいので、同じような方法で、Rgrey/taRgreyの設定をするようにしてます。
ちなみにtaRgreyのページを作成しまして、こちらでの説明もこの方法にしてます。
http://k2net.hakuba.jp/targrey/
[main.cf]
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
...
check_client_access regexp:$config_directory/permit_client_nots25r
...
reject_rbl_client dnsb.example.org
[permit_client_nots25r]
/\.dip\.t-dialin\.net$/ WARN
/\.dyn\.optonline\.net$/ WARN
...(other dynamic IP FQDN pattern(not match S25R pattern))
!/(^unknown$)|(^[^\.]*[0-9][^0-9\.]+[0-9])|(^[^\.]*[0-9]{5})|(^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z])|(^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9])|(^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\.)|(^(dhcp|dialup|ppp|adsl)[^\.]*[0-9])/ OK
/./ WARN
stealthinuさん：
返信削除どうもありがとうございます。
S25Rに引っかからないホストをDNSBLでの検査から除外するというのはもちろん良い方法だと思いますが、S25Rに引っかかって、かつDNSBLにも引っかかったからといって、「5xx」で蹴るのはなおも危険だと思うんですよね。
で、DNSBLに基づいて蹴るホストにはリトライの猶予を与えて慎重に扱ってほしいというのがこの記事の趣旨だったんですが、DNSBLに引っかかったホストをグレイリスティングに回すための方法はご存じですか？
はい、主旨とちょっと違うなと思いつつ書いてました (^^;
返信削除で、DNSBLに引っかかったものだけをgreylistingとかに回す、というのは
Debian -- whitelister
http://packages.debian.org/testing/mail/whitelister
というポリシーサーバ使うことで可能です。
先のコメントで書いた、S25Rにマッチしなかったら一般化されたホワイトリストにマッチしたと考えてOKにするのと同じく、DNSBLにマッチしなかったらOKとする、というものです。
S25Rを抜けれず、かつDNSBLも抜けれず、かつgreylistingも抜けれない、とかまでやれば、だいぶ安全そうですよね。
taRgreyの方向性よりもこっちのほうがより効果的にfalse positiveが減らせるかもしれません。
false negativeが増えそうなのをどうするか、という感じですね。
ありがとうございます。記事で紹介させていただきます。
返信削除そうですねえ。false positiveをほぼ根絶できればそれに越したことはないですが、false negativeが増えてくるとこれまた困りものですね。スパムの総数が増えていますから、false negativeが少し増えるだけで、すり抜けるスパムが大幅に増えることになりかねません。うまくやる必要がありますね。