Dominic Sayers

Comments in email addresses

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

I was turning a blind eye to the part of RFC5322 that allows you to put comments within an email address. But Cal H brought it up in an email so I had to bite the bullet. On reflection I think this was worthwhile. The most common error in email address validators is that they reject valid addresses. This really annoys people who like to put a '+' in their address and find they can't because registration form won't allow it. Why do they like putting a '+' in their address? Well it effectively tags the incoming email for you automatically. Mail sent to first.last+hello@example.com will go to the first.last mailbox, tagged with 'hello'. GMail will do this for you - try it. So that's why I think it's worth allowing comments. The next GMail might be able to do the same thing or something even more useful with comments: first.last(notify IM)@example.com Version 1.6 of my validator now passes all 222 unit tests. So does Cal's. I see no reason why you wouldn't use one of these in your project: they are free and they work. Why reinvent the wheel?

RFC nerd notes

Comments can contain folding white space and can be nested. This is the final nail in the coffin for regular expressions that claim to validate email address. Show me a regex that says this is a valid address: first(Welcome to  the ("wonderful" (!)) world  of email)@example.com A thank-you also to Paul Gregg who allowed me to add his validator to the head-to-head (and added mine to his page). He also provided some more unit tests.

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

Email address validation 1.2

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

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