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

251–260 of 405 posts

Re: The Correct Way to Validate Email Addresses

#251

Post by zAy0LfpBZLC8mAC »

oddlyaromatic wrote: post #89
mook wrote: post #67

Earlier quoted context omitted.

I've got an account where they just plain stripped the + character. Since I happen to have used only alphanumeric charters after, I am now registered with an email address I can't actually receive mail on - it goes to somebody else's inbox. Account synchronization was involved - IIRC the initial address confirmation message got thorough.

I thought that though the + is valid, nothing after the + is used to differentiate the email address? I use local+Organization when I sign up for an email list so that I can easily filter, plus I can see if that email address gets shared around. So on places that reject the + I just use everything before it as the local part. Maybe I'm missing something. Edit: I guess not all email providers do it this way but here's…

As far as email is concerned, "+" is just a character as any other. You might as well configure your mail server to ignore everything from the first "g" in the localpart when figuring out which mailbox to deliver to. Some mailservers happen to do this with a "+", if it happens to occur in a localpart, but that is just what they happen to be doing. There is nothing technically wrong with an email address like "++foo@example.net" or "x+y+z@example.net" or "+-@example.net", and "a+b@example.net" is a different address than "a+c@example.net", unless the operator of example.net explicitly specifies otherwise.

Re: The Correct Way to Validate Email Addresses

#252

Post by flurdy »

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 as well. Keeps a nice track of which have been leaked (or guessed) by spammers. And easy mail filtering to relevant labels on my side.

But it does get awkward quite a few times when having to interact with a human (customer services, hotel bookings, etc) via email or phone when they get a bit confused why their company name is my email alias....

Spelling a long alias over the phone letter by letter is especially tedious...

Also responding to emails either means I have to configure yet another sender alias, or mostly just send from my normal alias, which sometimes gets rejected or confuse whomever I interact with.

Also hate unsubscribe links that insist on sending unsubscribe email from that alias(mailman etc).

Re: The Correct Way to Validate Email Addresses

#253

Post by wtbob »

deathanatos wrote: post #186
wtbob wrote: post #114

Earlier quoted context omitted.

> I don't think you're really correct about "email addresses" being context-free, or at least, citation, please? > When I look at a generic "email address" entry field on a random form on the Internet, say on the sign-up page for some hot new startup's service, I expect it to take what RFC 5322 §3.4.1[1] calls an `addr-spec`; specifically, I don't ever expect such fields to take the grammar of what that RFC calls an…

Oh, shoot, I missed that. I saw "FWS" (meaning "folding white space"), and assumed that didn't include comments since they have nothing to do with folding whitespace. Well done.

No worries. The RFC is … complex.

Re: The Correct Way to Validate Email Addresses

#254

Post by moosterv »

girvo wrote: post #116
lstamour wrote: post #66

Earlier quoted context omitted.

Sadly at some places it's intentional so your password matches existing PIN systems or is "easy to remember" so you're not as easily locked out of your account. I wish in those cases there was a check box that says, "I know what I'm doing, leave me alone." Speaking of annoying validations, my name has a hyphen in it but you'd be surprised how often that's rejected with the familiar, "Please enter a valid last name."…

My partner has a hyphenated first and last name. So many systems refuse to accept that, and even regular humans struggle with understanding it!

My last name starts with oo, which many humans struggle to understand. It almost always becomes do, or co.

Re: The Correct Way to Validate Email Addresses

#255

Post by wtbob »

ubernostrum wrote: post #178
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,…

I wonder if the django validator will choke on perfectly valid email addresses such as (this)"() []:,;@\\\"!#$%&'-/=?^_`{}| ~.a"(is)@(valid)example.org(honest) If it doesn't, remind me to patch it to not accept that. I have strong views on email validation, and they include telling people who use that kind of address to go register on someone else's site.

> If it doesn't, remind me to patch it to not accept that.

You'd be wrong to do so. The whole point of RFCs and Standards is to take things out of the realm of personal preference.

Also, I suspect that a validator which allowed reasonable addresses like jim(somesite)@foo.invalid (which is both a good use of comments and what the + hack emulates) or "Ted Smith"@bar.invalid or "work@home"@jobs.invalid or "William \"Bill\" Jones"@baz.invalid but disallowed unreasonable ones would also be able to solve the halting problem. How many perfectly reasonable allowed features must one use before it's considered abuse?

> I have strong views on email validation, and they include telling people who use that kind of address to go register on someone else's site.

An email address is, simply, an address which can be given to an Internet mail server in order for it to properly route an email. All of the addresses I gave are perfectly valid ways to do so. An addresses is a property of the addressee, not of the addressor.

In other words: it may be your site, but it's my address.

Re: The Correct Way to Validate Email Addresses

#256

Post by klmr »

mook wrote: post #67
cperciva wrote: post #34

Earlier quoted context omitted.

Worse than that: I've encountered a few web sites which accept email addresses with '+' characters... and then tell me that my email address has a ' ' character in it. Every time I see this I think "there's got to be a multiple-form-decoding vulnerability here"...

I've got an account where they just plain stripped the + character. Since I happen to have used only alphanumeric charters after, I am now registered with an email address I can't actually receive mail on - it goes to somebody else's inbox. Account synchronization was involved - IIRC the initial address confirmation message got thorough.

Had this problem with Virgin Atlantic. Booked a ticket, never got it.

Re: The Correct Way to Validate Email Addresses

#257

Post by zAy0LfpBZLC8mAC »

throwanem wrote: post #245
zAy0LfpBZLC8mAC wrote: post #71

Earlier quoted context omitted.

1. Sanitization generally means changing information. As in, "removing bad characters", that kind of stuff. That's different from validation, which should result in rejection of bad input, and which can be perfectly fine. However, more often than not, validation is implemented badly and rejects perfectly fine input, which is why validation shouldn't be employed more than necessary either. 2. Rejecting @localhost addr…

> There is nothing particularly dangerous about receiving unsolicited signup emails or about sending emails to yourself. Depends on what you do with them, in the latter case. There could be an amplification attack there. Validating domain parts to a certain extent isn't a bad idea, at least as far as non-routable domain names and RFC1918 ranges go. I've seen this done (actually implemented some of it, in fact) at a p…

> Depends on what you do with them, in the latter case. There could be an amplification attack there.

Hu? How would that work?

> Validating domain parts to a certain extent isn't a bad idea, at least as far as non-routable domain names and RFC1918 ranges go.

What do you mean by "non-routable domain names" and what do you gain by checking for RFC1918 ranges?

> I've seen this done (actually implemented some of it, in fact) at a past employer, who were basically looking to cover the 90% case in terms of not getting hosed by a trivial attack.

Why did you prefer that approach over a robust solution?

My idea of a robust solution: Have one central outbound relay that's firewalled off from connecting to anywhere but the outside world, make all servers that need to send email use that relay as a smarthost (so they never connect to anything but that relay, regardless what the destination address is), use TLS and SMTP AUTH with credentials per client server to prevent abuse of the relay by third parties.

> What's not to like?

(a) that it's a lot easier to build a solution that's more robust, (b) it's extremely likely that your implementation is buggy, thus rejecting valid addresses, and (c) it's causing a maintenance burden (what happens when the first people drop IPv4 for their MXes? I'd pretty much bet that you don't check for AAAA records, so you'd probably suddenly start rejecting perfectly fine email addresses, thus making the transition to IPv6 unnecessarily harder, am I right?).

Re: The Correct Way to Validate Email Addresses

#260

Post by mgkimsal »

Freak_NL wrote: post #223
Zancarius wrote: post #199

Earlier quoted context omitted.

Hah, good point. Although I do have to wonder: When does it turn into filtering by force of habit? After all the legacy cruft has long been forgotten and is no longer maintained?

Because the other monkeys will chew you out if you start doing it differently all of a sudden. Nobody knows exactly why we're doing it the way we are doing it, but it is complex, and changing it might break something. It's the five monkey experiment : http://johnstepper.com/2013/10/26/the-five-monkeys-experimen...

It's not always that.

Let's use the "filtering chars from password" example above. You can't put some special chars in password field, and you want to change that so it's doing normal hashing where special chars don't matter.

In a larger org, even changing a practice like that so that it "makes more sense" can have a big ripple effect.

You have to

* explain to someone else on the team who came up with the original process that it's flawed (and why)

* explain to other dept that they need to update their testing process (and why)

* get support dept to change their language/process

* change outbound messaging in all affected places (perhaps with code you can't touch, involving other teams)

* possibly have a flag that deals with 2 versions of data

Even if your change brings you in to line with normal/safe practices, you may have to fight multiple inane battles, spend loads of time and political capital, and at the end of the day, you'll be able to also accept a !"@+'$ in a password field? Most people will not grasp the bigger issue at play.

Post reply on HN