4 ms·

"Mastering Regular Expressions" from O'Reilly covers regular expressions to validate email. The resulting regular expression is dozens of lines long. Consider

"Mastering Regular Expressions" from O'Reilly covers regular expressions to validate email. The resulting regular expression is dozens of lines long. 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 A one line regular expression won't do much but block valid users. As has been said often in this thread, the best way to validate an email is to send to the address and confirm delivery through user interaction. Everything else is half-measures, often doing more harm than good.

hanoz 4y ago
Interesting list, and I'm surprised by most of them, but part of the reason for that is that literally no-one uses email addresses like that.
- kjs3 4y ago
  I have seen addresses like at least 4 of the 8 in the wild in recent memory, tho to be fair it may be longer than 10 years for #8 (not many folks use UUCP for email any more). "I haven't seen" != "no-one uses".
chrismorgan 4y ago
The first three aren’t valid. As far as I can tell, RFC 3696 accidentally invented unquoted escaping there, which is not permitted by RFC 822, 2822 or 5322. The errata are a doozy <https://www.rfc-editor.org/errata/rfc3696 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 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.

hanoz 4y ago

Interesting list, and I'm surprised by most of them, but part of the reason for that is that literally no-one uses email addresses like that.

kjs3 4y ago
I have seen addresses like at least 4 of the 8 in the wild in recent memory, tho to be fair it may be longer than 10 years for #8 (not many folks use UUCP for email any more). "I haven't seen" != "no-one uses".

chrismorgan 4y ago

The first three aren’t valid. As far as I can tell, RFC 3696 accidentally invented unquoted escaping there, which is not permitted by RFC 822, 2822 or 5322. The errata are a doozy <https://www.rfc-editor.org/errata/rfc3696 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 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.