Could you add some Rules conditions to check if deleted comment has been deleted because of spam (reported by admin of by Mollom automatically). I want to create rule to block user accounts which comment was marked as spam.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pverrier’s picture

Version: 7.x-2.3 » 6.x-2.x-dev
Status: Active » Needs review
FileSize
61.12 KB
2.32 KB

I have exactly this need (using D6) : I want spammers IP being automatically banned when mollom classifies a content (comment) as spam. I added an event "Mollom: Content is classified as spam by Mollom" and with rules I manually set a rule to banish user IP when this occurs (see screenshot).

Note that in this version the event is sent only if the comment is set to be automatically deleted (mollom configuration for the comment form) ; it doesn't deal with manual moderation.

Attached the patch with my changes for D6 dev version. May be a start for D7 port.

Status: Needs review » Needs work

The last submitted patch, mollom-rules_support-1893918-1.patch, failed testing.

pverrier’s picture

FileSize
49.05 KB
40.58 KB
26.57 KB
21.16 KB
30.13 KB
38.5 KB

My (D6) website has been running with the "rules support patch" (I joined above) for about 3 weeks and 144 spamming IPs have been automatically banned (about 7 per day!).
But there's sometimes a problem, some bots send two different spams at the same moment, and as a result I get duplicate records in the access rules table (same IP is recorded twice). And this morning, for the first time, I even got three spams at once from the same bot, and three banishment rules with the same IP added! Below the different steps I followed to eliminate this problem, in vain.

PHP snippet

I added a condition for the banishment rule in order to verify the IP isn't already banned.
I wrote this php snippet in a custom module:

function acd_glue_snippet__is_current_ip_already_banned() {
  $ip = ip_address();
  $banned = drupal_is_denied('host',$ip);
  // watchdog for debug
  $msg = 'IP '.$ip.' is';
  if (!$banned) $msg.= '\'nt ';
  $msg .= ' already banned';
  watchdog('acd_glue',$msg);
  return $banned;
}

Boolean condition for the rule

Then I added a boolean condition calling this snippet, to be sure the IP is not already banned:
Edition of the boolean condition
(FYI language of my website is french)

Resulting rule

Resulting rule

Case 1: working well

My snippet detects the IP is already banned: good!
Working well with 2 spams sent almost simultaneously

Case 2: doesn't work

2 spams sent almost simultaneously, the banishment rule is still executed twice
2 spams sent almost simultaneously, the banishment rule is still executed twice

Case 3: doesn't work

This morning 3 spams sent almost simultaneously, the banishment rule is executed three times
3 spams sent almost simultaneously, the banishment rule is executed three times

Conclusion

When a spambot sends multiple spams at once, the rules handling of IP banishments sometimes implies multiple records of the same IP in the user access table, and the only way to avoid this would be to modify the (core) user module (?). Checking with a boolean rule that the IP is'nt already banned isn't reliable, I can't explain why, but the actual sequencing of the actions isn't what I expected...

I wonder if using the rules module for this need is not like using a sledge-hammer to crack a nut... My website has already about 70 modules, and I'd like to avoid adding rules just for that.

The other question is in which case the banishing should be done: for the comments mollom configuration form we have two choices under "When text analysis identifies spam:" : "Retain the post for manual moderation" OR "Discard the post" ; the patch I submitted in #1 sends the rule event only if the post is automatically deleted (manual moderation implies another kind of management, it is'nt my need).

Considering all this, I suggest adding a third option "Discard the post and banish spammer IP address", managed directly in the module, not using rules. Results (and patch) to follow (waiting for spams ;)).

Here's how the configuration form will look like (in french):
Added option in the configuration form

pverrier’s picture

Here are the results, for the last 4 days, with a direct ban instead of triggering a rule.
First of all, I emptied my access table (307 IPs), to have an idea of the interest of this banishing: over the 19 banished IPs (about 5 per day), 9 were previously met (about half of them!): this confirms the interest of bahishing the spammer IPs...

In the logs I noticed again, two times (over 19), the double recording of the same IP (spammer sending almost simultaneously 2 spams). Note that I did not check (in the code) if the IP was already banned before calling the banishing action (a priori, if it's already banned, it cannot send anything...).
Two spams sent simultaneously, case 1
Two spams sent simultaneously, case 2
As you can see this test seems necessary (but it wasn't efficient with the rules version (see PHPsnippet in #3)...
I don't see what I can do more to avoid these duplicate records. Perhaps it's harmless and not so important, but I don't like this.
Even setting a "unique" condition for mask+type+status in the access table is not possible:

ALTER TABLE `access` ADD UNIQUE (`mask`,`type`,`status`);
#1071 - Specified key was too long; max key length is 1000 bytes

I join a patch (over 6.x-2.x-dev) with my last and final version, I don't think I could do more. I think it's better than the above rules version, because it's simpler and doesn't need the rules module.

pverrier’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, mollom-option_discard_and_banish-1893918-4.patch, failed testing.

pverrier’s picture

Status: Needs work » Needs review
FileSize
13.91 KB

After 10 days I can confirm my patch #4 works as expected, even if some spams are sent simultaneously.
Since I set it up, this has occured 5 times, and it behaved well, banning the IP only once:
IP only banned once!

So, for me, it's a better solution than using rules.