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