Stop turning contact form spam into a user problem

We put contact forms on websites quite a lot, and we check that the input data is valid and sanitized of all evilness, however after a few weeks the invariable contact form spam starts to filter in to the client’s inbox.

To the client the obvious answer is a CAPTCHA.

However I advise clients that putting a CAPTCHA or other similar element onto a contact form is shifting the problem of the spam to their legitimate users. Why should your user have to mess about trying to read two difficult to read words, just to contact your business? The user shouldn’t need to care about your spam problem.

That said, spam is annoying and if you are getting a lot of it, it may prevent you noticing legitimate contacts. So what should you do about it?

If you are getting an awful lot of spam, one method is to deploy Akismet, which has a simple API that can be hooked up to your contact form and which returns a true or false result, depending on whether it believes the message to be spam or not. As Akismet is used by WordPress they have a huge amount of data on what is and is not spam – there are also plugins available for several content management systems and frameworks.

Comments

Simon Proctor: 11 May 2011 at 16:17:46

I love Akismet, it’s wonderful. It’s just horribly depressing at the same time.

Oh look! I’ve got 14 comments on my blog! Oh look… they’re all spam. Sigh.

But yes, I heartily agree with this post.

Shelly: 11 May 2011 at 20:36:22

I use a honeypot. Basically, it’s a form field that’s set to a width/height of 0, with “visibility:hidden” in the CSS. The label is set to instruct the end user to do absolutely nothing with the field – to just ignore it – so if someone using a screen reader comes along, they’ll know not to bother with it.

If any input is put into that field, it won’t be sent. Spammers generally auto-fill every field there is, so most times, it turns away the spammers right then and there. A few do get through, but not many. No need for CAPTCHAs, no need to depend on a third party service (and if you do use the 3rd party service, it’s just a bonus level of protection).

Pete Lacey: 11 May 2011 at 20:40:59

Wholeheartedly agree. Spam isn’t a users problem, it’s yours.

I wrote a blog post in a similar vien the other year, having a bit of a go at people who write cryptic email addresses. I think the same rule applies to CAPTCHA and other strange forms of validation: http://www.chopeh.com/blog/simple-contact/

Nick: 11 May 2011 at 21:06:49

I use fun or silly Captcha’s when it’s appropriate. Very easy mathematical sums are also good. You don’t have to decipher ugly jumbled-up letters.

Rich Adams: 11 May 2011 at 21:54:14

I find using a honeypot is a good method. I have fields named “email”, “site”, etc. set to have no size and hidden in CSS and the real ones called “liame”, “etis” (backwards). The label for the honey pot ones just say “Only fill these in if you’re a spammer” so if someone has CSS disabled they won’t be trapped by it. If any of the honeypot fields are filled in I instantly discard it as SPAM since only a bot would’ve filled those in.

Work surprisingly well, I’ve had no SPAM since implementing this.

Originally I had a honeypot with just a random name, but the bots got smart and would only fill in the fields called “email”, etc. So switching around the names of fields seems to work for now.

Michael: 12 May 2011 at 00:31:01

I was just (a couple of days ago, but it’s still loaded in my browser) an article from 2007 titled “Stopping spambots with hashes and honeypots” which outlines various ways of preventing spam without bothering users (well, most users, some few do see the honeypots).

I personally don’t mind the occasional simple sum, or easy task (“what’s the square root of -1?” is one I saw recently, others I’ve seen include entering the domain of the website). In fact, what annoys me more is having to enter an email address when I intend to merely post a throw away comment, or where I don’t intend to ever have a conversation with the author. In such cases I normally put a fake email address. I do not know what the point of requiring an email address is.

Jared Smith: 12 May 2011 at 02:26:41

We use the honeypot method hidden with CSS. We also set a hidden field with the current timestamp when the page loads. On submission, we compare the submitted timestamp (when the page was loaded) to the current time stamp (when the form was submitted). If it is more than 30 minutes or less than 4 seconds, then it’s probably a bot.

Using these two things with a very short naughty words filter has brought one of our forms from ~1000 spam submissions to 2 or 3 per month (and these are paid human spammers or SEO ‘experts’), and with no user impact.

Many more techniques at http://webaim.org/blog/spam_free_accessible_forms/

Martyn Drake: 12 May 2011 at 07:47:02

Add to that a good set of mod_security secfilters and you’re got yourself an excellent “bouncer” guarding your site.

David Radford: 12 May 2011 at 08:51:45

I agree with Rich and Jared – I have recently started using a CSS hidden honeypot with a ‘don’t fill this in…’ label screen readers etc. and it does work surprisingly well – but better not say it too loud in case those pesky spammers catch on…

Rachel: 12 May 2011 at 09:43:11

Loads of really helpful comments – thanks everyone :)

I’m seeing a lot of human entered spam on some sites which the honeypot method isn’t going to catch and Akismet often does. However for those really annoying automated posts that can flood in the honeypot method sounds to work well. So that’s another good option for people to try. Just make sure it’s obvious for people who do see the field that they should not fill it in!

Leave a reply