BRAVO TECHNOLOGY CENTER

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: 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 results.

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 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. RUDIMENTARY 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. CLIENT-SIDE 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. 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.

See Also:

• Anti-SPAM Initiatives
• SPAM Prevention
• Catch-All Alias
• Multi-Generation Forwards