7 ms·

I don't think this is good advice. From a previous startup we saw a ton of signups like, "john@gmail" and the like. Obviously this person will not get a valid

I don't think this is good advice. From a previous startup we saw a ton of signups like, "john@gmail" and the like. Obviously this person will not get a validation email -- and in all likelihood will not be able to log in to his account when he returns. It's best to catch him when he's entering the information.

riffraff 13y ago
still there is a difference between validating * @ * . * and trying to check if parenthesis are matched correctly.
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
kiallmacinnes 13y ago
I've seen a huge number of users do exactly this. Anyone who says "let the confirmation email handle it" clearly only has HN readers as customers. The type silly stuff, then email support to complain they never received the confirmation.
chrismarlow9 13y ago
Worked on custom mailing scripts for a few larger newsletters which had no regex based validation. It was "add and forget" on every form submission. Of the failed emails, forgetting the ".com/.net/.org" on the email was the most common mistake I saw as well.
ljd 13y ago
I hear and understand a lot of the comments on this thread mention that regex saves the user from a typo and such. So I want to vouch for a github project called mailcheck[0] by the Kicksend team that's great. At Ventata, we used to have the same issues you've all described with people forgetting things like ".com" and "gmial" vs "gmail". Once we started using mailcheck our bounce rate went way down. Now we only get bounces when people deliberately give us faulty addresses, but we aren't really concerned with trying to convert them. They are checking us out and want to stay anonymous, I don't mind that. That condition aside, Mailcheck is pretty much all you'll ever need. [0] https://github.com/kicksend/mailcheck https://github.com/kicksend/mailcheck
- rallison 13y ago
  Mailcheck looks pretty interesting - I'd been considering adding some sort of client side validation for email addresses for my personal projects, and this looks pretty solid. There are a few cases that it doesn't catch that I wish it would, but it appears it would catch a fair percentage of simple mistakes. For example, it catches foo@gmail, but it doesn't catch foo@outlook. Of course, gmail is going to be the more common case. Still, it looks good overall and an improvement over no client side validation. Edit: Actually, I see you can define a set of domains to check against. Very nice.
- baudehlo 13y ago
  The only thing mailcheck doesn't do is check if the domain has MX records, so valid looking domains that you'll never be able to send anything to will pass. I've tried to help this situation by creating an API for you guys: https://www.emailitin.com/email_validator https://www.emailitin.com/email_validator
  - adamzochowski 13y ago
    Domains without MX record can be valid, as mail servers, upon lack of MX record, will query for A record.
    - claudius 13y ago
      Or AAAA records.
anonyfuss 13y ago
I think it's great advice; remember, the advice is: Stop Validating Email Addresses __With Your Complex Regex__. Remember that new TLDs are added, and that john@tld can actually be entirely valid. If you want to prevent "john@gmail", then use a real RFC-compliant e-mail address parser, and attempt to resolve the domain component MX/A records (and remember, it might be an IP address). If that fails (or your regex fails, or whatever validation you use), ____SUGGEST____ to the user that the address appears to be invalid. There's no reason for an overzealous registration form to refuse to accept the user's actual e-mail address.
- ChrisLTD 13y ago
  "If that fails (or your regex fails, or whatever validation you use), ____SUGGEST____ to the user that the address appears to be invalid. There's no reason for an overzealous registration form to refuse to accept the user's actual e-mail address." Bingo. Help people, don't hinder them.
- tomjen3 13y ago
  Honestly if the user is signing up with an ip email then you really shouldn't accept it - it may be valid but something fishy is going on for sure.
  - anonyfuss 13y ago
    Why does it matter? If I managed to acquire the 8.8.8.0/24 netblock, I might very well want to use 'user@8.8.8.8' as my e-mail address. I don't see why it has any material affect on someone requesting e-mail addresses: if it's valid, then it's valid. This seems to be an example of the misplaced sense of propriety with which people approach validating e-mail addresses -- that somehow, your job isn't just to help the user enter an address, but also to define what is and is not 'reasonable'. Imagine if companies refused to accept "1 Infinite Loop" as a street address because it's clearly ridiculous. Except that it's Apple's actual street address.
    - davidw 13y ago
      The one user in 10,000 who actually uses an ip address as an email address can surely figure out why they're getting rejected. Of course, he'll probably go channel the Comic Book Guy and write a scathing post on his blog (Worst. Regexp. Ever.), but the normal people who use the service probably won't see that anyway.
invisible 13y ago
I love these articles that are posted and the ACCURATE answer is that the article proposes bad advice. In what world is not validating an email a good thing? It's not like emails vary after a certain complexity is reached. A better article would have been someone documenting a validation regex that approaches perfect without exceeding insane complexity. Next we'll see articles to not run the Luhn algorithm on credit cards =/.
- DanBC 13y ago
  > In what world is not validating an email a good thing? Validating an email address is important. The way you do that is send an email to that address. You can't do it with regex, and attempting to do so leaves you open to a variety of flaws.
  - invisible 13y ago
    That is not validating - that is accepting it blindly into your database. You potentially just lost a user and/or customer (or made them unhappy because now they have to register again). Like I said, when you accept a credit card, normally you validate the formatting of the card before trying to charge money using the info. Emails are very similar.
    - DanBC 13y ago
      What? They give you their email. You immediately send them an email with a confirmation link. They confirm, at which point you put their email in your database. You must send them a confirmation link because you shouldn't be sending them email in the future unless you've had them confirm their address and that they want to receive email from you. You appear (but perhaps I'm misunderstanding you) to be asking a user to enter their email address; checking that against a regex; storing it; and sending email to it. That's bad, don't do that. > You potentially just lost a user and/or customer (or made them unhappy because now they have to register again) You're potentially losing customers because their valid email addresses are not validating through your broken regex; or their incorrect email is validating through your regex. > when you accept a credit card, normally you validate the formatting of the card Credit cards are trivially easy to check for formatting. You use the Luhn algorithm which tells you if it's possible for that number to be valid or not. This is because there's a strict format for credit cards. There is no such format for email addresses. That's why the only sensible way to check a user's email address is to send a confirmation email to them.

riffraff 13y ago

still there is a difference between validating * @ * . * and trying to check if parenthesis are matched correctly.

deleted 13y ago
[deleted]
deleted 13y ago
[deleted]

kiallmacinnes 13y ago

I've seen a huge number of users do exactly this. Anyone who says "let the confirmation email handle it" clearly only has HN readers as customers. The type silly stuff, then email support to complain they never received the confirmation.

chrismarlow9 13y ago

Worked on custom mailing scripts for a few larger newsletters which had no regex based validation. It was "add and forget" on every form submission. Of the failed emails, forgetting the ".com/.net/.org" on the email was the most common mistake I saw as well.

ljd 13y ago

I hear and understand a lot of the comments on this thread mention that regex saves the user from a typo and such. So I want to vouch for a github project called mailcheck[0] by the Kicksend team that's great. At Ventata, we used to have the same issues you've all described with people forgetting things like ".com" and "gmial" vs "gmail". Once we started using mailcheck our bounce rate went way down. Now we only get bounces when people deliberately give us faulty addresses, but we aren't really concerned with trying to convert them. They are checking us out and want to stay anonymous, I don't mind that. That condition aside, Mailcheck is pretty much all you'll ever need. [0] https://github.com/kicksend/mailcheck https://github.com/kicksend/mailcheck

rallison 13y ago
Mailcheck looks pretty interesting - I'd been considering adding some sort of client side validation for email addresses for my personal projects, and this looks pretty solid. There are a few cases that it doesn't catch that I wish it would, but it appears it would catch a fair percentage of simple mistakes. For example, it catches foo@gmail, but it doesn't catch foo@outlook. Of course, gmail is going to be the more common case. Still, it looks good overall and an improvement over no client side validation. Edit: Actually, I see you can define a set of domains to check against. Very nice.
baudehlo 13y ago
The only thing mailcheck doesn't do is check if the domain has MX records, so valid looking domains that you'll never be able to send anything to will pass. I've tried to help this situation by creating an API for you guys: https://www.emailitin.com/email_validator https://www.emailitin.com/email_validator
- adamzochowski 13y ago
  Domains without MX record can be valid, as mail servers, upon lack of MX record, will query for A record.
  - claudius 13y ago
    Or AAAA records.

anonyfuss 13y ago

I think it's great advice; remember, the advice is: Stop Validating Email Addresses __With Your Complex Regex__. Remember that new TLDs are added, and that john@tld can actually be entirely valid. If you want to prevent "john@gmail", then use a real RFC-compliant e-mail address parser, and attempt to resolve the domain component MX/A records (and remember, it might be an IP address). If that fails (or your regex fails, or whatever validation you use), ____SUGGEST____ to the user that the address appears to be invalid. There's no reason for an overzealous registration form to refuse to accept the user's actual e-mail address.

ChrisLTD 13y ago
"If that fails (or your regex fails, or whatever validation you use), ____SUGGEST____ to the user that the address appears to be invalid. There's no reason for an overzealous registration form to refuse to accept the user's actual e-mail address." Bingo. Help people, don't hinder them.
tomjen3 13y ago
Honestly if the user is signing up with an ip email then you really shouldn't accept it - it may be valid but something fishy is going on for sure.
- anonyfuss 13y ago
  Why does it matter? If I managed to acquire the 8.8.8.0/24 netblock, I might very well want to use 'user@8.8.8.8' as my e-mail address. I don't see why it has any material affect on someone requesting e-mail addresses: if it's valid, then it's valid. This seems to be an example of the misplaced sense of propriety with which people approach validating e-mail addresses -- that somehow, your job isn't just to help the user enter an address, but also to define what is and is not 'reasonable'. Imagine if companies refused to accept "1 Infinite Loop" as a street address because it's clearly ridiculous. Except that it's Apple's actual street address.
  - davidw 13y ago
    The one user in 10,000 who actually uses an ip address as an email address can surely figure out why they're getting rejected. Of course, he'll probably go channel the Comic Book Guy and write a scathing post on his blog (Worst. Regexp. Ever.), but the normal people who use the service probably won't see that anyway.

invisible 13y ago

I love these articles that are posted and the ACCURATE answer is that the article proposes bad advice. In what world is not validating an email a good thing? It's not like emails vary after a certain complexity is reached. A better article would have been someone documenting a validation regex that approaches perfect without exceeding insane complexity. Next we'll see articles to not run the Luhn algorithm on credit cards =/.

DanBC 13y ago
> In what world is not validating an email a good thing? Validating an email address is important. The way you do that is send an email to that address. You can't do it with regex, and attempting to do so leaves you open to a variety of flaws.
- invisible 13y ago
  That is not validating - that is accepting it blindly into your database. You potentially just lost a user and/or customer (or made them unhappy because now they have to register again). Like I said, when you accept a credit card, normally you validate the formatting of the card before trying to charge money using the info. Emails are very similar.
  - DanBC 13y ago
    What? They give you their email. You immediately send them an email with a confirmation link. They confirm, at which point you put their email in your database. You must send them a confirmation link because you shouldn't be sending them email in the future unless you've had them confirm their address and that they want to receive email from you. You appear (but perhaps I'm misunderstanding you) to be asking a user to enter their email address; checking that against a regex; storing it; and sending email to it. That's bad, don't do that. > You potentially just lost a user and/or customer (or made them unhappy because now they have to register again) You're potentially losing customers because their valid email addresses are not validating through your broken regex; or their incorrect email is validating through your regex. > when you accept a credit card, normally you validate the formatting of the card Credit cards are trivially easy to check for formatting. You use the Luhn algorithm which tells you if it's possible for that number to be valid or not. This is because there's a strict format for credit cards. There is no such format for email addresses. That's why the only sensible way to check a user's email address is to send a confirmation email to them.