Module load weight

Not a "dead module." Is this a general recommendation, or do you have evidence that httpbl is not blocking blacklisted IPs?

I have this module installed on a number of my employer's higher trafficked sites, some with and some without captcha, and it consistently blacklists and blocks anywhere from a half-dozen to several dozen IPs a day.

If configured optimally, the blacklisted IPs are added to Drupal's core blocked_ips table. Unless overridden in settings.php, that table is checked on every page request.

Do you have the IPs of the commenters that CAPTCHA blocked?

I'm not sure you understand what httpBL is supposed to do. It only greylists or blacklists IPs found @ Project Honeypot, with threat-scores.

If you know the IP of the spammer, you can look it up @ Project Honeypot and see if it is even listed at all, and what the threat-score is if it is. There are still many spammers out there not yet in the PH list.

httpBL does have its own debug log. Just don't leave it on too long because it is a performance expense. It will show what IP's were evaluated and what the results were.

Changing version.

And there is no "debug" flag in the code I'm running (6.x-2.0-rc1), unless you're talking about adding entries to dblog, which doesn't add anything if it didn't grey or black list the IP. (Maybe 7.x has it, but the clients that need this are all on 6.x)

Sorry, but you posted this as a version 7x issue, and that version has exhaustive debug logging (bordering on overkill). When turned on it will log each IP checked and what the response code was from project honeypot. It was never implemented in 6x because logging is very expensive in D6. Logging is what first got me involved in this project, and if you're so inclined you can read the exhaustive debate between praseodym (this project's originator) and myself, #570742: Logging is not working.

When testing with the debug logging while porting this to 7x, I did see instances where IPs were not blocked because the response codes came back clean, yet I knew they were bad IPs because I had preselected them for testing because of their high threat scores on manual lookups. An hour later I would receive the correct response code and the IP would be blocked, as expected. In other words, yes, sometimes, apparently, for whatever reasons, there were invalid responses from p.h., but those misses were intermittent and beyond my control, and the module works when they are valid, so I didn't fret about it. By and large project honeypot stops more bad traffic than it misses. I've seen low (legitimate) traffic sites do an astonishing amount of blocking on a daily basis.

Perhaps for whatever reason you can't use the option to block on all page requests, rather than waiting to catch them in the act of leaving comments. I use this module on about two dozen production sites, in that "all" mode, because my thinking has always been to keep that garbage traffic off a site the moment it shows up. The risk is that it could punish innocent traffic with listed IPs, but that risk can be mitigated by adjusting the threshold. The module originally blocked anyone with any threat level greater than zero.

I'm adding this, https://drupal.org/node/354516#comment-6406368 , to the version of http:BL I'm using with clients, see as well: https://drupal.org/node/1248942#comment-6708832 . Although I'm looking for a different hook to use, as I'd only want it run when a module is enabled, not every bootstrap.

Try hook_install, as was recommended in the first link you sent at the top of this thread.

You can also refer to the code in the 7x version to see where you might add more logging to see what responses you get from p.h., but, again, be advised that logging is performance expensive in D6 because it comes at the tail end of the full bootstrap.

Three years ago or more I was unable to convince the creator of this module that the D5-to-D6 port had left functionality behind, so ran my own hacked version of it on my sites, and eventually that became the 6x-2 fork.

Overall I'm unconvinced that this is a captcha conflict. I've asked for evidence, you said you have it but didn't share, so color me skeptical.

Changing status (closing)...

I just re-read "Just had CAPTCHA block 8 comment spams in 3 seconds that http:BL didn't blacklist." in http://drupal.org/node/1833648#comment-6714046, and that actually explains what is happening:

httpBL, in comment checking mode, checks IPs only when the comments are actually in the process of being saved (created or updated). In D6 this happens in hook_comment, during an insert or update. In D7, it happens during hook_comment_presave.

Using CAPTCHA short circuits (prevents) that comment creation process altogether, by adding an extra form-validation challenge before Drupal actually attempts to save the comment. If spammers fail that challenge, there is no attempt to create the comment, thus httpBL never gets a chance to look those IPs up and block them. The IPs will only be checked by httpBL if spammers successfully beat the CAPTCHA challenge (confirmed via testing), and move to the next step in an attempt to commit/write/save the comment. At that time httpBL will block the comment, if those IPs are found listed at Project Honeypot, even though they passed the CAPTCHA challenge.

Changing the module load weight is not going to resolve that conundrum, as each module is targeted at different points along the path to writing a comment. Getting CAPTCHA out of the way will allow all commenter IPs to always be checked, but it will not prevent spam from newer spammers not yet listed at Project Honeypot.

If you must use both httpBL and CAPTCHA, I'd suggest letting httpBL check all page access, and leave the comments to CAPTCHA . That way you ban known bad traffic as soon as it shows up on your site (who needs it?). CAPTCHA will then take care of those IPs not yet listed in project honeypot, but dumb enough or robotic enough to fail the CAPTCHA challenge.

I'd also recommend, if you aren't already, fully using and registering your honeypots (and donating mail servers) with Project Honeypot. That's the only way to catch those nascent spammers that are not yet listed, and get them reported and listed so they will be blocked on future visits.