Mollom seems to rather regularly flag things that are not spam as spam. (See http://randyfay.com/node/69)

The user gets:

Your submission has triggered the spam filter and will not be accepted.

Could we add to this message something that offers some recourse to the poor user? Contact Mollom? Contact the site owner? Something? This message, when incorrect, is simply rude and annoying.

Files: 
CommentFileSizeAuthor
#62 0001-869782-by-sun-Added-link-to-Mollom-false-positive-re.patch3.97 KBsun
PASSED: [[SimpleTest]]: [MySQL] 4,448 pass(es).
[ View ]
#60 0001-869782-by-sun-Added-link-to-Mollom-false-positive-re.patch3.97 KBsun
FAILED: [[SimpleTest]]: [MySQL] 4,360 pass(es), 196 fail(s), and 134 exception(s).
[ View ]
#58 2013-04-02_14h09_56.png5.54 KBsun
#58 mollom.false-positive-report.58.patch3.87 KBsun
PASSED: [[SimpleTest]]: [MySQL] 5,029 pass(es).
[ View ]
#32 rfay_dell_Selection_119.png104.87 KBrfay
#32 rfay_dell_Selection_118.png155.33 KBrfay

Comments

A related suggestion: http://randyfay.com/node/69#comment-123

Here's an idea for Dries: When your post gets rejected, provide a little link that says "Really, i'm not spam, honest!" that takes you to a form on mollom.com to report the issue (validate this form with recaptcha?) This way mollom can investigate false-positives reported directly from end-users.

Thanks for reporting this, Randy. You can be sure that this is a top priority for Mollom. Some feature enhancements closely related to this suggestion are actively discussed and developed currently.

However, please understand that this is quite a complex problem space, as spammers can (and will) eventually abuse any possibility that allows end-users to report an invalid filter decision. The issue would likely get worse if end-users were able to report and take additional steps, but the data that Mollom gets wouldn't be usable due to abuse, so it reasonably couldn't do anything about it, and thus, end-users would be annoyed even more, because they "even did the additional steps, but still nothing changed."

I'm still trying wrap my head around the whole scenario, brainstorming ideas that may lead to less abuse. It's possible that I'll use this very issue to implement the improvement we come up with though.

Thanks, @sun.

Just a note, others have chimed in saying that they avoid commenting on sites that run mollom.

I do suspect that just making a way to either moderate or report false positives would resolve the annoyance factor here.

Isn't entering the captcha enough? I've been getting this message frequently on mollom enabled sites.

I've just recently found out that if I don't enter my homepage then the comment goes through? My homepage domain isn't live due to maintenance. Is that why or is my domain flagged or something? My last attempt was at 2bits - http://2bits.com/drupal-performance/reducing-size-and-io-load-apaches-we.... Where I used this info:

Your name: Dale Dude
E-mail: me@gmail.com (fake name, real provider)
Homepage: http://www.daledude.com
Subject left blank
Comment: Turn BufferedLogs on as well.

The more I think about this it isn't a "feature request" but rather a "critical bug". Many others have responded as I have in http://randyfay.com/node/69 saying that they just don't bother commenting on a site that has mollom running any more.

Subscribing. This happened to a user on my mollom-enabled site today as well, this is how I came across this thread.

Is it safe to post the Mollom session-id here -- if that can help to track down the problem.

Category:feature» task
Priority:Normal» Major

FYI: As a first measure, I'm working on #881534: Allow to unpublish spam posts instead of rejecting, which is close to RTBC already. Any feedback would be appreciated.

As mentioned earlier, any front-end improvements need more brainstorming and careful in-depth discussion, from which not all details can be publicly posted here.

I think a great fix would be a feature to disable mollom's refusal of a form that passed the captcha. I once tried typing a comment with mention of viagra into my site, and after passing the captcha mollom blocked me and it became impossible for me to post anything (apparently my IP was blocked). I had to reconnect to change my IP before being able to post on my site again.

Considering that a simple CAPTCHA gets rid of about 99.9% of spam on my site (mollom gets rid of 100% plus half of my legitimate posts), it really begs the question whether mollom's nazi filtering is the right way to go...

Got this msg day when submitting "Would you be open to help from India based team of Drupal experts?" http://groups.drupal.org/user/169053/contact while following posting guidelines http://drupal.org/node/308792

It would be nice, at the very least, to make the message that's displayed be configurable, with support for tokens. Support for rules would also be nice so that we could build our own custom workflows when content is flagged as spam.

I am still getting this error message on my site. Surprised that it hasn't been resolved for such a long time!
Where can I find the Session ID of my Mollom? I only see Public and Private keys.

What ever happened to the text analysis and CAPTCHA! Why was this removed. I think it was a great fall back that would eliminate this issue here. If the text analysis fails then the user is presented with a CAPTCHA.

@Jason Sale: That should already be the case -- if Mollom is unsure and presents a CAPTCHA, and the user solves that CAPTCHA, then the user should be able to post, regardless of how spammy the post may be.

@Vako: As of now, you can find the session ID for particular post attempts in Drupal's log messages (admin/reports/dblog), which you can filter by category "mollom".

@Funke-Tom: The functionality/behavior still exists and won't be removed. It is automatically applied to all forms protected via text analysis. However, not all forms support text analysis, so some forms can be protected with a CAPTCHA only.

My experience as a user, @sun, is still this: If you put a link in a form on a site protected by mollom, you will be summarily excluded. So 1) I don't use mollom on any site I have anything to do with because of the extremely negative impact on visitors and 2) If I place a comment on a site that has mollom on it, I just don't put a link in.

Mollom boasts about how many spams it's blocked, but still has never dealt with or built a way to deal with false positives, which means it has no idea how many spams it has blocked, just how many posts it has blocked. Mollom thinks "If I block it, it must be spam". Which I think is a problem :-)

It would be great if Mollom's reaction could be modified and people who have just posted a thorough response to an article and get the "your response has triggered the spam filter" could have a way to either report it to the site or report it to mollom, so mollom could at least get some kind of handle on these false positives. Since I can personally get about 80% false positive just by including a link on a mollom-protected site, I think it could be a good exercise.

When I goto admin/reports/dblog, I see the following list of options:

* Broken links
* Mollom statistics
* Public Download Count
* Recent hits
* Search engine referers
* Security review
* Statistics Pro
* Top referrers
* Top search phrases
* Top pages
* Top visitors
* Access log settings
* Browscap
* SWF Tools status
* Available updates
* Getclicky Stats Dashboard
* Status report
* Graphs

I tried all of the above, still couldn't find any Session ID...:(

One of my clients got a wave of registrations and lots of them couldn't register because of Mollom - now she has a really bad impression of it, and I'm probably going to have to swap it out for Akismet + Antispam or something similar.

I also have the impression that the latest official release for Drupal 6 is unusable owing to constant false positives. Not sure whether Mollom is faulty or the module.

Title:Explain what a user should do if "Your submission has triggered the spam filter and will not be accepted."Appeal!: Explain what a user should do if "Your submission has triggered the spam filter and will not be accepted."
Category:task» feature

After all this time, a false positive (not uncommon at all) still is non-negotiable with Mollom, preventing valuable feedback for site owners and community members, and frustrating an unknown (and uncounted) number of end users.

Couldn't we have an "appeal this judgment" link? That way the end user could say something about why it shouid be approved.

Mollom would be the ideal option only if it works better than what it's doing now. or at least the bugs get fixed.

Category:feature» support

In my test it is the same problem with 6-x-1.6 or 7-x-1.1. I did manage to post a comment when logged in. Settings are to allow comments when Mollom servers are unreacahble. I have never seen a Captcha form, and almost never been able to leave a comment.

So where is the problem? There is a long thread http://randyfay.com/node/69 about mollom false positives, on post about false negatives. It seems clear that the problem is with the Mollom service, not with the module. Is this because I am running low traffic sites where non-spam comments are rare? Maybe Mollom learns to reject almost every comment on my sites? In case anyone from Mollom is looking, my latest failed comment had session_id = '1108209fa4108e0960'. On Drupal 6 I have switched to Trick Question module, on Drupal 7 to Honeypot module.

@John_B: Thanks for the session_id - I'm forwarding that to the Mollom backend engineering team to analyze. Upfront, based on a quick inspection, the post was blocked due to an extremely bad reputation of the IP address it was posted from. This means that the IP has been (ab)used by spammers or a spambot very shortly before. In case you have a static IP address that doesn't change, you might want to check your system for viruses or trojans. In case you have a dynamically assigned IP, then this particular case is one of Mollom's worst-case, edge-case scenarios - Mollom automatically adjusts ("heals") the IP reputation as soon as the spam abuse stops, but this process might not have been fast enough. As mentioned, I'm going to forward this session info to the engineers.

@all: In case you have a concrete case, ideally but not necessarily with Mollom session IDs (like @John_B), it's going to be way faster to contact Mollom support directly, by creating a ticket on http://mollom.zendesk.com or sending an e-mail to support@mollom.zendesk.com.

/me will clarify that on the project page as well now

I have the problem a lot. I use mobile broadband with dynamically assigned IPs which change very often (sometimes even 'spin' without disconnecting! you know it happens when you are kicked out of online banking or cPanel for no apparent reason, cPanel returns 'your IP address has changed'). Maybe mobile broadband IPs should be whitelisted?

Nice. Love how that support site is not mentioned on the Mollom website.

@ebeyrent: It's the same as using http://mollom.com/contact - sorry for the confusion.

Why Captcha is not enough? ever since I moved to my new house, I was forced to fill captcha field. I don't understand why I should do it forever? and now I simply can't comment anywhere! it's easy to build a spam filter that blocks all the spammers and people, isn't it? a good spam filter recognises humans after 100th captcha I filled? instead I got blocked all together.

I think it's more a bug rather than a feature request
PS: Thank god d.o doesn't use mollom!

PS: Thank god d.o doesn't use mollom!

Is it true that drupal.org does not use Mollom?

But I don't agree that it is a bug with the module since the problem seems to be stemming from Mollom's own servers rather than the module.

There was no followup to the session ID I provided for a false positive, though sun was kind enough to say thanks for it. It is very depressing as a loyal and enthusiastic Drupalista to have to face the fact that (for my purposes at least, and quite a few others) Mollom is broke. Although complaints of false positives have been around on the web for some time (eg a comment on Dries' own blog http://buytaert.net/mollom-2010-retrospective) there are few signs that it is going to be fixed. I have been using Honeypot module with good success to block spam on low traffic Drupal sites.

Drupal.org does not use mollom, but groups.drupal.org does.

I guess the default setting can be altered to accept suspicious comments. Dries did that oh his blog you referred to. I tried to comment on that post days ago and was blocked. now I get into approval queue

Hi,

Can you confirm that Mollom still makes problems for you also ?

And did you find a better solution ? Using Captcha module is IMPOSSIBLE as pages with a CAPTCHA are not cached...

Thanks.

Given that many people have had problems, and there is no clear statement from Mollom that things have changed, I personally would not use it. I use Honeypot for anti-spam. For for a large busy site, it is not clear whether Honeypot would be enough, and a more sophisticated solution such as Mollom may be needed. I am guessing that for big corporate customers, who are paying for Mollom, it must be working fine. But for small users of the free service, it seems best avoided on the basis of my experience.

My Mollom worked fine for several months and suddenly started to capture legit comments as spam and I lost a lot of them.
I contacted Mollom and opened a case. Their response is very slow (several days if you are lucky!) and with no solution. They are just saying that the posts are spam because the IPs are tagged as spammers!! they are not, they are mine and my friend's IPs that I personally know.
There is a bug in their code and they are not looking into it seriously.
Currently I switched back to the Captcha module.
I wish Mollom works though, it's much easier for my visitors.

StatusFileSize
new155.33 KB
new104.87 KB

I still find it amazing that the Mollom service allows the false positives it does. I think if site owners were aware of how many frustrated users try to post comments they'd all cease to use it. It seems that the people who run the service just don't understand what happens to real people (like me) out there.

Here's a concrete example. I just posted a very simple comment, with no links at all, and got rejected (with no appeal possible, of course):
rfay_dell_Selection_119.pngrfay_dell_Selection_118.png

Yes, I contacted Mollom support and their answer was that the people who are posting are tagged as spammers!!
I'm one of the posters and the others are friends that I know.
I tried hard to make it work by sending them session IDs and more and eventually gave-up and back to the ugly CAPTCHA / BOTCHA combination.
If anyone has other solutions, please let us know.

This is possibly a separate problem, since mollom seems to be rejecting everything in my tests -- the blank session ID? -- but the basic difficulty of rejecting without showing a captcha, and difficulty of correcting / debugging, is the same.

87983:Feb 22 04:51:34 sojourner drupal: http://agaric.com|1329904294|mollom|209.234.253.106|http://agaric.com/contact|http://agaric.com/contact|0||Spam: 'I have an idea for a mobile app but don\''                                           Data:  post_body = 'I have an idea for a mobile app but don\'t know where to start.  It seems like a good idea and I am told there is already somethign OUT THERE but I haven\'t found it...'#012  author_name = 'Joan Smith'#012  author_mail = 'jsmith@example.com'#012  author_ip = '209.234.253.106'#012  session_id = ''#012  checks = 'spam'#012#012Result:  spam = 2#012  session_id = '120222bde5627b757a'#012

I would like to know how many of the people suffering with Mollom false positive problems are using a caching reverse proxy. I use Varnish, and Mollom is useless for me. But maybe something to do with my Pressflow-based .vcl (Varnish config file). Cf http://drupal.org/node/962534 for example.

@mlncn: Yes, separate issue. I've forwarded that session info to Mollom. The author's originating IP seems to have been heavily abused by a spammer very shortly before that post attempt. The IP's reputation might be recovered by now.

The solution proposed in comment #10 would be helpful. As a workaround, I installed the String Overrides module, then configured it with the following override:

Original: "Your submission has triggered the spam filter and will not be accepted."
Replacement: "Your submission has triggered the spam filter and will not be accepted. If you feel this is in error, please <a href="mailto:xxx@xxx.xxx">contact us</a>."

That's a band-aid. Since this issue has been around for so long, it's a shame not to see a solution for it.

Version:6.x-1.x-dev» 7.x-2.x-dev
Category:support» bug

I think as Jason said in #8, comments should be accepted if they've passed the captcha. It's insane to make people jump through the hoops of submitting the content once, then submitting it again having filled out a captcha, and finally being told "Sorry. You're still spam."

As I see it, this is a bug.

-Joseph

@jtbayly: I talked to the Mollom backend engineering team and they confirmed that this is not the case.

In case a CAPTCHA is triggered after text analysis was unsure, then the post is considered as ham if the author solves the CAPTCHA correctly.

There is only exception to that - if the author significantly changed the post's content while solving the CAPTCHA, and e.g., spam links have been added, then the text analysis is triggered again and will return "spam" -- otherwise, spammers could easily trick out Mollom by posting unsure content and adding lots of spam content when solving the CAPTCHA.

Sorry as this is off topic and I know that this has been covered elsewhere, but at least 2 of the above threads appeared to be related.

We are running Domain Access with Varnish / Memcache and we had the most f'ed up issue with the IP on Drupal 6. Double check if the IP is correctly parsed and sent to Mollom.

In Drupal 7, there are 3 variables in play:

<?php
    $ip_address
= $_SERVER['REMOTE_ADDR'];
    if (
variable_get('reverse_proxy', 0)) {
     
$reverse_proxy_header = variable_get('reverse_proxy_header', 'HTTP_X_FORWARDED_FOR');
      if (!empty(
$_SERVER[$reverse_proxy_header])) {
       
// If an array of known reverse proxy IPs is provided, then trust
        // the XFF header if request really comes from one of them.
       
$reverse_proxy_addresses = variable_get('reverse_proxy_addresses', array());
       
// Turn XFF header into an array.
       
$forwarded = explode(',', $_SERVER[$reverse_proxy_header]);
       
// Trim the forwarded IPs; they may have been delimited by commas and spaces.
       
$forwarded = array_map('trim', $forwarded);
       
// Tack direct client IP onto end of forwarded array.
       
$forwarded[] = $ip_address;
       
// Eliminate all trusted IPs.
       
$untrusted = array_diff($forwarded, $reverse_proxy_addresses);
       
// The right-most IP is the most specific we can trust.
       
$ip_address = array_pop($untrusted);
      }
?>

Very useful to know about these variables This was the first issue that caused all of our submissions to be blocked.

So the D7 variables that need setting are:

<?php
variable_set
('reverse_proxy', 1);
// If different... variable_set('reverse_proxy_header', 'HTTP_X_FORWARDED_FOR');
// Kind a really screwed up logic in ip_address(), you have just specified one or two times that
// you don't trust the remote address but it is added as the most likely remote IP...
// So add the server IP to the blacklist too.
$server_ip = $_SERVER['SERVER_ADDR'];
variable_set('reverse_proxy_addresses', array($server_ip))'
?>

The second was a complete wtf from the ip_address() function in Drupal 6. This was somehow set with the wrong IP address early in the bootstrap and was being set to the server IP. Removing the static forced a correct result.

<?php
function ip_address() {
-  static
$ip_address = NULL;
$ip_address = NULL;
?>

I have suggested some requirements checking of the settings in this issue: #1711634: Build in IP error checking into hook_requirements().

Sun, thanks for the update. I had a user report that exact scenario. He tried to submit a comment, and got a captcha. He tried to submit the comment after solving the captcha 3 times in a row, and after his 4th attempt (3 with captchas) he was told his comment was spam. Am I to assume that means he solved the captcha wrong three times in a row?

Alan, I'm running D7, (and I'm using Barracuda/Octopus from Omega8.cc), but I'm not sure what you're saying I need to do. How do I go about checking if the "IP is correctly parsed and sent to Mollom"?

Thanks,
-Joseph

@jtbayly: If you can find the log entries related to the post attempt of that user, then it would be great if you could send them to support@mollom.com, so the Mollom backend/support team can have a look at what exactly went wrong there.

In general, I think expanding the "blocked" message so that it includes instructions as to how an end user can proceed/report the block is a great idea.

However, the Mollom session IDs for the comment that was blocked are critical here. If there is a way to include those in some sort of automatic appeal process, or programmatically insert some text in the comment the reporting user would leave with the site admins indicating the session ID of the comment that was just blocked, that would be ideal. Without the session ID, there is no good way (or at least, no _easy_ way) for a site administrator to tie an "appeal" to an actual comment in her Drupal logs. And, having the session ID of the post is essential when further reporting the block to Mollom; the session ID is the first thing they will ask for and the essential thing they need to find out why the post was blocked and to take remedial action.

That said, I don't know of a way to get the session ID automatically included in something the site administrator would notice -- perhaps clicking the appeal link could cause a log entry to be written under a "mollom appeals" category with an automatic entry that would read something like "User X appeals the blocking by Mollom of his post with a Mollom session ID of Y." where X is the user's name and Y is the session ID of the post that was just blocked. A message could be displayed through drupal_set_message or otherwise that would say something like "Your appeal has been recorded for administrator/moderator review."

At least in this scenario, the admin would have the session ID right at hand to give to the Mollom support staff for investigation.

In my experience, working with Mollom support will not result in a solution and is a waste of your time.
I had sent sessions IDs to Mollom support and have couple of cases opened. But their response was that the people who are posting those comments (I was one of them) were tagged as spammers and they refused to look any further. That's a false positive, the people are my friends and they are 100% not spammers, specially that it was happening irregularly.
So a lame response like that made me stop using Mollom and go back to captcha (unfortunately).

The fact is that people, since June 2010 are complaining about this issue, yet there's no solution...

Cross posting to #1345422: Determine and show whether correct IP addresses are sent, as this would help determine the root cause of some issues.

@jtbayly
Check the sites recent log messages, and filter by Mollom
The host IP should be listed on the blocked messages, and if this equals the servers IP, then there are issues with the set up.

We had to hack ip_address() to fix this in a D6 pressflow installation running varnish / memcache on domain access. So far we have had no issues on stock D7 installations after setting the 3 system variables (well the default for reverse_proxy_header didn't need updating).

@sun in another issue somewhere you said there was documentation on this; setting the core Drupal proxy settings. I could not see this on the documentation pages nor the readme. Am I blind?

Anyway for Drupal 7, in your settings.php file:

$conf['reverse_proxy'] = true;

# This is the default, either var_dump($_SERVER); or check your server doco for the correct variable.
# Should be correct for 95% websites
# $conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';

# Replace 127.0.0.1 with your servers IP. For some reason the wrong IP still trusted after you
# explicitly state that it is not to be trusted by setting 'reverse_proxy'
$conf['reverse_proxy_addresses'] = array('127.0.0.1');

Please can you confirm that Mollom is still as bad and still marking as spam what is not spam without letting you a chance to review this ?

Thanks.

Yes, still as bad. All you have to do is be a *user* of a website (you'll never know about the problems as a website manager). Leave a comment on a mollom-enabled Drupal website. Include a link that is legitimately helpful. It will most likely be rejected.

But does the website manager has a chance to see the rejected comment ?

I don't believe the website manager has any opportunity to see (or even be notified of) the rejected comment.

The rejection, of course, is added to the huge number of successful Mollom statistics.

But there is this option:

When text analysis identifies spam:

Automatically discard the post
or
Retain the post for manual moderation

@make-online-shop, I do remember that now. However, it's not really a win, since there's no differentiation between actual spam and false positives. On a normal website, you're going to go see a thousand spams... most people won't look through those.

What I do, sadly, on my low-volume sites is one of two approaches:

1. Use a captcha and notify of every comment by email.
2. Require moderation for every comment.

I just could wish that Mollom could find a way to distinguish better, especially when it's already challenged the user, and the user has succeeded at the challenge!

I can confirm that this issue is STILL not fixed. While testing the webform "Contact Us Fast" on a customers site I was rejected without even being given a Captcha. My IP was my local Starbucks. So how many of my and my customers users have been rejected just because of their IP!!! That is a FATAL bug as far as I am concerned, if text analysis fails you should be given a Captcha and if you pass then you pass. Rejecting someones entry just because of their IP address is WRONG! I will be cancelling Mollom and switching to an alternative.

Additional information:
By selecting Captcha instead of 'text analysis' Mollom will accept my forms. Of course this leaves me with an ugly Captcha always displayed on the front page of my customers website (just like the Captcha module). I will use this option until I can find replacement for Mollom. Too bad Mollom is broken, the idea was nice.

@fdg123:
If you don't want users to see a captcha you could try something like the honeypot or BOTCHA modules.
Those types of solutions seem to be pretty decent from what I have seen, and are much better for the end user.

All these modules that pretend to prevent spam are BS.

None works correctly, I wasted days and night testing this.

People who tell the contrary just don't know what they are talking about and haven't tested intensively, or just don't care.

The best solution that I have found is to use CAPTCHA RIDDLER and just select an easy question to which anybody can reply.

And change it if it happens that robots guess it.

I think the next internet millionaire is the one who will find how to definitively get rid bots without making user having hell experience !

Title:Appeal!: Explain what a user should do if "Your submission has triggered the spam filter and will not be accepted."Allow users to report in case they are blocked
Category:bug» task
Status:Active» Needs review
StatusFileSize
new3.87 KB
PASSED: [[SimpleTest]]: [MySQL] 5,029 pass(es).
[ View ]
new5.54 KB

Hi all,

I'm sorry it took us so long to find a way to improve the situation in this case.

Upfront, I'd also like to mention that we've identified a major bug in Drupal core's caching mechanisms in the last two weeks, which caused posts from anonymous users to get inappropriately blocked as spam under certain circumstances. The latest 2.x development snapshots for both D7 and D6 contain a workaround/fix for this, and we're planning to roll out new releases this week.

On sites that got bitten by this bug, the chance for false-positives will significantly decrease. Nevertheless, there will always be a chance for posts to get inappropriately classified as spam.

Therefore, we're implementing a simple false-positive reporting mechanism for end-users.

As already mentioned earlier in this issue, we are still concerned about the trustworthiness of such reports and very potential abuse by [human] spammers. However, we'd like to give it a try and investigate whether it will work out or not.

Attached patch:

  1. Extends the final, blocking error messages with a link to a false-positive report form on mollom.com.
  2. The link is specially crafted to contain the data that is necessary for Mollom Support to investigate what happened (specifically, the session IDs of the form submission attempt as well as public API key of the originating site).
  3. The report only goes to Mollom. For now, the site owner is not informed. That is, primarily due to the possibility of false reports as mentioned above. If this turns out to work, we will investigate whether we can additionally inform the site owner in the future, but not for the time being.

I'd appreciate some help with wordsmithing for the additional UI text/link. The currently proposed messaging is:

Your submission has triggered the spam filter and will not be accepted. If you feel this is in error, please report that you are blocked.

(italics denoting the link/anchor)

Specifically, I'm not sure whether "this is in error" is proper English?

Here's a screenshot depicting the new error message:

2013-04-02_14h09_56.png

What do you think?

The english is proper, and the progress is exciting. Thanks much! I look forward to trying it out.

-Joseph

Version:7.x-2.x-dev» 6.x-2.x-dev
StatusFileSize
new3.97 KB
FAILED: [[SimpleTest]]: [MySQL] 4,360 pass(es), 196 fail(s), and 134 exception(s).
[ View ]

Thanks for reviewing the English text!

Committed to 7.x-2.x.

Status:Needs review» Needs work

The last submitted patch, 0001-869782-by-sun-Added-link-to-Mollom-false-positive-re.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new3.97 KB
PASSED: [[SimpleTest]]: [MySQL] 4,448 pass(es).
[ View ]

Version:6.x-2.x-dev» 7.x-2.x-dev
Status:Needs review» Fixed

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

I'd appreciate some help with wordsmithing for the additional UI text/link.

Suggestions:
SHORT VERSION
Your contribution has triggered our spam filter, so it has not been accepted. If this is an error, please report the fault by clicking this link.
LONG VERSION
Your submission has not been accepted because it has triggered our spam filter. If this is an error, please report that your contribution has been blocked so that we can improve the accuracy of our filter.

@John_B: Not sure whether the proposed wording makes a bit difference to #58?

@jtbayly/everyone, what do you think?

@John_B: Not sure whether the proposed wording makes a bit difference to #58?

No. Same meaning, it is only intended to sound more friendly (bearing in mind that it can pretty annoying for end users to spend a long time composing a comment then having it rejected). For example there is a view among some UX people that the words 'submit' and 'submission' should always be changed to 'send' or 'post' because of the way the word 'submit' can make users feel.

At the end of the day on the type of site where these details matter, the message will be customised. If it is not too time-consuming it might be good to add a field to Settings allowing site admins to customise the failure message.

We had to make progress and publish a new release due to some major bug fixes. So the messages are still the same, sorry.

If there's sufficient interest in improving those messages, I'd be very happy to discuss in a new issue. So if you want, just go ahead and create one. :)

Quick follow-up: Turns out it was a good idea and decision to not copy these reports to the site owner:

As of now, around ~20% of reports are submitted by human spammers who are trying to game the spam filter.

These would definitely not be obvious to a regular site owner. The Mollom support team is able quickly identify such malicious attempts, since they have direct access to all direct, indirect, and related classification data for each submitted report.

Even though most sites did not update to the latest stable release yet, this new facility allowed the backend engineering team at Mollom to identify and fix a range of problems already — in turn, significantly improving the quality and accuracy of the Mollom service.

If you haven't already, make sure to update to the latest stable release of the Mollom module for your version of Drupal core.

I'd like to thank everyone once again for sticking with this issue. Especially @rfay, who originally filed this issue. It took a long time to figure out how a potential solution could work out. Given the data and results we're seeing, I'm absolutely confident that the now implemented solution is not only the best for now, but also the ultimate long-term resolution that will be ported and adopted by Mollom client plugins of other platforms, too.

Thanks all!

@sun, your work on this is very much appreciated. Seems like pretty major progress! It should improve Mollom's performance too, getting some feedback when it makes mistakes. Thanks so much!

Yes, thanks, I look forward to trying Mollom again soon.

one more suggestion: just use Akismet http://drupal.org/project/akismet

it's way better than Mollom

We're seeing several Akismet users that are switching over to Mollom every single week, and who are actively providing feedback on how switching to Mollom improved the situation with spam on their sites, so based on these actual data points, the claim in #72 does not seem to be true.

Anyway, that's completely off-topic for this issue either way and I don't understand why you commented on this issue. Feel free to create a new issue or use my drupal.org contact form to get in touch.

Thanks,
sun

Akismet was discontinued since 2008!

Status:Fixed» Closed (fixed)

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