サーバ上で画像スパムに対抗するため、FuzzyOCRとか、今後出てくるであろうHTMLをレンダリングする機能をもったフィルタとか、どのくらいの流量までは利用できるのか考えてみました。
先日のエントリーで、FuzzyOCRは重くて流量の多いメールサーバでは使えない、と書いたんですが、それでもやっぱり使いたい場合はあるので、改善策を考えます。
現在、メール総数のうち8割〜9割がスパムだと言われています。とりあえず8割だとします。
うち、画像付きHTMLメールの率は、スパムで25%、正しいメールで5%くらいとします。
画像フィルタの処理速度が1s/通だとします。
これら全てのメールをフィルタする場合、全メールに対しスパムで20%、正しいメールで1%の計21%のメールをチェックする必要があるため、1時間に届くメール数が17,000通以下であれば間に合うはずです。
スパムのうち、95%程度はSMTPセッション時の情報だけで、ほぼ誤検出無く排除することが出来ます。
すると、80%×95%＝4%のスパムと、20%の正しいメールと、計24%分のメールに対してフィルタを掛けることになります。
すると、スパムで1%、正しいメールで1%となります。
全メール数の2%がフィルタすべきメールになるため、1時間に届くメール数が180,000通以下であれば間に合うので、なにも1次フィルタが無い場合に対して約10倍のパフォーマンスが出ることになります。
それでも間に合わない場合、S25Rにマッチする動的IPっぽい接続からの場合のみOCRを掛けるようにすれば、さらに倍まで耐えることが出来ます。
ユーザごとに選択的にフィルタを掛けるようにする場合でも、.forwardでコンテンツフィルタを通すだけじゃなく、SMTPセッション時の情報でもフィルタを掛けるように仕組みを準備してやれば、負荷増を最小限にすることが出来ると思います。
また、ベイジアンフィルタや他のフィルタでまったく怪しいことがわからないわけではないため、一旦普通にSpamAssassin通してやり、全く怪しくないものや、すごく怪しいものは、その時点で白黒付いたと考えて、灰色のものだけを画像フィルタに掛けてやることで、さらに減らすことが出来ると思います。
また、これはFuzzyOCRとかがそうなってるのか知らないのですが、一旦スパムが入っていると判定された画像ファイルは、別でシグニチャを作っておき、次回はまずそのシグニチャリストでもって検索し、それでもダメだったときにOCRに掛ける、と良いと思います。
判定結果をキャッシュするようなものですが、これは実装されてそうな感じだけどどうなんだろ。
(追記)
FuzzyOcrPlugin - Spamassassin Wiki
Experimental MD5 Database feature
とあるから、やっぱり実装されてそうな感じ。
(さらに追記)
SpamAssassin日本語パッチのメンテナーであるid:t-tkzwさんからフォローいただきました。
FuzzyOCRでは、このエントリーで書いたような判定のキャッシュや、他のフィルタでスパムとわかってるものを除外する機能がすでにあるそうです。
- 判定のキャッシュ設定 focr_enable_image_hashing（デフォルト:0）
- スパムとわかってるものを画像フィルタから除外 focr_autodisable_score（デフォルト:10）
これでまたさらに、余計な判定を減らせそうです。
(関連)
FuzzyOcr - Trac
モーグルとカバとパウダーの日記 - ベイジアンフィルタによるスパムフィルタの限界
モーグルとカバとパウダーの日記 - FuzzyOCR(文字認識)対策されたスパム
