Starpitよりもさらに誤検出の少ないスパム検出方法についてのアイデアです。(まだ実装はありません)
簡単に言うと、
S25R + tarpitting + greylisting
というもので、つまりStarpitで排除されるメールをさらにgreylistingで救済するという手法です。
S25Rに引っかかる条件で、かつ遅延を抜けられず、かつ再送もしてこなかったらスパムとして排除されます。
tarpitting では相手が切断してしまうので、その後再送してくるかを検出できれば上記の構成にすることが出来ます。
切断されたのか、それとも通ったのかを確認するには、ほんとうならMTA側になんらかの実装、つまりパッチが必要になりそうですが、Postfixでは smtpd_recipient_restrictions でDBに登録して遅延を掛け、smtpd_data_restrictions でDBと照らし合わせて、抜けてこれてないものは遅延の間に先方が切った、つまりtarpittingに引っかかったもの、と考えることが出来ると思います。
ただ、単にgreylistingを掛けると、postfixやqmailなど普通のMTAをスパム送信に使っている場合、greylistingで救済されて全部抜けてきてしまいます。
むろん、誤検出を減らす目的だけの場合はそれでも良いのですが、なるべくならあまり検出率も下げずに救済策を取りたいと考えました。
tarpittingやgreylistingで誤検出を検知することを考えるとき、スパマーは頻繁にIPを変えながらスパムを送信してくるので、長期に同一IPからスパムを送ってくることがほとんどありえないため、同一のIPから長期にわたってメールが出されているが受け取れていない場合、誤検出の可能性が高い、と考えられます。
そこで、greylistingで再送してきても、最初に受け取った時から2日くらい経ってからも、同IPで再送してきているか、を確認してはどうか、と考えました。
これだと、greylistingのパラメータの設定のみでこのような動きをすることが出来ます。
正しいメールサーバを2日とか待たせてしまう可能性がありますが、Starpitで誤検出されるメールサーバはほんとうにごくまれで、そういうレアケースを救済するための処置です。
またgreylistingのように、ホワイトリストやブラックリストをDB化して持つことで、S25Rに引っかかる場合、正しいメールサーバなのに常に遅延を掛けられてしまう問題や、すでにスパマーとわかっているIPからの接続も毎回遅延させることで起動smtpdが増加する問題も、回避することが出来ます。
PostgreyかPolicy Daemonをベースに修正して、これらの機能を持ったポリシーサービスデーモンを作る予定です。
その前に、ログからスパマーがどれだけの期間、同一IPでメールを出してるのか、統計出す必要がありそうです。
(追記)
postgreyをベースにこのポリシーサーバを書きました。
taRgrey - S25R + tarpitting + greylisting
モーグルとカバとパウダーの日記 - taRgrey - S25R + tarpitting + greylisting
また、同一IPからスパムが出される期間については、下記エントリーを参照下さい。
モーグルとカバとパウダーの日記 - 同一IPからスパムが出されている期間
モーグルとカバとパウダーの日記 - 一見さんは1日以上同一IPを使ってるか確認するスパム対策手法
