既にそれなりの効果を上げているものから妄想段階のものまで、コメント・スパム対策を羅列してみる。とりあえず10個。とりあえずて。ちなみにうちでは3つほどを連続でチェックしてます。現状では95%近く拒否できている模様。みんなでやればきっと楽しいいたちごっこ!

評価の星(☆)は5段階。とは言うものの5のものはなかったりする。これは僕が未だに「決定的な対策は無いかなぁ」と感じていることを受けています。また、手作業でのスパミングは考慮外です。文末に「(未確認)」と付いているのは、誰も実装してない妄想段階の対策です。あくまでも機械的に投稿されるものへの対策。手作業でのスパミングはIPで投稿間隔チェックとかで良いと思います。

URLのチェック ☆☆☆

ブラックリストなURLのリストを作成し、それに該当するかどうかでチェックする方法。誤爆の可能性は無く、対策としては確実。しかし、最初の一回は絶対に防げないことや、ブラックリストの管理などの手間がかかることなど、コストの割に報われない。

アスキーチェック ☆☆☆

コメントの本文がアスキーのみかどうかでチェックする方法。効果はかなり高いが、誤爆の可能性も否定できない。最近ちょくちょくあったりするロシア語や韓国語のスパムは防げない。

ひらがなチェック ☆☆☆☆

アスキーチェックを一歩進め、コメントの本文にひらがなが含まれるかどうかでチェックする方法。これも誤爆の可能性は否定できないが、ロシア語や韓国語のスパムは防げる。

URLと本文の比較 ☆☆☆☆

(typesterさん案)URLとして入力された文字列が本文にもあるかどうかでチェックする方法。マッチさせる方法は工夫する必要はあるので、誤爆の可能性は否定できない。しかし、多くのスパムがあるURLへの誘導を目的としたものであり、結果としてURLと本文の両者に同じURLがあることが多いというスパマーの心理を突いた対策で、効果は高そう。

本文のURLの数をチェック ☆☆

(typesterさん案)本文にURLが5つ以上書かれているかどうかでチェックするという方法。誤爆の可能性は否定できないが、通常のコメントでは5つ以上URLをコメントで投稿することはまずないのであまり問題になることはない。一方で、しきい値(この場合は5)に満たない場合はまるでチェックできないなど問題もある。他のスパム対策と組み合わせて利用するべきか。

指定した文字列を入力チェック ☆☆

コメントの投稿フォームに予め設定したランダムな「this is not spam」などという文字列を手動で入力してもらい、それをチェックする方法。基本的に手作業での投稿を強制することに繋がるので、効果はそれなりに高い。しかしそれ以上に訪問者が負担と感じると思われるので、スパム対策としては下策。

画像で指定した文字列を入力チェック ☆☆

コメントの投稿フォームにランダムな文字列を画像で表示し、その文字列を手動で入力してもらい、それをチェックする方法。基本的に手作業での投稿を強制することに繋がり、効果はそれなりに高い。しかしそれ以上に訪問者が負担と感じると思われるので、スパム対策としては下策。

hiddenでパラメータを渡してチェック ☆☆☆

(oobaさん案)エントリのIDなどから類推しづらい文字列を機械的に生成し、それをhiddenでパラメータとして渡してやり、それをチェックする方法。指定した文字列を入力チェックなどとは違い、訪問者に負担をかけないという点では優れている反面、機械的に解析することが比較的容易であるという脆い面もある。

プレビューチェック ☆☆☆

訪問者に一旦プレビューしてもらい、その後改めて投稿してもらうことによりチェックする方法。これも手作業での投稿の強制に繋がるので、効果はそれなりに高い。前の2つと比べても訪問者への負担は少ないので良い。

IPチェック ☆

ブラックリストなIPのリストを作成し、それに該当するかどうかでチェックする方法。確実ではない上に、誤爆の可能性も否定できない。更には最初の一回も防げない。管理の手間も辛い。という即効性は皆無な対策。ただし、投稿間隔のチェックなどのためにIPをチェックすることは必要とは思われる。

リファラチェック ☆☆☆☆

リファラがblog設置URLまたはblog設置先ドメインを含むかどうかでチェックする方法。詐称することは可能なものの、機械的にスパミングする奴でそこまでやっている奴はあまりいない(今のところ)ので、効果はかなりある。

HTTP_ACCEPT_ENCODINGをチェック ☆☆☆(☆)

HTTP_ACCEPT_ENCODINGにgzipが含まれるかどうかでチェックする方法。基本的に誤爆はしない(はず)が、詐称することは容易。HTTP_ACCEPT_ENCODINGにgzipが含まれる場合、gzipでエンコードしてサーブするサーバー(XREAなど)の場合は、詐称しても意味が無い(gzipのデコードを実装しなければならない)ので☆追加。

HTTP_ACCEPT_LANGUAGEをチェック ☆☆☆

HTTP_ACCEPT_LANGUAGEにjaが含まれるかどうかでチェックする方法。詐称することは容易な上、中にはきちんと設定していない人もいる。取りこぼし・誤爆共に可能性が高いと思う(未確認)。

HTTP_FORWARDEDをチェック ☆☆☆

(oyamaさん案)多くのプロクシ・サーバーが送信するヘッダであるHTTP_FORWARDEDやHTTP_X_FORWARDED_FORがあるかどうかでチェックする方法。多くのスパムがプロクシ・サーバーを介して投稿されることを考えると、効果は絶大ではある。しかし、スパムの投稿以外の目的でプロクシ・サーバーを介して投稿することもかなりあると思われる(会社からなど)誤爆率も高い。一時的な処置としては良いと思う。

JavaScriptでフォームを書き出す ☆☆☆

(oobaさん案)JavaScriptでコメント投稿フォームを書き出すことによって、機械的にパースしにくいフォームに仕様という対策。JavaScriptファイルを別ファイルにすれば、さらにパースしにくくなるかも。JavaScriptのパーサーはいくつもあったりするのでばれれば即終了とか言う可能性は否定できないが、現状では効果的な対策かもしれない(未確認)。

mt-comments.cgiをリネーム ☆☆

(oobaさん案)Movable Type専用の対策方法。それなりに効果があると思いきや、あまりひっかからない模様。スパマー手強い。


こうやって対策をぶっちゃけていくと、スパマーも学習してしまうわけで、結局は独自に学習するスパム対策が・・・ということになって、ベイジアン・フィルタマンセー! になっちゃいそうな。

他にも良い対策あったら教えてください。

追記

oobaさんとoyamaさんの案を追加しました。

追記@2004/09/20

typesterさんの案を追加しました。