Mollom is letting through a good 75% of the spam and this is obvious spam bots. It wasn't working at all until I synced up server time via this issue and "self resolve"
http://drupal.org/node/1913728#new

It looks like spambots post in rapid succession 10-20 comments in a row and Mollom API in terms of time cannot pick them all up, something to do with timing.

As far as I got in a debug and if there are dynamic IP lists to just block spambots there might be a good idea, but I've already added 100 IP addresses to the firewall and if I add any more at the top level, I'm going to slow my site due to all of the IP tables.

This is so bad, it's hard to find the real comment in the moderation queue from the flood of spam. Thx.

I am using a custom AJAX commenting display but that doesn't seem to be involved since the spam mollom identifies vs. passes seems to be a timing issue and not a type of form submit one.

Comments

Category:task» support

The Mollom API definitely does not have any timing issues — Mollom is able to process multiple thousands of posts per second.

Since you mentioned a custom Ajax comment form integration, I'm tempted to say that this must most likely be caused by that code.

Can you disable the custom Ajax code to verify whether the issue remains to exist with the regular comment form?

It is happening with just regular comments, same result. There is a firewall, csf/lfd but I don't see that having an effect since the API is not blocked. Additionally the clock sync referenced , before that was done, mollom wasn't working at all, which implies some sort of sync/time issue to me. This is on a VPS, CentOS 6.

I don't know your code well enough to guess on what it could be, although I'm wondering if cache_form allows spam bots to resubmit repeatedly in rapid succession? I have no idea.

Title:75% of spam getting throughServer setup issue? Spam is not blocked

Sorry, to clarify once more: The server time has to be synchronized for the Mollom module to communicate with the Mollom API in the first place. If the server time is not synced with UTC, then the module is not able to operate. That explains why you didn't see Mollom doing anything, because it did not communicate at all. These are two completely separate issues.

re: Firewall: Did you verify that your server is able to make outbound requests to Mollom? E.g., does the module settings page that your API keys were verified to be correct?

re: "csf/lfd": What does that mean?

Can you let me know of some log messages from posts that were not blocked, from your Drupal logs? (you can filter by category "mollom") Since those log messages are larger, it would be best if you'd copy them into a .txt file and attach that here.

I'll edit the comment with the logs later. For now, csf/lfd is the firewall plus login failure daemon. It's a plug in that comes with WHM/Cpanel (which I increasingly hate). Yes, API keys recognized and after UTC sync to the server, mollom is capturing some, I guestimated 25% wheres Drupal 6.x previously it got it all on comment spam, although the captcha in Drupal 6 I'd get bot user registrations. I'll try to capture the hits and misses for a couple of days. To sum, same server, same site, upgrade from D6 to D7 is the variable.

Update: You changed the issue title? Really?

Ok, I changed php.ini to output buffering

output_buffering ON

That seems to dramatically increase mollom's spam detection rate in the logs, maybe 85% now?

Some spam is still getting through and I see this in the logs:

"Comment: unauthorized comment submitted or comment submitted to a closed post"

Which is a catch all error in comment.module, so I don't think it means an actual comment was submitted through a form.

I haven't been able to trace what is causing the "unauthorized comment submitted". The comments are closed in these nodes and there is no comment form there, i.e. closed comments on content type looks correct. That is the most common dblog entry when mollom doesn't catch the spam coming in.

==============
the mollom settings are "strict" check subject, body, no profanity.

Status:Active» Postponed (maintainer needs more info)

Hm. The details you describe sound like a fairly custom setup, and I'm not sure whether I'll be able to help with that.

The client-side Mollom module functionality is covered by automated unit tests.

That said, could you try whether the latest 2.x-dev development snapshot improves the situation on your site?

Issue summary:View changes
Status:Postponed (maintainer needs more info)» Closed (cannot reproduce)