Skip to navigation

Accessible Email Masking with Modified Email Redirection

There are many methods for masking email addresses online. Generally, the point is to obscure (obfuscate or fragment) an email in the HTML code so that it is not readable by SPAMming software, but is still displayed on the screen for users. As you will see, this creates an accessibility problem. Therefore, I have combined two popular methods of email masking to create what I think is the most powerful method ever created.

Terms

The following terms will be used to describe this method:

Assumptions About Masking Methods

  1. In order to prevent detection by spammers, the coded email must not look like the real email. In other words, any email masking method must obfuscate the real email address in the HTML code.
  2. In order to achieve accessibility by normal users, the display email must look like the real email. In other words, any email masking method must display the real email address clearly on the screen.
  3. In order to achieve accessibility by special users, the coded email must be semantic. In other words, any email masking method must contain the real email address in the code, in some readable form.

The Problem

Given these assumptions, there is a clear problem! Assumption 1 and Assumption 3 are contradictory, which means that the two conditions cannot co-exist. One can prevent detection from spammers and achieve accessibility by normal users, but not by special users. One can achieve accessibility by normal users and special users, but not prevent detection by spammers. However, it is most desirable for web developers to achieve all three of these things. So the question is, how can it be done?

Current Masking Methods

Obfuscation, fragmenting, JavaScript generation, images--all of these methods obscure the coded email, making it non-semantic. This prevents detection by spammers, and a clever coder can achieve accessibility to normal users by making the display email look exactly like the real email. The only problem is that a non-semantic coded email means a non-accessible email to special users.

Contact Forms

Although this topic need not be addressed (this paper is on email masking, after all), I felt a word on contact forms would be appropriate and helpful.

The typical web developer may read this rather complicated discussion of email masking and say to him- or herself, "Why not just create a contact form and not display your real email at all?". The answer is simple. Contact forms are impersonal and can be discouraging to some users. Users sometimes feel like contact forms are a dead end, and that their emails will never be answered. Therefore, contact forms are often passed-by by many web users. Displaying an email address is a much more desirable choice for most web developers. It allows users to use their own email program to contact you. This is especially advantageous to special users, who may have special email programs.

The Solution: Modified Email Redirection

The only solution to this problem is a combination of two current methods: images and email redirection. The combination of these two methods is called modified email redirection. In modified email redirection, an image is created which displays the real address. This image acts as the display address. The image can be obscured so as to deter image-reading programs, but still display a readable email address to a normal user.

As described so far, this method accommodates normal users and prevents detection by spammers. To accommodate special users, modified email redirection uses a temporary email address. The temporary email address is put into the alt attribute of the image, with some message explaining that the given email address is temporary or will expire. Text in attributes is semantic, especially in attributes like alt which are commonly read in special browsers. The temporary address is programmed to forward to the real address, so that special users can contact the real address through the temporary address. If the owner of the real address wishes to communicate with this special user through email, they can respond through the real address. Once this is done, the special user no longer needs the temporary address, which will expire anyways. In fact, the special user no longer needs to refer to a web page to get the real address, since they most likely have it stored in their email program.

Therefore, modified email redirection accommodates all three cases: normal users, special users, and spammers. It displays visually to normal users, semantically to special users, and only gives a temporary address semantically to spammers. The more often the temporary address is changed, the less SPAM lists the email will end up on. If the temporary email address is changed often enough, spammers will a) not detect the temporary email address in time to harvest it or b)not have enough time to SPAM it once they have harvested it.

Proof: Why Modified Email Redirection is the Best Method

First, some assumptions about email masking and detection:

  1. There can be programs created which detect emails which have been obfuscated or fragmented in any manner within the code.
  2. There can be programs created which detect emails which have been encoded in any manner in the form of an image.
  3. Images are more expensive for programs to process than text.
  4. Images are more expensive to retrieve over the web than text.
  5. Text within images, because of the nature of images, can be obscured in more ways than text within code, if that text is to be displayed in a visually sensible way.
  6. Images by themselves are one of the least-accessible pieces of data available to special users.
  7. If the real email occurs within the alt tag, it defeats the purpose of masking the email.

Now, the conclusions which lead us to Modified Email Redirection:

  1. Images are the best way to hide an email address, so the display email should be within an image.
  2. There must be some semantic addition to the image in order to make it readable to special viewers. This solution is the alt attribute.
  3. An alternate email must appear in the alt tag (rather than the real email), along with a notification about the nature of this alternate email. This alternate email must forward to the real email account in order to serve its purpose. If this alternative email remains static for too long, spammers will find it and may begin to SPAM it. Therefore, this alternative email must be changed regularly, either with a script or manually.

Thus, the most optimal email masking method appears to be the one described in the three conclusions above: Modified Email Redirection.

Notes and Miscellany

A Good Example of MER

A good way to obfuscate your email address within an image is to use a graphical representation of your email's domain name. If you use an email provider such as Gmail, Yahoo!, or MSN, you could make an image using that company's logo, like:

name @ [LOGO IMAGE HERE]

The same can be done if you use your own domain name for email. Simply put your logo in there, or make a graphical version of your domain name.

Automation

I have yet to automate this process on my own web site, but I plan to do so soon. Automation can be done on many levels. I propose these levels of MER automation with web scripts:

  1. Level 1: The temporary email address is stored as a server-side include, so that it can be updated on the web with one change (once the webmaster has reprogrammed it on his or her server).
  2. Level 2: When run manually, a script creates a new temporary email address with forwarding configured, updates the server-side include file, and deletes the old temporary email address.
  3. Level 3: On a scheduled basis, a script creates a new temporary email address with forwarding configured, updates the server-side include file, and schedules the deletion of the old temporary email address within an appropriate time-frame (perhaps one or one-half day).
  4. Level 4: A server-side include is called with one parameter: the real email address. Upon being called, the include generates a new temporary email address, with forwarding configured, to be used only for its current call. On a scheduled basis, the script deletes old temporary email addresses within an appropriate time frame (as low as two or three hours).

Optional feature: Bounce-back support. Instead of simply deleting old temporary addresses, the script will send a bounce-back message after an appropriate time frame, explaining to users that the temporary email address has expired, and providing a link back to the web site to get the current temporary email address.

MER Automation Services

An MER automation service could be made as a public service to the webmaster community. The service would require webmasters to place a small piece of server-side code (perhaps written in PHP), which would request a temporary email address from the service's server, given the user's credentials. The service would process this request by creating a temporary email that will forward and expire according to the user's settings and then returning that email to the server-side script on the user's side. Such a service could even provide image-generation capabilities.

Image Splitting and CSS

MER could be more effective if multiple images were used to create the display email. In this case, only the first of such images would contain the temporary email in its alt tag. The rest of the images would contain a blank alt attribute.

CSS could be used to make this even more effective. To do this, an image would be placed inside of a div or some other appropriate element. This image would display a piece of the real email, and its alt tag would contain the temporary email. The div container would have its background set with CSS, so that its background image completed the display email by lining up with the image inside the div container. Doing this makes it even more expensive for programs to process the email address from within the images, since it could potentially involve parsing an external style sheet in order to get the location of the second half of the image.

I believe that this method of MER is the most powerful method available, since it would essentially require spammers to harvest emails by hand--by actually reading them from a web page and manually adding them to a list.

However, I have not tested this method for accessibility. I suspect that there may be some difficult problems with 1) the blank alt attributes of split images and 2) divs that don't contain any textual data, but are merely in place to display a background image. My expertise in accessibility is not good enough to predict what these problems may be, but I suspect that they will exist.

One pitfall of using CSS is that non-CSS browsers will not display the full email address, but rather a fragment. Those users may still be able to access the temporary email address, but it may be confusing and most users would not think to hover their mouse over an image for more information. This concern is picky, though. Most users nowadays have CSS support (especially for things as simple as backgrounds).

Conclusion

I have been using this method (updating manually) for about two months now. It has worked so well that I plan to automate it for my own site in the coming months. It can actually be miraculous to see how well it works. When one of my temporary email addresses sits for more than a few days, I see a spike in SPAM emails. But when I then change the temporary email address again, the SPAM stops immediately.

Please contact me regarding this method or any other methods that you know of. I would love suggestions for improvements, or some thought on any flaws in this method. If you'd like to email me, my address is at the top of the page.