Validate an E-Mail Address with PHP, the Right Way

if (!preg_match('/^(\\\\.|[A-Za-z0-9!#%&`_=\\/$\'*+?^{}|~.-])+$/',
str_replace("\\\\","",$local)))
{
// character not valid in local part unless
// local part is quoted
if (!preg_match('/^"(\\\\"|[^"])+"$/',
str_replace("\\\\","",$local)))
{
$isValid = false;
}
}

The regular expression in the outer test looks for a sequence of
allowable or escaped characters. Failing that, the inner test looks for
a sequence of escaped quote characters or any other character within a
pair of quotes.

If you are validating an e-mail address entered as POST data, which is
likely, you have to be careful about input that contains back-slash
(\), single-quote (') or double-quote characters ("). PHP may
or may not escape those characters with an extra back-slash character
wherever they occur in POST data. The name for this behavior is
magic_quotes_gpc, where gpc stands for get, post, cookie. You can
have your code call the function, get_magic_quotes_gpc(), and strip the
added slashes on an affirmative response. You also can ensure that the
PHP.ini file disables this “feature”. Two other settings to watch for are
magic_quotes_runtime and magic_quotes_sybase.

The two regular expressions in Listing 5 are appealing because they are
relatively easy to comprehend and don't require repetition of the
allowable character group, [A-Za-z0-9!#%&`_=\\/$\'*+?^{}|~.-]. Here's a
test for you. Why does the character group require two back-slash
characters before the forward slash and one back-slash character before
the single quote?

One deficiency of the outer test of Listing 5 is that it passes local part
strings that include dots anywhere in the string. Requirement number
two states that dots can't start or end the local part, and they can't
appear together two or more times. We could address this by expanding
the outer regular expression into form ^(a+(\.a+)+)$, where a
is (\\\\.|[A-Za-z0-9!#%&`_=\\/$\'*+?^{}|~-]). We could, but that
leads to a long, hard-to-read, repetitive expression that's difficult
to believe in. It's clearer to add the simple checks shown in Listing 6.

The local part is a wrap. The code now checks all local part
requirements. Checking the domain will complete the e-mail validation. The
code could check all of the labels in the domain separately, as does the
whiskey-loving code shown in Listing 2, but, as hinted earlier, the solution
presented here allows the DNS check to do most of the domain
validation work.

Listing 7 makes a cursory check to ensure only valid characters in the
domain part, with no repeated dots. It goes on to make DNS lookups for
MX and A records. It makes the check for the A record only if
the MX record check fails. The code in Listing 4 verified the
length of the domain value.

So, is it good? You decide. But, it would be nice to test the logic to
ensure that it at least is correct. Listing 8 contains a series of e-mail
address test cases that any e-mail validation should pass.

Be sure to run the test to see the valid and rejected e-mail addresses,
the double-escaping (\\) inside the PHP strings tends to obfuscate
the addresses. You're challenged to subject your favorite e-mail validation
code to this test. Be assured that the code in Listing 9 does pass!

Listing 9 contains a complete function for validating an e-mail
address. It isn't as concise as many—it certainly isn't a one-liner.
But, it is straightforward to read and comprehend, and it correctly accepts
and rejects e-mail addresses that many other published functions
incorrectly reject and accept. The function orders the validation tests
roughly according to increasing cost. In particular, the more complex
regular expression and, certainly, the DNS lookup, both come last.

Sure your DNS lookup up would fail, but what is the point of validating the format if you are just going to do a DNS lookup anyway for a domain name that should have already been deemed invalid by the format validation code.

Format validation and existence verification (DNS lookup) serve different purposes, and just because a domain name does not exist does not mean the format is not valid.

There are so many holes in your code, whoever paid you for this write-up is highly deserving of a total refund. If you are going to title such an article as "... the Right Way", you could at least do it the Right Way.

Backslash is not an RFC compliant component of an non-quoted email address local-part. May have been in the past, but not anymore, and has not be since the publication of RFC 2822 (2001). Move on folks.

Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters

! # $ % & ' * + - / = ? ^ _ ` . { | } ~

period (".") may also appear, but may not be used to start or end the
local part, nor may two or more consecutive periods appear. Stated
differently, any ASCII graphic (printing) character other than the
at-sign ("@"), backslash, double quote, comma, or square brackets may
appear without quoting. If any of that list of excluded characters
are to appear, they must be quoted.

Also the quoted string check appears would allow null (x00). According to RFC 2822 3.2.5. Quoted strings and 3.2.1. Primitive Tokens the permitted NO-WS-CTL characters are x01-x08, x0B, x0E-x1F, x7F. This does not include the null character x00.

Appendix B. Differences from earlier standards
Items marked with an asterisk (*) below are items which
appear in section 4 of this document and therefore can no longer be
generated.
12. ASCII 0 (null) removed.*