スパムがまた増えたので、スパム対策まとめ

| コメント(0) | トラックバック(0)

最近またスパムが増えた。
昔からいろいろやったまとめ。

Sender Policy Framework
完全に普及したら多少はスパム対策にはなるけど、現状では微妙。でも携帯のキャリアとか大手については、今でもそれなりにつかえてる。携帯のアドレスを詐称してるスパムはそれなりにある。まあ、SPFだけで拒否するのがいいかは思想による。

ドメインキー
ドメインキーといえば、Yahoo!とか、Gmaiとかlになるんだろうけど、こいつらには外部を拒否する前に自分の中のスパマーをなんとかしろと、言いたいヒトも多いんではないだろうか。これも現状は大手のみ。ヘッダとか文字コードをアレしちゃうようなサーバもいるのでこれで拒否するのは現状では面倒。

DNSBL
有名どころは
bl.spamcop.net
sbl-xbl.spamhaus.org
all.rbl.jp
など。便利だけど危険性もある。ちょっと前はスパム対策のソフトとか箱がDNSBLを直接参照してた。今は直接ではなくDNSBLを自前で編集して利用してるみたい。
最近あるのがウイルス感染とかトロイで意図せずスパムメールを発信しているケースで、これがDNSBLに登録される。で、単純にDNSBL使って拒否すると、全くメールができなくなる。そんなことにならない運用が必要。

Greylisting
最初に再送要求で拒否って、二度目は受け取る。今のところ、これに対応するスパムはそれほど多くないのでそれなりの効果はあると思う。ただ無害なメールサーバにまで多少なりとも負荷を与えることになるので個人的にはあまり好みじゃない。あと、これに対応するスパムが増加した場合に無意味になるどころか悪影響になるのも難点。SPFとかドメインキーみたいにスパムは防げなくとも一応他の意味もある(使えるか知らないけど)ならいいんだけど。

Tarpitting
返答を遅延する牛歩戦術、スパムはあまり待たないことを利用。利点、問題点はGreylistingとほとんど同じ。

S25R
あるパターンのホストを拒否する、普通それでは問題があるので再送要求して二度目は受け取る。結局のところ、何でも拒否せずあるパターンに条件を絞るGreylisting。

# 初期の偽陽性判定率約13%。ホワイトリストの保守(自動化可能)が必須です。
# メールログを監視できない人は使わないでください。
# メールの受信の遅延がいやだと思う人は使わないでください。

とのこと。ホワイトリストの保守が必須なら、全部をGreylistingかTarpittingしてホワイトリストつくったほうが効果が大きいと思う。負荷などのバランスを考えた結果なんだろうか、思想がよくわからない。

SpamAssassin
自動化したいし、ミスは減らしたいし、GreylistingとかTarpittingは避けたいとなると結局これ。複数の条件にマッチした場合にスパムと判断するという動作が重要。SPF、ドメインキー、DNSBL、S25R、全部に対応できるし、便利なSpamAssassinのユーザ定義ファイルを公開してるヒトもいる。ただしかなり処理は重い。

導入、運用、保守、考えるとSpamAssassinが楽だけど、これだけスパムが増えるともっと根本変えないと駄目になってくるんだろうな。

トラックバック(0)

トラックバックURL: http://uwi.but.jp/mt/mt-tb.cgi/298

コメントする

このブログ記事について

このページは、uwiが2010年6月21日 11:09に書いたブログ記事です。

ひとつ前のブログ記事は「自分の研究費は自分でとってくるもの」です。

次のブログ記事は「Gentoo Linux で error: libpq-fe.h: No such file or directory」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。