11–20 of 228 posts
I appreciate the idea here but generally you set a non perfect regex expression and just roll on with whatever other verification there is (send email). Well I don’t but if you did I don’t see much harm. I won’t ask people to type the email twice, that’s just annoying.
Can't upvote this enough. There simply is no need to check the email addr provided by the user. Send the mail, if it bounces, the user has only himself to blame. What if I don't want them to go through the hassle of an activation link? Then I don't bother with an email account in the sign-up process in the first place. If they want a passwd reset method, they can later provide an email in their settings page, if that…
Bouncing usually requires money
1) Consider if you really even need to verify that email address. Why are you collecting email in the first place, why do you need it? HN is a great example of this - email totally optional, if you forget your password it's on you. Lot of online services going in the wrong direction with requiring a phone number.
2) Trust the user. Okay to give them nice nudges ("you probably meant gmail.com and not gmail.co") but if I really did mean gmail.co, let me through if I insist.
Don't throw up a garbled mess of a Regex[0] that only serves to frustrate me when I try to sign up with my vanity email. I'll abandon the sign-up entirely.
[0]: https://stackoverflow.com/questions/20771794/mailrfc822addre...
I'm happy for my service to quickly and correctly validate 99.999% of emails and I don't really care if your oddball edge case emoji Sanskrit 6-level-deep domain fails. Just do normal stuff.
For example, control characters, line breaks, shell escape characters, SQL injections, or simply uploading an ISO image into the E-mail field.
There is the RFC, and there is what we would nowadays consider a sane E-mail address. Nobody has addresses with spaces, nor does anyone have an address with an IP literal in it. Why? Because no other system will accept it. Think bank, etc.
TL;DR at the very least you need to validate field length, control characters, quote signs, and backslashes. Those have no business being in am e-mail address.
.+@.+\..+
https://html.spec.whatwg.org/multipage/input.html#valid-e-ma...
"This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."
The regex is:
/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/
Chromium:
https://source.chromium.org/chromium/chromium/src/+/main:thi...
WebKit:
https://github.com/WebKit/WebKit/blob/0d7afc5a45c140c44497a8...
Yes, do verify email addresses by sending a confirmation link if you bind users to their email addresses, though. Don't confuse validation with verification.
Also, never check file existence.
These things just take up time, introduce race conditions, and can't be trusted anyway.
That said, there are reasons to want to check some things with UI-level validation because calls to a slow back end are slow. Thus the name. I get that.
So if you're doing UI validation, don't get it right. Just get it mostly right. And do it fast. Cheat!
/[^ ]+@[^ ]+/ is OK except for trailing punctuation, double @'s, and it definitely doesn't work with that quoted example. The first Rails one in this post /\A[^@]+@([^@\.]+\.)+[^@\.]+\z/ is at least better than what I came up with - I'll take a battle-tested regex if it's on offer.
daydreams about strong cryptography