Don't use regular expressions to "validate" email addresses

[Ben Finney]

Steve Holden <steve at holdenweb.com> writes:

> Ben Finney wrote:
> > The best advice I've seen when people ask "How do I validate
> > whether an email address is valid?" was "Try sending mail to it".
> > 
> That only applies if it's a likely-looking email address. If someone
> asks me to send mail to "splurge.!#$%*&^from at thingie?><{}_)" I will
> probably assume that it isn't worth my time trying.

You, as a human, can possibly make that decision, if you don't care
about turning away someone who *does* have such an email address. How
can an algorithm do so? There are many valid email addresses that look
as bizarre as the example you gave.

> > The sending system's mail transport agent, not regular
> > expressions, determines which part is the domain to send the mail
> > to.
> > 
> > The domain name system, not regular expressions, determines what
> > domains are valid, and what host should receive mail for that
> > domain.
> > 
> > Most especially, the receiving mail system, not regular
> > expressions, determines what local-parts are valid.
> > 
> Nevertheless, I am *not* going to try delivery to (for example) a
> non-local address that doesn't contain an "at@ sign.

Would you try delivery to an email address that contains two or more
"@" symbols? If not, you will be denying delivery to valid RFC2821
addresses.

This is, of course, something you're entitled to do. But you've then
consciously chosen not to use "is the email address valid?" as your
criterion, and the original request for such validation becomes moot.

-- 
 \        "During my service in the United States Congress, I took the |
  `\                 initiative in creating the Internet."  -- Al Gore |
_o__)                                                                  |
Ben Finney