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

281–290 of 405 posts

Re: The Correct Way to Validate Email Addresses

#281

Post by wyldfire »

lucb1e wrote: post #265
wyldfire wrote: post #137

Earlier quoted context omitted.

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?

Someone could have just created an account and accidentally put the wrong email address in. Therefore, putting a link that extends full trust in the welcome/confirmation email is a design error. The fix for this error is to require the newly created account holder to put in their password on this first login. While the account's in this state it shouldn't be possible to reset the password.

Re: The Correct Way to Validate Email Addresses

#283

Post by bballer »

In all my projects I use the same methods for validating an email address: 1) Does it contain a `@` 2) Split the string on the `@` and make sure that at least one character exists on both sides of the `@` 3) Send verification email.

This check is done server side, while on the client I just use an html5 input[type='email'] with a required attribute.

Re: The Correct Way to Validate Email Addresses

#284

Post by zAy0LfpBZLC8mAC »

scaryclam wrote: post #275
zAy0LfpBZLC8mAC wrote: post #235

Earlier quoted context omitted.

I am not sure what you are trying to say. Yes, of course, it costs money. Just like serving websites costs money. And just as checking the syntax of an email address costs money (CPUs cost money and need power to run!). Now, how is that an argument for checking the syntax of an email address to avoid sending a single email and seeing whether it bounces?

Sending a lot of bounced emails is going to get your mailservers reputation tanked, which is not an acceptable tradeoff for removing email validation. Email validation is actually really important if you send even a medium amount of email. Testing by bouncing is not a very good idea, especially since there are a lot of ways to test the deliverability of the email before you try and send it. That's not to say use a re…

> Sending a lot of bounced emails is going to get your mailservers reputation tanked, which is not an acceptable tradeoff for removing email validation.

?!?

OK, let's break this down: What could be reasons for an email to be bounced due to an invalid address?

1. Because the address is syntactically invalid: Your own email server will notice and reject/bounce the email. Noone outside your own server will notice.

2. Because the domain doesn't exist or has no inbound mailserver: Your own email server will do the DNS lookup(s) and bounce the email. Noone outside your own server will make any note of that (and you can't find out without doing DNS lookups anyway).

3. Because the localpart doesn't exist: You can't find that out without trying to actually send an email (and consequently risking a bounce).

So, what exactly was the point of email validation "without bounces" again?

The only thing you can actually do to avoid unnecessary bounces is to make sure your emails have a valid return path and to make sure that you somehow process all the bounces that arrive there to make sure that you don't continue sending emails to addresses that start sending bounces (i.e., that don't exist (any more)). If you send lots of mails, it's probably best to employ VERP for that.

Re: The Correct Way to Validate Email Addresses

#285

Post by 6DM »

ryandrake wrote: post #35
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 ;)

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

At least you got a notification. One bank just stripped all of mine off and submitted like that. At least they were consistent about it, I didn't realize until I accidentally mistyped and still got in.

In disbelief I logged out, tried again but this time I intentionally didn't use any special characters. It worked....

Re: The Correct Way to Validate Email Addresses

#286

Post by pluma »

kasparsklavins wrote: post #277
creshal wrote: post #229

Earlier quoted context omitted.

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

My bank limits passwords at 15 characters. The best thing? There is no verification, it just cuts off. Have fun figuring out why you can not login anymore.

Fun fact PayPal (used to?) silently cut off passwords when signing up, but not when logging in. And the password rules are of course not shown on the login screen. So good luck remember what length they cut your password down to when your password manager has stored the longer version.

Re: The Correct Way to Validate Email Addresses

#287

Post by [deleted] »

lucb1e wrote: post #265
wyldfire wrote: post #137

Earlier quoted context omitted.

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?

[deleted]

Re: The Correct Way to Validate Email Addresses

#288

Post by FungalRaincloud »

bballer wrote: post #283

In all my projects I use the same methods for validating an email address: 1) Does it contain a `@` 2) Split the string on the `@` and make sure that at least one character exists on both sides of the `@` 3) Send verification email. This check is done server side, while on the client I just use an html5 input[type='email'] with a required attribute.

That's probably reasonable, but you might want to amend 2 to "split the string on the last '@'". There's no restriction to only '@' before the domain. It's exceptionally rare that a server even allows '@' in the mailbox name, fortunately for us.

Re: The Correct Way to Validate Email Addresses

#289

Post by puddintane »

I always search out that a validation library hasn't already been done in my current language first before attempting validation with custom code - this leads to more easily maintainable code for future eyes.

For example in PHP I use filter_var function with the FILTER_VALIDATE_EMAIL [1] - while it's great to know why and how to do a particular thing programming, it's better to use a time tested library that is maintained by multiple eyes versus just your own.

[1] http://php.net/manual/en/filter.examples.validation.php

Post reply on HN