Honeypot API key not catching spammers

There could be any number of reasons.

1) the spammer could already be in the good cache.
2) the spammer might have not been on the honeypot db when he was checked.
3) there might be an error in the api key field (a space for instance).
4) Your host may not have url open access so the call to the api fails.
5) You might be using an older version of the plugin that checks for proxy server headings and the IP was spoofed. (go to blogseye.com and download the beta version that has some fixes.)

Keith

Hi Keith,

Thanks for your reply. Since my first post a week ago, we still haven’t caught any spam registrations through the Honeypot API and lots of spam registrants are getting let in that exist in the Honeypot spam database. This tells me that it must be something to do with the call to the API not functioning as expected.

I have triple checked that the API key is correctly entered but this still has not resolved the issue.

There is nothing in my debug.log that can help me figure out the main reason of the problem. The SFS and Botscout checks are working great so it shouldn’t be the url open access and the plugin is the latest version 5.9.3.

Is there anything else it could be or something I could test to debug the problem?

Thanks,
Ana

I think that Honeypot is the last thing checked.

Honeypot uses a dns lookup – the PHP function is gethostbyname. I might be that your host does not allow the function or somehow has it blocked.

I have not test the honeypot code in years. It was working when I wrote the code, but that was a while ago. I had to take out similar code for the dnsbl because it was timing out, but at the time honeypot was still reporting correctly. I was wondering about the lack of hits for the the TOR code that uses a gethostbyname call, but I thought that was because there were so few examples of it and the other checks all go first so it never came up.

Keith