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 "[email protected]", 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).

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

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

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

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.