The current approach seems to allow spammers a free rein or no users can use the site. Our users are frustrated or we are frustrated with spam.
- Accept all form submissions
- Block all form submissions
Recently Mollom's uptime has not been that encouraging. Is it possible to find a third option with some middle ground? I would like to request an additional option where we use CAPTCHA (other spam detection methods could be used) when Mollom is down or unreachable. Then a site can still be used by the community with one extra step in submitting content or specific forms. This third option could be from an other module or from with in Mollom's own module.
- Accept all form submissions
- Supply CAPTCHA for all form submissions
- Block all form submissions
Now our sites could still operate just with an extra step for the users and keeping spam out of the site.
Comments
Comment #1
steve.colson commentedSeconding this. I have been noticing lots of stability problems too, and a fallback to the captcha module as an option would be ideal to getting all of the spam messages in my inbox that mollom normally does an awesome job at blocking.
Comment #2
sunMollom's CAPTCHA also require that the Mollom service works.
That said, there have been some unfortunate short time-frames of downtimes in December and January, as Mollom migrated to a massively improved server infrastructure. That migration should be completed by now, so the root cause for this issue should be fixed.
Comment #3
steve.colson commentedI think the idea would be to allow it to fail over to another CAPTCHA service, like recaptcha, if it is detected that the Mollom infrastructure is unresponsive.
After all, "improved" is great only until the service gets a lot more users. Again.
Edit: At least, that would be my suggestion, to offer a way to fail back. Even using the actual captcha (http://drupal.org/project/captcha) module as a fallback--or anything that hooks in to what it offers--would be desirable.
Comment #4
sunThis feature is not on the roadmap for the foreseeable future, so reverting the issue status.
It's also going to be hard to architect, since there is no generic API or standard that would allow some other module to take over, but only in case of unexpected communication/networking errors, and only if any other module exists that is capable of taking over.
That said, if anyone would like to actively work on this, please feel free to re-open this issue or create a new one.