Ask HN: What is the norm for email validation? | Hacker News Reader

Ask HN: What is the norm for email validation?

7 pointstaylorcooney17 comments

For email validation, what is the norm for mobile apps? Are people making a service call to third-party like Mailgun, or checking on the client side?

I'm trying to come up with the options on the service side and client side, and what options exist in the Rails environment already. I feel like our CTO is more inclined to go with what other tech companies are using on the mobile apps.

View on HN

Related (was on Hacker News)

"On the Futility of Email Regex Validation"

https://jackfoxy.github.io/FsRegEx/emailregex.html

Thanks for the read, @aonoma....something good for my commute home.

You can, and should, knock out the really obvious stuff with regex validation but you're smart to be concerned about one thing that most people miss in this conversation.

A confirmation email doesn't solve the problem if the user mistyped the address to begin with. You're right, they wait for a confirmation email that never comes.

Using a third party service like BriteVerify's rest api is the only way to get an actual verification that the inbox exists.

Send the user a verification mail.

We do that, but I don't want our server sending a verification email to "taylor@gmail.con", it should fix that on the input field.

.con might be a valid TLD though, there's so many TLDs now.

Just send a verification email...

We do...but then people wait for a verification email that will never arrive (.con vs .com). Ideally, we want to fix this before they register their account. Looking for server-side (rails), service calls and client-side options.

I know Mandrill has webhooks that can notify you of events such as bounced emails.

https://mandrill.zendesk.com/hc/en-us/articles/205583217-Int...

Wouldn't integrating this help solve the issue, as you can possibly check if you received a bounce for that email shortly after the user attempts to register, and then notify them on the screen?

What about passwordless, email-based login? It's easier than username/password login, it verifies the email address, and it provides the same level of security (assuming password can be reset via emailed link).

Cool concept, but would require a complete revamp of our sessions infrastructure....I am looking to slap something on to our codebase to check email formatting after the '@' symbol.

The Firefox browser source code has a list of current TLDs, IIRC. There's over a thousand. You could use that to at least verify the TLD part.

The following may not work for your use case and I'm no expert in the area, but it could be possible to write a simple shell script to dig the mx records, and fail out if there's no such, and if you wanted to go a step further, you could open SMTP, and fail out if you can't, and if you wanted to go a step further you could even on the mx maybe even do a direct ping or some other lookup of the address part in that session, so long as the server is not a catchall. I feel the total bandwidth outlay would be no more then a small http roundtrip. Tho you might get a bit of hit on the connection time, or retries, as my feeling is not all SMTP hosts are speedy. Thanks

Greylisting[0] would still be a problem. Signup is exactly the situation where this would be both most likely and most inconvenient.

[0] https://en.wikipedia.org/wiki/Greylisting

> it provides the same level of security

No, it absolutely doesn't.

If an attacker breaches a user's mailbox, and then uses a 'forgotten password' process to gain access to another system, the user will know about it - their existing long-lived session would be killed, and the password they remember/have saved will no longer work.

If the attacker simply uses the mailbox access to use & delete "login link" emails, they could make use of this to access the victims account for as long as they have access to the mailbox.

I use JS validation library + Mailcheck.js on the front end. The regex checks for format and mailcheck validates second and top level domains. Coupled with a verification mail this is good enough for me.

If you're only worried about the domain aspect, and want a super simple approach just check if you can resolve the hostname.

I want to be checking for errors after the '@' symbol, such as @gmial.com or @gmail.con

Right so as I said, do a hostname lookup: if you get a result (ie not nxdomain) then it's ok, if not, it isn't registered, is a non existent tld, or has no records, all of which mean mail will fail.

Reply on news.ycombinator.com