Topic awaiting preservation: Email Address Obfuscation/Spambot Honeypot

Recently a local competitor emailed one of my clients critcizing the email address obfuscation techniques I employ on their web site (the Hivelogic Enkoder 5.1). She suggested that substituting a unicode character entity for a single character in the domain name is safe, effective and does not require the visitor to have javascript enabled. I disagree on all points but the javascript.

However, I have no proof and I can find no evidence on the web comparing the efficacy of the different methods out there.

I want to run an experiment to gather data on spambots and which address obfuscation methods are effective against them. I've given some thought to test protocol and Googled around looking for as many obfuscation methods as I can find. Thus far, I'll be testing 26 addresses, each representing a different method or variation on a method, plus four more addresses to test against dictionary attacks against the mailserver directory.

What I'd like is some feedback on the methods I'll employ to set up the honeypot, suggestions on additional obfuscations to test against and some help in directing spambots to the honeypot.

I've started a document laying out the test methods and the address obfuscations I've found to test. If you're so inclined, please download the document and post comments back to this thread.

In OpenOffice format, download http://www.brucew.com/ozone/spambot_honeypot.sxw.
In RTF format, download http://www.brucew.com/ozone/spambot_honeypot.rtf

Thanks in advance!

Spambots are much smarter nowadays. Replacing characters with HTML entities won't stop "modern" spambots from indexing the address. Also, replacing "@" and "." with textual representations "at" and "dot" (or variations like "[at]" and "[dot]") won't stop some spambots either. So, the more you obfuscate the address, the better.

BTW In my opinion even using JavaScript to generate appropriate HTML code with "mailto:" link can be overridden and e-mail address can be retrieved. I don't know if such spambot exists, but since Internet Explorer rendering engine can be included in other programs (as ActiveX object), one can write a program that will fetch html pages, feed them to IE, and then retrieve parsed html code or even better use DOM to directly access elements on the page (links)...

My web page ( http://www.slimeland.com/ ) uses a combination of JavaScript, character entities, and string concatenation with predefined variables to construct my email address. It's kept out spam for at least a year now.

However, it's so obfuscated that I feel obligated to also include a contact form ( http://www.slimeland.com/contact/ ) with which people can contact me if they don't have JavaScript enabled.

mr.maX: I agree that the primitive methods are probably broken and that other methods will have a limited lifespan. It's a matter of how much work they want to put into the effort and when they do it.

Slime: Is yours a method you're willing to add to the test? And are you willing to make a tool to generate addresses using your method?

We've all heard the theories and arguments. However, there's no body of evidence to support any claims or theories of spambot defenses in the wild. With no comparative evidence, we're all just shouting in the wind.

The experiment's question is, which methods have spambots learned already and which ones haven't they? Only then can real arguments be made and, more importantly, real decisions based on fact not theory.

Naturally the answer will change as spambots evolve.

Usability and accessibility test are for a different experiment that maybe someone else is willing to undertake. And BTW, I'm not testing the .htaccess ban methods either since not everyone has the skill to impletment them, nor am I comfortable myself in running huge .htaccess files on many domains on a shared server.

Thanks for the comments so far and keep them coming.

I just use a PHP mailer form using an ldap directory lookup to provide the e-mail address - that way there are no e-mail addresses to see, and certainly no "mailto"


Bug-free software only exisits in two places
A programmer's mind and a salesman's lips

Unfortunatley that kind of form leaves you open to a different kind of spam...there are spambots out there that instead of spamming email addresses will find sites with firms just like that and keep filling them in, over and over, sending mountains of spam to your address, and the beauty is it totaly bypasses your spam filters becuase it is coming from your own domain's email address.

Yes, but forms on a web page can be removed, so that's stoppable. In addition, you could modify the script that handles the form to do your own spam filtering (if you felt up to the challenge). On the other hand, you can't do anything about your email address being on someone else's spam list.

Brucew: I wouldn't make a tool to generate addresses with my method, because the more people that use it, the less effective it is. =)

However, I can say with a significant amount of confidence that the only way a spambot could get by my method is if it either (a) could parse and execute JavaScript, or (b) interfaced with a browser or some other type of program that could do so. (b) is more likely, but I've only gotten a very small number of spam emails in the last year or so, so I figure there aren't any popular spam bots that do these things. I do know that my address isn't 100% safe, but I'm willing to settle for the protection that I have.