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…
I can assure you that this would end up with far more problems than it will solve. I run an online store, people miss entering their email address is one of the largest causes of customers contacting support, and they regularly jump to being angry accusing us of being incompetent or worse. I would take the 0.001% of people who may have an email incompatible with a regex being frustrated (which will happen to them all…
Stop Validating Email Addresses with Regex (2012)
211–220 of 228 posts
Re: Stop Validating Email Addresses with Regex (2012)
#212Earlier quoted context omitted.
What's much more important than validating the syntax of the e-mail is not to let your service be turned into a relay for targeting e-mail addresses of third parties with "backscatter". Don't put up a web page where any visitor can put in an e-mail address, to which you send something, without any safeguards: like not sending to the same e-mail address more than just several times in a 24 hour period or something. Ha…
I got some like that just last week. They were using a public sales quote request contact form, filling it with a bunch of random characters except for a valid email address and the name, which was something like "♥ Martha wants to meet you! Click http:// ... ♥"
It is mostly because proper defenses against such abuse aren't built into software allowing such forms (or cost money). Wordpress form plugins are one such widespread bad example.
Re: Stop Validating Email Addresses with Regex (2012)
#213Re: Stop Validating Email Addresses with Regex (2012)
#214Re: Stop Validating Email Addresses with Regex (2012)
#215Earlier quoted context omitted.
And being bond to some database? That is... not for everyone. Password manager is good if it is planned to share all my passwords after my death with my family, for not gifting my funds to some random guys. In every other cases it sucks like Sasha Grey (from my lifestyle's point of view which involves heavy use of random devices most of them even does not support any passwd mngr).
> In every other cases it sucks It doesn't for basically everything I do, and I have a lot of systems, subscriptions, and profiles to worry about. > random devices most of them even does not support any passwd mngr In the simplest case, 2 things are needed to support a password manager: Network access, and copy-paste.
Re: Stop Validating Email Addresses with Regex (2012)
#216Here’s the regex you should use: .+@.+\..+ Works every time 100% of the time.
Famously won't work for n@ai, either with or without the trailing period to ensure global name resolution. The .ai is one of a rare few ccTLDs that have (or had) top-level MX and A records. https://mail.gnome.org/archives/evolution-list/2002-January/...
Re: Stop Validating Email Addresses with Regex (2012)
#217Here’s the regex you should use: .+@.+\..+ Works every time 100% of the time.
Haha I like the other poster dude's suggestion of just letting it through if you see an @ symbol. Wouldn't yours work with potentially too many weird character sets? probably language/runtime dependent
Re: Stop Validating Email Addresses with Regex (2012)
#218https://github.com/JoshData/python-email-validator (my project)
The README covers a lot of ground: internationalized domain names, internationalized local parts, SMTPUTF8, Unicode normalization, not performing SMTP checks, not permitting obsolete email syntax, and missing UCS-4 support in Python 2.7.
Re: Stop Validating Email Addresses with Regex (2012)
#219Earlier quoted context omitted.
You might want “clean” or “normal” addresses too (for whatever reason). For example, disallowing “+” would just give you the canonical email instead of one that risks being tagged with a unique ID revealing who leaked it. Being too generous in the early input validation regex (e.g just check for non empty and containing one @) risks making registrations fail and customers not returning. This seems like a much bigger…
`+` is a legal part of the mailbox name everywhere but gmail (and gmail clones). Broken "checks" like these are exactly what the simple validation is avoiding.
The entire argument I was trying to make was that what constitutes a "legal email address" is not always what you want to validate. That some providers allow using '+' isn't as important as the number of users that actually do. If some nontrivial number of users use + on purpose, then don't reject them.
Re: Stop Validating Email Addresses with Regex (2012)
#220RFCs for email addresses are cool, but on the web we have our own standards! 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 manner…
One important aspect of this that I often see people forgetting is that this check is designed for working with ASCII, but the domain name at least can be non-ASCII. User interfaces should remember to support IDN in domain labels and convert it to punycode before validating, and if you store A-labels (which you probably do) then convert it back to IDN form when presenting it to users. (Alas, still doesn’t support non…
I used an-emoji.my.domain for a while until chrome changed it back to punycode