Anfang Oktober hatte ich über Probleme zwischen Bad Behavior (Version 1.2.2) und Spam Karma 2 berichtet (hier und hier). Ich habe die Angelegenheit nicht mehr weiterverfolgt, weil ich Bad Behavior aufgrund seiner mangelnden Konfigurierbarkeit und dem daraus resultierenden Alles-oder-Nichts-Prinzip nicht mehr eingesetzen wollte. Aufgrund eines Pingbacks von Thomas Schneider habe ich mal recherchiert, wie es aktuell aussieht.
Das Problem scheint gelösct zu sein. Von beiden Seiten (Spam Karma/WordPress und Bad Behavior) wurden Lösungen zur Verfügung gestellt.
Der eigentliche Verursacher war WordPress. WordPress setzt (zumindest bis zur Version 1.5.2) bei http-Requests nicht den User-Agent. Dies wertet Bad Behavior als schlechtes Verhalten und damit als spamverdächtigt und „macht zu“.
Bei WordPress Trac gibt es seit Anfang Oktober das Changeset 2933, das mit wenigen Zeichen zusätzlichem Code WordPress beibringt, sich beim http-Verkehr zu identifizieren (sprich den User-Agent zu setzen). (Fragt man sich nur, weshalb nicht gleich so…)
Auf der anderen Seite wurde bei Bad Behavior in der Version 1.2.3 die Prüfung des User-Agents entschärft:
Bad Behavior 1.2.2 introduced a requirement that user agents present a User-Agent header. This caused quite a few unexpected things to break, and has been changed in this release. A User-Agent header will now be required only for POST requests.
[aus dem Changelog zu Bad Behavior 1.2.3]
Ein kurzer Test mit einem ungepachten WordPress/Spam Karma und Bad Behavior 1.2.4 verlief bei mir positiv.
Someone else below asked this already about antispam scripts.
I am getting nailed with Spam on my website mails and in our blog website – now its offline too
much spam. Is there anyway to stop this? If not, there really isn’t any point in leaving it up
and active. Any help will be greatly appreciated.
Thanks for help, Keep up the good work. Greetings from Poland