• Dear Erik,

    not a bug report! Its more of a feature request. For a few months now, many of my sites get strange spam messages that are not detected by your plugin. Name, Message and other generic fields get filled with something like “UaQfNbEorkNntZdCYb”

    Just this one random string. I did write a custom heuristic rule in my functions.php to tackle this type of spam (since those messages come in hoards), but I wonder on how we could improve your plugin so this type of spam gets filtered out. I am not using any honeypot features.. maybe this would help?

    Cheers!

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Erik

    (@codekraft)

    Ciao @ohhcee,
    This is precisely the case where I would use honeypots or client-side fingerprinting. I don’t think yours is spam but rather a script/scan, given the modalities you are describing. In this case, when you block that IP address, the problem will (probably) be solved.

    Let me know if this solves the problem, and remember that for special cases, you can activate the extended debug mode of cf7 antispam, and in this case, you will find in the WordPress log much more information about the spammer.

    Thread Starter ohhcee

    (@ohhcee)

    Ciao Erik,

    apologies for my late response. The fingerprinting gave me false positives sometimes in the past, that’s why I disabled it. But I will give the honeypot section a try next year. I used another plugin in the past which just added basic honeypot to cf7, but those were not sufficent anymore – the reason I switched all clients to your plugin 🙂

    thanks for your great work and have a great holiday season.

    Plugin Author Erik

    (@codekraft)

    Hi @ohhcee,

    Thanks for the update and for your kind words!

    Yes, giving the honeypot section a try is definitely the right move. I suspect the reason the previous solution didn’t work for you is actually quite technical, and it highlights a key difference in how my plugin handles this.

    Many plugins inject honeypot fields using JavaScript (to keep them hidden from human users). The problem is that the vast majority of bots (99.9%) do not execute JavaScript. As a result, they never even “see” those honeypot fields, so they don’t fill them out, and the trap is never triggered.

    My plugin inserts the honeypot server-side, directly when Contact Form 7 generates the form HTML. This means the field is physically present in the raw code that the bot scrapes. Since bots are programmed to fill every input they find, they fill the honeypot, and we catch them immediately.

    Let me know how it goes once you switch it on!

    Happy New Year!

    Erik

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.