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'.

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.

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:

$GLOBALS['mollom_response']['spam'] = MOLLOM_ANALYSIS_HAM;
watchdog('mollom', t('Correct CAPTCHA: %message', array('%message' => $data['post_body'])));

to:

$GLOBALS['mollom_response']['spam'] = MOLLOM_ANALYSIS_HAM;
$GLOBALS['mollom_response']['session_id'] = $_POST['session-id'];
watchdog('mollom', t('Correct CAPTCHA: %message', array('%message' => $data['post_body'])));

(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.

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?

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.

@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

Onderwerp: [redactie] hello

carinsurance heeft u een bericht gestuurd via het contactformulier
http://steinerschooldehazelaar.be/contact.

http://carinsurance.all-nintendo-wii.info/index.html carinsurance

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..

mollom test heeft u een bericht gestuurd via het contactformulier
http://steinerschooldehazelaar.be/contact.

mollom is goed probeer het eens

Report as inappropriate: http://steinerschooldehazelaar.be/mollom/contact/45c716d838ecb91b

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.

Hmm

Just checked the last entry for me

Watchdog says:

mail	2008-06-01 11:16	Gartman6 <Dan1oo@narod.ru> sent an ...	Anonymous
mollom	2008-06-01 11:16	Unsure: Extraordinarity: , <a ...	Anonymous

But - the mail when it arrives

Gartman6 sent a message using the contact form at
http://www.chrissearle.org/contact.

Extraordinarity: , <a

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:

http://groups.google.it/group/anne1242/web/giochi-jack-black
[url=http://groups.google.it/group/anne1242/web/giochi-jack-black]giochi
jack black[/url] <a
href=http://groups.google.it/group/anne1242/web/giochi-jack-black>giochi
jack black</a> <a
href=http://groups.google.com/group/brett2963/web/ringtones>ringtones</a>
http://groups.google.com/group/brett2963/web/ringtones
[url=http://groups.google.com/group/brett2963/web/ringtones]ringtones[/url]
[url=http://groups.google.it/group/bethany5772/web/video-slots]video
slots[/url] http://groups.google.it/group/bethany5772/web/video-slots <a
href=http://groups.google.it/group/bethany5772/web/video-slots>video
slots</a> http://groups.google.it/group/bethany5772/web/baccarat-on-line
<a
href=http://groups.google.it/group/bethany5772/web/baccarat-on-line>baccarat
on line</a>
[url=http://groups.google.it/group/bethany5772/web/baccarat-on-line]baccarat
on line[/url] <a
href=http://groups.google.fr/group/isaac2112/web/jeu-poker-gratuitement>jeu
poker gratuitement</a>
[url=http://groups.google.fr/group/isaac2112/web/jeu-poker-gratuitement]jeu
poker gratuitement[/url]
http://groups.google.fr/group/isaac2112/web/jeu-poker-gratuitement 

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:

tjenww sent a message using the contact form at
http://couleeregiononline.com/contact.

Pe6C0U  <a href="http://sievhehagicx.com/">sievhehagicx</a>,
[url=http://kqwebgzuyqmb.com/]kqwebgzuyqmb[/url],
[link=http://ymhtctyzkjoh.com/]ymhtctyzkjoh[/link],
http://kntuasxmpskk.com/

No option to report on any of them.

Michelle

I tracked down this problem to:

  function mollom_validate($form_id, $form_values) {
  // form_values does NOT have 'op' present
  // so when calling
  mollom_protect_form_analysis($form_values, $data);
  }

  // and then in 
  function mollom_protect_form_analysis(&$form, $data) {
    if ($form['op']) {}
  }
  // mollom finishes without doing anything

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.

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:

diff -r1.1.2.17 mollom.module
714c714
<   if ($form['op']) {
---
>   if (isset($_POST['op'])) {

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:

function mollom_protect_form_analysis(&$form, $data) {
  if (isset($_POST['op'])) {
    watchdog('mollom', 'Mollom: _POST-op isset.');
  }
  if ($form['op']) {
    watchdog('mollom', 'Mollom: form-op is TRUE.');
  }
  else {
    watchdog('mollom', 'Mollom: form-op NOT TRUE.');
  }
  if (isset($_POST['op'])) {      // change proposed by Dries (#32)
    $mollom = $_POST['session-id'] ? array('session_id' => $_POST['session-id']) : array();
    // ...
  }
  else {
    watchdog('mollom', 'Mollom did not receive $form with \'op\' present.');
  }

And this is the watchdog

mollom	07/03/2008 - 07:25	Mollom did not receive $form with 'op' present.	Anonymous	
mollom	07/03/2008 - 07:25	Mollom: form-op NOT TRUE.	Anonymous	
mollom	07/03/2008 - 07:25	Unsure: <a href= ...	Anonymous	
mollom	07/03/2008 - 07:25	Mollom: form-op is TRUE.	Anonymous	
mollom	07/03/2008 - 07:25	Mollom: _POST-op isset.	Anonymous	

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)

194.8.75.204 l10n.krimson.be - [03/Jul/2008:05:25:40 +0000] "POST /index.php?q=contact HTTP/1.1" 200 9666 "http://l10n.krimson.be/index.php?q=contact" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
194.8.75.204 l10n.krimson.be - [03/Jul/2008:05:25:42 +0000] "POST /index.php?q=contact HTTP/1.1" 302 0 "http://l10n.krimson.be/index.php?q=contact" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
194.8.75.204 l10n.krimson.be - [03/Jul/2008:05:25:44 +0000] "GET / HTTP/1.1" 200 35214 "http://l10n.krimson.be/index.php?q=contact" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

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:

function mollom_protect_form_analysis(&$form, $data) {
  mollom_debug('in mollom_protect_form_analysis - form:', $form);
  mollom_debug('in mollom_protect_form_analysis - data:', $data);
  mollom_debug('in mollom_protect_form_analysis - post:', $_POST);
  if (isset($_POST['op'])) {
    // existing code
  }
}

// Special function to add extra debugging to mollom
function mollom_debug($texto, $var1){
  file_put_contents(PATH_TO_OUR_SITE.'/files/mollom_log.log',date('d/m/Y H:i:s').' - '.$texto.' - '.var_export($var1, TRUE).'',FILE_APPEND);
  flush();
  return;
}

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

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:

04/07/2008 09:08:15 - in mollom_protect_form_analysis - post: - array (
  'name' => 'test1',
  'mail' => 'test1@jwo.be',
  'subject' => 'subject1',
  'message' => 'message1',
  'FLOPop' => 'Send e-mail',
  'form_id' => 'contact_mail_page',

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.

#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

function drupal_process_form($form_id, &$form) {
  global $form_values, $form_submitted, $user, $form_button_counter;
  static $saved_globals = array();
  // In some scenarios, this function can be called recursively. Pushing any pre-existing
  // $form_values and form submission data lets us start fresh without clobbering work done
  // in earlier recursive calls.
  array_push($saved_globals, array($form_values, $form_submitted, $form_button_counter));

  $form_values = array();
  $form_submitted = FALSE;
  $form_button_counter = array(0, 0);

  drupal_prepare_form($form_id, $form);
  if (($form['#programmed']) || (!empty($_POST) && (($_POST['form_id'] == $form_id)))) {
    drupal_validate_form($form_id, $form); // mollom is fired on validate!
    // IE does not send a button value when there is only one submit button (and no non-submit buttons)
    // and you submit by pressing enter.
    // In that case we accept a submission without button values.
   // Mollom does not fire on programmed forms so we skip that. Otherwise, we use the very same "submitted" check.
    if ((($form['#programmed']) || $form_submitted || (!$form_button_counter[0] && $form_button_counter[1])) && !form_get_errors()) {
      $redirect = drupal_submit_form($form_id, $form);
      if (!$form['#programmed']) {
        drupal_redirect_form($form, $redirect);
      }
    }
  }

  // We've finished calling functions that alter the global values, so we can
  // restore the ones that were there before this function was called.
  list($form_values, $form_submitted, $form_button_counter) = array_pop($saved_globals);
  return $redirect;
}

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.

The D7 code is entirely different to the D5 code.

Created #1365618: Contact form: "Report to Mollom" link not added to e-mail against D7.

Reverting issue status.