Is_email()
github.com
github.com
(The fact that an email address is syntactically valid is a matter for SMTP/MTA implementers and syntactic validity doesn't mean that an email address actually receives mail.)
It also has a thresholding system to allow you to pick how quirky the email addresses (and therefore, how full of typos) that you accept can be. You can set it up to accept RFC5322 addresses and tolerate up to certain levels of errors.
The default is just "valid syntax", but DNS lookups and domains that violate the SMTP spec are tolerated if you use the (demonstrated) ISEMAIL_THRESHOLD check.
I think this is the best email address validator I've seen. It sticks to the standards, at least those relevant when the software was last maintained, and doesn't do anything silly like regex checking.
Validating through a mail server that just tries to send an email and hopes nobody made a typo is a burden on most users (typos are easy to make and weird email addresses should show a warning, though only completely invalid addresses should show an error) and can even lead to IP reputation damage for the mail server.
If you need anything more specific the best bet is to try send an email to it.
And yes, those should be defended when constructing the mail, but checking early doesn't cost much.
Honest question! I'd love to hear the details of any specific case where one has ever been used.
Point is that checking whether something is a valid email or not is 1179 lines long (I know there are a lot of comments). Particularly interesting is to look at all of the possible error conditions, and the fact that "whether a string is an email address" is not so much a binary yes-no, but the library provides a "likeliness threshold" option.
Essentially just pointing out that checking if a string is/can be an email address is surprisingly complex.
This library runs the risk of blocking actual, working email addresses.
According to W3Techs, WordPress powers 43% of all the
websites on the Internet, including those without a
content management system (CMS) or with a custom-coded
CMS. Or to put it another way, WordPress powers over
one-third of the web! And if you limit the data set
to only websites with a known CMS, WordPress’ market
share gets even more dominant.
In that case, WordPress holds a 65% market share
for content management systems on websites with a
known CMS.
I'm curious to know if there are some important cases where someone would prefer to use the function OP shared instead.
https://core.trac.wordpress.org/browser/tags/6.1/src/wp-incl...
if ($email =~ /@/) { ... }Maybe if I spent more time with that style, it would click for me?
1. I'll let you pass no questions asked:
* gotta have that '@' sign
* left of '@' sign must have greater than zero characters-- a-z, 0-9, dots are cool, plus whatever the rules are for international characters
* right of '@' whatever the rules are for domains
2. Pay me $1.99 through stripe to continue whatever you're trying to do, every time you're trying to do it:
* you've got double quotes, spaces, or other "actually, emails can contain..." bullshit in the local part of the addy
Consider RFC 3696, "Application Techniques for Checking and Transformation of Names". The author provides some example valid email addresses:
Abc\@def@example.com
Fred\ Bloggs@example.com
Joe.\\Blow@example.com
"Abc@def"@example.com
"Fred Bloggs"@example.com
customer/department=shipping@example.com
$A12345@example.com
!def!xyz%abc@example.com
The errata are a doozy <https://www.rfc-editor.org/errata/rfc3696>, with a bad correction verified, a bad correction of that correction verified, and a reversion of the two incorrect corrections with incomplete justification (not quite mentioning the root cause, that you can’t actually use backslash-escaping outside a quoted-string like the RFC deliberately did) “held for document update” (which I suspect means that the reviewer finally realised the actual error, and decided it was too large to deal with with this way, but there are no verifier notes and I don’t know where the errata discussion records are, if they’re even public).
I wrote more, but it becomes all messy and confusing and I think I just discovered that according to RFC 2822’s and RFC 5322’s grammars, a space inside a quoted-string would actually need escaping, which would ruin "Fredd Bloggs"@example.com, which is widely understood to be valid. (This is because qtext lacks %d32 (space), which I think is accidental but it’s not entirely clear—it’s all bound up in the painful question of whether space is printable or not; see also <https://www.rfc-editor.org/errata/eid4692>. But their intent was clearly for space not to need escaping, as various examples all over the place use spaces unescaped in quoted-strings.)
So… I’m going to tip-toe gently away now and stop thinking about email address syntax for the rest of the day if I can help it.
"I haven't seen" != "no-one uses".
/^\w+([\.-]?\w+)@\w+([\.-]?\w+)(\.\w{2,3})+$/
The only reliable method is to send an email with a token to the address.
Realistically, trying to validate email if you aren't in the business of providing an email service is a fool's errand that doesn't bring much to the table.
However, ISEMAIL_DNSWARN_NO_RECORD is defined as 6, still lower than the ISEMAIL_THRESHOLD (16) used to indicate a warning rather than an error.
define('ISEMAIL_STRING_AT' , '@');
define('ISEMAIL_STRING_BACKSLASH' , '\\');
define('ISEMAIL_STRING_DOT' , '.');
define('ISEMAIL_STRING_DQUOTE' , '"');
define('ISEMAIL_STRING_OPENPARENTHESIS' , '(');
define('ISEMAIL_STRING_CLOSEPARENTHESIS', ')');
define('ISEMAIL_STRING_DOUBLECOLON' , '::');
define('ISEMAIL_STRING_IPV6TAG' , 'IPv6:');You could do it with namespaces and `const` though to be less verbose.