First Published: May 17, 2005
Last Updated: August 20, 2007One 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 "@rochester.rr.com" 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:
- 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.
- 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.
- 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 |
|