Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Correct Way to Validate Email Addresses

hackernoon.com

Post reply on HN
Print view View original

161–170 of 405 posts

Re: The Correct Way to Validate Email Addresses

#161

Post by developer2 »

kazinator wrote: post #95

Sorry, I disagree. There is absolutely is a correct way to lexically validate an e-mail address: namely, implement a parser for the syntax specified in whatever RFC is the up-to-date successor of RFC 822. There is such a thing as incorrect e-mail address syntax: namely, non-RFC-conforming syntax, whatever that is. You may reject that, and that's about it. Please don't reject RFC-conforming e-mail addresses.

I agree, with two specific exclusions: notations for IP addresses in square brackets, and comments. Just removing those two never-encountered-in-real-life syntaxes reduces the RFC regex down to nothing. Comments are not a real thing, RFC be damned. And square bracketed IP addresses are never encountered in the real world, especially with the requirements for PTR records to pass all the major providers' spam filters.

Anyone trying to provide an email address with a square bracketed IP or a comment is specifically trying to find an excuse to cause drama when their email is rejected. Those exceptions aside, fuck anyone who validates email addresses that don't permit perfectly valid real-world characters like '+', or who whitelist specific TLDs (.com, .org, .net et al).

Re: The Correct Way to Validate Email Addresses

#162

Post by eyelidlessness »

thedufer wrote: post #156
wtbob wrote: post #37

Earlier quoted context omitted.

> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…

It is true that regular expressions in the CS sense can't parse context-free grammars. However, PCRE, which is what most programmers are talking about when they say "regex", can do so. So you're both kinda right, I guess. But you're being a bit pedantic.

> PCRE, which is what most programmers are talking about

I wish that were the case. http://www.regular-expressions.info/refunicode.html

(They used to have a much more useful and concise comparison table but I can't for the life of me find it.)

Re: The Correct Way to Validate Email Addresses

#163

Post by underwater »

voidz wrote: post #97
blechschmidt wrote: post #53

Earlier quoted context omitted.

Yes, the + is incredibly useful for tagging emails. When I register new web accounts, I always specify a new unique tag so that I can track down the source in case I receive spam. Furthermore, they help my mail server when filtering out junk mail.

These days I do this differently; I created a subdomain that forwards all email to my main account. hackernews@foo.example.com would forward to main@example.com, and I can just filter the prefixes. That way I can use the subdomain for my own unique addresses, without interfering or using up addresses on the parent domain.

I do this too. Unfortunately some spammers decided that they'd use @.com as their reply address and I have to filter out all of their bounces.

Re: The Correct Way to Validate Email Addresses

#164

Post by niij »

zAy0LfpBZLC8mAC wrote: post #75
vacri wrote: post #74

Earlier quoted context omitted.

email addresses for usernames have the advantage of already being unique. None of this "gregmac already taken, try gregmac23, gregmc_595, or verbingnounXX instead?" nonsense

> email addresses for usernames have the advantage of already being unique Not true. There are people who share an email address.

Care to expand? As in having a first.last@example versus firstlast@example

Re: The Correct Way to Validate Email Addresses

#165

Post by nucleardog »

tempestn wrote: post #155
sbuttgereit wrote: post #96

Earlier quoted context omitted.

Ha! If only! Probably more than 50% of the sites I visit that have a maximum length that my password manager exceeds... give me an unrelated error message. Some times they tell me I haven't met the minimum length (100 chars, really?), sometimes they tell me that I've not met complexity requirements (I use upper/lower/numbers/special chars), etc. It's as though the developer only ever thought of how people wouldn't me…

You default to 100 character passwords? Doesn't that make it extremely inconvenient on the rare occasions when you need to type a password out? I figure 14 characters is going to be effectively unbreakable, but still possible to manually copy in under a minute.

Yeah, basically this. In theory every time I need a password I can copy and paste.

In reality, sometimes I'm on someone else's computer or something else comes up that I need to open my database up on my phone and type it in by hand.

For instance, I can't imagine trying to enter a 100 character password with a PS3 controller to log myself back into Netflix...

If I'm already at "it's going to take 100 quintillion years to break this hash, even if they're only using MD5", then I really don't see any security benefit to using a longer password... But there's a definite loss of usability.

Re: The Correct Way to Validate Email Addresses

#166

Post by brianwawok »

pwg wrote: post #61
ryandrake wrote: post #35

Earlier quoted context omitted.

Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...

Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. Why: Because if they were (at least) hashing it the output from the hash would be a binary string in which case they would have to be 8-bit clean through to the DB column where the hash output resided, and then there wou…

> Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text.

I don't think that is true at all.

I may very well want to put a few simple rules I validate serverside, such as

1) No username in password 2) No email in password 3) No list of 100 most common passwords in password

All of which require me to look at the text for your password, none of which mean I am storing it in plaintext.

Re: The Correct Way to Validate Email Addresses

#167

Post by jcoffland »

ChuckMcM wrote: post #141

I think the 'valid but wrong' email is a more common failure. Having just spent a few weeks with my wife trying to convince some poor person that they had mistyped their email address when they created their Amazon account. Reminded me of this xkcd ( https://xkcd.com/1279/ ). It does seem effective to have someone type the address twice as that can catch a typo fairly easily.

I hate it when sites make me type my password in twice like I'm some sort of idiot. What's really bad is when they disable pasting. This is so stupid because it makes sure I cannot copy and paste from my password DB. I will often not use a site for this reason alone.

Re: The Correct Way to Validate Email Addresses

#168

Post by jerdfelt »

eyelidlessness wrote: post #159
tedmiston wrote: post #20

Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…

By all means, validate. But err on the permissive side. The odds are pretty great that you're wrong, and you're preventing real email addresses (and almost certainly real users) by doing so. I'd never looked closely at Django's email validation, but after looking at it I'm inclined to stop using it. Example reason: > # max length for domain name labels is 63 characters per RFC 1034 There is a high likelihood that mos…

The 63 character limit on domain name labels in RFC 1034/1035 isn't arbitrary, it's a limitation in the way DNS packets are encoded. The upper two bits of the label length are used for compression of labels in DNS packets.

Without protocol changes, DNS cannot support labels longer than 63 bytes.

However, I agree that validating it is unnecessary.

Re: The Correct Way to Validate Email Addresses

#169

Post by bbcbasic »

DHowett wrote: post #131
Xorlev wrote: post #120

At this point, our email validity criteria: .+@.+\..{2,} That is, at least one character for the inbox, at least one character for the domain, at least two for the TLD (we assume that TLD-less domains are undeliverable by us). This ensures we don't allow 'a@a' or 'a@a.a', but do allow 'a@a.io'.

a@[IPv6:2001::1] is, unfortunately for your validation regex, a valid e-mail address. [EDIT: I see that you consider TLD-free e-mail addresses undeliverable; still!]

  .+@.+
FTW?

Re: The Correct Way to Validate Email Addresses

#170

Post by vidarh »

LordKano wrote: post #160
ryandrake wrote: post #35

Earlier quoted context omitted.

Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...

A former employer, that I will decline to mention by name, stored a hash of the password AND the plaintext in the database so it could be sent to people via email when they forgot it. I tried to explain to my boss why this was such a terrible idea and he was not hearing any of it.

If I ever use the "forgot my password" functionality at a site and they mail out something that is probably my original password, I make a point of cancelling my account and sending them an e-mail explaining why I don't trust them any more.
Post reply on HN