If you put something like this in your website:
<a href="mailto:firstname.lastname@example.org">email me!</a>
spammers can identify that email@example.com is an email address with automated tools that review thousands of websites (analogous to the “spiders” used by search engines like Google and Yahoo). They can add your address to their databases. And eventually, they will surely do so. In fact, it turns out that spammers are pretty good at extracting anything that looks like an email address, whether it’s in a mailto: link or not.
First Generation Solutions
The underlying theory is that while spammers could easily get your email address by going to the site, loading the page, and looking at the results, very few spammers will invest the time necessary to do so. If the automated tool doesn’t return an email address, they won’t check each site by hand. The economics of spamming are contingent on the incremental cost of sending each email being very, very low — anything that requires the spammer to invest time eats into the profit margin.
email: test (at) example (dot) com
Towards a Second Generation Solution
I observed several serious problems with my “munge” library:
- It was too complicated and hard to use. Programmers seemed comfortable with it, but web designers often weren’t, and “ordinary” people struggled mightily with it.
- It was inflexible. It worked ok for text links that were all by themselves, but it didn’t readily support linking an image, for example.
- It didn’t play particularly well with many “what-you-see-is-what-you-get” (WYSIWIG) web page editors.
- It put the burden of creating the fallback <noscript> support on the page author. Many page authors were confused about how to do this effectively, and many just didn’t bother.
Conceptually, the progressive enhancement model looks like this.
We still start with a library included in the <head> section:
In the body of the page, we have the link information in a format that is easily human-readable, but less easily machine-readable:
email me at <span id="contactAddress">test (at) example (dot) com</span>
There’s one significant catch: You can’t turn the text into a link until after the browser has displayed it in the page. That makes this code a good candidate for an “onload” event, which the browser will run after the page finishes loading.
Enough Talk, Where’s the Code?
guardMailto is released under The MIT License.
Instructions for adding guardMailto to your site are covered in using guardMailto.