土曜日, 11月 16, 2013

SpamCopによる偽陽性判定が発生

 2009年4月29日の「SpamCopを設定してみた」で説明した方法で、S25RにSpamCopを併用するようにして以来、最近までSpamCopによる偽陽性判定を経験したことはなかった。ところが先日、ついに偽陽性判定が起こった。
 11月10日、兄からのメール(メールドメインはcatv296.ne.jp)を送信するメールサーバmail05.SiriusCloud.jpがSpamCopによる偽陽性判定でブロックされていた。誰かがこのメールサーバを利用してスパムを撒いたのだろう。maps_rbl_reject_codeを450に設定していたので、再送が続いているうちにローカルのホワイトリストに登録して受信できた。
 ブラックリスト入りしたのはこの一つのメールサーバだけではなく、周辺のIPアドレスも同時に登録されていた。11月11日にはmail02.SiriusCloud.jpもブロックされた。ホワイトリストを範囲指定に直して受信した。
 経験上、SpamCopは、DNSBLとしてはそこそこ信頼できる。しかし、正当なメールサーバの利用者がスパムを撒いて、それがSpamCopに通報されることもある。そうなると、maps_rbl_reject_codeをデフォルトの554のままにしていた場合、正当なメールが即座にエラーリターンして、善良な送信者と受信者が迷惑を被ってしまう。やはり、maps_rbl_reject_codeを450に変更して再送要求を返し、再送を監視することは必須である。

 ところで、SpamCopのブラックリスト登録は、ある程度の時間で自動的に解除される。そのため、まともなメールサーバを使って撒かれたスパムは、しばらくSpamCopによってブロックされても、再送期間(Postfixやsendmailのデフォルト設定で5日)が終わらないうちにブラックリスト登録が解除されると、受信されてしまう。実際、それでスパムが受信されてしまったことがあった。
 11月14日15:17に始まったaircel-mx1.aircelservices.inからのアクセスがSpamCopでブロックされ、その後再送が続いていた。送信者アドレスが怪しげで、スパムに違いないと判断したので、smtpd_sender_restrictionsパラメータのcheck_sender_access指定で指定したファイルに送信者アドレスを登録することにより、ブラックリスト登録が解除された時に送信者アドレス条件で蹴るようにした。11月16日03:39に拒絶に成功した。
 smtpd_client_restrictionsの条件がsmtpd_sender_restrictionsの条件よりも先に評価されるので、送信者アドレス条件を設定しても、SpamCopに引っかかっている間は再送要求を返し続ける。ログが膨らんでうざったい。しかし、運用手順が単純であることと、同じメールサーバからの他の正当なメールのエラーリターンを避けられることから、この方法が良いと思う。