[Email-SIG] Email Address Validator
Matthew Dixon Cowles
matt at mondoinfo.com
Tue Oct 19 21:56:01 CEST 2004
> I think it would be great to a real world tested Email Address
> Validator in to the library. I have attached a python program that
> condenses all the Validator examples I found on the web. This is a
> good starting place although none of the examples return accurate
> results 100% of the time. So there is work to be done :)
A parser that fully implements RFC 2822's rules is pretty non-trivial
to write, I think. When I first read RFC 822, I remember wondering if
the authors were frustrated parser designers.
Even considering only the actual address ("addr-spec" in RFC
2822-ese), we have these rules:
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
dcontent = dtext / quoted-pair
dtext = NO-WS-CTL / ; Non white space controls
%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"
I think that a function that will check an address for correct syntax
would be somewhat convenient to have, but I think that one that's
right only 99% of the time would probably be worse than none at all.
In particular, I'd be rather surprised if someone could implement all
those rules with just a regular expression. Two of the four examples
you sent along don't like the (I'm pretty sure) legal address
"fred&barney"@example.com. And none of them like email@example.com
which isn't used much but I'm not aware of its having been declared
In your list of bad addresses, I'm pretty sure that "brian" and
"brian at localhost" are both legal.
I suspect that the lack of email address validators out there stems
both from the difficulty of writing one and the fact that they're not
all that critical. I've always thought that if the MTA can deliver a
message, that's fine. And if it can't, the user will get it back.
More information about the Email-SIG