I had some very helpful input from Cal Henderson on interpreting RFC 2822. I’ve included his latest validator in my head-to-head comparison and updated the test suite to reflect the consensus from our discussion.

I’ve also updated my own routine so that it still passes all the tests, of which there are now 158. As always, the full analysis is on my website and the latest version of the source code will always be in Google Code.

I would really appreciate it if you find a valid address that fails my validator, or an invalid one that passes, if you would get in touch with me and let me know.

Here are the latest scores:

Dominic Sayers: 100% validated correctly
Simon Slick: 91%
Cal Henderson: 84%
Phil Haack: 80%
Dave Child: 79%

I know Cal is working on IPv6 validation so this may change soon.

RFC nerd notes

There are two principle changes in this version.

Firstly, I now accept Dave Child and Cal Henderson’s opinion that a backslash can escape anything in a quoted string local element. However, it must escape something – it can’t be at the end of the string.

Secondly, if the string is not quoted then the local element must be a vanilla atom. You can’t escape individual characters unless the element is surrounded by double quotes.

By “local element” I mean a single component of a dot-delimited local part.

I’ve extracted the raw specification of a valid email address in BNF (Backus-Naur form) from RFC 5322 and put it here: The BNF from RFC 5322 defining parts of a valid email address. If you try to follow this in the RFC you end up going backwards and forwards and getting confused – it’s much easier to understand in the way I’ve laid it out.

Quick links: Source code | Email address validators head-to-head

OK, after some correspondence with Dave Child and Cal Henderson I have now released version 1.0 of my PHP email address validator.

This version passes all 139 unit tests in the suite – tests I have collated from RFC 3696 and from articles by Dave Child, Doug Lovell and Phil Haack plus some of my own to test the IPv6 address format. The full analysis is on my website and the latest version of the source code will always be in Google Code.

I would really appreciate it if you find a valid address that fails my validator, or an invalid one that passes, if you would get in touch with me and let me know.

Here are the scores on the doors:

Dominic Sayers: 100% validated correctly
Simon Slick: 86%
Dave Child: 81%
Phil Haack: 79%
Cal Henderson: 71%

For the RFC nerds, this version now correctly validates the obsolete local form of word *(“.” word). In other words you can regard the local part of the address as a dot-delimited series of elements each of which can be separately quoted. This means that first.”last”@example.com is now recognised as a valid address.

Quick links: Source code | Email address validators head-to-head

I’ve discovered a number of other public-domain functions that attempt to validate the format of an email address. I tried to validate my 124 test cases against these functions with the results below:

Dominic Sayers: 100% correctly validated
Simon Slick: 88% 
Dave Child: 80%
Cal Henderson: 72%

Interestingly, all the other functions failed correctly to validate the example addresses given in RFC3696 (Section 3: Restrictions on email addresses).

I couldn’t include Doug Lovell’s function in my tests because the code is copyright All Rights Reserved by Linux Journal (ironically).

Some of the other functions also supply test cases; I’ve added these to my test suite. More analysis and commentary here: RFC-compliant email address validator.

In summary, I recommend you use my function if you want totally RFC-compliant address validation.

Quick links: Source code | Email address validators head-to-head

There’s a gazillion regular expressions out there that claim to validate an email address. They don’t. Doug Lovell explains why here. The function that Doug made for his article is good, but it delegates the validation of the domain part of the address to the DNS servers of the world. This is a good approach but there are three issues with it:

1. The RFCs reluctantly allow you to use an IP address rather than a domain name, so you need to check for that.
2. The DNS may not be available to your function at the time it needs to check the address (maybe it’s an intranet application)
3. There’s no need to add extra workload to the DNS servers of the world if the address is wrongly formatted in the first place.

So I’ve come up with a PHP function that validates all parts of a given email address, according to RFCs 1123, 2396, 3696, 4291, 4343, 5321 & 5322. I’ve released it under a license that allows you to use it royalty-free in commercial or non-commercial work, subject to a few conditions (Doug Lovell’s function is All Rights Reserved by Linux Journal so you can’t use it for anything).

It’s almost certainly the first email address validator that correctly lets you put an IPv6 address in for the domain part…

I’ve also included a lot of unit tests, including all Doug Lovell’s examples and all the examples of valid addresses in RFC 3696. You might try running these test past your current email address validator. Prepare for the same nasty surprise I got :-)

The source code is available here.

Quick links: Source code | Email address validators head-to-head

More details here: Generating Dynamic CSS with PHP

I’ve left the demonstration in place here: Dynamic CSS MIME demonstration but adjusted the text to make it clear I was at fault, not the browser.

Why do the other browsers behave differently? Well the CSS was returned to the page within an element of the page’s header that declared the contents to be text/css so it was fairly easy for a “smart” browser to guess my intention. And also quite easy for me to make the fatal assumption that that was enough.

We live and learn. And Firefox is a strict mistress.

I’ve put a demonstration of the problem here.

I’m surprised that Firefox behaves so differently from other browsers. We all know which browsers we think are non-standards-compliant. If I’d been posting this about an Internet Explorer behaviour then I wouldn’t have expected any surprise or sympathy. But Firefox. I’m getting cramp in my eyebrows – they’ve been permanently raised since I discovered this.

I’m hoping there’s a way I can code round the problem. The latest version of Firefox (3.0.2) still exhibits this odd behaviour.