Contact form: flag as 'abuse' link not added to the end of email

Thanks for the bug report, Richard. While the site-wide contact form seemed to work, there was a problem with the 'per-user contact form' that prevented the 'Report as inappropriate' link from being added to e-mail sent through the per-user contact form. I've just fixed that bug so I'm marking this 'fixed'.

Re-opening: with the 1.1 release, we're still getting many emails sent through the contact form with no link at the bottom. My guess is because the response from the Mollom web service is coming back as empty, so the if statement resolves as false.

I am unable to reproduce this condition. Could you maybe try to reproduce it on your site and print some extra debug information:

- print the $data when entering the mollom_protect_form_analysis function
- print $result right after the checkContent call in mollom_protect_form_analysis
- print $result after loading them from the globals in mollom_mail_alter

This debug information should allow us to analyze the problem.

In mollom_mail_alter I put in the following at the very end of the function:

$body .= "Debugging info:\n" . print_r($response, TRUE);

In emails sent by me as an anonymous user, I get an array with a hash, and the link appears. Tried the same with an authenticated user, got the same thing. Both roles do not have the "post with no checking" permission. Just now, though, an automated (spam) email came through, and it only shows "Debugging info:" at the bottom with no data.

The question is if the connection to Mollom failed, or if the passing of mollom_response via the globals fails. With the above test we can't be sure what goes wrong. Could you mail me one of the spam messages you received without link so I can go dig in our logs to see if we ever checked the content: ben&mollom.com.

You could also try to add a dummy field to mollom_response in the mollom_protect_form_analysis function. If this field disappears in the emails, it's a problem with the globals, otherwise it's a mollom server issue.

In the function mollom_protect_form_analysis of the Mollom 5 module, can you try changing the lines:

to:

(This inserts a new line in the middle. It would be somewhat surprising if that worked though -- it would mean that global variables store a reference to variables with a local scope -- instead of allocating the value to the global address space.)

I can also report that with Mollom 5.x-1.1 I'm getting spam contact form submissions with no 'Report as inappropriate' link. However, I always get the link when I send messages as an anonymous user myself.

An example spam that got through was recorded in the Watchdog as 'Unsure' by Mollom and then immediately after that there is a watchdog record from mail that says the spammer has sent me an email [with no rebort abuse link]. A moment later I received an email (with very obvious automatic spam content) as described in the watchdog. Does this suggest that the spamming device was confronted with the CAPTCHA and managed to solve it? I will forward this example to Ben.

I can confirm this issue.
Although on our site there even is no ham/spam/unsure-record in the watchdog for this spam post.

I can not reproduce the issue; but every other day a spampost without 'report as inappropriate' line added to the post seems to get past Mollom.

At this writing, DRUPAL-5 has the line that Dries suggests, and spam is still getting through the contact form without a link at the bottom. Looking at the watchdog log (which gets set on line 750) for the spam that just got through, it got flagged as "Unsure":

Apr 21 15:58:06 localhost drupal: http://www.urbanvancouver.com|1208818686|mollom|0|*** IP Address available upon request ***|http://www.urbanvancouver.com/contact|http://www.urbanvancouver.com/contact||Unsure: *** text of spam here, also available on request ***

There is no log message for CAPTCHA, neither "Incorrect" or "Correct", even though CAPTCHA attempts are logged in this version.

I'm busy writing tests to reproduce this problem but it is non-trivial.

Can you disable page caching for a while and see if that makes any difference?

Disabling the page cache (through Administer » Site configuration » Performance) yesterday afternoon seems to have had no effect. We still got spam that passed through the contact form this morning, marked as "Unsure" by Mollom, with no CAPTCHA (neither Correct nor Incorrect) in the watchdog log.

Still getting junk emails through to email with no 'flag as abuse' link at the bottom with 5.x-1.2. Also, there's still no indication that the module or the web server even contacts the Mollom web service, since the $response variable appears to be empty in the mollom_mail_alter() function.

Unfortunately, I can't reproduce the problem. However, I've just committed some changes to the DRUPAL-5 branch. These changes won't solve the problem, but will print out some additional watchdog information that might help us identify the problem. If you could upgrade to the HEAD of DRUPAL-5, that would be great ...

After you upgraded, and when the problem happens again, please check your watchdog for error messages. Thanks.

I've just created a new release of the Mollom module for both Drupal 5 and Drupal 6. I'm not sure this bug is fixed (I can't reproduce it) but I recommend that you upgrade as we fixed some other glitches. If you upgrade, please let me know whether or not this problem persist. Also, the new release includes some additional logging as discussed in #14. This might help us identify the problem.

Richard: does that mean the problem persists?

I'm currently running 5.x-1.3 and I encounter the same problem. I get several spam messages each day without mollom link at the end of the email. I guess this problem can only be found while monitoring a production website because reproducing seems to be impossible.

Some info:
Watchdog: there is no ham/spam/unsure-record in the watchdog, while I do see the 'mail' record.
A random IP address of the spammer: 72.55.160.180
The spam emails started to come in at the 5th of April. I use Mollom since the 13th of March, which is the same day this website was ported to Drupal.
The spam messages mostly have 'hello' as subject

Some more info related to the previous comment:

I did find watchdog entries from mollom with 'Unsure: ...' as message, from similar spam messages.
It's typically 4 in a row, all the same (IP, subject, message), within the same minute.

I hope this can help.

Dries, yes, it persists in 1.3.

Is it possible to log attempted but failed connections to the Mollom server? My impression is that it's either one of two things: the Mollom server doesn't return any data, or it's not connecting to it at all for a certain (unknown to me) reason.

toemaz: is 4 the number of times you have set in the Contact module settings before it disallows submissions?

@Richard Eriksson

The spam I'm reporting comes from the side wide contact form (/contact). The submission limit is not set on 4, but much higher.

If possible, please sprinkle your code with some debug code to see if you can help debug this. I'm still unable to reproduce this on my system. :/

running. mollom 5.x-1.1

i can confirm this still exists on some of my private sites.
I'm receiving some spam submissions a day both through the site-wide contact form, and through personal contact forms.
But they don't have the 'flag as abuse' link at the bottom

I will add some debugging to the watchdog, to try to aggregate some more info.
Are there any special location where i should check?

Below an example of such a submission

I've upgraded to version 5.x-1.3

I've tried submitting the same message on the contact form as anonymous user and mollom presents me the captcha.
I filled in the captcha and mollom has blocked the submission, according to the watchdog. So no email was send out.

Btw. This test was the first event that was ever logged to the watchdog. Could this be due to the upgrade to 1.3

As a second test i've submitted a ham message to the contact form.
No Captcha was needed, email was send out, and .. It now has the report link..

The problem seems to be resolved. I will follow up

It was too soon to announce this bug to be fixed in 1.3

I just received another spam through the contact form, which does not have the "Report as inappropriate"-link.
I will add extra debugging info to check what is happening.

In mollom_mail_alter() I put a line to directly mail me the contents of $response after it gets populated by $GLOBALS['mollom_response']. It's empty, suggesting that there are some cases where the Mollom server doesn't get contacted. How can we test for the Mollom server not even being attempted to get contacted? The fallback is supposed take care of that, isn't it? Otherwise, is it possible the Mollom server isn't responding with anything? Shouldn't the server gets contacted no matter what if the form is protected, correct?

I'm guessing that mollom_protect_form_analysis() populates the global variable for the module to process, but the response it's getting is empty? I just sent the contents of $data that is supposed to go to Mollom for analysis (he may need to check his spam folder as it contains words that will likely set off a filter).

Hmm

Just checked the last entry for me

Watchdog says:

But - the mail when it arrives

Rest of mail removed - we don't really need a set of porn links here :)

However - NO link to report to mollom.

The strange thing for me was that I _did_ get links for 5.x-1.0 - but not 1.1 thru 1.3 (however, if it's a bug that doesn't always show up then this may be just my perception).

I have successfully reproduced this.

I don't know why, but this message text successfully gets through with no sign that mollom is even contacted, at least successfully:

On http://www.angrydonuts.com/contact -- I was able to send this message to myself twice in a row. I'm actually posting the message in because I think it actually is relevant; sending normal messages got a normal response, so I think it has something to do with the actual text.

I'm currently getting a slew of them on one site and they are all weird looking like:

No option to report on any of them.

Michelle

I tracked down this problem to:

Now the real question is why 'op' is not present just on contact form. This is where I got lost.
Patch adds another watchdog which logs such events.

Attachment	Size
mollomContactForm.patch	579 bytes

Thanks for the patch Rok. It would be great if some folks could give Rok's patch a try.

I've committed the following small change to the Drupal 5 version of the Mollom module:

I don't know if it will make a difference but given Rok's analysis, it might. If you want to help test, please upgrade to the development snapshot of the Drupal 5 module or manually apply the suggested change.

I applied Rok's patch.
The spam-messages that just got through Mollom triggered indeed the "Mollom did not receive $form with 'op' present." message.

Just applied Dries's patch too (and some extra debugging statements to help out later).
We generally get several spam messages passing through every day, so in about 24h we will know if this is a solution.

The proposed patch from #32 did not solve it.
I have added some extra watchdog-entries in order to understand what's happening:

And this is the watchdog

It looks like this kind of spam is increasing fast: 25 of these spammessages got through Mollom in the last 6 hours.

[edit: added the access log]
And the access logs:
(we are using Lighttpd)

Change to _POST works for me and contact form is protected by Mollom now. I tried sending out so popular a/url/link spam email and it got stopped.

Spam keeps on flooding in (about 1 every 10 minutes), which makes it much easier to debug this :-)

I added some extra code to make debugging easier:

The log (containing 1 of the spams that got through) can be found in the attachment.

Attachment	Size
mollom_log.log_.txt	19.38 KB

This is a weird problem I am still seeing "Mollom did not receive $form with 'op' present." watchdogs though I also see that Mollom does in fact work on contact form if I try it and some non-spam emails got through with "Report as inappropriate" footer. I'll add more watchdogs and see what they show.

@Jo, it look like $form['op'] and $_POST['op'] are set initially, but then when the user/bot tries to resubmit the form (with an empty CAPTCHA solution), both $form['op'] and $_POST['op'] got unset.

@Rok, does that mean to problem is fixed? It's not clear what you are trying to say other than "this is a weird bug". ;-)

@Jo, Rok: try changing isset($_POST['op']) to isset($_POST) please ... thanks.

@Dries: Yes, that's right. I managed to repeat what the spambot does by renaming the 'op' in the form to something else:
(in this case 'FLOPop')

This is what my debugging shows:

The result is no "Report as inappropriate" link

I'll change the code as requested; that's indeed probably a solution.

Looks like #38 is the solution:

2 spammessages (that would have passed before) show up in the watchdog and debugging-file, but are stopped my Mollom now: Mollom is 'unsure', asks for the captcha; and after the bot tries to pass the captcha test (by unsetting 'op'), mollom is 'unsure' again and asks for the captcha again.
That looks like the correct behaviour to me.

I also repeated my test (see #39) and this time the mail I receive has the 'report as inappropriate' link.

Waiting a few more hours before I dare to claim that this is solved, but it looks very promising...

The patch Dries submitted did not solve the issue, I keep getting these kinds of emails.

Copypaste from drupal_prepare_form.

Edit: $form_submitted is set when there was an 'op'. The other piece is when there is no op but there is only one button. We know there was a form submitted because we are fired from validate. Drupal 6 has this nicely centralized.

Edit2: http://drupal.org/node/58059 but it's more spammers than IE which is the problem here. Contact form is often enabled for anon so there is token protection too.

Attachment	Size
mollom.patch	1.7 KB

#42 seems to be the solution we havent received a single spam mail for about 4h. And there are no watchdogs that would indicate contact form submissions are going around Mollom.

I'll give #42 a try but I'm surprised that #38 isn't working. I don't know what $form_button_counter is but I wonder if it works for _all_ forms -- including forms with multiple buttons, CCK forms, etc.

(I only have SimpleTests for Drupal 6 and this patch affects the Drupal 5 version of Mollom. I'll have to do manual testing, I guess.)

#42 suggests that we need to clean up the form API a bit. It's somewhat ugly to use the internal/global variables. Maybe for Drupal 7, we should try to create an API function for this or something ...

@Gabor: did you tried #38 too?

Dries, this code is from form.inc

With copying this check over to Mollom we make sure that Mollom fires every time drupal_submit_form does. It's a trick yes but it's the same trick form API does :)

I committed an alternative fix to the DRUPAL-5 branch. I think it will put this issue to bed once and for all. If possible upgrade to the HEAD of DRUPAL-5 and let me know if it worked. If so, I'll roll a new release of the module.

It looks like the spammers have discovered that we have closed the hole: I didn't receive any spam-attempts since over 3 days. (I had to add extra debugging to believe it)

2 days ago Mollom has been upgraded to D5-HEAD on our site and I have tested it with my previous tests (including unsetting 'op'). All tests were successful.

I would call this issue fixed, although I would feel more comfortable if a few spam-attempts 'from the wild' were stopped by Mollom.

@Jo, thanks for the update. I'll wait 1 or 2 more days to make a release. Hopefully you and a couple of other people can declare victory/failure by then. ;-)

Let's call it a victory :-)

14 pages of blocked spam show up in my log entries for the last 48h.
I'm not sure they tried the old trick with the unset 'op', but since this issue has been tackled 5 days ago, no spam passed the filter; and the one that did pass the filter contained a 'Report as inappropriate'-link.

I'm making a new release, and I'm marking this fixed. Thanks all.

Automatically closed -- issue fixed for two weeks with no activity.