You've got it backwards-- the use case is to catch things like "grandma@aol" and "foo@@bar,com". If we just check for "@" then we'd send email into the void. Instead, we check for more specifics, and we prompt the user to correct the email address. This improves our response rate about 2% which for us is significant.

But grandma@aol is a valid email address (if aol were to become a proper TLD with an MX record).

Hahah yes you're correct. We do client-side auto-suggest on email validation, so we can ask "Did you mean to type [email protected]"?

We have seen a real email address without any dot, and it routes successfully to a TLD MX exactly like you describe so yes, it does happen. :)

Just for fun: https://en.wikipedia.org/wiki/Bang_path#UUCP_for_mail_routin...

But yeah, that's effectively dead and you probably don't want to try sending mail that way.

He'd have to have bang routes set up on his mail server for that. =) So it's not just effectively dead, it's dead-dead.

I am chose my phrasing for the very reason that it's merely incredibly unlikely and not at all impossible. I've even sent mail with bang-paths post-2000 just to confound the recipient, though it is a rare network that would accommodate that today.

Edit: punctuation.

Where can I still use bang-paths?!

Nowhere that I know of, at least not for certain. The company with the mail server I used has been subsumed by another company, however some other companies from that time may still be running compatible mailers.

Here's another thought, just off the top of my head: get people to sign up by sending an email to "[email protected]". You can include that as a "mailto:" link and many browsers will deal with it correctly.

There's very good odds that the email they send will have their "From:" (or "Reply-To:") address correctly set. Then just have an email autoresponder which emails them back a link with a token in it, when they click on that it'll take them to a page to create their account, with their email address already filled in by the token.

Sending people to their emailclient would probably decrease conversion too much.

Yeah, maybe. But you're going to have to send them there some time to do the "confirm email" thing, I was just thinking perhaps get that over and done with upfront.

Ideally, all this would be done away with by OpenID or client-side certificates or something along those lines. The whole password-and-email-in-case-you-forget-it paradigm is broken, really.

I did that for a time (which I mention in the article), but it's still a superfluous check on top of an activation email. If your users are typing the wrong values into your registration form, perhaps you need better labeling or placeholder text? Display an error that the activation email couldn't be sent. But why add superfluous checks?

While I appreciate the elegance of your solution from an engineering perspective the user who accidentally enters an invalid address is definitely getting a worse user experience here. If you're using javascript to validate the email a user will know they've made a mistake immediately. In your scenario they'll see a page telling them that they should receive an email, and then what? They have to start again? If they're lucky they'll think of hitting the back button and full it in correctly. More likely, they'll just think; hmm this email's taking a while to come through, I'll check Facebook... With a bit of luck they'll remember they were trying to sign up for your service, otherwise, you just lost a signup.

Yes exactly. We validate client side using typical JavaScript, and we also validate server side.

In our case, accounts may be created by third-party apps using REST JSON APIs, so we want to let the third-party app know that the email address isn't RFC-valid.

Knowing whether the email was sent is not always something you can do synchronously.

A simple check for an "@" sign would go a long way to avoiding bounced mail notifications from usernames being entered in email address fields.

Yes, agreed (and I mention this at the end of the article as well) and I still use the /@/ regex often. But a good UI on the registration form can go a long way in alleviating the "switching the email address and username fields" problem.

>a good UI on the registration form can go a long way in alleviating //

But not all the way. And so a simple "you might have got this wrong" flag would be helpful, no?

"You might have it wrong", yes. "You are wrong, we won't let you submit the form" won't.

One addtional check---see if there's an MX or an A record on the portion after the "@".

Often, your web server application won't know that the activation email can't be sent. It's common practice to throw outgoing emails into a job queue, so a very basic check isn't superfluous at all.

Yep, this is definitely most often the case. Perhaps I should have reworded that to reflect that I believe anything more than a simple /@/ check to be largely superfluous. I still use the /@/ regex often, which I mention at the end of the article.

I totally agree. The one other thing I might add is to check for commas, since they are never valid in an email address and "something,com" is a common typo.

By my reading of RFC 822, commas are technically valid, as long as they are properly quoted, as in: "Doe, John"@example.com

Of course, whether any email server actually accepts that is a different story.

At the risk of sounding like a hyprocrite since I just advocated for minimal validation of emails... that is a nonissue. Nobody actually does that.

Anyway, the regexp I use is /.+@.+\..+/ which supports the address you describe, but (usually) catches the relatively common mistake of user@yahoo,com

Commas can be valid and our servers manage them correctly.

That's not true either. I don't know how it's set up other than that we use exchange, but on our internal network, you can send an email to someone's firstinitiallastname (the part that is before the @ for external senders) and it will go through.

So on our production servers, I need the @, but on our dev/text servers, I don't. And no, the ___domain is not appended to the address before sending. That's the part I actually know about.

It's common practice to allow unqualified emails addresses (ie. without the @___domain.tld) from local sources since it's trivial to look up against your own user list. Depending on the MTA, the ___domain may or may not be appended, but often the local organisation's default ___domain is implied. However, this shouldn't work when routing mail via external MTAs that have no knowledge of your organisational structure.