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

51–60 of 405 posts

Re: The Correct Way to Validate Email Addresses

#51

Post by zAy0LfpBZLC8mAC »

jwecker wrote: post #13

I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses. With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localh…

> I always assumed it was more a sanitization issue for security's sake.

Sanitization is at best idiotic, at worst creates security problems. There is no such thing as "bad characters", there only is broken code that incorrectly encodes stuff. If you ever find yourself modifying user input "for security reasons" (or really, for any reason at all), you are doing it wrong. The only sane thing to do is to make sure that the semantics of every single character of your user's input is preserved in whatever data format you need to represent it in.

Re: The Correct Way to Validate Email Addresses

#52

Post by devNoise »

Ameo wrote: post #40

I have a .link domain for my personal email and a lot of sites refuse to let me register because they don't recognize it as a valid TLD. Then there's the textbook company that lets me register but refuses to let me reset my password claiming that I'm trying to enter an "invalid email address."

I've been using various emails on a personal domain for different sites. Some time this year Six Flags put in an email check and I can't register my season pass anymore. They give the following error:

We were unable to finish validating your connection with the "*.net" email server.

Yet I've been signed up for the pass holder announcements and get the email on a regular basis.

Re: The Correct Way to Validate Email Addresses

#53

Post by blechschmidt »

Benjamin_Dobell wrote: post #30

The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)

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.

Re: The Correct Way to Validate Email Addresses

#54

Post by Natsu »

usaphp wrote: post #48
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...

Or when a password that is generated by my password manager is rejected with a message "Password should be 12 characters maximum". Why???

That always makes me think there's probably a Password char(12) in the Users table somewhere.

Re: The Correct Way to Validate Email Addresses

#55

Post by pwg »

usaphp wrote: post #48
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...

Or when a password that is generated by my password manager is rejected with a message "Password should be 12 characters maximum". Why???

This very heavily implies that the database column which stores "passwords" is typed as "char(12)" and that the site is storing unhashed plaintext passwords in that column.

Why: Because if they were (at least) hashing the password, then the output of the hash would be a fixed size token unrelated to the length of the input plaintext password, and no such arbitrary short limit would be necessary on the plaintext password itself.

Re: The Correct Way to Validate Email Addresses

#57

Post by jwecker »

kej wrote: post #24
jwecker wrote: post #13

I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses. With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localh…

And that's a great philosophy until your email gets rejected by some service that picked a different "common class of email addresses" than you did. This is precisely why we have written standards.

Back when SMTP servers still had remnants of UUCP etc.- where the address could actually contain characters that specify intermediate servers to route to, I would have argued that front-end sanitization was important as, for example, html sanitization from end-users from a security perspective.

However, IETF made lots of progress simplifying things- to the point where, at the very least, the standard tells us specifically that we should leave it up to the destination host to interpret the local part of the email address-- that is, the thing to the right of the @ should be given the thing on the left unmolested ideally- even being ignored by intermediate relay servers. Since that's what most people complain about, any validation to the left of the @ should become extinct.

But off the top of my head that still leaves the thing on the right of the @ (such as localhost), buffer overflows by allowing longer strings than the standard allows (those limits do exist), and the problem with multiple @ which the MTA may or may not handle well... Since I'm not a security expert I'm going to go out on a limb and assume that I'm missing a bunch of other things.

My point is not that the article is wrong, though- my point is that if he wanted to convince me to only validate by sending the email on any string, he should convince me that those security concerns are not an issue- not that it's not good at catching type-os.

Re: The Correct Way to Validate Email Addresses

#59

Post by jwecker »

zAy0LfpBZLC8mAC wrote: post #51
jwecker wrote: post #13

I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses. With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localh…

> I always assumed it was more a sanitization issue for security's sake. Sanitization is at best idiotic, at worst creates security problems. There is no such thing as "bad characters", there only is broken code that incorrectly encodes stuff. If you ever find yourself modifying user input "for security reasons" (or really, for any reason at all), you are doing it wrong. The only sane thing to do is to make sure that…

An email address isn't a document though, it's a routing command. I don't mean sanitization in the sense of inserting backslashes. I mean sanitization in the sense of "we don't allow people to set their email address to a mailbox on localhost at our mail server."

Re: The Correct Way to Validate Email Addresses

#60

Post by wtbob »

Programmatic wrote: post #43
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,…

You are correct: >>> from django.core.validators import EmailValidator >>> EmailValidator()(""""() []:,;@\\\"!#$%&'-/=?^_`{}| ~.a"(is)@(valid)example.org(honest)""") Traceback (most recent call last): File " ", line 1, in File "/usr/local/lib/python2.7/dist-packages/django/core/validators.py", line 203, in __call__ raise ValidationError(self.message, code=self.code) django.core.exceptions.ValidationError

Well shoot, that's my email address! /s

Seriously, though, this is why regexp-based validation is Not Even Wrong. It's like showing up to a gunfight with a keen eye for detail.

Post reply on HN