Earlier this month, Mollom was officially discontinued. If you still have the Mollom module installed on some of your Drupal sites, form submissions that were previously protected by Mollom will behave as if Mollom was offline completely, meaning any spam Mollom would've prevented will be passed through.
For many Drupal sites, especially smaller sites that deal mostly with bot spam, there are a number of great modules that will help prevent 90% or more of all spam submissions, for example:
- Honeypot: One of the most popular and effective bot spam prevention modules, and it doesn't harm the user experience for normal users (disclaimer: I maintain the Honeypot module).
- CAPTCHA or reCAPTCHA: Modules that use a sort of 'test' to verify a human is submitting the form. Some tradeoffs in either case, but they do a decent job of deterring bots.
- Antibot: An even simpler method than what Honeypot or CAPTCHA uses... but might not be adequate for some types of bot spam.
There are many other modules that use similar tricks as the above, but many modules only exist for Drupal 7 (or 8, and not 7), and many don't have the long-term track record and maintenance history that these other more popular modules have.
But there's a problem—all the above solutions are primarily for mitigating bot spam, not human spam. Once your Drupal site grows beyond a certain level of popularity, you'll notice more and more spam submissions coming through even if you have all the above tools installed!
This is the case with this website, JeffGeerling.com. The site has many articles which have become popular resources for all things Ansible, Drupal, photography, etc., and I get enough traffic on this site that I get somewhere between 5,000-10,000 spam comment submissions per day. Most of these are bots, and are caught by Honeypot. But 2% or so of the spam is submitted by humans, and they go right through Honeypot's bot-targeted filtering!
Filtering Human Spam with CleanTalk
Mollom did a respectable job of cleaning up those 100 or so daily human spam submissions. A few would get through every day, but I have a custom module whipped up that shoots me an email with links to approve or deny comments, so it's not a large burden to deal with less than 10 spam submissions a day.
The day Mollom reached EOL, the number of emails started spiking to 50-100 every day... and that was a large burden!
So I started looking for new solutions, fast. The first I looked into was Akismet, ostensibly 'for Wordpress', but it works with many different CMSes via connector modules. For Drupal, there's the AntiSpam module, but it has no Drupal 8 release yet, so it was kind of a non-starter. The Akismet module has been unmaintained for years, so that's a non-starter too...
Looking around at other similar services, I found CleanTalk, which has an officially-supported CleanTalk module for both Drupal 7 and Drupal 8, and it checks all the boxes I needed for my site:
- No CAPTCHAs
- Well-maintained module for Drupal 7 and 8
- Easy SaaS interface for managing settings (better and more featureful than Mollom or Akismet, IMO)
- Free trial so I could see how well it worked for my site (which I used, then opted for a paid plan after 3 days)
- Blacklist and IP-based filtering features for more advanced use cases (but only if you want to use them)
I installed CleanTalk in the first week of April, and so far have only had 5 actual human spam comment submissions make it through the CleanTalk filter; 4 of them were marked as 'possible spam', and one was approved (there's a setting in the module to auto-approve comments that look legit, or have all comments go into an approval queue using Drupal's built-in comment approval system).
So CleanTalk worked better than Mollom did, and it was a little simpler to get up and running. The one tradeoff is that CleanTalk's Drupal module isn't quite as 'Drupally' as Mollom or Honeypot. By that, I mean it's not built to be a flexible "turn this on for any kind of form on your site" solution, but it's more tailored for things like:
- Drupal comments and comment entities
- User registration
To be fair, those are probably the top three use cases for spam prevention—but as of right now, CleanTalk can't easily be made to work with generic entity submissions (e.g. forum nodes, custom node types, etc.), so it works best on sites with simpler needs.
CleanTalk's pricing is pretty simple (and IMO pretty cheap) too: for one website, it's currently $8/year, or cheaper if you pay for multiple years in advance.
Disclaimer: CleanTalk offers a free year of service for those who post a review of CleanTalk on their websites, and I'll probably take them up on that offer... but I had actually written the first draft of this blog post over a month ago, before I found out about this offer, when I was initially investigating using CleanTalk for my DrupalCon Nashville session submission Mollom is gone. Now what?. I would still write the review exactly the same with or without their offer—it's been that good in my testing! Heck, I already paid for 3 years of service!
If you have a Drupal site and are disappointed by the uptick in user registration, webform, and comment spam since Mollom's end of life, check out CleanTalk for a potentially better solution!
Edit: Also see some excellent suggestions and ongoing work in integrating other spam prevention services into Drupal in the comments below!
I tried to get Akismet back up and running last year, but haven't had the time to give it the attention needed:
Good to know; it would be nice to have a module in that namespace, since 'Antispam' doesn't seem directly related; similar to the situation with 'Wysiwyg' in D7, where a lot of people probably went with CKEditor just because there was an official module for CKEditor that didn't try to be all things to all people.
I forked the Mollom project and swapped in Akismet. It works, but if it's to be a real project I'd need co-maintainers. https://www.drupal.org/sandbox/ksenzee/2948481
IMHO, The simplest and most efficient way of preventing spam in comments (and also in webforms and contact forms) is to use the Block Anonymous Strings module. You can define your own regular expression strings to check and block submissions against.
I’ve also recently integrated Human Presence, a similar tool that uses behavioral analysis to score web traffic as human vs. bot with a CAPTCHA fallback. More deets on the project page: https://www.drupal.org/project/hp
Honeypot is great and works really well for the most part, but I couldn't find any information on the Drupal.org project page about it supporting multi-part webforms in D7. End user reports suggest that it doesn't, but I don't have much more info than that.
I have a couple of site where honeypot does the trick but occasionally i have a site which seems to attract spam which bypasses it.
Hi - in regards to CleanTalk - did you install it on a site that was already running your excellent contrib module Honeypot?
Yep! They work together well.
Hi, just checking if this bot submission makes it or not :P
Looks legit to me!
The cleantalk module was marked as Unsupported on 1/23/2019 due to a security issue not fixed by the maintainer:
Yeah, that has me a bit concerned. The module is obviously getting new patches and releases, so it's not like it's unmaintained. I wonder if there was just some miscommunication with the maintainer? I've opened up an issue to see what's going on: Critical security issue - module unsupported?.
Seems like they have already solved it, don't they?
Just a note about webform integration and IP blocks. We were getting a ton of false positives using webform with modal_forms because 'ajax_' variables were getting posted to cleantalk causing false positives. Webforms that are blocked by cleantalk have no mechanism for sending after marking "not spam." They also don't seem to have a reasonable release policy for IP blocks. Our user base is international, so it's a ton of work marking a bunch of IPs "not spam" that had been used as a spam network 3 years ago.
I guess the takeaway is that cleantalk might not be the "set and forget" solution they claim it to be. Review your logs!
For more advanced use cases and for webforms we're going to keep looking for other options.