SPAM Avoidance: <MAILTO:> Alternatives by Sam C. Chan
First Published: May 17, 2005
Last Updated: August 20, 2007
Related: Jan 5, 2015 Part II: Public Email Contact Options

One of the primary principles in SPAM prevention is: Never post email address on public web sites (your own, or forum, etc.), or public record databases (such as: whois).

The problem: There are numerous robots scouring the web around the clock to harvest email addresses. A skilled programmer can write such a script in mere minutes. Even any low tech individual could simply use the search engines to scour for all publicly posted email address for any given domain. e.g. Search for "" and you'll see the results.

Any email address posted in a public web site is guaranteed to be in the circulation of spammers within a matter of a few weeks. Once in circulation, it'd only worsen exponentially, as it's being traded/resold over and over again. Before long, it'd reach an explosive point where the address is simply unusable.

Dilemma: How to allow your web visitors to contact you electronically...

Over the years, I have arrived at three (3) effective alternatives to the <MAILTO:> tag:

  1. Graphic Rendition of email address. Instead of listing clickable email address in plain text with <mailto:>, display a graphic image of the email address without link. The human can discern it and copy manually into their email. The robot and search engines would miss it all together. Of course, determined parties can still use OCR software or hire someone to defeat it.
  2. JavaScript Encrypted <MAILTO:> tag. Instead of a plain text tag, your web page contains an encrypted email address, along with a JavaScript decrypting program, which executes upon clicking by human, and provides the original <mailto:> tag, triggering your default email program with the decrypted address.
  3. Web Form & CGI-based database of email proxy. This is the method favored by virtually all major corporations. The user interacts with a web form by filling in the required fields. The form in turn calls a backend CGI program to populate the information into a custom database, to be retrieved by the site owner. For smaller companies, there's typically no database. Instead, the CGI simply acts as email proxy and send an email to the designated email address. There are a lot of subtle details to be coordinated for this to work well.

Naturally, once you respond to a message, you'd be exposing your reply address. The secondary defense is to use a short term alias for such routine responses and periodically retire them. You can even reply w/ a blackholed alias, with that familiar "do not reply to this" notice and instruct them to send another message via your URL. Once you have determined the correspondent is legitimate, and not merely evoking a response in order to capture your address, it would be safe to disclose the normal address for their long term use.

Comparison of Approaches
Characteristic Graphic Image JavaScript Form + CGI
User friendliness Poor Excellent Very Good
Can prompt for specific info No No Yes
Custom Database required No No Optional
Implementation Cost Low Medium High
Formatting of email sent Normal Normal Unformatted Blob
Human Manual Harvest email Yes Yes Completely Safe
Mechanical Ways To Defeat OCR Status Line Reader None
Exposures Address Upon Reply Yes Yes Yes

See Also:


Copyright @2005-2006   Bravo Technology Center  *  Bravo:GO  *  Contact Us