Live data from Hacker News

The Correct Way to Validate Email Addresses

hackernoon.com

361–370 of 405 posts

Re: The Correct Way to Validate Email Addresses

#361

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…

Regarding that testdata, what is the reason for rejecting bare IP literals on the right hand side? It seems pedantic to require the square braces.

That part is confusing to me.

I ran a fresh install of Django to confirm and it behaves as you suggest.

Edit: Perhaps only for low digits. Hmm.

    >>> from django.core.validators import EmailValidator
    >>> e = EmailValidator()
    >>> e.__call__('foo@[1.2.3.4]')
    >>> e.__call__('foo@1.2.3.4')
    ValidationError: [u'Enter a valid email address.']
    >>> e.__call__('foo@0.0.0.0')
    ValidationError: [u'Enter a valid email address.']
    >>> e.__call__('foo@[0.0.0.0]')
    >>> e.__call__('foo@10.10.10.10')
    >>> e.__call__('foo@[10.10.10.10]')
    >>> e.__call__('foo@255.255.255.255')
    >>> e.__call__('foo@[255.255.255.255]')

Re: The Correct Way to Validate Email Addresses

#362

Earlier quoted context omitted.

I mean, in this case there are two reasons. They're both bad reasons, but still. 1. "Our email provider won't send to them". That excuses OP's part in the thing, although now we need to ask why the email provider is being stupid. 2. "We don't do validation links, they cause too many lost users". I have serious problems with this, but from a pure-business standpoint they decided that rejecting valid emails loses fewer…

Are they being stupid though? For example, hotnail.com is a parked domain. There's virtually no chance that a user actually has an email address there and sending an email to a wrong email address is bad for the email provider reputation... I mean it's not like they block a huge amount of domain names but with their volumes, it makes sense to avoid sending emails that will never be received by their intended recipien…

This is a fair point. I guess it's the sort of thing that I'd prefer to see fixed with a double-check prompt instead of a rejection, but I doubt it's causing many problems.

I was primarily thinking of short domains like "gmail" and "aol". For those, I can see a company called, say, "Gail" getting blocked from legitimately using "Gail.com". "Hotnail" seems a lot less risky.

Not a big problem, I just have an aesthetic objection to very high-friction things like blocking possibly-legal domains. As a double-check option I wouldn't object, and in fairness it's possible no one has ever been inconvenienced.

Re: The Correct Way to Validate Email Addresses

#363

Earlier quoted context omitted.

The concern isn't that there's no way to do it, it's that there's no reason to do it unless the plaintext is going to matter again in the future. The best guess I've seen is that they might be hashing, but also having people read passwords to customer service reps. That would justify caring about rude plaintext, but it's also a terrible system.

Heh, to be fair, we are talking about a company with millions of customers that is consistently rated as "most hated" by consumers. I'd be surprised if a decent percentage of attempted passwords weren't "fuck time warner"...

Hah. I can see some poor support rep getting a dozen calls a day with insulting passwords, actually - maybe it's about reducing call center turnover...

Re: The Correct Way to Validate Email Addresses

#364
post #123

Earlier quoted context omitted.

> ...@(valid)example.org(honest) Are those parens really permitted in the host name? I'm looking at RFC 3696. > 3. Restrictions on email addresses > .... The syntax of the domain part corresponds to that in the previous section. and > 2. Restrictions on domain (DNS) names > Any characters, or combination of bits (as octets), are permitted in DNS names. However, there is a preferred form that is required by most appli…

> > ...@(valid)example.org(honest) > Are those parens really permitted in the host name? I'm looking at RFC 3696. RFC5322 states that an addr-spec consists of a local-part, followed by @, followed by a domain. It states that a domain may be a domain-literal; a domain-literal may begin and end with commented folding whitespace (CFWS). It's all in https://tools.ietf.org/html/rfc5322#section-3.4.1 It's only the dtext po…

Thank you for that; this has been eyeopening.

The possibility of having a valid email address where the second-level domain component can't actually be registered as a domain, to the best of my understanding, eg "bar!.com", is interesting.

Re: The Correct Way to Validate Email Addresses

#365

Earlier quoted context omitted.

> "Cannot be resolved" means NXDOMAIN. OK, that at least shouldn't reject any valid addresses, so maybe ... > Why assume email addresses only get checked in one place, and not all? It's not an assumption, it's just a matter of simplicity and reliability. > Ten million a day was a milestone. I left that company over a year ago; it would astonish me to find that figure now exceeded by less than a factor of twenty. Gran…

I may have erred in giving the impression that the application-level checks are the only line of defense here. They're not. The (bespoke) MTA underlying this product performs most if not all of these checks as well. I didn't really spend any time on that side of the business, so I might be wrong about that, but it would be something of a surprise. I do know our analytics needed to be able to cope usefully with an ast…

> Checking whether an email address's domain-part is an RFC1918 IP is actually pretty easy.

What I still don't understand: Why do that at all? What's the point of this? Security? Preventing user errors? What else?

Re: The Correct Way to Validate Email Addresses

#366

Earlier quoted context omitted.

1. There are no "obviously invalid email address[es]". 2. Getting billed for sending emails? WTF?

With respect to (1), the cases I had in mind as "obviously invalid" is something that doesn't contain all of the required components of an email address. For example, if the user submits their email as "foo" or "foo@bar" or "foo@bar." I should have provided examples as the way I wrote it was definitely ambiguous.

How about foo@[1.2.3.4] ?

"foo", ok, I agree with the blogpost, if there isn't even an @ in there somewhere, maybe it's sensible to catch that and reject it outright. But that's probably about it.

Re: The Correct Way to Validate Email Addresses

#367

Earlier quoted context omitted.

> Scarier still is when it's a server-side response that rejects my password for its contents... Why? Assuming that you have established a secure connection with that server (i.e., HTTPS by means of TLS), then it is perfectly fine for the server to check, at the time you are setting the password , if your password confirms to the rules established. And when the password turns out to be suitable, it is okay for the pa…

> At no time is the plain text password stored anywhere Hopefully. When I see rules limiting passwords to 16 characters and disallowing SQL special characters, I'm having doubts.

I remember Starbucks was doing it for their mobile app about two years ago, sacrificing security for a "better"/faster UX. It's one of those things that you think "No one would be dumb enough to do this", only to be surprised by the fact that a big player has been doing it for a while.

Re: The Correct Way to Validate Email Addresses

#368

Earlier quoted context omitted.

Regarding that testdata, what is the reason for rejecting bare IP literals on the right hand side? It seems pedantic to require the square braces.

That part is confusing to me. I ran a fresh install of Django to confirm and it behaves as you suggest. Edit: Perhaps only for low digits. Hmm. >>> from django.core.validators import EmailValidator >>> e = EmailValidator() >>> e.__call__('foo@[1.2.3.4]') >>> e.__call__('foo@1.2.3.4') ValidationError: [u'Enter a valid email address.'] >>> e.__call__('foo@0.0.0.0') ValidationError: [u'Enter a valid email address.'] >>>…

Huh. "Well tested" indeed.

Re: The Correct Way to Validate Email Addresses

#369
post #252
post #97

Earlier quoted context omitted.

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…

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

I had that problem so many times that I whipped up a quick Rails app that generates new email addresses. Type in the company name, hit submit. It uses a random project name generator gem to create something like SteelyFishSauce@.com, displays it on the screen, and emails " has been associated with SteelyFishSauce@.com" to the spamcatcher address.

Post reply on HN