お試し中です。3日ほど使ってますが、問題なくスパムを弾いています。
以下、気付いた点ですが。

・ログ
降順(新しいログが上)のほうが見やすい人もいるかも。自分の場合は、ログのページを開いたら一番下までスクロールするのが毎回のことなので。
・ログの見方
ヘルプがあるといいなと思いました。
たとえば「GC finished. (xx files deleted.)」や「PreSkinParse: ip listed on …」はどういう意味なのかな？と。。

ありがとうございます。

ログについては確かにそうですね。昇順、降順についてはちょっと考えてみます。
# NP_BlacklistはNucleusのプラグインとしては珍しくほとんどDBを使っていないので、ちょっとしたことをやるのが結構大変です。

ログについてはホント申し訳ないです。
言い訳をすれば、基本的にはデバッグ用なので、バージョンによって出力が違ってしまっているのでマニュアルを作るがちょっとつらい状況にあります。

ちなみに「GC finished」のGCはGarbage Collect（ガベージコレクト）のことで、不要になったキャッシュファイルを削除したことをあらわしています。

「PreSkinParse: 」というのは、"ページを表示する直前である"というタイミングをあらわしています。従来は「referer:」という表記がされていたのですが、refererチェックを行っていないにもかかわらずrefererチェックにひっかかって困っているというフィードバックがあったため、名称を変更しています。

また、ログには"ip listed on #### found."という表記がたくさんあると思いますが、これは「####というブラックリストにアクセス元のIPが載っていましたので、アクセスを遮断しました」という意味です。

こんな感じでいいでしょうか？

根本的なところで質問なのですが、ページの表示を行う場合にもSPAM判定は行われるのでしょうか？
携帯電話（au。PCサイトビューア使用）から index.php を開こうとすると 403 Forbidden になってしまうのですが・・・。
（ログには「PreSkinParse: ip listed on niku.2ch.net found (Referer:)」と記録されています）

ページの表示を行う場合にもSPAM判定は行われるのでしょうか？

されます。PreSkinParseというのがまさにそれです。コメントやトラックバックだけが防御できれば良いという場合にはPreSkinParseを無効にすることもできます。

やり方については下記に解説してあります。
http://blog.cles.jp/item/1615

あっさり出来ました。ありがとうございます。
# そのページも見てたはずなんですが…見落としてました。すいません。

PreSkinParse

あまり気にしてませんでしたが、僕のサイトでは重要かも。毎日20件～30件ほどこのログ出力があるのですが、見た目に普通のGoogle検索クエリ(日本語含む)のようなので何かな？と思ってました。とりあえず外してみました。
これはつまり、リファラを見て怪しいと判断できたら、ページの表示すらもしないでお帰りいただくという機能でしょうか？

ログの解説ありがとうございました。実は、何が削除されたかと気になってましたが安心しました。

…と思いましたが、よく考えるとスパム業者である可能性が高いのですね。彼らがどういうふうにターゲットサイトを探しているのかが参考になると思って、少し注意深くログを見てみます。

説明の仕方が下手で混乱させてしまってごめんなさい。

これはつまり、リファラを見て怪しいと判断できたら、ページの表示すらもしないでお帰りいただくという機能でしょうか？

オプションの「Enable referrer based blocking?」が「はい」の場合には仰るとおりの動作になります。

ただ、この場合の動作のログは「PreSkinParse: ip listed on ####」ではなく、「PreSkinParse: url(s) listed on ####」という形になるはずなので、そこで見分けることができます。

つまり、ip listed on ###が出ている場合にはリファラを見ているわけではないということです。

彼らがどういうふうにターゲットサイトを探しているのかが参考になると思って、少し注意深くログを見てみます。

鋭いですね。

yamaさんと同じことを考えてログにリファラを出力するようにしたという経緯があります。。。。。

NP_Blacklist 0.98 jp8を使わせていただいています。
ブラックリストの禁止ワードに[url]を登録したのですが、「auの」と言う言葉に反応してはじかれてしまいました。
これはどういう現象でしょうか？
（jp7の時も同様でした。）

この禁止ワードは"正規表現"に従った指定ができるようになっているので、一部の記号に特殊な意味があります。

そのため、[url]というように指定してしまうと、uやrやlがひとつでも含まれると拒否するという意味になってしまいますので、「auの」という言葉に反応するというのはサクラキャンドルさんの意思には反する動作ですが、プログラムとしては僕が作ったとおりに動いているといえます。

どんな記号が特殊扱いされるかということについては下記URLの「メタ文字」という部分に書いてあります。
http://jp.php.net/manual/ja...

対処方法としては、jp8から禁止ワードの登録画面に「enable regular expressions ?」というチェックボックスが追加してありますので、これにチェックを入れないで、[url]という文字を追加してみてください。

そうするとメタ文字がメタ文字として働かないように処理をしてから禁止ワードに登録する処理をしてくれるようになります。[url]の場合は\[url\]に変換されますが、この状態で[url]という文字列に反応してspamを防ぐことができます。

なるほど。早速登録しなおしをしてテストしてみましたが、はじかれないようになりました。ありがとうございます。

ついでに、本日のスパムログを見ていたのですが、niku.2ch.netで一致してはじかれるIPが結構ありますね。
そのうち１つはyahoo!からの検索で来た@niftyのユーザーのようでしたが、過去にスパム行為をしたとか、そういう理由ではじかれるのでしょうね。

そうですね。理由はいろいろあるようですが、荒らしというよりも、ゾンビPCになっているとか、公開Proxyになっているという場合が多いみたいです。

はじめまして、NP_Blacklist 0.98 jp8を使わせていただいてます
禁止ワードに正規表現で先頭から末尾まで英数字、空白文字、改行などしかない、いわゆる全角文字がないものを登録したんですが、コメントはうまく弾いてくれるのにトラックバックは弾いてくれません、どうしたらいいでしょうか?

NP_TrackbackはバージョンによってはNP_Blacklistと連動していないバージョンもあるはずなので、使っているバージョンを教えてください。

具体的にはどんな正規表現を入れたか教えてもらえますか？

てっきりNP_Blacklist単独で動作しているものだと思っていました
確認したらNP_Trackbackが1.2だったので2.03にしたところトラックバックも弾くようになりました
ちなみに使った正規表現は「^[[:print:][:cntrl:]]+$」です

解決したようでよかったです。
また何かあったら教えてください。

たぶんTrackbackは弾かれたと思うので、コメントで。
http://fjsk.s39.xrea.com/it... に書いたのですが、どうやらxreaサーバーが軒並みBBQ登録されたらしく(いくつか確認してみましたが全部NG）、NP_Blacklistに弾かれてFreshReaderもTBもできないという状況になっております。

BBQの解除方法を調べたんですが、DNSBLに登録の場合は解除も簡単なのですが、BBQ登録の場合はこれという解除方法が見あたらず、xreaのサポートでも「対応方法は探しているが現状ではどうすればいいのかわからない」という回答が来る状況です。

BBQはかなり強力だとは思うのですが、登録の解除が難しいとなるとブログシステムのブラックリストとしてはちょっと厳しすぎるかなぁ…と思います。

たぶんTrackbackは弾かれたと思うので、コメントで。

ログが残っていなかったのでおかしいなと思って調べたらApacheレベルで403を返していました。
# NP_Blacklistに引っかかったIPは定期的に.htaccess規制に入れているのが仇になりました。

確かにDNSBLを引いてみると、IPが登録されていますね。

91.200.163.219.niku.2ch.net. 2017 IN TXT "shutouted IP: 219.163.200.91"

とうとうこういう問題起きてしまったかという感じです。現在の仕組みでは不特定多数の人が利用するレンタルサーバーを使っていると巻き添えをくってしまう可能性が高くなることはある意味避けられそうにありません。

解除が簡単なDNSBLというのはある意味ザルであるとも言えますし、DNSBLによっては動的割り当てブロックであればすべてアウトというポリシーのものも存在することを考えれば、BBQが特段厳しいポリシーで運用されているとは思えないのですが、理由の開示と削除手順が明確に規定されていないのはやはり欠点といわざるをえません。だからといって有効な代替案があるわけでもないので、ちょっと頭が痛い問題だと思います。

直接的な解決にはならないのですが、最近ちょっと思っていることとしてPreSkinParseで画面の表示自体を一切しなくなるというのはNP_Blacklistの機能としてはちょっとやりすぎなのかなと思っています。あくまでNP_BlacklistはSpamCheckイベントの処理のみに専念することを考えたほうがいいのかなと。。。。。

なにかうまい方法があればいいんですが。

BBQ側では解除する理由がないと思うので、たぶん解除されることはないと思うんですよね。
なにしろxreaでproxy動作するcgiについて規約で禁止している以上、xreaから2chへの書き込み規制を書けても誰も困ることはないのですから…。
レンタルサーバー経由の書き込みはそもそも考慮せずに弾いてよい「掲示板」と、TBというスクリプト書き込みが機能としてそなわる「ブログシステム」で同じブラックリストを使うのは難しい面がある気がします。
とくにxreaはかなりのNucleusユーザーが使用しているはずで、そのユーザー全てがTBを遅れなくなるとなると影響は大きいなぁと。

確かにPreSkinParseは外してもいいかもしれませんね。またはデフォルトOFFにした上でオプションで変更できるようにするぐらいがいいかもと思います。それならFreshReaderは使えるし…。
それでもTBができない、って問題は残っちゃうんですけどね…。

レンタルサーバー経由の書き込みはそもそも考慮せずに弾いてよい「掲示板」と、TBというスクリプト書き込みが機能としてそなわる「ブログシステム」で同じブラックリストを使うのは難しい面がある気がします。

確かにそうですね。現存するDNSBLのほとんどはオープンリレーのメールサーバ、spamメール、匿名プロキシをリストしたものなので、TBを防ぐためにこれらを流用すれば問題が発生するのは必然でした。

Bulkfeedsがやっているように、独自にDNSBLを立てるという選択肢も残っていますが（とりあえず作るところまでは実験してみました。）、現状のリソースを考えるとブラックリストを毎日メンテナンスするのは現実的ではなさそうです。

ほかに考えつくのはwhitelistを作るということなんですが、これもどうやって収集・配布するかという問題がありますね。

うーん、頭が痛い。。。。

独自DNSBLはちょっと難しいですよね。ブログ用のDNSBLとなるとやはりBulkfeedsあたりなんですが、アレだけだとやはり弱い感じでしょうか？

そもそも私のところは旧版ブラックリストの単語で弾けてしまってたっていうのがありますんで、あまりDNSBLのありがたみがわからないというのもあるんですけどね…（＾＾；

もうひとつ気付いたことがありました。
不具合ってわけではなく改善提案ですが。

管理画面の「Generate .htaccess snippets」の「Generate .htaccess snippets」ボタンで生成されるリストですが、
order allow,deny
allow from all
この２行も含められるといいのではと思いました。何日か前に、このリストで生成されたスケルチIDリストをそのまま.htaccessに貼り付けたら、一部のページの表示に不具合が出たので外したことがあるのですが、そもそも何が原因かと思って調べてみたら上記の２行が必要ということを理解してませんでした。表示の不具合がどんな内容だったかは今はよく覚えてませんが。。

yamamotoさん

上記の改良、jp9に入れ忘れたままリリースしてしまいました。上記の修正はjp10から入ります。ごめんなさい。