home | legal stuff | glossary | blog | search

 Legend:  new window    outside link    tools page  glossary link   

How to avoid spam

You’ll be far less annoyed by spam if you don’t get any in the first place. In addition to following some of the spam rules I describe elsewhere, you might also try some of these tricks to keep yourself off the spammers’ lists.

First, how do spammers get their lists of target addresses? There are three reliable ways to generate “original” spam address lists:

Occasionally spammers offer lists for sale to other less experienced spammers, but these often contain “gotcha” addresses of known anti-spammers and others who can get the unwary purchaser into trouble.

In order to keep your address as far out of sight by spammers as you can, then, you’ll want to know

Here are some tricks that may be of help; I’ve rated them by how easy and how effective they may be, as well as where they can be used.

Use an “unguessable” e-mail address
(Very easy and quite effective)
(Applicable: anywhere)

As we noted above, spammers will often try to guess at addresses that might be found within a domain, and then test them using directory harvest attacks. This means that even if you follow the other advice on this page to keep your address out of sight, it might still fall into the hands of a spammer if it is fairly “guessable.”

Therefore, you might consider making up an e-mail address that does not contain common words or names, such as wefs23xi@my-isp.foo or similar. Longer is better, and further down the alphabet is better, since these choices may further reduce the likelihood that the address will be guessed by the spammer. This may be a bit inconvenient because it will be more difficult for you or others to convey this address over the phone or on paper; however, once your address is in the address books of you and your frequent correspondents, this is less of a problem.

Use a sacrificial address
(A little inconvenient, but effective at what it can do)
(Applicability: web, usenet)

You can take advantage of one of the many free e-mail services to coin new addresses that you can use for activities that bear risk of address harvesting. Such “sacrificial” addresses can be made to work something like real-world post office boxes, as a means for you to receive mail without revealing your “true” address (that is, the one you want to keep away from spammers).

Suppose you want to sign up for a hobby-oriented mailing list, but aren’t quite sure whether you can trust its proprietor not to sell your address. Rather than using your personal address, you can set up a brand-new sacrificial address to use just for this list. You can use webmail to pick up your list messages, or else set up a new queue in your mail program just for this new address. If you find that this new address starts to get spammed, you can simply shut it down and the spam will cease immediately.

You can also use sacrificial addresses for any other kind of online activity where a valid e-mail address is required (e.g., registering products, signing up for “free” web services). These addresses will probably be harvested and spammed eventually (unless you also protect them using one of the methods below), but your private address will not.

If you don’t want to use the free services, you may be able to get sacrificial addresses from your own ISP for little or no cost. Such addresses will either be all-new, self-standing addresses with their own separate mail spools, or they may be aliases of your current address. Either will work for this purpose, though there are differences:

In either case, as with freemail addresses, you can simply disable these addresses if they begin to get spammed; this will not affect your true address.

Munge your address
(Very easy, modestly effective)
(Applicability: web, usenet)

To “mung” or “munge” (rhymes with “sponge”) is hacker jargon for “mash until no good;” it entails clobbering some string of strictly-formatted data (an e-mail address, in this case) until it can no longer fulfill its intended function.

Since spambots look for simple text patterns (i.e., “x@y.z”) to find e-mail addresses embedded in web pages or usenet posts, you may be able to elude them by simply altering your address in some fashion that humans can (perhaps) easily deal with, but that the spambots might be unable to detect. For example, you can simply spell out the punctuation:

frank16 at nobody dot zzz

Or, you can add some text to the address that a human correspondent will (one hopes) know to remove:

frank16NOSPAM@nobody.zzz

(assuming that the munged address here isn’t actually someone else’s address)

This trick will work anywhere you simply want to display an e-mail address, such as on a web page. You can also configure most mail programs and news readers to use a munged address as your mailback address that gets displayed on your postings. Naturally, you won’t get the mail if someone tries to use them without first de-munging them.

You might decide to be clever and use this sort of munged address in a web page as the visible portion of a mailto link, like so:

<a href=“mailto:frank16@nobody.zzz”>frank16 at nobody dot zzz</a>

but this isn’t clever at all: your real address is perfectly visible to the spambot scanning your HTML markup, even if it doesn’t appear onscreen when a web browser renders the page. So, always avoid using mailto links with such addresses.

To the extent that spambots simply look for straightforward “x@y.z” patterns, this trick should effectively keep you off the lists. It is certainly possible, however, that more sophisticated bots might pick up some of the simpler munging techniques, so this may not be a long-term safeguard.

One other significant drawback of this technique is that it won’t pass the “Aunt Edna” test; unsophisticated net users (like your Aunt) might not understand how to “de-munge” the addresses and therefore won’t be able to contact you.

Escape your address using HTML character entities
(Not so easy, maybe not so effective)
(Applicability: web only)

If you’re putting your address on a web page, you can use special HTML codes (called “character entities”) to disguise (“escape”) some or all of the characters in the address. For this example, note that in HTML “&#64;” is the character entity for the “@” (at-sign), and that “&#46;” is the “.” (dot). You could then write your address in the HTML markup as

frank16&#64;nobody&#46;zzz

which would be rendered in a web browser as:

frank16@nobody.zzz

If you’re feeling lucky, you can even use the escaped address in the HREF of a mailto link; the address will (usually) be unescaped when it reaches the users’ mail programs. Here’s how you’d code it:

<a href="mailto:frank16&#64;nobody&#46;zzz">
frank16&#64;nobody&#46;zzz</a>

And here’s how it would look on the page (try the link for yourself, but cancel the message before you send it).

frank16@nobody.zzz

You can dump the HTML source for this page to see for yourself that the escapes work.

If you’re really a glutton for punishment, you can encode the entire address in this fashion; for example, “f” = “&#102;”, “r” = “&#114;”, and so on (consult any table of HTML character entities, or ASCII/ISO-8859-1 Latin characters, such as the one here). Don’t forget the semicolons after the decimal code number or these things won’t work.

Although this technique passes the Aunt-Edna test with flying colors (since she won’t have to do any decoding in order to use the link), I’m not sure how effective it would be at eluding harvesting; although the spambot would read the “escaped” text, it seems to me that a reasonably sophisticated bot might be able to unescape it pretty easily.

Turn your address into a picture
(Easy for most users, very effective)
(Applicability: web only)

Humans can read text from a bitmap picture as well as they can from a “typeset” line; spambots can read text, but can’t easily make sense of text buried in pictures. That’s why it can be effective merely to put your address into a GIF or JPEG (or PNG) image for posting on a web page:

Here again, as with munging, make sure you don’t turn this picture into an “uncloaked” mailto: link (or your real address will be visible to the spambot).

Obviously, this technique is of no use in e-mail or usenet postings, where the e-mail address must appear as text and not as a picture.

This technique does OK at the “Aunt Edna” test, since she doesn’t have to translate the address. She does have to type it into her mail program “by hand,” however, so there’s a risk for error there.

Use a JavaScript to write a mailto: link
(Slightly complicated, very effective)
(Applicability: web only)

JavaScript, a lightweight programming language designed for web use by the folks at Netscape (and currently administered by Sun Microsystems), is probably the most popular form of “client-side” web automation. The less clue-deprived spammers like to use it a lot, so you might as well use some on your own web pages.

The basic idea is to use a very simple JavaScript in your web page source to cause the visitor’s browser to generate a mailto link “on the fly;” your address won’t be visible to the visitor until his browser downloads the page and executes the script. Your e-mail address can be effectively obscured by this trick, since spambots won’t be able to capture it unless they try somehow to run the script. More than likely, they’ll never do it, because there are thousands of other addresses that can be gotten at without such hassle (plus, it can be difficult if not impossible to execute a JavaScript outside the context of a conventional web browser).

I’m borrowing here from the website at http://www.joemaller.com/js-mailer.shtml, which explains the script in more detail and even provides an automated script generator for the programming-impaired.

I’d recommend visiting Mr. Maller’s site for the full story, but here’s the gist: let’s suppose that your e-mail address is the ever-popular “frank16@nobody.zzz.” In place of the normal, basic mailto link, which might look like

<a href=“mailto:frank16@nobody.zzz”>frank16@nobody,zzz</a>

you would type (or paste) in the following script. I have highlighted the portions you need to change to your own address in yellow; if you want to change the text that would appear as the anchored text in the hyperlink, you can change the bit in pink to whatever text you like, surrounded by single quotation marks (or in a named variable, as below), but please don’t use your e-mail address in the clear or the trick will be pointless:

<SCRIPT TYPE=“text/javascript”>
<!--
// protected email script by Joe Maller
// JavaScripts available at http://www.joemaller.com
// this script is free to use and distribute
// but please credit me and/or link to my site

emailE=('frank@' + 'nobody.zzz')
document.write('<A href=“mailto:' + emailE + '”>' + emailE + '</a>')
//-->
</script>

<NOSCRIPT>
<em>Email address protected by JavaScript.<BR>
Please enable JavaScript to contact me.</em>
</NOSCRIPT>

Basically what this little script does is to define your address as a concatenation of two separate strings (the frank16@ part and the nobody.zzz part), then, it tells the browser to write a mailto link at the point on the page where the script appears. When the viewer looks at this page, he’ll see a perfectly normal mailto link like this:

When the spambot collects it, it won’t see anything useful (dump the HTML for this page to see for yourself).

You can protect every instance of your e-mail address on your website using this same script; simply paste it in at the places where you want a mailto link to appear. If you have a lot of them on many pages, you can put the script in a separate file and use a server-side-include (SSI) directive on your web pages to pull in the file:

<p>My address is:<!--#include virtual=“hidden.js” --></p>

Here, the contents of the file “hidden.js” (which should include the script above) will be inserted into the page by the web server when it sends the page out to the visitor’s browser. SSI may not be supported on many free or “personal” web hosts, and there are some tricks to know here (involving web server configuration directives, file paths, and file permissions); if you have trouble with this technique, refer to instructions for SSI directives such as those here.

At Joe Maller’s site, you can use a nice form to generate a personalized version of this script using your own e-mail address. He also explains how you can make the script even more secure. If you know JavaScript, you can figure out even more devious forms of disguise, perhaps combining them with the character escapes explained above.

There’s no question but that this trick passes the Aunt Edna test, but it won’t work unless the visitor has turned on JavaScript support in his browser (many paranoid surfers prefer to turn JavaScript off to avoid potential security problems, or just tacky web effects). Joe has addressed this drawback with the <NOSCRIPT> tag, which tells the visitor to turn on JavaScript if he wants to use the link.

Use a mailback CGI application
(Complicated and risky, but very effective if done right)
(Applicability: web only)

If you run a website and can use CGI programs, you might like to install a mailback application on your website. The most famous of these is known as formmail but there are also many other newer (and perhaps more secure) examples. Before you install your own, you might check to see whether your provider has already installed such a application that you can use.

When you use a mailback application, rather than include a mailto link on your web pages, you would provide a link to an HTML form that your visitor could use to type in the message, and then send it to you via e-mail by pressing the “submit” button. Once the visitor has done this, he or she gets another page (which you create yourself or which may be built into the CGI program) that tells him or her that the message was sent. The message is sent to an address of your choosing, one that can be effectively hidden from public view (and harvesting by spammers).

You need to do some planning and investigation before deploying a mailback app on your website. CGI in general, and mailback programs specifically, pose significant security risks (and many personal web hosts therefore don’t support users’ CGI apps). A mailback application that isn’t properly secured can be exploited by spammers to broadcast their mail (as can be seen elsewhere on the site). Make sure you use a program that’s been around for awhile and has been consistently maintained and armored against such abuse, and be sure to turn on these security features wherever you can.

Configuring these programs properly is very important. Although you shouldn’t have to be a Perl or PHP adept to do this configuring, you do often have to know at least a bit about programming and other topics (such as how regular expressions work) to set these things up. The better examples will guide you through this process.

If you decide to write your own script or program (the mechanics aren’t that hard for a journeyman or hobbyist programmer to master), make sure that users can’t type in shell commands that will be executed on your server (this can be done in Perl, for instance, by calling it with the taint-checking feature enabled), and that the script itself is not in a web-accessible directory (so that it can’t be scanned by a spambot). Also, you must NOT include your address in the HTML form as a hidden (or visible) field, since the spammer can not only read it but might also be able to exploit it to send mail to anyone (by replacing your address with the recipient’s addresses in the CGI query string). It’s better to hard-code your address in the program itself (so that it can’t be altered in the CGI call), or otherwise stash it out of sight (for example, by making your CGI app read it in from a secure external file on the local file system), and then make sure the program is nonreadable to casual visitors (best to place it in another directory tree than the one that contains your HTML files).

Frankly, I think the JavaScript trick is just as effective for most uses, with none of the potential risks and much less hard work. However, feedback scripts can be useful for more complicated applications (such as saving correspondence in a file, mailing to multiple addresses, retrieving HTTP query data for each use, etc.).



 home | legal stuff | glossary | blog | search

 Legend:  new window    outside link    tools page  glossary link   


(c) 2003-2008, Richard C. Conner ( )

33300 hits since March 28 2009

Updated:Sat, 21 Jun 2008

Document made with KompoZer