Am being totally blocked by Mollom on GDO

We don't have any control over it, but we can work with the mollom folks to get feedback on why it's happening.

Unfortunately, I looked at the log files as far back as we have them and didn't see a message about you.

Can you keep trying and post a message here immediately after you get blocked by mollom?

We just got another report from MkeHack so I'll combine the details here. The first problem occurred at 12:37 while attempting to create an event that referenced moshe and had little additional content: 100114102ee0430320

12:50 Session: 100114cc34e4bcacb2
12:52 Session: 100114a97d574af30b
13:05 Session: 100114f3d588749260
13:10 Session: 1001142b27198fc11d

I'd like to get one or two more reports and then we'll try to get some insight from Mollom.

RegLogge - my second comment was about a different user who reported the same problem. If you could try posting your content on groups today and if it fails immediately report the problem here then we will be more likely to be able to help.

Got it - Session: 100114b76294f34351

Pinging Dries now.

Hi,

I am experiencing the same issue: Can't post any content (tried discussion, event, comment), contact form isn't working too...
For example http://groups.drupal.org/comment/reply/44566 a minute ago.

cheers,
chris

The original problem for criz was Session: 1001146795c65af757

There have been several messages blocked since, but they were all very short and talked about being blocked already.

We're looking into this.

New one - Session: 10011894f087dd3ea9 by BartVB. #687990: Can't post a reply, post rejected by Mollom

Another one with KVantomme - Session: 1001186b1a895f8d45

#687984: spam overkill

As greggles said in #11: I tried to post something like:

"xtrabackup has been created by Percona as an opensource alternative for mysqlhotcopy, I'm currently doing some research and am planning to implement this to do online backups (on my slave server).

More information can be found here:

http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup_manual"

in http://groups.drupal.org/node/40944

Tried it again and it's still failing. This is a pretty annoying spam filter :+

Subscribe and mentioning "Your submission has triggered the spam filter and will not be accepted." to make it easier for other users to find this issue.

For Sirkitree the session ID was: 10011923df6ccf8d20

Also marked #689312: g.d.o reputation as a duplicate.

The bug has been hunted down. Users were not blocked based on the text classification, but due to a poor reputation of their IP. It was a problem with an integer overflow of timestamp arithmetic in the Mollom backend: reputations were incorrectly computed leading to people being blocked.

The bug has been fixed, all Mollom servers were updated, and the reputation for GDO users has been reset. Sorry for the inconvenience.

Has indeed been fixed for me. Thanks!

Yeah, it is working for me too now. Thx!

Interesting the problem with the ip. I've just been banned to post from my work at the hospital. I plugged my Iphone to use it to send the form (so with a new ip) and it went ok. Going back to my connection from the hospital triggers the bug again :-(

cannot reply my own post: http://groups.drupal.org/comment/reply/44754

Mollom made me enter a CAPTCHA more than a dozen times today. It's not the first time (Dries and I talked about this after a meetup last month in Boston) and now my account is blocked as well. This doesn't seem to be related to my IP since all the exit points provided by my VPN appear to be blocked.

I now have no way to get any work done in the groups I manage. As I've said before, I'm fed up with Mollom. Even a good community can be broken by bad technology.

christefano, not sure what is going no with your account. We'll look into it once more.

Thanks, Dries! Similar to reglogge's experience, something seems to have freed up my account. I'm being given a CAPTCHA every time but I can finally post again now.

christefano, we just reset your reputation (minutes ago) and we have tweaked our algorithms to avoid this problem from happening. Let's see if this is better. Please keep us posted on your experience. We're committed to get this right, and we'll continue to improve our backend until it works.

Thanks, Dries. I really appreciate it.

Let's see if this is better. Please keep us posted on your experience.

Sounds like a plan. I'll keep you posted.

Since this seems to be where to log this kind of thing, there was a similar report over at http://groups.drupal.org/node/48818#comment-126603.

g.d.o / Mollom seems to be working fine here, other than the minor annoyance that I get prompted with a captcha pretty much every time I post/edit something. But that's been normal since it was rolled out. I guess I am spammy. ;)

I post quite a bit less frequently than webchick and I'm also getting a captcha on virtually every wiki post/edit. Also get a captcha on wiki previews?

If you get a captcha that is annoying, but largely unavoidable. If real useres permanently blocked (i.e. without captcha) then I consider that a bug.

> If you get a captcha that is annoying

*very* annoying. Every time I edit a wiki page with lots of links, I need to wait for the response, and then try to answer the captcha. In these cases (adding to a page that will be considered spam anyway) - I prefer to respond to the captcha on the first form, and not wait for the first submission to fail. This is really bothering 99% of the legitimate users for the 1% spammers.

I think that for logged in users to be presented with a captcha is a no-no.

The way mollom is used on g.d.o is not how you should use such a system.

The only excuse for this is that a comment or node on g.d.o gets mailed out to potentially hundreds of people. Thus, if allow spammers to do whatever they want we'd fall risk of being accused of spamming ourselves.

HOWEVER, there aren't actually that many spammers active on g..o and those who are, are sure able to solve a captcha because they are human. So I think that the annoying qualities of mollom (or any similar system) are far higher than the protective ones (in this case).

To get rid of the "we might be considered as spammers" argument, we should put mollom (or something similar) not on the UI but on the mail backend, before a mail is actually sent. This would limit mollom to "send" or "not send", the "show captcha" part would not be possible, but I think we can live with this (again considering that there aren't that many spammers active).

Now we need volunteers to implement something like I outlined above.

The main problem (in most cases) is not Mollom harassing logged in users but the amount of false positives that Mollom generates. In your proposal these false positives would (invisibly) prevent Drupal from sending updates to subscribers which would degrade the end user experience. Users rely on getting email updates for issues, Mollom would break that expectation.

I live in Europe, but over here a site like d.o would not be responsible for spamming if someone abused the system to send out spam to email recipients?

Currently I manage a community with 150k users and 40k new user submissions/day, here we only have a simple captcha on registration. The spammers that get through that (a few per week in my case) get banned almost immediately by my team. This way real users are never hampered by an anti-spam system, it requires almost no effort my the team and there are no false positives.

Mollom is a good system for being a front gate for anonymous submissions, I don't quite understand why it's used to annoy regular community members like it currently does especially if you say that there aren't that many spammers on the drupal sites. (Robot) spammers should be taken care of at the entrance, not with every user submissions. Currently it kind of feels like the *.d.o users are all guinea pigs for mollom.com where we feed the filters that the Mollom system needs. I hope that *.d.o isn't necessary for that purpose anymore.

I agree that fixing mollom would be the best thing. But since it is a black box system this is out of my hands.

Yes, putting a spam filter after comment submission would probably have some false positives too. Can't be helped, but I think this is more acceptable than annoying a largish part of g.d.o's userbase. Affected would only be the mails sent by users who were now totally blocked. These weren't too many.

I also live in Europe, and while we might not be legally responsible for any such spam this would not help if some overzealous admin (or user!) puts us on e.g spamcop.net.

I totally share your sentiments wrt being guinea pigs for mollom. That's why it is not installed on d.o. Mollom is also (part of) the reason why I don't use g.d.o that much. I hate being presented with an almost illegible captcha for no good reason.

"That's why it is not installed on d.o."

So if I understand this correctly this is not a technical or timesaving (reduce spam cleanup) thing but a political thing?

In that case; Wouldn't it be possible for Mollom.com to modify the system (or sponsor someone to modify the system) so that submissions are sent to mollom.com including some basic user stats (time registered, number of posts) so that they can use this data to increase their corpus without g.d.o acting on the decision that the Mollom system makes?

And and even better question; does Mollom still need g.d.o? It seems like they are filtering quite a bit of content from other sources already. I have no clue about the history of all this but I get the feeling that g.d.o has been used to bootstrap the Mollom system. If that's the case then my guess is that Mollom can just be removed from judging submissions by logged in users?

Who decides things like this? Dries? The infrastructure team?

It's not political, really.

I think it is not useful to run it on drupal.org: the spammers that we get are mostly human and could fill out a captcha. Also, there is a quite high rate of false positives (I subsume the events when a legitimate user needs to fill out a captcha as false positive).

The burden that mollom would put on the webmasters of d.o is likely higher than the few spammers that we do get. I think this is also the case on g.d.o, but apparently people disagree.

The only place where I potentially would put a captcha based solution is on the registration form, but again, I think there is not much gain from this.

g.d.o has its own maintainers (greggles and joshk) who decide what code runs there and how it is configured.

I have had too problems with Mollom on g.d.o; all times I was replying to the synchronization requests, and reported that account <link_to_gdo_account> has been synchronized with <link_to_do_account>, Mollom presented me the CAPTCHA. In my case, the solution is probably easier (as Mollom has a permission that allows a role to never fill out a CAPTCHA), but that is not so for authenticated users because selecting the same permissions for the authenticated users would mean to avoid the CAPTCHA is presented at all (there is a solution to this, and it doesn't require any changes to mollom.module).

I understand that Mollom is a closed system that cannot be changed, but it is also true that mollom.module is a normal Drupal module for which it is possible to create feature requests that would be useful not only to g.d.o, but to every Drupal site using Mollom.
Just to make two examples:

• It would be useful if the module would allow to have a local settings to decide the reputation of a user. As far as I understand, the reputation is defined centrally, and it is defined basing on the reports done from every sites using Mollom; there is no way to control it locally for a single site (which would of course mean that the reputation would not influence the global reputation). In some situations, I can understand that a site administrator could need to overwrite the global reputation for a user in his own site, especially to avoid that a user that is well known on that site community for not being a spammer (in example, I think we trust killes, and we don't consider him a spammer).
  This would help, but would also require to manually set the reputation of each single users; still, it would be a step forward to the actual situation, where the reputation can just be changed centrally.
• The module could allow to have an option that allows to set for which users the CAPTCHA should not be presented. This means that users would see a CAPTCHA, and when they complaining about seeing a CAPTCHA too much times, somebody would add the user to that list.

A solution that would not require any change to mollom.module, and that works in particular for drupal.org where the accounts on the subdomains are linked to the accounts created on the master domain, is to create a role that has the same permission of an authenticated user, but with also the permission to avoid the CAPTCHAs. Also in this case, there would be the need for somebody to change the settings (in this case, to assing a role to users), but it's clear that it's required somebody else that values the reputation of an user, and acts in consequence of his/her valuation.
Probably, it would be possible to create a custom module that after X posts made from the user, it assigns automatically the role to the user.

I don't think hijacking this issue for mollom feature requests is a good idea. It won't be tracked down by mollom maintainers here. The OP issue was sort of fixed, but the annoyance remains.

The maintainers of g.d.o. should decide whether they ditch mollom, use standard captcha (which would be less annoying), or not use any form of CAPTCHA at all.

Are there any bots registered to d.o.? if no, mollom is doing nothing but annoy; if yes, and mollom blocks them on page submissions, why not block them at registration time?

I don't think hijacking this issue for mollom feature requests is a good idea.

I am not hijacking this report. I just pointed out that Mollom is a closed system that cannot be changed, but it is not automatically true for mollom.module.

use standard captcha (which would be less annoying)

So far, I had to fill a CAPTCHA few times, while with another module implementing CAPTCHAs I would had filled a CATCHA all time I posted a comment.

Are there any bots registered to d.o.? if no, mollom is doing nothing but annoy; if yes, and mollom blocks them on page submissions, why not block them at registration time?

You forgot it is still possible that a human registers an account that will be used from a bot to spam on Drupal.org. In fact, it is not possible to create an account on Drupal.org without to follow a link reported in an email sent from Drupal.org.
Then, there is the evidence that some recently created spam posts were created using bots.

> I am not hijacking this report.

Sorry, I didn't mean to offend. just to node that mollom.module maintainer might not be tracking this issue.

> So far, I had to fill a CAPTCHA few times

Editing a wiki page results in captcha every time (based on the pre-existing content of that page). I was referring to this case

> You forgot it is still possible that a human registers an account that will be used from a bot to spam on Drupal.org.

Those get blocked pretty quickly after the first try. Is this really a problem?

> I am not hijacking this report.

Sorry, I didn't mean to offend. just to node that mollom.module maintainer might not be tracking this issue.

No offense has been taken (although, saying hijacking is a little exagerated).
I also know the maintainer of Mollom is probably not tracking this issue, but that was not my point at all. The point is that between using Mollom as it is, and not using it there is a third option.

Those get blocked pretty quickly after the first try. Is this really a problem?

If you tried to delete 200 comments created from some users in few time, then you would know if that is really a problem; if it has been implemented a solution to allow delete 900 comments with few clicks, that doesn't make the problem a minor problem.
I am not sure they are blocked quickly after the first try, nor that they are blocked quickly enough to not allow them to spam so much comments.

See the attached screenshot for why we use mollom.

If we didn't use it, all those giant orange bars would be e-mails to somewhere between dozens and thousands of people. I'm sure OSL would not like us doing that.

I am somewhat in favor of killes idea to use mollom at the point of determining whether or not to send a mail message, but there is no module for that. Someone builds that module we can consider installing it.

Killes claimed that bakery was the source of the recent falloff. I've zoomed the graph so that we see the time period when the major fall-off happened until right now. We can see that spammers stopped their major attempts before bakery was installed and that the spam levels have stayed pretty constant from before to after bakery was installed.

Very interesting, thanks for sharing that.

What is the meaning of a spam in mollom? a failed CAPTCHA? I know I failed the CAPTCHA a few times. The small amount of spam vs. ham looks like innocent misses to me (unless I am wrong about spam definition in those graphs).

Also, does that mean that some human is signing up, then giving the credentials to a bot, who logs in, and tries to post spam? Are there any statistics about which users are sending spam?

We could figure out some of the details using watchdog, though I'm not really excited to do that. It appears from patterns of posts and messages that I've seen that the spam comes from a mix of humans and bots. I'm not sure how they register - whether it's automated or manual.

Mollom just gave me the finger on a comment I tried to make on g.d.o. My solution is to ignore g.d.o as long as this is not fixed.

Will investigate this. Would be great to get some Mollom session IDs from the watchdog.

For Killes most recent one it is Session: 100210b727e0d300a9

We spent some time investigating and made some adjustments to the backend. Gotta say, groups.drupal.org is an interesting case for us. Most sites that we don't protect have different interaction patterns. Sorry for the inconvenience, but we're committed to make this work for groups.drupal.org.

CAPTCHAs have reappeared for me in the past few days but there haven't been any problems submitting them. Thanks for your work, Dries.

From Dries' twitter

Two weeks ago we rolled out backend improvements for @Mollom. Noticed an improvement on your sites since? /via @benschrauwen

We also made some tweaks to the Mollom configuration on groups.drupal.org at about the same time. So...any feedback? Still having problems? Seeing more/fewer captchas?

Yeah, I've noticed it being much better too. In fact it actually started to freak me out because I always counted on the inevitable capctha being a "safety net" so I could look over my post one last time before I posted it. But now I need to be more careful because they go through the first time. :D It's a good problem to have. ;)

There are more reports about this over at http://groups.drupal.org/node/63253#comment-187288 and below.

I am experiencing this as well. Specifically, at http://groups.drupal.org/comment/reply/29208 on 5/12/10 at 4:55 PM EST.

I fixed your account, jerseycheese.

Here are the mollom details for Dries/Ben to look into.

Spam:

Array
(
[post_title] => Sure!
[post_body] => I'm certainly interested in organizing still. I'll make some calls tomorrow and see if Cogan's has wifi. If not, I know Fair Grounds coffeeshop in Ghent has it and has a little side room that we could use.

Still open to venue suggestions, as well! I'll report my findings tomorrow.

Sounds like 8PM is safe for everyone.
[author_name] => jerseycheese
[author_mail] => [removed]
[author_id] => 30868
[author_ip] => [removed]
)

Result:
Array
(
[spam] => 2
[profanity] => 0
[quality] => 0.602
[session_id] => 10051260257bec4f30
)

I don't know where a good place to go for this problem, but I'm having it too. I was trying to add a helpful comment to http://groups.drupal.org/node/63488 and now it seems that I'm banned? I already had commented on this topic and with the group before? I don't know what to do, I wasn't shown a CAPTCHA, just banned.

Hi mplsdan - I went back through the logs and didn't see any reports of you being blocked.

If you could post here right after you get blocked that will help us to research this more.

I just started getting blocked my Mollom today on our local Drupal user group page: http://groups.drupal.org/comment/reply/68993. I am not seeing any Capcha, just blocked. I did have a link to my web site in my signature and read somewhere that it might cause this problem, so I have removed my signature. But I don't know how to get my account unblocked so that I can properly post to my user group now. Can you see if my account is screwed up? Thanks!

The session information for mpotter is

Array
(
[spam] => 2
[profanity] => 0
[quality] => 0.559
[session_id] => 100517f4c8f68a0be9
)

It seems like we're getting more of these. I'll ping Dries.

Thanks for the reply. I just tried to post something again, at 1pm CST, and got the spam message. http://groups.drupal.org/comment/reply/63488

jerseycheese and mpotter should now be able to post again.

Here's the info for mplsdan:

Array
(
[spam] => 2
[profanity] => 0
[quality] => 0.63
[session_id] => 100517ea5f3abbd07f
)

Thanks guys, my post works now.

the 'unexplained blocking' problem seems to be hitting several sites that are using Mollom - if it is in fact a 'central clearinghouse' of some sort that maintains history or reputation or some such on some identifier (username? ip address? dunno but it's been mentioned in some posts) then will the problem happen across sites if my username or login is the same? I'm using this post as an 'experiment' to see whether it's going to block me here as well. Didn't get a captcha or anything on the CiviCRM site, just blocked. Any more information on exactly what's going on?
Howard J

Is this issue being resolved, or just the symptoms being fixed by twiddling individual accounts? Over at the CivCRM blog the problem still happens, and I'm being told basically 'live with it' as the spam problem is too acute to consider messing with mollom at all. I'm not seeing any substantive discussion of exactly what's happening, just that the Mollom Black Box returns a spam value, but we don't have any visibility to what it's doing. Is it logging and tracking IP addresses, for example? Is there an ombudsman I can contact to find out why I'm having the problem, and get some open explanation of what my "reputation" is on the Mollom server? Sure, I can understand that 1) the algorithms are proprietary to a commercial business entity that wants to protect them, and 2) we can't reveal the secret sauce, because then the spammers would know how to defeat it. Hmm I believe that's called security through obscurity. And as far as proprietary goes, that smells a little weird for an open source community, eh? Oh well, I guess it's above my pay grade, as we used to say.
Howard J

Dries et al:

this has come up twice in the last week for us (civicrm.org) so would be great if there was some resolution to this other than having to reset each record individually

can someone from mollom take a look and help fix things

lobo

I talked with lobo in irc and shared our system from groups.drupal.org

For anyone in the future looking for general Mollom support (i.e. for sites other than groups.drupal.org), please use http://mollom.com/support instead of this issue.

+1 with this problem on Drupal Groups. I'm using the login "ostraining".

Had no problems leaving comments here or posting elsewhere.

Here are some details from your interactions:

First post:

Array
(
[spam] => 2
[profanity] => 0
[quality] => 0.811
[session_id] => 100614e033a9acfdd6
)

More recent post:
Array
(
[spam] => 2
[profanity] => 0
[quality] => 0.797
[session_id] => 100614567c6c99b81d
)

After the first post it looks like you tried to post ~5 more times.

I manually fixed your account so you should be good for now.

I found that a legit person wanted to sign up as a user on my site and was continually denied by Mollom.

The ip is for Lawson Software, and Project Honeypot associates its ip with spammer activity.

Is there a way to override Mollom?

Thanks!

This is one of the attemps (truncated) below:
[op] => Create new account
[submit] => Create new account
[form_build_id] => form-393ffe1ee2ef009d8172b20c775e2742
[form_id] => user_register
[mollom] => Array
(
[session_id] => 1277921237-1006309ba92a849b7c
[captcha] => nj6TH
)

As we're getting random support requests on this issue I'm going to lock/close commenting.

People who are having problems with mollom on groups.drupal.org should file an issue at http://drupal.org/node/add/project-issue/groupsdrupalorg

If you have general issues with mollom, go to Mollom.com to investigate support available.

If you have problems with the Drupal module, use the Mollom issue queue on drupal.org.