No SPAM filter is 100% accurate, and despite recent advancements unwanted messages slip through. The only way you can stop this is to make sure your account is in a spammer database. While there are some common actions you can take to keep your primary e-mail addresses from being public knowledge (keep your business and personal ones separate, use a disposable/free account for mailing lists, forums, and registration forms, etc) sometimes you need to have them out there in public. Like in the contact section of a webpage. While setting up aliases/forwarders helps prevent your main account from being hit (comments@fakedomain.net) they will still forward spam to you. This article will outline a few different methods for keeping your e-mail addresses safe from harm… unless someone comes along and manually adds them in, or if they are using a new/advanced script.

Forms

One tried and true method is to have a contact form where users type their message on your site and a server side script sends the information to your mail account. The drawbacks to this approach are the facts that feedback is dependent upon a script (which may fail for a variety of reasons), that your address cannot be added to a visitor’s address book for quick/frequent access, the impossibility of being able to reply to messages with mistyped mail addresses in the form, etc. An example of a server side script would be this old favorite at matt’s script archive. Security concerns about using cgi based scripts are outlined here by the W3C

JavaScript

This method directly limits accessibility – users that choose to browse with JavaScript disabled, very old browsers, possibly screenreaders, or users who disable JavaScript may not be able to view the address it is a well respected method. However the majority of users can still view this, and a <noscript> error message can prompt those who really wish to contact you to briefly enable JavaScript. Most of the scripts are fairly similar in functionality; one of the better ones seems to be from bronze-age.com (more details here), which I’ve lightly modified and put up for download here.

The gist of it is that you break up an address in the source, and a short script (less than 1KB) you include in the page head puts it together. For example in the source:

<a href="mailto:nobody@fake.address9z.com">Mr Nobody</a>
would be expressed as
<script>mail2("nobody","fake.address9z",0,"","Mr Nobody")</script>

The first and second variables are parts of the address, the third variable is a shortcut for domain type (0 = com, 1 = org, etc), the fourth can be used to designate a default subject line e.g. "?subject=Application_X". Finally the fifth variable contains what the link will appear as. There is also an automatic tool to convert e-mail addresses. His version does not have .edu domains included, so I added it in so you would make the third variable ‘3’ for .edu accounts.

AJAX

While this takes a bit more work to set up, and requires the user to have cookies enabled as well as some server side scripting, it should be a bit more effective than the Javascript method. A server-side script generates a Session and an md5 value for the email attached to the identifier of an element. As the page is loading the source would then contain an MD5 hash… once it is loaded JavaScript is used to asynchronously call the value onto the page. Rajeczy.com includes source and example usage.

Further Reading

1. Protecting your website’s email addresses from being used by spammers, Aron Roberts, IST–WSS Berkeley Computing & Communications, Volume 13, Number 1 (Winter 2003)
2. Hiding E-Mail Addresses, Sarven Capadisli

Other Techniques

A few methods in the past included adding in obviously fake words to be removed (nameFAKE@NOSPAMdomain.net), exchanging ‘@’ with ‘AT’ and ‘.’ with ‘dot’, or using Unicode encoding for certain characters, e.g. @ for ‘@’ and . for ‘.’ None of these stand up to the current harvesting techniques (unless you are very creative I suppose), which check for common phrases or capitalized blocks etc. While there are some ways to use CSS to obscure content, only modern browsers understand the techniques (pseudo-element :after, unicode-bidi, display: none) etc that can be used to visually present valid links that are unusable from the pure source, though it wouldn’t be too hard for spammers to write scripts that can decipher the meaning. Another drawback of using CSS is that you do not end up with a clickable link, though the text on screen is at least able to selected and then pasted into a client.