Live data from Hacker News

The Correct Way to Validate Email Addresses

hackernoon.com

261–270 of 405 posts

Re: The Correct Way to Validate Email Addresses

#261
post #211

Earlier quoted context omitted.

Even Linux tools like GNOME Archive Manager in Linux Mint 18 rejected my RAR password containing a $ as the incorrect password, even though it was the correct password for the RAR file I was trying to extract. I then used the command-line unrar utility with the exact same password, and it extracted successfully. Now, why would you preemptively (and explicitly) throw out a candidate password string based on its charac…

I'm guessing both are because the are calling command line tools. One of my pet peeves with linux is that many of these tools are only callable via text and don't expose an API for other programs.

But even PHP has a way to escape shell arguments safely

Re: The Correct Way to Validate Email Addresses

#262

The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on. In 99% of those cases, it prevents someone from entering a wrong email. We do not do email activation by forcing people to click a link in their email to validate that they received it since that causes a drop in the funnel and reduces the amount of…

> We do not do email activation by forcing people to click a link in their email to validate that they received it

Have you considered doing email validation without forcing users to comply? It's fairly common to require valid emails after X days, or in order to unlock N features. Gets the advantages of having valid emails without the disadvantages of a drop signups.

Re: The Correct Way to Validate Email Addresses

#263

Earlier quoted context omitted.

> 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 f…

'Non-routable' as in a single label, or as in not resolvable. I don't think it is unreasonable to consider an address invalid when its domain part cannot be resolved. Checking for RFC1918 ranges means you don't try to send to another class of addresses that's never going to be received.

You would lose the bet. The product supported IPv6 from day one.

That is a robust, if somewhat complex, solution for a relatively small volume of mail. When you're sending ten million messages a day by the end of the first month, pushing everything into a single relay of any kind is asking for a lot of trouble.

Re: The Correct Way to Validate Email Addresses

#264
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…

Doesn't solve all of it, but that's why I use random localparts instead. Sometimes people wonder whether the address is correct, but if I confirm that it's ok that it looks weird, people aren't overly confused and just accept it. I then have it all integrated with Mutt so it tags emails with a human-readable label and automatically selects the correct source address when replying.

Re: The Correct Way to Validate Email Addresses

#265
post #2

TL;DR the odds that the user entered an incorrect-but-valid address are way higher than that they entered one which will not actually be able to receive mail. Send a validation email.

For flip's sake, yes please! Close the loop, fer crying out loud. I got a popular givenname.familyname@gmail.com address and I frequently get mail that's meant for other people who share my name. The vast majority of the time it's the individual themselves who sign up for a service or offering but there's rarely a validation upfront. The best emails are the ones who extend full trust to the email recipient over some…

> The best emails are the ones who extend full trust to the email recipient over some account during that first email. [Random company,] shame on you.

Well what else would you have them do? Have people enter their address and send letters there to do a password reset?

A confirmation email before full trust is going to do little: a malicious person would just click that link, right?

Re: The Correct Way to Validate Email Addresses

#266

Earlier quoted context omitted.

> The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on. That can be helpful, but I assume you suggest the user that they may have made a typo and not flat out reject the input? > […] having an email with a local domain name with no TLD is valid but it'll never be valid in the context […] Well, depending…

Our email provider flat out refuses to send to those domains actually so we actually reject the input for the domains that the email provider blocks. > I would not rule out someone actually using ceo@cocacola at some point Of course, this is subject to change if the practice changes. The aim is to make sure that we balance the percentage of emails that are correct versus the number of potential rejections. If 0.00001…

How about rejecting all email addresses that contain the character sequence "jex"? 99.9999% of email addresses with "jex" in it are invalid, so it makes sense to reject it, doesn't it?

Re: The Correct Way to Validate Email Addresses

#267

As an aside, I received an email from a government department recently that had an '&' character as part of the email address. I didn't think that was valid, but lo and behold, when I checked the specs, it IS indeed a valid character in an email address. Just goes to show that assumptions are often wrong, and you have to crack open the spec document from time to time... [1] [1] - https://tools.ietf.org/html/rfc2822

I have a feeling somewhere on the Internet is the story of the sysadmin who got the request from that department for an email address with an ampersand. S/he probably stopped themselves from replying "uh, that doesn't work", tried it, and then learned it's valid.

Re: The Correct Way to Validate Email Addresses

#268
post #140

Earlier quoted context omitted.

Yes. OS X keyboard drives me nuts sometimes, Karabiner can only fix some bits of the weirdness.

option-e and then a vowel will create {á é í ó ú} option-u and then a vowel will create {ä ë ï ö ü ÿ} option-n and then an 'n' will create ñ Found this out while learning Spanish since holding down keys to select their alternate was way too slow.

For the record:

option-n and then 'a' will create ã

option-n and then 'o' will create õ

Re: The Correct Way to Validate Email Addresses

#269

Earlier quoted context omitted.

I had a .to domain for a while, and I had an email address "firstname@firstname.to" where firstname is my first name. I wanted to use it when I needed to give out emails causally, like if someone from Church or some other group wanted my email. I gave up on it, not because of computer validation but because of stupid people! Nobody would "get" the .to domain and they'd always think there should be a .com or .gmail.co…

I'm discovering the same problem with my *.xyz domain name.

As a counterpoint, I was surprised to see we've had very little trouble with our *.solutions domain, even from clients who are otherwise not very tech-savvy.

Re: The Correct Way to Validate Email Addresses

#270

Earlier quoted context omitted.

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?

Or, more simply, `.@.`.
Post reply on HN