Skip menu!

2007-05-28 Breadcrumb trail: Home page Computer issues

Erik's notes on

Erik Thau-Knudsen

Nobody likes spam or junk mail, yet some of us want to be accessible to other people through the Internet. This page deals with various ways to trick the spammers, tricks that go beyond what spam filters can do. My treatment of spam filters will, thus, not be in-depth. Also, server side e-mail scripts will not be treated, as these require expert knowledge.

  1. Personal behavior
    1. Keep it all secret
    2. Give it only to people you trust
    3. Keep your e-mail address changing
    4. Use aliases. Set up and delete when needed
  2. Spam filters
    1. Remote side spam filters
    2. Own server-side spam filters
    3. Client side spam filters
  3. E-mail addresses on web pages
    1. The wrong way
    2. Plain text
    3. Spelling it out
    4. Tables
    5. ASCII coding
    6. JavaScripting
    7. Imaging
    8. Background imaging

Personal behavior

There is really much to be achieved if you behave with the necessary caution. You should pay more or less the same caution as when giving your snail mail address away to any other postal order company.

Keep it all secret

Don't hand over your e-mail address to anybody. Keep it in your locker, swallow the key, never open your mailbox.

Pros

  • You won't be bothered ever.

Cons

  • You won't be able to enjoy all the advantages of this well-established web technology.

Give it only to people you trust

Deliver your e-mail address in a handwritten form or dictate it by phone. Make sure it will only stay on their personal address books. Make them promise that they never show it to anybody.

Pros

  • You are likely to receive mail only from people you know.

Cons

  • Vira and other menaces can enter the electronic maillists, read your mail address and spam you anyway.
  • You are likely never to expand your name to people who could be your friends in the future.

Keep your e-mail address changing

Set up an address on your mail server of the kind my-name_2005@my-domain.dk. In 2006, change it to my-name_2006@my-domain.dk.

Pros

  • You may get spam, but only till the end of the year.

Cons

  • You will have to update the address on the mail server.
  • Also, you will have to inform all your contacts about your change of e-mail address.

Use aliases. Set up and delete when needed

Some internet providers offer aliasing, i.e., a number (sometimes unlimited) of different names for the same recipient. All e-mail for the aliases will be directed to the same mailbox. I met a guy in 2004, who does this. For his participation on the Danish web portal Jubii he has the type jubii@my-domain.dk; in his Macintosh user group he uses macuser@my-domain.dk, whereas while at work he uses the type work@my-domain.dk.

Pros

  • When leaving an interest group, workplace etc., you delete the alias from the server, and spammers have no way to reach you.
  • If you by chance get spam (you will!), you are also able to track the source (the aforementioned guy was thus able to observe a breach of privacy on web sites that otherwise promise secrecy of their users' e-mail addresses).

Cons

  • You will have to remember a lot of mail aliases (the aforementioned acquaintance has more than 20 different aliases)

Spam filters

As I told in the beginning, spam filters is not my specialty. The below chapter is an outline only.

You may set up spam filters. The ones existing to-day can be divided into roughly three types, at least, all depending on which fase of the transmission we are dealing with:

  1. Remote side spam filters
  2. Own server side spam filters
  3. Client side spam filters

Remote side spam filters

This type is a filter that a server may have set up to prevent that his server, sometimes even a SMTP server will be used by a junk mail emitter. Some of the on-line e-mail services, such as Eudoramail, will prevent you from creating maillists with more than 20 addresses. This is good, because often spammers use well-known domain names as their addresses, such as yahoo.com, hotmail.com etc. Sometimes this happens even within the mail program which may have an upper limit of names in an address list.

FYI: Around 2001, I got an offer (by junk mail, can you believe it?) of a CD-ROM with 2 million valid e-mail addresses. Not doubt how this should be used.

Own server-side spam filters

Many e-mail providers offer junk mail filters. These filters filter off spam mail by analysing all incoming mail by specific parameters, such as domain names renowned for hosting notorious spammers, or mismatching sender addresses.

Client side spam filters

Many e-mail programs offer junk mail filters. The free Gecko based programs (Mozilla, Netscape 6+, Thunderbird) and Apple's Mail have intelligent spam filters, by which you teach the filter what is spam and what is not. It takes some time, but once they're up and going, they are quite satisfactory.

E-mail addresses on web pages

If you write your own web pages, you are more in control with how to do things. More control does not necessarily keep you spam free. This section deals with what you can do with HTML to prevent robots (automatic programs updating the contents from HTML documents) from interpreting e-mail addresses.

The wrong way

HTML code Representation in browser
<span><a href="mailto:my-name@my-domain.dk">My name</a></span> My name

Pros

  • It is easy to write.
  • The user just clicks the link to start up his mail program to send an e-mail

Cons

  • Encoding like this is exactly what e-mail searching robots are expected to look for. This is an invitation to spam your mailbox

Plain text

HTML code Representation in browser
<span>my-name@my-domain.dk</span> my-name@my-domain.dk

Pros

  • this is even easier to write than the above text

Cons

  • The user cannot go to his mail program to write the mail, but will have to copy and paste.
  • Probabilities are that the e-mail robots will detect this as they would in the above case.

Spelling it out

HTML code Representation in browser
<span>my-name at my-domain dot dk</span> my-name at my-domain dot dk

Pros

  • Bullet-proof way.

Cons

  • You cannot even copy-and-paste, but will have to remember and re-type it.

Tables

HTML code Representation in browser
<span><table><tr><td>my-name</td> <td>@</td><td>my-domain.dk</td></tr></table></span>
my-name @ my-domain.dk

Pros

  • Bullet-proof way. A robot reads code, whereas the human eye reads what it sees on the screen.

Cons

  • The user must resort to copy-and-paste.

ASCII coding

HTML code What the browser reads What the browser displays
<span><a href="
&#109;&#97;&#105;&#108;&#116;
&#111;&#58;&#109;&#121;&#45;
&#110;&#97;&#109;&#101;&#64;
&#109;&#121;&#45;&#100;
&#111;&#109;&#97;&#105;&#110;
&#46;
&#100;&#107;">My name</a></span>
<span><a href="mailto:
my-name@
my-domain.dk">
My name</span>
My name

Pros

  • The user clicks the link once and will be redirected to the e-mail program.

Cons

  • Very hard to write.
  • If I were writing those nifty little robots, I would also take these cases of ASCII encoded links into consideration. If browsers can display them, operating systems can understand them, why then should malicious software not be able to parse the code?

The ASCII model can be twisted ad infinitum. You might add enough characters to display

<span><a href="mailto:'My name' <my-name@my-domain.dk>">My Name</a></span>

I expect that this will really confuse the robot. It will also be more convenient to the user, whose Recipient field will be properly filled in.

Link

Asciitable.com

JavaScripting

HTML code What the browser displays
<span>
<script type=text/javascript>
//<![CDATA[
document.write ('<a href="');
document.write ('mailto:');
document.write ('my-name@');
document.write ('my-domain.dk');
document.write ('" title="Click to send me an e-mail using your own
e-mail program.">');
document.write ('my-name');
document.write ('@my-domain.dk</a> ');
//]]>
</script>
</span>

Pros

  • The search robot will not be able to decode this script as an e-mail address, particularly if you split the critical code parts such as mailto: and @ to even smaller units (letter by letter).

Cons

  • Quite unhandy.
  • Global (site-wide) updating of an e-mail address becomes difficult (can be overridden if you use an external JavaScript instead of inserting it into only this document).

Frankly, this model is my favourite.

Imaging

Three varieties
HTML code What the browser displays
1. @ as an image  
<span>E-mail: My-name<img src="images/at.png" alt="at" />my-domain.dk</span> E-mail : my-name atmy-domain.dk
2. my-name@my.domain.dk as an image  
<span>E-mail: <img src="images/my-name-at-my-domain.png" alt="My name at my domain" /></span> E-mail :
3. E-mail: my-name@my.domain.dk as an image  
<span><img src="images/my_e-mail.png" alt="My e-mail" /> </span> My e-mail

Explanation

All three varieties are built on the principle that instead of text, the junk mail www robots will get images and thus not be able to decode them. After all, they are just programs, not human eyes.

Using images to cover e-mail addresses is an approach often used on the World Wide Web.

Pros

  • We have all heard of Optical Recognition Software (ORS), you know the kind that dechifers the texts you scan into a file. Some people have ported them other programs so that they can set up e-mail accounts at some sites, where you have to type a text from an image into a form field in order to open an account. It is most unlikely that this measure will be applied for sucking valid e-mail addresses from pages at your site.

Cons

  • The user will have to type it all to write you a mail.
  • If you want the e-mail address to be available for visitors with a mobile phone, typing it again — let alone remembering the address — is cumbersome.
  • Using images will exclude blind people and some others with visual disabilities from responding to your web pages.

Background imaging

HTML code What the browser displays
<span style="height: 13px; width: 156px; background-image: images/my-name-at-my-domain.png; background-position: top left; background-repeat: no-repeat;">
<span style="visibility: hidden; ">See my e-mail with an image enabled browser!</span>
</span>
See my e-mail with an image enabled browser!

Explanation

This trick is inspired from Zen Garden, a group of web designers that aim to show the supremacy of the Cascading Style Sheets technology over styling with HTML codes only. The principle behind is a bit like the previous trick — to use an image to replace text. Here, though, I made it a background image. To make sure you won't see multiple images, you will have to add the information background-repeat: no-repeat;, whereas the CSS property background-position: top left; is not that important, since it is the default setting of most desktop browsers.

To aid people with non-image browsers such as Lynx or aids for visually impaired, I added a dummy text. In fact the trick won't work unless you add some text to the second <span> tag. It will not be seen by users with regular browsers because I added the the property visibility: hidden;.

Using <div> tags instead of <span> tags is better, because the former are more obedient to the CSS height and width properties than are <span> tags.

I have not used this trick, but feel free to do so.

Pros

  • E-mail harvesting machines might one day be equipped with optical recognition software (ORS); however, ORS only finds what it is supposed to look for. And since this trick has not even been tried yet, the ORS is not supposed to look for e-mail addresses hidden in background images!

Cons

  • As in the previous trick, the user will have to write the whole text down to send you and e-mail.
  • Requires much coding, which, of course, should be replaced with class styling in external stylesheets once you find out that re-use the particular e-mail address.
  • Visually disabled persons will have problems reading this address.

 

Erik Thau-Knudsen

2007-05-28


| About this site | Copyright | Contact Bookmark and Share
Erik Thau-Knudsen • Skolegade 2A, 2. sal • DK-8600 Silkeborg • Denmark • Tel.: (+45) 8680 1882  • Mob. (+45) 4013 4133