Email Validation Rules | Hacker News Reader

Email Validation Rules

rumkin.com

34 pointsnvr21937 comments

I feel like people really overthink email validation. I just look for an "@" and a ".". If you really need proof that an email address is valid, send an activation email. Otherwise, who cares if a few emails in your database are invalid?

Additionally, lots of 3rd party mail systems have some mechanism to notify you of bounced emails, so you'll figure out which are invalid at your first attempt anyway.

Definitely, spending time validating email is useless. Look for an @ to make sure the user didn't mistake the email field for the name field and send him a confirmation email if you really want to be sure.

I'd even drop the '.' requirement. Look for an @, then send a confirmation email. Done.

Requiring a dot breaks your form for people using bare TLD email or people using an IPv6 address instead of a domain.

There's a sufficient mass of people with dots in their e-mail addresses that it's worth checking for an at and a dot, even if you don't require it - just to check that they haven't typed a comma or something instead.

The HTML5 standard prescribes a regex for implementers to validate email addresses on the client side:

  /^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

So if you're going to use <input type=email>, you might as well use the same check on the server side.

I found this talk by Ricardo Signes on email parsing to be an excellent primer into why email addresses (and emails in general) are terrible to parse: http://youtu.be/JENdgiAPD6c

Informative and entertaining, thanks.

Yep. I'd like to add that some ESPs have their own additional restrictions on mailbox names, plus it's usually helpful to verify the existence of the domain part (DNS) because people make mistakes all the time.

We (Mailgun) have a free service which does all of these things: http://blog.mailgun.com/post/free-email-validation-api-for-w...

It's also trival to contact recipient STMP server and check if it accepts rcpt to.

The practical way to validate an email address is:

1: Does the domain part have either an MX or A record? 2: Does the address in that record accept mail? 3: Does the server that accepts mail at that address respond favorably to the local part as a RCPT TO argument?

If yes, it's a valid email address.

In particular this article is wrong that emails are always 7-bit. With SMTPUTF8 you can put whatever you want in there.

Would you mind expanding on how to implement these steps, or do you know a good reference?

Here's a gist showing the basic steps, using the unix utilities host and netcat: https://gist.github.com/jwmerrill/6502014

That was "Email validation for pedants".

Practically speaking, the following regex -

  /^[_\.0-9a-z-\+#]+@([0-9a-z][0-9a-z-]*\.)+[a-z]{2,6}$/i

coupled with a DNS check for domain name is yet to generate a single false negative in years that we've been using it across multiple projects.

(edit) Do read through the thread below before getting all downvote happy.

Sorry, just broke your regex.

    hello@visit.melbourne.

Yes, that's a valid TLD now.

No, it's not - http://en.wikipedia.org/wiki/List_of_Internet_top-level_doma...

If you are referring to {2,6}, then it's easy to adjust once longer domains are put to actual use. If you are referring to the trailing dot, then that's exactly what I was saying - practically, email formats that are used by real people is a much simpler subset of what's permitted by the spec.

Yes, it is, or at least close enough that you should be considering it.

http://newgtlds.icann.org/sites/default/files/ier/hu62oef5uc...

gTLD can also contain punnycode/unicode now, which additionally breaks your regex in another way.

"Close enough" doesn't count :)

It does for all the irritated people that can't use their new domains on the tens of thousands of systems with rigid regex like this. Even if it's not breaking anything today, it's certain it will in the future.

It "doesn't count" for melborne TLD that currently sits in the "Initial Preapproval" state.

--

But more generally, you just don't want to hear what I'm saying.

Right now, people do NOT use email addresses with internationalized domains, they do NOT put trailing periods in domain names, etc. Once they start doing that, the regex can be adjusted to accommodate for that on first false rejection. As it exists now, the regex is tailored exactly to how emails are used now, by real humans. A negative is an indication of a bot activity or some other oddity that needs attention. Feel free to support that transparently, but the question is why would you want to do that.

> for that on first false rejection.

This assumes that you manually verify every rejection, or that they contact you. In other words: Either you're not using this anywhere with volume that matters, or you don't know that it hasn't caught false negatives.

> A negative is an indication of a bot activity or some other oddity that needs attention

High volume of negatives is an indication of bot activity or some other oddity. A single or handful of negatives is just humans going about their business as horrible typists.

If your volume is small enough that you can treat every negative as something to investigate, you really have no basis for saying anything about how well your regex works.

It's not the Gmail-level volume, but it's an email per day either. And yet there is still very few negatives, so it is possible to go through them by hand. Vast majority falls into "fafafa" and "test@test" category. The remainder is typos, e.g. commas instead of periods.

> A negative is an indication of a bot activity or some other oddity that needs attention. Feel free to support that transparently, but the question is why would you want to do that.

Why?:

It's very bad UX to say to a human "we don't support you because we think you just might be a bot".

I did actually use an interesting domain for a little while, but got completely fed up of it being rejected everywhere.

Why do you want so much to limit to 6, especially since you also do a DNS validation?

You should better lean on the permissive side; that would be one less thing to think about.

That kind of "validation" does not check for existing email addresses anyway, so there is not much value in trying to be strict in this area.

Yeah, I agree in principle, but it's at 6 simply because it works fine as is. Given new developments it might make sense to bump it up and/or add support for punycode, and we'll do it once it's actually needed.

What is the threshold where supporting a domain becomes important? It seems awfully arbitrary to say it "works fine as is" when it is disenfranchising millions of registered domains as it stands.

Forget new gTLDs, the current ones are tricky enough:

http://publicsuffix.org/

how do you test for false negatives?

By manually going through the log of rejected email addresses.

Amongst other problems, that limits TLDs to 6 characters, which is about 16 characters shy of the longest TLD right now in the DNS root zone: https://data.iana.org/TLD/tlds-alpha-by-domain.txt

Add to that the fact it would fail on a legitimate top-level domain like .рф or .中国.

It's funny that that is the easiest thing the author can do to summarize the rules.

I'd think a grammar (http://www.ietf.org/rfc/rfc2822.txt) would work just great.

There's no mention of minumum email length length, but I have noticed that some services do not accept email addresses like m(@)dy.fi or m(@)x.com etc. They claim that address is too short. Strip parenthesis from addresses.

Minimum should be 6: a@x.ca

Max is 254: http://stackoverflow.com/questions/386294/what-is-the-maximu...

Strictly speaking, the minimum should be 4, because TLDs could accept email too (resulting in a@ca).

Fair enough. Does this exist in the wild though? Thx

does it really matter? there are sites that store your password in plain text and they manage to become big hits. there are sites that completely ignore current css design rules, and they do fine as well. why are you arguing over a problem that is basically 99% solved?

Reply on news.ycombinator.com