Latest TweetsGreat post about the latest power grab: www.eff.org/deeplinks/2018/09/…
Perishable Press

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 an 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:

Send a message

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.

Jeff Starr
About the Author Jeff Starr = Creative thinker. Passionate about free and open Web.
Archives
48 responses
  1. Excellent article. Great to see someone test out different methods for results. We personally stick with contact forms and never had a problem.

  2. A few years ago I came across a technique that I’ve used since.

    While it is another JavaScript dependent solution, I haven’t yet found a better solution (other than a contact form):

    http://www.maurits.vdschee.nl/php_hide_email/

  3. Our method is to use .jpg files for each email address. But that is not for the faint of heart! Your methods are much simpler, of course. Our method requires an image editor. And it is a bit cumbersome to place on a web page. But I can tell you this. The email addresses have not been spammed in 10 years on the web. (It helps not to use the email address online in any web page.) I think your methods would work equally well, because I use text obfuscation on my blog, like email[at]yahoo[dot]com, and that email address has not been harvested, either. I think harvesters are not especially bright and probably just about all the methods work well. The most valuable email addresses will be for clueless users, more likely to click on an emailed link.

  4. Adam Haworth September 14, 2011 @ 5:07 am

    I sometimes use images for the email address but contact forms work well for me and reduce spam. I had problems when using null to confuse the code, as people would copy and paste the address without looking at it.

  5. Sam Anderson September 21, 2011 @ 2:23 pm

    I have used Hivelogic EnKoder for since 2003. Its magic. However ive recently had issues using it with my CMS.

    It still works magic for most situations and does an excellent job.

    On recently reviewing my email hiding techniques, i came across Obfucatr http://obfuscatr.flashbit.net/obfuscate.html

    This provides an active link with your email address onscreen, with the address concealed and hidden at source level.

    I can only think that your email address could be scraped by copying and pasting the text onscreen. Which i thought would be a pain in a$$ in most situations. and not doable by bots.

    Your thoughts to this?

  6. Jeff Starr

    Thanks for the link! :)

    It looks like a solid JavaScript menthod, but I’ve heard of bots that are now able to scrape JavaScript links. Also, requires JavaScript, which isn’t that big of a deal anymore, but not everyone has it, so not recommended for more serious sites.

  7. Paul McKeown November 14, 2011 @ 8:21 am

    Interesting article, interesting comments.

    BUT utterly unconvincing.

    All the “solutions” provided have unacceptable accessibility and/or usability faults. Use them if you will, but never claim compliance to WCAG/508 or any other accessibility standard or code, if you should do so.

    Perhaps obfustication as an image file would be acceptable, provided that an audio file were also provided for those for whom the image file was inaccessible, coupled with provision of plain text by javascript for the convenience of the 95% who are able-bodied, sighted and have enabled/not disabled javascript.

    Even were someone to walk that extra mile and provide genuinely accessible and usable mail obfustication, it would be still be beaten in the end by the (chain of expletives deleted) barbarians.

    Tighten up your firewalls and filters on the server and tolerate the occasional spam that does slip through.

    If you get zero spam, perhaps you’re missing loads of genuine mail that people didn’t send in the end, because your obfustication defeated them?

    Ultimately email protocols need authenticated senders and receivers, encryption and secure, tamper and spy-proof transmission. But with all the vested interests, I’m not holding my breath.

  8. Jeff Starr

    LOL – relax Paul, nobody is gonna falsify WCAG/508 compliance without consulting you first!

    Thanks for the laugh.

  9. Paul McKeown November 14, 2011 @ 10:49 am

    Jeff,

    The point is genuine.

    All the methods stated here prevent or obstruct different groups of genuine readers from obtaining or using an email address from a site that uses these methods.

    If you wish to take such a dismissive tone towards genuine concerns, why bother providing a comment form? Sorry for having wasted my time and yours.

  10. Alexandre Plennevaux November 14, 2011 @ 11:29 am

    Paul,
    I find your concern to be right, and justified.

    My technique makes screen readers provide a very reasonable experience. It replaces the email mailto: link by html that explains how to reconstruct the email address:

    info(replace these parenthesis by @)pixeline.be

    Javascript then kicks in and produces a mailto: link.

    Let me know if you think it is good or if i should update the script to better accommodate disabled users.

    http://pixeline.be/downloads/email-protector-plugin-for-wordpress-450.html

  11. Jeff Starr

    Sorry didn’t mean to hurt any feelings, just thought you were having fun with that first part.. I stand corrected.

  12. Paul McKeown November 17, 2011 @ 8:42 am

    Sorry, Jeff, I guess humour and tongue in cheek doesn’t always work on the net. I guess that’s what smileys are for. Offence unconditionally untaken!

[ Comments are closed for this post ]