すり抜けスパムがDNSBLにどれだけ引っかかるか

　3月から4月にかけてスパムを着信させたホストがDNSBLに引っかかるかどうかを、RBL.JPのBlack list DB checkで調べてみた。このCGIによって、ホストがSPAMCOP、spamhaus、RBL.JPに登録されているかどうかを調べることができる（2008年3月20日「DNSBLって効くの？」を書いた時にはもっと多くのDNSBLについて調べることができたが）。
　送信元ホストと、それを登録しているDNSBLを表で示す。

a190.watel.vt.cust.gts.sk [85.248.46.190]	SPAMCOP
blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]	なし
gate49.cableone.ne.jp [61.7.42.49]	なし
smtp.pyramide.co.ma [196.206.253.90]	SPAMCOP
adsl.eb23-sjoaoponte.edu.pt [194.210.65.9]	SPAMCOP
brevnov.drino.net [213.151.83.161]	なし
adsl.ep-adrcisteralcobaca.edu.pt [194.210.105.124]	なし
mail.gpk.lt [82.135.204.112]	なし
cr-0.accnet.wireless.royell.org [208.91.182.67]	なし
techfirewall.lighthouse.net [69.216.168.41]	なし
unknown [211.12.212.178]	なし
mail.thaibinh.gov.vn [222.252.216.155]	SPAMCOP
o7.jdisonline.com [204.54.152.26]	なし
mail.sistema102.net [200.50.20.150]	なし
gprsinternet04.porta.net [200.25.197.97]	なし
mail-fx0-f179.google.com [209.85.220.179]	なし
pop.landrumshouse.com [209.194.32.242]	なし
ttx01.ttx-net.sk [193.110.187.2]	SPAMCOP
a2.sabnet.bj.cust.gts.sk [62.168.87.6]	SPAMCOP
cerstef.b.astral.ro [83.103.177.74]	SPAMCOP

　blu0-omc4-s29.blu0.hotmail.comとmail-fx0-f179.google.comはS25Rに引っかかるが、ここから着信したのは、hotmail.comとgoogle.comをホワイトリスト登録しているからである。正当なメールサーバを経由して送信されたスパムは、S25R方式ではいかんともしがたい。
　unknownのホストは、リトライの挙動からメールサーバと思われたものである。ホワイトリスト登録してみたら、着信したのはフィッシング詐欺のスパムだった。

　20個のホストのうち、SPAMCOPに登録されていたのが7個あった。ここから計算した阻止率は35%である。spamhausとRBL.JPには一つも登録されていなかった。このことから、S25Rをすり抜けるスパムをブロックするのにいくらかでも効果がありそうなDNSBLはSPAMCOPだけだと考えられる。
　また、2008年3月20日「DNSBLって効くの？」で述べたとおり、SPAMCOPだけが、S25Rで阻止されたスパム送信元ホスト10個のうち8個を登録していて、ほかのDNSBLは一つも登録していなかった。このことからも、役立ちそうなDNSBLはSPAMCOPだけだと思われる。ただし、その記事で述べたとおり、ウェブで見つけた証言によれば、そのSPAMCOPでも阻止率は50～60%程度しかないらしい。
　一方、SPAMCOPによる偽陽性判定のリスクも見て取れる。SPAMCOPに登録されていたsmtp.pyramide.co.maとmail.thaibinh.gov.vnは、名前からして明らかにボットではなくメールサーバである。第2レベルのラベルから見て、pyramide.co.maはモロッコの企業、thaibinh.gov.vnはベトナムの政府機関と推測される。これらのホストからスパムが送信されたのは確かでも、一時的にスパマーに悪用されただけかもしれない。同じホストから正当なメールも送信されるかもしれないのに、SPAMCOPは、ボットかメールサーバかを区別せずにブラックリストに登録している。ほかのDNSBLでも同じようなものだろう。DNSBLを信用して応答コード「5xx」で蹴るのがいかに危険かがわかる。
　とはいえ、蹴る時の応答コードを「4xx」にすれば、DNSBLを使っても、正当なメールをエラーリターンさせる事故を避けることができる。応答コードを変更するには、Postfixのmain.cfファイルで

maps_rbl_reject_code = 450

のように指定すればよい。この方法をとれば、SPAMCOPを利用してすり抜けスパムを減らすことができるかもしれない。
　次の記事で、SPAMCOPを利用する設定方法を説明する。