I maintain that the only reasonable way to validate an email address is to send it a message and hope for a reply. Every other method I've ever tried has failed in some silly way, as described in the article.

As far as I know, that literally is the only way to validate an email address, universally speaking, beyond an internal whitespace check.

But I think if you take "local" out of the equation, as you would for customer emails, you can validate a bit more. You might be able to validate on a single @ being in there somewhere, with something before and after it, maybe look for a period after the @ for "[email protected]" as I think every external address needs a dotted domain.

That's about as far as I think you can safely go. Anything else is legal.

Well, maybe not a single @. At least one @ maybe. There's a set of special characters that aren't permitted in the local part of an email address including @... unless they're quoted. So "@"@example.com is a valid address.

Oof, thanks. I forgot you could quote the @ and thought it was the one universally illegal character. Also forgot there were others, oops.

I usually just recommend people don't validate email addys and let the email verification message do the job for you. This is pretty much why.

Domains labels are fairly strictly defined, so you check that a bit more stringently.

> as I think every external address needs a dotted domain.

Something like example@com is technically a valid email address; although I don't know if there are any TLDs which accept emails.

That's true, I didn't think about that case.

I don't think I've ever seen a bare TLD in real life like that though--maybe very early on as DNS became a thing? Not since the web though.

Yep, I agree. On frontend, use a very simple validation such as /.+@.+\..+/ (better to use string splits IMHO, but you see the idea) just to give users some feedbacks in case of a clearly invalid email.

On the backend send an email and let the user confirms.

Sometimes you need to harvest email addresses and want to distinguish them from junk data. If you're actually developing the algorithm in the face of real data, you'll get a good validator.

I have seen this "problem" before. But I'm pretty sure rejecting the '+' sign is so that you have to swallow the spam when it eventually comes.

If you know about this trick and you want to harvest as much email addresses for spam as possible, wouldn't it make more sense to accept pluses in email addresses, and then strip them out later? It seems far more likely that it's because it's unintentional, due to poor programming.

Not if using/selling the email address you provide is according to the ToS of the seller. Then they can legally spam [email protected] but not [email protected], which is a huge downer.

I've had similar problems with financial or medical institutions systems handling the .family TLD. My workaround is to have a .org TLD that is similar to my .family TLD and then forward incoming email to the same name mapped onto the .family TLD. It'd be nice if I didn't have to do this, but unfortunately there are quite a few systems with shoddy email validation logic.

Considering this is talking about client-side validation in JS, that shouldn't be hard to fix/bypass locally. Worth a try, it's not a given that there's matching backend validation!

However, at least they had the decency not to hardcore the TLD list. I used to have a .eu email and it would get rejected rather often, even years after the TLD came out.

I've had to locally override some JS on the client-side and hoped their backend validation was a lot more sane. The frontend validation logic was limiting the TLD to minimum of two characters and max of four ({2,4}). I use a .email TLD for sites that I don't want to give my personal email.

If you're using Chrome (65+), you can easily bypass any validations/logic by using local overrides (https://developers.google.com/web/updates/2018/01/devtools#o...). As marcolussetti said, it's worth trying out.

That article doesn't read like you were trying to buy the car... 95% of the article is explaining about the regexp stopping you ;-)

The only reliable way of checking for a valid email address is to see if it contains the @ symbol.

If you can explain why your email address was rejected, then you didn't buy a car because you didn't want to.

That's true, but wouldn't make for an interesting blog post.

Yes, I'm sure the author could go register [email protected], but it's really a post about incorrect assumptions.

This blog should really be understood as another in the "falsehoods programmers believe about..." series.

Surely you can buy a car without any email address.

...oh, this was online only. Well there's your problem.

Not from that retailer, at any rate.