First Published: May 17, 2005
Last Updated: August 20, 2007
Related: Jan 5, 2015 Part II:
Public Email Contact Options
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: It's a long way from 1991, and legacy usage of <MAILTO:> tag is UNACCEPTABLE! There are numerous bots
scouring the web around-the-clock to harvest email
addresses. A programmer can write such a script in mere
minutes. Even low-tech individuals could use web-search to mine publicly posted email addresses for any given
domain. e.g. Search for "@rochester.rr.com" (with quotation marks) and you'll see the
Addresses posted in public web sites will be
in circulation for spammers within a matter of weeks. Once started, it'll worsen exponentially, as it's being
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:
- RUDIMENTARY Graphic Rendition of email address. Instead of
listing clickable email address in plain text with <mailto:>,
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
plain text tag, your web page contains an encrypted email
executes upon clicking by human, and provides the original <mailto:> tag, triggering your default email program with
the decrypted address.
- SERVER-SIDE Web Form & CGI-based database / 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. See it in action: Bravo Unified Contact SINCE 2006
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. OR, reply via "blackholed alias,"
with that familiar "do not reply to this" notice instructing them
to send another message via URL. Once legitimacy is assured (not merely evoking a response in order to capture
your address), it would be safe to disclose the address for
their normal use.
Comparison of Approaches
Form + CGI
|Can prompt for specific info
|Custom Database required
|Formatting of email sent
|Human Manual Harvest email
|Mechanical Ways To Defeat
||Status Line Reader
|Exposures Address Upon Reply