Overview of the different ways of protecting your email address

You surely know that displaying an email address as plain text in a website today is a sure way to get your mailbox full of viagra, rolex and poker ads in no time.

Spammer have bots running all day long, crawling through hundred of thousands of pages, grabbing everything that looks like something@somewhere.com.

Existing way of protecting your email address

The safest way is to not display it in the first place. Nothing beats that. But if you really need to be contacted through email, here are some of the possible alternative.

Using a contact form instead.

That's what I'm doing on this site.

This way I don't have to display my address, I let my server script send the email for me.

Unfortunatly, it means that you have to protect your contact form against spam now. How to do that is not the scope of this post, however.

Using an image

Instead of writing your email as plain text, you can use an image inside which your email is written. Spam bots can't read images (well, they could but they won't bother when there is still so many clear email they can grab without worrying about images).

Unfortunatly it has two drawbacks. First, you force your reader to type your email as they can't copy/paste it. This lead to possible typos, and more importantly will frustrate your user.

Secondly, people browsing without images (yes, that does exists, either because they have a slow connection, browsing through an old mobile phone or using a text reader) won't be able to contact you.

Spelling it aloud

One of the better way is still to appeal to the human brain and telling your user what your email is, like "my name, at, my domain dot com" or "tim@nowhere.com where you have to change nowhere to pixelastic".

I've even seen someone using the very long form of : "tee ee em at pee hi ex ee el ah ess tee hi see dot see oh em". Sure, spammer won't get that, but the truth is, not many user won't either.

The drawback of this method is the same as the previous one, you force your user to type your address.

Ain't there an easiest way ?

Would'nt it be better if we hadn't to worry about that. If there was a way that all our reader would read the email, click on it and send us a mail ? While being protected from spam bots ?

Well, there have been attempt to do that, using various server side and client side techniques. Unfortunatly, all of them failed for at least one type of users.

Encrypting email using unicode

One can encrypt any string in Unicode using server script language. It will turn every character into an entity like .. Your browser will stil understand it correctly, and display it as the corresponding value.

We could assume that bots won't understand it, but I have no data to back that up. It would be trivial for an harvest bot to parse email using unicode, so I won't recommend it.

Using CSS to display the mail

Modern browser, with great CSS support can help in this process with the use of generated content and the :after pseudo class.

Let's look at the following code :

<span class="email" rel="@pixelastic.com">tim</span>

span.email[rel]:after {
  content: attr(rel);
}

You just put your username in the span, and the domain name in the relattribute and let CSS display it as one single email address.

But you need a browser with a correct CSS support to do that, otherwise you will only see the user part, which is not really useful.

Using an HTTP redirect

This one is a clever one that I haven't seen used a lot. Instead of making a link to a mailto:, you make the link go to a mail.php page that will only contain one php statement :

header('Location: mailto:user@domain.com');

I'm not sure of the browser support of this, however. And it still won't solve the problem of displaying your email address.

Adding HTML noise

You can add HTML comments (<!-- -->), or useless elements (<span />) all around your email adress. They won't get processed by your browser that will still display it as normal, but it will most likely make the spam bot choke.

Unfortunatly, you can't use them in the href="mailto:" section of your link, so it is not a perfect fit either. But still, that's a good start.

Using Javascript to populate the email

The principle behind this one is that Javascript will write the email adress for you in the code. As most spam bots won't have Javascript enabled (again, I don't have source to back that up but I assume so), they won't be able to see it.

Just write your email address in a Javascript file, maybe in several different variables that you'll merge to create the final one. The more obfuscated your code is, the harder it will be for the spammer to add its logic to its bot.

Conclusion

There isn't one perfect solution yet. But maybe, merging several of them we could bypass the weaknesses to create something that really handle all the situations.

I have some ideas in the back of my head actually, I'll try to make something with them and post it here.

I'm pretty sure starting with an obfuscated HTML source (but still correctlt displaying), then adding an obfuscated Javascript layer to create the mailto: link is the way to go.

This would mean a better user experience for users with Javascript, but that's ok, that's what Javascript is for.

Opera bug : border-radius and background-color on an input

The form inputs of this site all have a border-radius and a background-color. Unfortunatly, the latest Opera version just don't like that (9.5 works like a charm).

When you apply the following rules to an input element, Opera will discard your background color and render it as transparent instead.

input {
    border-radius:5px;
    border:none;
    background:#375a5e;
}

All three rules causes the bug. Remove one of them and the bug disappear.

Solution

At first I thought that I could just as well remove the border-radius rule and I won't have any more bugs. But a slightly decreased user experience for my Opera readers.

Then I'll try to come up with a better solution. One can add a background- image instead of a background-color. Odd enough, this won't trigger the bug.

But I wanted to avoid that, that's one more useless request to the server and it's far more easier to change a color code in a css file that to edit an image file.

The solution I choose was to not set a border:none; but to simulate it by adding invisible border. That would add 1px around the input element, so we'll limit it by only adding the border on one of the sides. Adding it on the right side seemed to be the more convenient method.

So here's my updated code :

input {
  border-radius:5px;
  border:none;
  border-right:1px solid rgba(0,0,0,0);
  background:#375a5e;
}

New website

I just uploaded the new version of the website. The old one was severely needing a fresh new look, so here it is.

As I want to showcase my skills as a web developer I didn't want a website with a too awesome design, so I decided to do it all by myself. I'm quite happy with the result.

The "Work" page is still in progress, images from the old site aren't yet available and I haven't yet tested it with IE.

I've added a comment section (a feature that was lacking from the previous site). I plan to translate the site in French to have something fully bilingual, but that too is a work in progress.

If you ever spot a bug, just drop a comment, I'm hunting them right now.

Migrating mails from IMAP to IMAP (part 1/2)

One of my clients wanted to change its hosting provider because of almost constant downtime. I suggested that we move the whole site and the associated email addresses to Dreamhost.

He is heavily using its webmail, with a dozen of different accounts, all with custom address book and drafts to reuse.

I had already moved a previous site of the same client to a GMail powered webmail and he wasn't so satisfied of it because of the lack of a "draft" feature that would allow him to reuse the same message templates.

Its current webmail is powered by Imp (Horde) and the default Dreamhost webmail is Squirel Mail.

So now I'm faced with a challenge. Which webmail should I choose and how will I initiate the migration ?

Contestant 1 : Horde

The easiest way would have been to reuse Horde. Horde has a nifty export/import function. It means that I could have exported the settings on the current host and imported them back in the new host.

Unfortunatly, Horde is not pre-installed on Dreamhost. It means I would have to install it and I don't really want to do it. This is not my area of expertise and if something goes wrong it will take me ages to fix.

Additionnaly, the default php5 install on Dreamhost lacks the IMAP extension needed and SSL connection requires an additional monthly fee.

That would be the better solution for the client, but I don't feel capable of doing it.

Contestant 2 : Squirel Mail

Squirel Mail is the default webmail on Dreamhost. It means that they do handle all the heavy stuff of configuring it and making sure it does not crash.

They assure me that I can have unlimited hosting of my mails, the only limits are a maximum of 100 SMTP sending per hour and no attached filed > 7Mo.

Those are almost no issues at all, we can handle that. I just have to check if the 100 sending per hour is for each mail address or for the entire account.

The only problem will be that I can't export/import the horde feature into Squirel.

What I could do however is synchronize the two IMAP servers, effectively copying all the mail from the current one to the new. Unfortunatly, there is no easy way to do that.

The Dreamhost support even told me that it was impossible. I found a linux command named imapsynch however that maybe could help, but I'll need to know the name of the dreamhost imap server and needed credentials to connect to it. I'll sort this out with them.

Contestant 3 : GMail

I've already set mails up with GMail a couple of times in the past so this won't be too hard. Could take some times, but nothing difficult about that.

I may be able to copy the current mails to the GMail server, I've seen some articles on the subject floating on the network, but I'll definitly won't be able to copy drafts.

Conclusion

I'm still in contact with the Dreamhost support to choose the better option. I don't think I'll install Horde, this will be too much work. I guess I'll go with the second option of migrating mails to Squirel Mail.

Whatever solution I'll pick, I'll be sure to post the whole details here for others to follow.

Update

I finally won't have to migrate mails, the client makes regular POP backup of its mails so he will just do one more right before the transfer and will start over with a brand new mail boxes. Concerning the drafts, he will manually copy-paste them from one webmail to the other and he told me that he wasn't using the address book...

So it appears that I'll just have to change the DNS to point to the new webmail and create a temporary CNAME to still access the old webmail on the old server until the migration is totally over.

Re-update

In fact, it appears that I won't be able to access both webmail at the same time. I'll have DNS issues, and the registrar panel that I have is very basic, I won't be able to fine tuned it correctly.

It seems that I'll have to migrate mails from one server to the other.

Pros and cons of using Google CDN for your assets

With the recent Google Fonts breakout, much debate surfaces to know if it really was useful to use Google CDN to deliver your assets to your users.

I used to think it was a goog thing because it allowed for parallelized download, but after reading really good articles on the subject I'm not so sure.

I'll try to list the pros and cons of using Google CDN instead of serving your files locally.

Pros

• Using a CDN assure you that your users will get content from the closest server around them, no matter where they are.
• The more websites will use Google CDN, the biggest the chance of your user already having the file in its cache
• Downloading from a CDN assure that you won't be sending useless cookies along the request. You shouldn't send cookies when fetching your static files anyway, but sometime -Google Analytics for example-, some script create domain-wide cookies that still get sent.
• Many niched major websites (ArmorGames.com, StackOverflow.com, etc) uses the CDN, so if a large part of your trafic is coming from one of those, using the CDN and the exact same library version will have no perfomance downsides for you.

Cons

• Using a CDN create a new connection to access the ressource on an other server instead of using the already open connection to your website. Creating a new connection is slow.
• Caching of the files will only be possible if the exact same version url is used. E. using /jquery/1.4.0/ instead of /jquery/1.4/
• If you already are using your own CDN for your images, you should also use it for your javascript and in this case the google one is worthless because you already have all the advantages.
• An Internet connection is required. This may seem obvious but if you have to work on a project while on a trip, you'll need a local copy of the library.

Stalemate

• Using a CDN force a DNS lookup. This lookup can be cached if the user already visited your website or another that use the same CDN however.
• Browsers have a limit of paralels downloads on the same host. Using a CDN allow for more parallelization. But creating dummy subdomains like static.domain.com would also defeat this limitation.
• In the case of Javascript/CSS, packing all your files (scripts and libraries) in one big file on your server and serving it gzipped will result in a better compression that serving the library from a CDN and your scripts from your server. On the other hand, the user would have to re-download the whole package whenever you make a tiny change to your scripts, even if you didn't changed the library.
• Downloading script usually block page execution. So reducing the number of scripts to load (by packing them in one file instead of downloading one locally and one on the CDN) will reduce the blocking time. On the other hand, merging two files will result in a longer download time (because the file is larger) while using the CDN would allow the two scripts to download in parallel.
• What happen if your CDN is down ? Well, when using Google that's not much a risk but still. As a side effect, you should'nt even consider using a CDN if your application is for an intranet.

Conclusion

As a conclusion, all I can answer to the "Should I use the Google CDN for my javascript libraries ?" is "Well... it depends...".

Really it depends on your configuration. Run some tests, try with a CDN or by compressing the library into your main file. Check where your users are coming from and the average loading time. Test various configuration until you found the one that works the best for you.

On a personal note I do use Google CDN for my websites. The cost of the DNS lookup and connection to the Google server is really worth the parallelized download in my case. But it may be so because I'm living in France and my website is hosted in the US, so a CDN really helps.

Source links

• http://docs.google.com/document/pub?id=14Xn7kkKwVxSie6xHJwWRAP5mutM7qlWcrHgWtZo63gI
• http://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns