Live data from Hacker News

Stop Validating Email Addresses with Regex (2012)

davidcel.is

211–220 of 228 posts

Re: Stop Validating Email Addresses with Regex (2012)

#211

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…

You can obviously warn the user, but it shouldn't be a strict validation. That's half of the point. It's probably a mistake if someone typed gamil.com instead of gmail.com, but it's not a mistake if someone typed pm.me (or something punycode).

Re: Stop Validating Email Addresses with Regex (2012)

#212
post #94

Earlier 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's a massive issue. It's not only spam, it also enables malware distribution and e-mail bombs (flood of mail to cause DoS or to hide some other letters).

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)

#215
post #76

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

network access itself is not necessary foe using various password managers, though of course for the majority of uae cases you'll require it anyway. But if you e.g. have a journal that is encrypted, you only need copy-paste.

Re: Stop Validating Email Addresses with Regex (2012)

#216
post #27

Here’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/...

2unusual4me

Re: Stop Validating Email Addresses with Regex (2012)

#217

Here’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

That dude gets it!

Re: Stop Validating Email Addresses with Regex (2012)

#218
It's complicated but thankfully you don't have to reinvent the wheel:

https://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)

#219

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

If people who use '+' on purpose are fewer than those who type it in error (who type bobsmith+ when they meant bobsmith0, then it might not be a good idea.

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)

#220
post #17

RFCs 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 thought they've rolled back most of this because it made phishing domains indistinguishable from the real ones?

I used an-emoji.my.domain for a while until chrome changed it back to punycode

Post reply on HN