5 ms·

I couldn't buy a car because my email address was 'invalid'

41 points by jawns 6y ago

bzb3 6y ago
If you can explain why your email address was rejected, then you didn't buy a car because you didn't want to.
- db48x 6y ago
  Not from that retailer, at any rate.
- Gunax 6y ago
  That's true, but wouldn't make for an interesting blog post. Yes, I'm sure the author could go register random_boy_8786@hotmail.com, but it's really a post about incorrect assumptions. This blog should really be understood as another in the "falsehoods programmers believe about..." series.
  - perl4ever 6y ago
    Surely you can buy a car without any email address. ...oh, this was online only. Well there's your problem.
kumarharsh 6y ago
That article doesn't read like you were trying to buy the car... 95% of the article is explaining about the regexp stopping you ;-)
zach_garwood 6y ago
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.
- SamReidHughes 6y ago
  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.
- dgellow 6y ago
  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.
- geoelectric 6y ago
  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 "addr@domain.tld" 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.
  - arp242 6y ago
    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.
    - geoelectric 6y ago
      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.
  - sohex 6y ago
dsign 6y ago
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.
- gruez 6y ago
  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.
  - dsign 6y ago
    Not if using/selling the email address you provide is according to the ToS of the seller. Then they can legally spam john+as.entered.in.the.form@gmail.com but not john@gmail.com, which is a huge downer.
ahnick 6y ago
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.
marcolussetti 6y ago
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.
- cxam 6y ago
  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#overrides https://developers.google.com/web/updates/2018/01/devtools#o...). As marcolussetti said, it's worth trying out.
thomasedwards 6y ago
The only reliable way of checking for a valid email address is to see if it contains the @ symbol.

41 points by jawns 6y ago

bzb3 6y ago

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

db48x 6y ago
Not from that retailer, at any rate.
Gunax 6y ago
That's true, but wouldn't make for an interesting blog post. Yes, I'm sure the author could go register random_boy_8786@hotmail.com, but it's really a post about incorrect assumptions. This blog should really be understood as another in the "falsehoods programmers believe about..." series.
- perl4ever 6y ago
  Surely you can buy a car without any email address. ...oh, this was online only. Well there's your problem.

kumarharsh 6y ago

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

zach_garwood 6y ago

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.

SamReidHughes 6y ago
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.
dgellow 6y ago
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.
geoelectric 6y ago
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 "addr@domain.tld" 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.
- arp242 6y ago
  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.
  - geoelectric 6y ago
    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.
- sohex 6y ago

dsign 6y ago

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.

gruez 6y ago
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.
- dsign 6y ago
  Not if using/selling the email address you provide is according to the ToS of the seller. Then they can legally spam john+as.entered.in.the.form@gmail.com but not john@gmail.com, which is a huge downer.

ahnick 6y ago

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.

marcolussetti 6y ago

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.

cxam 6y ago
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#overrides https://developers.google.com/web/updates/2018/01/devtools#o...). As marcolussetti said, it's worth trying out.

thomasedwards 6y ago

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