Vielen Dank für diesen Bericht — er hat mehr ausgelöst als eine Fehlerbehebung.
Sie haben recht: Der Nutzen der Gibberish-Erkennung steht in keinem Verhältnis zu dem Schaden, den sie anrichtet, wenn sie danebenliegt. Ein abgewiesener Beitrittsantrag wiegt schwerer als ein durchgerutschter Spam pro Woche. Ich habe nun auch schon mehrere Reports in diesem Zusammenhang.
Mit Version 6.0.0, soeben veröffentlicht, ist die Erkennung standardmäßig aus. Nach dem Update prüft sie gar nichts mehr, bis Sie ausdrücklich Felder dafür auswählen. Der Proof-of-Work, die Blockliste und die Wiederholungssperre laufen unverändert weiter — genau die Schutzschicht also, die für Sie ohnehin die Arbeit macht.
Wenn Sie die Prüfung für ein einzelnes Feld wollen (das können Sie tun wenn wieder etwas durchkommt): Öffnen Sie eine gespeicherte Nachricht, und neben jedem Feld steht ein Knopf „Check this field for gibberish”. Ein Klick genügt, ein weiterer nimmt es wieder heraus. Wählen Sie dort Nachrichten- oder Betreff-Felder — technische Felder wie Tokens oder Referenznummern sind von Natur aus zufällig und würden jede echte Einsendung auffällig machen.
Zu Ihrer zweiten Beobachtung, dass aus dem Protokoll nicht hervorging, welches Feld die Blockade auslöste: Auch das ist behoben. Die Begründung nennt jetzt den Feldnamen — gibberish:letters=5,alnum=304,solo=0,field=…. Ihr Wert alnum=304 deutet übrigens auf genau so ein technisches Feld hin: 304 Zeichen aus Buchstaben und Ziffern, aber nur 5 Buchstaben-Token — das schreibt kein Mensch, das ist ein verstecktes Feld eines anderen Plugins.
Das hört sich gut an, das wird uns sehr helfen. Das Formular, das hier die Probleme macht, ist recht komplex, es benutzt Contact Form7 zusammen mit Conditional Fields für Conatct Form 7 und Contact Form 7 Signature und enthält viele Felder und eine Menge Bedingungen, die wohl zu recht viel technischen Feldern führen. Ich werde das nach dem Update auf die neue Version beobachten und hoffe, das ihr Plugin jetzt wieder so gute Dienste leistet wir bisher.
