Best Method for Email Obfuscation?
Awhile ago, Silvan Mühlemann conducted a 1.5 year experiment whereby different approaches to email obfuscation were tested for effectiveness. Nine different methods were implemented, with each test account receiving anywhere from 1800 to zero spam emails. Here is an excerpt from the article:
When displaying an e-mail address on a website you obviously want to obfuscate it to avoid it getting harvested by spammers. But which obfuscation method is the best one? I drove a test to find out.
After reading through the article and its many findings, here are what seem to be the best methods for obfuscating email addresses displayed publicly on web pages..
Reverse the text direction
According to the article, one of the best methods for hiding your email address from spammers is to write it backwards and then reverse the text direction with a little CSS trickery. Let’s say we want to display and obfuscate the following email address:
kick@inception.com
We would include the email address by writing it backwards in our web page, and wrapping it in a <span> tag with a nice class attribute:
<span class="obfuscate">moc.noitpecni@kcik</span>Then to display it properly for our visitors, we apply the following CSS:
.obfuscate { unicode-bidi: bidi-override; direction: rtl; }When CSS is enabled, this declaration block will reverse the display of any text within the .obfuscate-classed <span>. Works great, but not without a few downsides:
- Requires the user to manually type out the address (i.e., a
mailto:link won’t work) - The email address will display backwards if CSS is unavailable.
- When the user does a copy/paste of the email address, it’s going to be backwards.
- Bots could probably “decipher” these strings easily if programmed to do so.
Despite these issues, the reverse-text method proved 100% effective throughout the 1.5-year test, so definitely a good method to know.
Add some “null” text
Another effective way of obfuscating email information is to insert some “dummy” text into the email address itself. For example, using our “kick@inception.com” address, we would insert “<span>null</span>” into the address:
<span class="obfuscate">kick@<span>null</span>inception.com</span>..or even something more complex:
<span class="obfuscate">
kick<span>null</span>@<span>null</span>inception<span>null</span>.com
</span>With these injected character strings, the markup looks nothing like an actual email address. But we’re not finished with it yet – we still need to ensure that our human users are able to read the correct information. This involves hiding the nonsense <span>s with a little CSS:
.obfuscate span { display: none; }Simple enough. Again, this works great because users will only see the email address and not the “null” text. This method is effective at hiding your email address from the spammers, but there are some familiar downsides:
- Requires the user to manually type out the address (i.e., a
mailto:link won’t work) - The email address will display the “null” text if CSS is unavailable.
- When the user does a copy/paste of the email address, it’s going to include the “null” text.
- There may be a bot that can decipher such convoluted email addresses, so be careful.
Serious accessibility/usability challenges, but still another 100% effective method according to the test results.
Encode/Decode with ROT13/JavaScript
The ROT13-algorithm is an encoding method whereby all alphabetic characters are rotated by 13. Similarly, ROT5 is used to encrypt numeric digits, whereby every number is incremented or decremented by 5. This type of cipher is commonly used in Usenet/chat threads.
Using ROT13, we can use a free online tool (or directly via PHP) to encode an email address and then use JavaScript to decode it in the web page. Encoding our example email address, we get this:
xvpx@vaprcgvba.pbz
We then include this ROT13-encoded address in the web page using this JavaScript:
<script type="text/javascript">
document.write("<n uers=\"znvygb:xvpx@vaprcgvba.pbz\" ery=\"absbyybj\">Fraq n zrffntr</n>".replace(/[a-zA-Z]/g,
function(c){return String.fromCharCode((c<="Z"?90:122)>=(c=c.charCodeAt(0)+13)?c:c-26);}));
</script>That snippet will then display the following markup:
<a href="mailto:kick@inception.com" rel="nofollow">Send a message</a>
..which will create an email link on the page for your visitors:
This is another 100% effective method according to the test, with the only downside being that JavaScript is required for it to work.
Other Obfuscation Methods
The test also included a fistful of other methods that varied in their overall effectiveness. Here is a quick run-down:
- Replacing “
@” with “AT” and “.” with “DOT” in plain-text email addresses was also quite effective (but not 100%). - Building/inserting the email address entirely with JavaScript (404 link removed
http://bit.ly/ImZkc6) was the next-best method, but some spam still got through. Looks like harvesters are learning JavaScript. - Encoding “
@” and “.” with character entities in plain-text addresses resulted in a significant volume of spam. - Splitting the email address up with HTML comments was also ineffective at stopping spam.
- Encoding the email address with urlencode was less effective than any other method mentioned so far. Email-harvesting bots apparently have the whole “urlencode” game figured out.
- And worst of all is just using plain-text to display your email address. Definitely not recommended if you hate teh spam!
And, although it wasn’t included in the test, you could also use an image to display your email address, but the accessibility and usability is pretty poor, and there are bots that can interpret image-based text.
So which one of these email-obfuscation methods is best? One of the first three, based on the test results. Generally, these methods are useful for dropping the occasional email here and there, but perhaps the best method is to..
Use a Contact Form
When it comes to providing an easy, spam-free way for people to contact you, nothing beats the convenience of a simple, web-based email form. If you are using WordPress, there are many contact forms available, including my clean and simple Contact Form X, which is Ajax-powered for extra awesomeness.
Of course, form email has its downsides as well. Most notably, it takes longer to set up and test an online form than it does to slap down a line or two of code (as in our previous examples). Another challenging issue that I have experienced is getting contact forms to properly handle code characters (HTML, PHP, et al).
Use whatever works
If you have the time, using a web-based email form is probably the best solution for contact pages, but if you just need a way to simply include an email address, one of those first three methods may be just the ticket for keeping your publicly displayed emails spam-free.
For more information on these (and more) anti-spam email techniques, check out the original article. And, if you happen to have a favorite – and effective – email obfuscation trick, throw down in the comments and I’ll add it the post.
48 responses to “Best Method for Email Obfuscation?”
@Aziz Light: Absolutely. Hivelogic Enkoder is a great way to go. I have used the online service many times and highly recommend. Good call.
@Sunny Singh: Nice tip! Looks like that may be the ticket for base64-encoding while using the
mailtolink. Thanks for sharing. Btw, for future reference, to post code in your comments, just wrap each line or term with a set of<code>tags. WordPress just gobbles the stuff up otherwise.@Rick Beckman: Thanks for mentioning the captcha method. Using reCAPTCHA’s MailHide or any other captcha method is known to be pretty effective. Some contact forms even have this functionality built-in, making it even easier. Good to see you again, btw – you’ve been keeping a rather low profile! :)
@Julian: Yes definitely, and that method is mentioned in the article in the “Other Obfuscation Methods” section. Apparently it’s a pretty effective method.
@Micah: Sweet tip! I may try that method for my next project. Would be great to get the protection of email info while also using the
mailtolink. Nice.@Thomas Scholz: Always great stuff from you! Filtering by POST request seems like it would be effective indeed. What fallback do you recommend once spammers catch on and start POSTing their requests?
@AC: Good point. This was something that I was wrong about for years. At some point way back in the day, it seems that
example.comet al were not reserved for such use. Good to know that it’s okay to use.@Jesper: That’s another useful method, but I’m not sure how effective it is.. I recall using the
antispambotfunction back in early WordPress days and receiving tons of spam email shortly thereafter.@Rick Beckman: That is interesting indeed.. keep in mind that Perishable Press is running a (much) older version of WordPress, so that shortcode processing in comments may not happen in newer versions.
(Not trying to change the subject…)
I have a question that stems from this article:
Do you think the backwards method (with CSS to display the address forward) could possibly work for a very simple CAPTCHA system? The bots would see the digits/letters forward(the invalid input) The users would see the backward(valid input) display?
Nice article!
@Jeff: I’ve added a text field and hid it per CSS. If it isn’t empty, I return nothing.
An additional option were: encode the IP address of the visitor per base49 (anything from 20 to 64 will do) in the local part of the e-mail address and use a catch all mail account. That could be the base of a very useful shared block file. :)
But in the long term … e-mail is dead.
@Thomas: No way is email dead – we’ll be gone long before email, unless you’re talking about IMAP/SMTP technology, which may be left for something better.
There is a practicality, utility, and simplicity with email.
What would replace it?
Facebook messages are the future, Jeff. ;)
Seriously, though, even the mighty Google sought to “upgrade” email with Wave, but from what I can tell, it pretty much flopped.
@Jeff: E-mail as a format is (without encryption) insecure, it offers poor accessibility and no build in protection from spammers (who produce more than 80% of all e-mail traffic).
As a plain text medium it cannot handle binary files very good. And a conversation with more than two addressees (sp?) is ridiculous difficult for the average user.
Okay, maybe these are the reasons why we stay with it. :)
@Rick: Yes, Wave was very promising, but it’s dead (for the moment). Google seems to have a secret recipe for failing with social apps (bookmarks, buzz, chat, video). Let’s hope Yahoo! doesn’t find out this …
Maybe e-mail will die without a replacement. I’m eager to see what happens then. At least we don’t have to worry about these kind of spammers anymore.
@Rick: lol – so true! Facebook is definitely the answer. ;)
@Thomas: I agree that the technology will/should change, but the utility of the email as communicative tool will be around until the end of time. It’s just too practical for the all-purpose functionality it provides. Google Wave was a flop because you can’t do better than dead-simple.
As for the technology behind, I’ve been emailing stuff for years with no major problems regarding security, accessibility, or binary content. Or, at least no more problems than any other software.
For multiple-thread/person conversations, however, I agree that email isn’t the future. :)
Thanks for this overview. I usually use submittable forms, but just acquired a client who doesn’t like them. This info helped me figure out what to do.
I ended up using the ROT13/JAVASCRIPT, but I used ROT47 instead, and encoded my email address and phone number.
I saw another method on a site – http://www.albionresearch.com/misc/obfuscator.php.
Is that better, or worse, then the ROT/JS method?
Since the ’90’s I was using Jim Tucek’s encoder script which eventually disappeared. Now Dan Appleman picked it up and made it available for everyone again. Zero spam over the course of 12 years. It gives you a variety of visitor clickable mailto: links decoded via javascript and handles any reasonable number of different email addresses per site. It’s still free too. It works on WordPress or plain old html sites.
It’s at http://www.danappleman.com/?page_id=61
My favoured obfuscation method is to simply use a spam email address combined with a straightforward encoder , eg
greetings@mysite.comWhen the spam gets too much, just change the email address to eg
helloagain@mysite.comThanks for this thorought investigation. I recently had to setup a wordpress for my school, with many authors that i could not expect to behave correctly. I therefore set up a plugin that turns any email address in the post body into an obfuscated html string à la : john(replace this parenthisis by the @ sign)doe.com, so the html is clean and users without javascript can figure out the email address quite easily. With a bit of javascript i transform it into a nice mailto: link.
If you’re interested, you can find it here.
http://pixeline.be/blog/email-protector-wordpress-plugin
PS: really enjoyed that article on htaccess php error logging. Great write up!