Validating an email address

[Tom Anderson]

Hi all,

A hoary old chestnut this - any advice on how to syntactically validate an
email address? I'd like to support both the display-name-and-angle-bracket
and bare-address forms, and to allow everything that RFC 2822 allows (and
nothing more!).

Currently, i've got some regexps which recognise a common subset of
possible addresses, but it would be nice to do this properly - i don't
currently support quoted pairs, quoted strings, or whitespace in various
places where it's allowed. Adding support for those things using regexps
is really hard. See:

http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

For a level to which i am not prepared to stoop.

I hear the email-sig are open to adding a validation function to the email
package, if a satisfactory one can be written; i would definitely support
their doing that.

tom

 

[Ben Finney]

A hoary old chestnut this - any advice on how to syntactically
validate an email address?

Yes: Don't.

<URL:http://www.apps.ietf.org/rfc/rfc3696.html#sec-3>

The only validation you should be doing before sending the message is
on the domain part. Since there are records available in DNS to
verify, you can check those. Is there an MX record? Is the address
valid? Do the mappings both way for that record make sense?

Please, don't attempt to "validate" the local-part. It's not up to you
to decide what the receiving MTA will accept as a local-part, and
(short of asking the MTA which most of them disable due to abuse by
spammers) you can't find out without just delivering the message.

So, once you've determined that you can reach the MX host, and that it
actually *is* the MX host for the domain, just deliver the message.

 

[Tom Anderson]

Yes: Don't.

<URL:http://www.apps.ietf.org/rfc/rfc3696.html#sec-3>

The IETF must have updated that RFC between you posting the link and me
reading it, because that's not what it says. What it says that the syntax
for local parts is complicated, and many of the variations are actually
used for reasons i can't even imagine, so they should be permitted. It
doesn't say anything about not validating the local part against that
syntax.

Please, don't attempt to "validate" the local-part. It's not up to you
to decide what the receiving MTA will accept as a local-part,

Absolutely not - it's up to the IETF, and their decision is recorded in
RFC 2822.

tom

 

[Mike Meyer]

Absolutely not - it's up to the IETF, and their decision is recorded
in RFC 2822.

Wrong. The IETF dictates what your MTA *must* accept, not what it will
accept. It's perfectly legal to accept more than what the IETF says is
legal. In fact the rule of thumb for interoperability (on the off
chance that anyone still cares about such) is "be generous in what you
accept, and strict in what you send", so you're even encouraged to
accept more than what the IETF says you have to.

If you didn't generate the address, you have no way of knowing if the
the receiving MTA will accept it or not without actually trying
it. Rejecting an address because you don't like it could break
perfectly functional email addresses.

<mike