Yeah no, if you try to check this into any codebase it should get rejected straight away. There is no need to regex emails pretty much anywhere, when you use an email for signup or similar you send a confirmation email which serves the same purpose - to make sure the address is valid and correct. Use `<input type="email">` or check that "@" is present if you must, but anything beyond that is nonsense.
That is fair, but I don't think it changes the outcome. The only way you can verify an email address is correct is to send a verification email. If you want to help the user ensure their input was what they intended, having two inputs for the same value is a better way to do that than a regex on a single field. As an example, my email is 20 chars long, the whole email regex thing only validates one or two of those 20 chars and doesn't help against typos in any way. In short, it's a lot of complexity without any real upside.
What exactly changes when validating in an email client? foo@localhost, foo@bar and f@b are all valid email address and your user may want to send an email to those address. There is literally nothing there for you to validate.
What are you talking about with the bcc thing? Generally you receive someones email address once, and then optionally verify. If you fill the To/Cc/Bcc fields from your address book, everything should be fine. If you insist on typing something yourself and you enter a wrong email address, it just doesn't arrive (or reaches another recipient, depending on the typo).
That neither solution proposed upthread - double inputs, or a verification email - is as user-friendly as catching "oops you forgot a dot" validation on the field in an email client.
I think you're wildly overestimating how useful that is compared to the complexity of the solution in the linked article. Mistyping a "," for a "." is as likely of a typo as typing "gnail" instead of "gmail". My personal email is over 20 characters long, and statistically nearly every typo I can make is something you simply can't check for.
To put another way, as anecdotal experience I've encountered many forms online that won't accept my email address or phone or whathaveyou because of buggy validation. I can't recall when I mistyped my email, but surely it's possible I've done it at some point, however the difference is in the price I pay. If I mistype my email and don't get a confirmation email or w/e I can always try signing up again. However if I can't use the form because the validation is bugged there is no straightforward recourse I can take as a user.
I know about this, but how many domains exists with just a root domain? The vast majority of cases, a missing dot is a typo. I also wouldn't want to imagine how painful using services must be with a foo@bar style address.
Why not reject invalid top level domains then? This is going to catch a vastly larger amount of typos (including foo@gmailcom) without eliminating any valid emails.
Gmail doesn't need to support "you own an entire TLD and use its root for email" use cases, so you can at least check for a dot after the @ and catch a bunch of typos that leave frustrated users.
I usually just test for the presence of @ - that’s it. Works for IDN addresses as well.
I remember some story back in the day where someone had an email address using the top level to domain only.
Like “x@to”, pretty cool but probably a pain to use (:
Use "mail.parse()" or whatever there is for your language. In general just parse stuff instead of letting some regexp loose on it.
For a quick check to make sure people don't mix up fields or accidentally hit enter before they finished typing, just /.+@.+\..{2,}/ is more than enough (technically foo@com is valid, but no one uses that – note that root@localhost or cron@sysops CAN be valid, so in some contexts you want to use just /.+@.+/, but that doesn't really apply for signups and the like).
