As a software developer I’m constantly challenged with avoiding annoying spammers. I easily spend 30% of my time working against people that serve no purpose but to bother me. The challenge isn’t simply blocking bots and spammers on development projects, it’s balancing the blockage with the loss of real users.

A good test case, the techdiversions.com mailing list. The concept is simple, a side-panel area where visitors can sign up for our mailing list to receive industry news, video game promotions and game release dates. The mailing list, from a business perspective, keeps users remembering who you are so they come back next time to buy from you and not your competition.

Enter the spam bot. This little bot comes along each day and causes endless headaches for my wife, the store owner, when she wants to manage her mailing list and user-base. This bot, for whatever reason, signs up for the mailing list with bogus e-mail addresses five times a day with ten new sign-ups each vist. Thats around 50 new sign-ups a day!

Now, you may ask “why would a bot use a bogus address for a mailing list?” Because bots aren’t very smart and more than likely the bot really wants to sign up for a site account so it can spam the comment log with advertisements for erection drugs and other products only 2% of its user-base buys.

Lucky for me, my wife runs the store so I can get away with a bit. But, had I developed the mailing list side-bar for a client and received calls saying “your module is causing IT nightmares” I’m back on the job to fix the issue. Had I thought ahead the issue wouldn’t have ever become a problem.

The lesson? Any form you present to the user will be subject to endless attacks by bots and frauds. Every site has a solution (or should) to the problem. For credit card fraud, some sites require you to enter the bank holders name from the back of the credit card before you can continue. For user spam, some sites require you to validate your e-mail address before you can login (i.e. Drupal). Others, like pligg, use “captcha” to accomplish registration successfully.

The problem with these solutions? Every single one will cause your users to think twice about sign up or purchasing. Internet users are lazy, I know, I am one of them. In certain circumstances a user will weight the annoyance of validation against what their attempted to get out of your site. A site that requires captcha to leave comments or login means the users going to think “is it worth my time to try to figure out this messy set of letters and type them in?”

In some cases, the annoyances of validating they are not a bot is enough to make them click back and head to a new site. This was also the case with techdiversions for user account login validation. By making users validate their account by testing their e-mail address means they may not purchase from us because they get confused, lazy or just don’t care. Yet, by allowing them to insta-login means we’ll receive more bots and fraud attempts because it’s “annoying” to have to sign up with endless valid e-mail addresses to login (although dodgeit.com makes it easier for them).

So, how do you balance good vs. evil? Market testing, unfortunately, will be the only real way. Setup a barracade to your spammers and bots and monitor your user registration, user comments or whatever you’re securing. If the number drops drastically you’ll have to find a better solution to the problem or lose precious eyes. In some cases, the solution is to bog yourself down in validating, by eye, each registration or deleting unwanted posts–yuck.

How did I solve my mailing list attack? I watched for patterns and reacted to the attack with a plan… I noticed each bot that came by created a first name and last name that were identical. How many people do you know with the same first name and last name? Very few! So, I took my chances and refuse anyone to sign up for our mailing list whom has the same first and last name. I guess we’ll lose folks named Bob Bob or John John but the benefit outweights the annoyance of daily user cleansing.

Did it work? So far I’ve received zero new sign-ups on the mailing list from bots! They may get more creative, but I believe the bot was signing up in error given the uselessness of the cause. To sign up for an e-mail only newsletter with a bogus e-mail is a good waste of time for both parties involved.

The lesson to take away from this:

• Think Ahead: Can you develop a software application that has natural barriers to bots without harming your users.
• Test Barriers: Try one new barrier against the bots and monitor the reaction from the humans. If you lose your audience you’re going to be worse off than dealing with bots.
• Monitor Comments: Some “bots” are actually humans; they’re out to get back-links without providing any useful purpose. Delete them or monitor out the urls.
• Monitor forums: Bots have a nasty habit of creating 200+ accounts and spamming urls all over the place. Listen to your users, they probably use your site more than you do (we hope!)
• Bots Repeat: The only saving grace is that bots really only know how to do a limited number of things… over and over. Patterns can be seen and counter-measures can be taken.

Lastly, check to see if your CMS has spam-blocking modules. Wordpress has many to choose from so browser around! Speaking of which, I’ve got to go delete the 376 spam messages in our pending queue.

Happy surfing!