Yawasp – das steht für “Yet Another WordPress Anti Spam Plugin”. Dabei handelt es sich um eine Weiterentwicklung der erfolgreichen Spamfrei-Methode von Thorsten und Christoph. Sven Kubiak hat das Verfahren ein wenig vereinert und daraus ein WordPress-Plugin gebastelt, welches er gestern nach einer Betatestphase, an der auch ich teilnehmen durfte, veröffentlicht hat. Damit besteht nun wirklich kein Grund mehr, den Besucher mit lästigen Rechenaufgaben zu nerven. Wie ich schon in den Kommentaren zu diesem Beitrag bemerkt habe: die Kunst der Spamabwehr liegt darin, dass man sie nicht bemerkt.
{ 4 trackbacks }
{ 26 comments… read them below or add one }
Hört sich gut an, bei mir funktioniert die ursprüngliche Methode in Verbindung mit Spam Karma aber noch recht zuverlässig. OK, ich bin jetzt auch kein A-Blogger und für die Spammer recht uninteressant…
Das hat mit A-Blogger (bin ich übrigens auch nicht) nicht viel zu tun. Ich kenne kleine Blogs, die werden regelrecht überschwemmt. Soviel Spams hatte ich auf apfelquak und admartinator.de zusammen nicht.
Wie sehen solche Spam-Beiträge eigentlich aus? Glücklicherweise sieht man diese hier ja nie.
Oder meint ihr Spam-Mails im Allgemeinen?
Guck hier auf den Screenshot:
http://www.admartinator.de/2008/04/09/spambots-sind-lernfaehig/
Ansonsten das Übliche. Viagra, Rolex und Co.
Also bei mir leistet Akismet perfekt seine Dienste:
“Akismet has protected your site from 43,802 spam comments already”
Da kam in 2 Jahren vielleicht 3 oder 4 mal was durch.
Wenn ich dann auf 2.5.(1) umgestiegen bin, probiere ich es auf jeden Fall mal damit. Schön das es jetzt ein Plugin dafür gibt.
Die 43802 Spams landeten aber bei dir auf dem Server und durchgeschaut hast du sie vor dem Löschen sicher auch. Oder?
Mit barrierefreiem oder behindertenfreundlichem Web hat das aber nicht mehr viel zu tun. Man sollte nicht vergessen, dass Blinde ebenfalls auf “dumme” Software angewiesen sind und bei zufällig benannten Input-Feldern und einem author-Honigtopf auch in die Falle laufen werden.
Diesen Kommentar habe ich gerade mit lynx abgegeben. Du siehst – scheint also doch barrierefrei zu sein, diese Lösung. Einzig das versteckte Feld irritiert ein wenig, aber das dürfte ein kleineres Problem sein.
Ächz. Mein Standard-Browser wird das nicht…
Das sah übrigens so aus: KLICK!
@Martin H.
Ich weiß leider nicht, wie eine behindertengerechte Software durch das Kommentarformular parst, aber die Namen der Input-Felder sehe ich da nicht als Problem. Wenn diese in einer Sprache verfasst sind, die der Nutzer nicht versteht, kommt er damit auch nicht klar, oder?
Das versteckte Feld ist da schon eher ein “Problem”. Aber wie der ad ja festgestellt hat, klappt das sogar mit lynx
@kubi: Wenn mich nicht alles täuscht, so nimmt man Lynx zum Testen solcher Bedingungen. Deswegen habe ich mir das ja angetan.
@ad: Warum sollte auch Lynx nicht funktionieren? Das Problem ist doch eher, das man in bspw. reinen Textbrowsern das Eingabefeld sieht, was leer bleiben soll.
Mein Tipp hier wäre noch einen versteckten Text dazu, der sagt, das man dies Feld leer lassen soll. Dann versteht man es auch im Lynx und auch der Blind bekommt die Information das Feld leer zu lassen.
Btw. nicht ‘lynx’ sondern auch ‘links’ ist sehr gut zum Konsolentesten geeignet
Sollte ja auch nur der Beweis sein, dass die zufälligen Input-Felder kein Problem sind.
Ich glaube Martin Hiegl wollte auf den Namen des Eingabefeldes hinaus, weil der Blinde daran erkennt, um was es sich für ein Eingabefeld handelt bzw. es leichter erkennen kann.
Und genau diesen Namen verändert ja das Plugin zu gunsten der Spamabwehr, aber zu lasten der Barrierefreiheit. Ist halt ein Kompromiss, aber was will man machen
Bei den versteckten Feldern muss man immer berücksichtigen, wie sie versteckt werden.
Die moderneren Screenreader können visibility:hidden; interpretieren, wenn man aber text-indent:-9999em; nimmt schauts schon anders aus.
Bedenken sollte man aber immer, dass was ein Screenreader kann, kann ggf. auch ein Spambot. Im Moment tendiere ich zu einer CSS-Lösung, die dann das versteckte Feld über class=”…” anstatt style=”…” ausblendet. Da einige Themes die Formularfelder über die class=”…” formartieren, müsste der Spambot schon die Semantik der CSS-Eigenschaften prüfen. Anderseits möchte ich dem Nutzer auch nicht zu viel Arbeit mit auf den Weg geben, bevor das Plugin läuft.
Aber Ich bin da offen für Vorschläge jeglicher Art
Das Plugin hat m.M.n einen sehr guten Ansatz und ist gerade mal eine gute Woche alt. Ich sehe da noch viel Potenzial für weitere Entwicklungen 
Bevor ich irgendwelche Anti-Spam Maßnahmen ergreife warte ich erstmal bis überhaupt Spam auf meine Seite kommt. Bis jetzt Null!
danke, super tipp! werde ich auf jeden fall die tage installieren!
Mich stört doch das nicht wenn die Kommentare auf dem Server landen und Akismet sie abfängt.
Die werden dann ja gelöscht. Durchgelesen hab ich noch keinen, ab und zu mal reingeschaut. Aber da blieb noch nie was grundlos hängen.
Großes Dankeschön an Ad für den Tipp. Läuft seit gestern erfolgreich auf Macnotes und hat bisher 427 Spambots abgefangen.
Vorher hatten wir eine Kombination aus Captcha (für nicht registrierte Leser) und Filter.. das war zwar recht zuverlässig, aber die Spam-Kommentare landeten natürlich trotzdem erstmal in der Datenbank. So sparen wir uns die Ressourcen.
427 an einem Tag sind natürlich eine Hausnummer. Da komme ich mit meinen 45 nicht mit. Selbst, wenn ich die 15 von Apfelquak mit dazu zähle.
Wieso veröffentlichst du deine verschiedenen Plugins, die du im Hintergrund deines WP-Systems laufen hast, inkluse deren Versionsnummern? Hast du da nicht Angst von Hackerangriffen?
Nö, sollte ich?
danke – das klingt mal nach einem block-plugin, wie ich es mir vorstelle .. werde es testen.
zum naming: das umbenennen der felder ist kein problem, da der (interne) name dem nutzer nicht angezeigt und auch nicht interpretiert wird. er wird von scripten und – wenn man will – zum aufloesen des css genutzt.
{input name=”author” ..}Name{…}
und
{input name=”hx6g56j6″ ..}Name{…}
sind aus html-sicht gleichwertig.
im kommentarfeld auf dieser site gibt es allerdings einen kleinen bug.
{input name=”ac2c2039ea23ca633eca165a4577c247″ id=”author” }
{input name=”c62ac98d8e22b073144c03e06f3dfb19″ id=”author”}
ids muessen eindeutig sein. imho wird fuer das hidden-field ein input tag wird author-id reused.
wer bei einfuehrung zum copy und paste gegriffen hat, koennte rasch irgendwas anderes als id eintragen und das fixen.