4 ms·

When is this needed? A one line regex can't get you far enough here?

Gigachad 4y ago
Unless you are providing a user with an email account and need to ensure it's 100% valid, it's not worth doing anything but the most trivial validation. It's far better to allow an invalid email to be entered than disallow a valid one. The real validation is sending an email to it and the user opening that link. If they managed that, then it's a valid email.
- jancsika 4y ago
  How about tiered validation: 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
dharmab 4y ago
Email address validation is non trivial: https://www.netmeister.org/blog/email.html https://www.netmeister.org/blog/email.html The only reliable method is to send an email with a token to the address.
stonogo 4y ago
"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.
98codes 4y ago
As someone who uses an email address in the form of <word>@<numeral>.<word>, I can tell you from lots of experience that entirely too many devs in the world thought "can't we just" and got it horribly wrong.
- theonething 4y ago
  This is the first result in Google for "regex for email validation" and it validates your email format correctly /^\w+([\.-]?\w+)@\w+([\.-]?\w+)(\.\w{2,3})+$/
0x457 4y ago
You can have a one line regex that validates email that are correct according to RFC. However, most popular email services don't care about that. A lot of "valid" (as in active emails on email service like Gmail) are not "RFC valid", some "RFC valid" emails are not valid to many email services and MTAs. 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.
- necovek 4y ago
  Nope, you can't. Email address are not defined with a regular language, so they provably can't be validated with a regular expression no matter how long.

Unless you are providing a user with an email account and need to ensure it's 100% valid, it's not worth doing anything but the most trivial validation. It's far better to allow an invalid email to be entered than disallow a valid one. The real validation is sending an email to it and the user opening that link. If they managed that, then it's a valid email.

jancsika 4y ago
How about tiered validation: 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

dharmab 4y ago

Email address validation is non trivial: https://www.netmeister.org/blog/email.html https://www.netmeister.org/blog/email.html The only reliable method is to send an email with a token to the address.

stonogo 4y ago

"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.

98codes 4y ago

As someone who uses an email address in the form of <word>@<numeral>.<word>, I can tell you from lots of experience that entirely too many devs in the world thought "can't we just" and got it horribly wrong.

theonething 4y ago
This is the first result in Google for "regex for email validation" and it validates your email format correctly /^\w+([\.-]?\w+)@\w+([\.-]?\w+)(\.\w{2,3})+$/

0x457 4y ago

You can have a one line regex that validates email that are correct according to RFC. However, most popular email services don't care about that. A lot of "valid" (as in active emails on email service like Gmail) are not "RFC valid", some "RFC valid" emails are not valid to many email services and MTAs. 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.

necovek 4y ago
Nope, you can't. Email address are not defined with a regular language, so they provably can't be validated with a regular expression no matter how long.