3 ms·

This has been discussed at length several times before and the answer to why you use a regex like that to validate emails is because you aren't trying to valida

This has been discussed at length several times before and the answer to why you use a regex like that to validate emails is because you aren't trying to validate against a standard, but against a subset of email formats. You want a "normal" simple email. No "+" domains etc. Because it doesn't matter if you annoy the 0.01% of your users that would be negatively affected by that, it's better to have their simple/canonical emails. On the right side of the @ I agree completely, e.g. you must allow longer tlds. The regex is shit. But the same "simplification" thing would apply for IPv4: I'd probably want to have 4 groups of {0-9} even if a valid ipv4 address could be written in a lot more creative ways than that. The normal/simple/canonical way to write the address is a smaller scope than the set of allowed ways. The regex to parse any valid email and the regex to parse the info I want, (perhaps from the user subset I want!) can be very different. Edit: don't shoow the messenger - there is just zero chance you want a db that is more likely to contain user errors, has less valuable emails in it. "Enter your email" doesn't mean "Enter a string that can be considered valid according to the RFC"! No one cares whether "foo/baz=frob@example.com" is a valid email adress or not. In some cases you want RFC-compliant addresses, in which case it's a perfectly good idea to parse strictly to the spec. But in most cases you want a user identifier you know you can also contact with 100% certainty using some email SaaS. Or one you can cross reference to some other source. That's stricly a different purpose than parsing RFC compliant addresses. And allowing "foo@bar"@baz.com is just not a good idea.

yreg 5y ago
How is it better to have "simple" emails?
- alkonaut 5y ago
  It depends on the use case, but for some business use cases you e.g prefer access to the end users default/canonical inbox and not a specific one the user can use to filter etc. It’s also much less likely to cause downstream problems like distribution issues, be rejection by spam filters and so on. Annoying a tiny fraction of users or losing their business just isn’t a big enough issue to matter.
  - ratww 5y ago
    The only use case you're describing is being able to send spam or sell the user's information to third-parties while preventing the user from identifying that, or from filtering e-mails coming from your service. Those are not legitimate uses.
    - alkonaut 5y ago
      Being able to notify users, limit erroneously input emails, or cross reference to existing databases (which invariably have the same kind of validation) are legitimate use cases. Even if I have no interest in selling emails, it's still a net benefit if leaked data (e.g. after a breach) isn't full of bob.smith+mycompany@... rather than bob.smith@
      - ratww 5y ago
        > Being able to notify users Using + emails don't prevent that from happening. > limit erroneously input emails BS excuse. That's what email confirmation, confirmation link, smtp inbox validation, etc, are for. > cross reference to existing databases Not being able to be cross referenced is a feature for the user, not a bug. > Even if I have no interest in selling emails, it's still a net benefit if leaked data (e.g. after a breach) isn't full of bob.smith+mycompany@... rather than bob.smith@ It's benefit for the company, not for the user. I'd prefer to know which company leaked my email.
        alkonaut 5y ago
        > It's benefit for the company, not for the user. Yes. Absolutely 100% agree. What I'm arguing is: if you are ready to annoy a tiny fraction of your users, you will get away with a simpler validation, that is better FOR YOU AS A COMPANY, because it has some benefits ranging from shady to just half-shady. This is why companies do this. Not just a small share of them, and not only because developers didn't understand the RFC. I'm not arguing this is in any way good for end users. I'm saying it can be a good idea despite being horrible towards some users. You keep arguing from the users' perspective when I'm saying "This is being an asshat to users, but it's worth it." The argument "That's bad for users!" isn't a counterargument to that
- jobigoud 5y ago
  This is usually done to catch what they think has a high chance of being a user error, even if otherwise valid.
  - yreg 5y ago
    And what does this solve? A user mistakenly entering an extra plus sign gets a validation error. While user mistakenly entering an extra alphanumeric character (far more common) does not. Maybe they could ban adresses with `q` as well. Most people's names don't contain Q, so might be a user error.
rwallace 5y ago
The point being missed here is that no algorithm can tell you whether a string is a valid email address, because that's not a property of the string in the first place, it's a property of the world. Having a fairly low entropy Gmail address, I get an intermittent drizzle of messages of the form of 'thank you for signing up to Acme!' whose content is such as to make it clear that an actual Acme customer typo'd their email address, and Acme thought you could validate it by checking the form of the string. The only way to validate an email address is to send email to that address, asking the person behind it, are you the one who just signed up for Acme. And once you are doing that, there is no point checking the string for anything other than containing an @.
- alkonaut 5y ago
  > The point being missed here is that no algorithm can tell you whether a string is a valid email address, because that's not a property of the string in the first place, it's a property of the world "Valid" can mean at least 3 different things: a) Conformant to a spec b) Can actually receive email c) Looks like a nice, simple "canonical" standard email address. If you validate to the RFC (a) you still might fail b) and c). (The value of c is debated at length in a separate subthread but let'sjust say that there are more or less shady reasons why this is often a business goal). Since you'll probably validate b) anyway - the validation of either b) or c) is a convenience, because validating b) isn't instant. So you validate to prevent errors and frustration. The question is merely: do I as a business want to have an address with quotes, spaces and backslashes in it, in my database just because it's possible according to the specification? > And once you are doing that, there is no point checking the string for anything other than containing an @. I think there is a legitmate case for a service to simply think "I'd rather lose the business of 1 customer out of a million than worry about backslashes in email addresses". It's not user friendly, and it's not "correct", but it's one of those "good enough" scenaroios.

yreg 5y ago

How is it better to have "simple" emails?

alkonaut 5y ago
It depends on the use case, but for some business use cases you e.g prefer access to the end users default/canonical inbox and not a specific one the user can use to filter etc. It’s also much less likely to cause downstream problems like distribution issues, be rejection by spam filters and so on. Annoying a tiny fraction of users or losing their business just isn’t a big enough issue to matter.
- ratww 5y ago
  The only use case you're describing is being able to send spam or sell the user's information to third-parties while preventing the user from identifying that, or from filtering e-mails coming from your service. Those are not legitimate uses.
  - alkonaut 5y ago
    Being able to notify users, limit erroneously input emails, or cross reference to existing databases (which invariably have the same kind of validation) are legitimate use cases. Even if I have no interest in selling emails, it's still a net benefit if leaked data (e.g. after a breach) isn't full of bob.smith+mycompany@... rather than bob.smith@
    - ratww 5y ago
      > Being able to notify users Using + emails don't prevent that from happening. > limit erroneously input emails BS excuse. That's what email confirmation, confirmation link, smtp inbox validation, etc, are for. > cross reference to existing databases Not being able to be cross referenced is a feature for the user, not a bug. > Even if I have no interest in selling emails, it's still a net benefit if leaked data (e.g. after a breach) isn't full of bob.smith+mycompany@... rather than bob.smith@ It's benefit for the company, not for the user. I'd prefer to know which company leaked my email.
      - alkonaut 5y ago
        > It's benefit for the company, not for the user. Yes. Absolutely 100% agree. What I'm arguing is: if you are ready to annoy a tiny fraction of your users, you will get away with a simpler validation, that is better FOR YOU AS A COMPANY, because it has some benefits ranging from shady to just half-shady. This is why companies do this. Not just a small share of them, and not only because developers didn't understand the RFC. I'm not arguing this is in any way good for end users. I'm saying it can be a good idea despite being horrible towards some users. You keep arguing from the users' perspective when I'm saying "This is being an asshat to users, but it's worth it." The argument "That's bad for users!" isn't a counterargument to that
jobigoud 5y ago
This is usually done to catch what they think has a high chance of being a user error, even if otherwise valid.
- yreg 5y ago
  And what does this solve? A user mistakenly entering an extra plus sign gets a validation error. While user mistakenly entering an extra alphanumeric character (far more common) does not. Maybe they could ban adresses with `q` as well. Most people's names don't contain Q, so might be a user error.

rwallace 5y ago

The point being missed here is that no algorithm can tell you whether a string is a valid email address, because that's not a property of the string in the first place, it's a property of the world. Having a fairly low entropy Gmail address, I get an intermittent drizzle of messages of the form of 'thank you for signing up to Acme!' whose content is such as to make it clear that an actual Acme customer typo'd their email address, and Acme thought you could validate it by checking the form of the string. The only way to validate an email address is to send email to that address, asking the person behind it, are you the one who just signed up for Acme. And once you are doing that, there is no point checking the string for anything other than containing an @.

alkonaut 5y ago
> The point being missed here is that no algorithm can tell you whether a string is a valid email address, because that's not a property of the string in the first place, it's a property of the world "Valid" can mean at least 3 different things: a) Conformant to a spec b) Can actually receive email c) Looks like a nice, simple "canonical" standard email address. If you validate to the RFC (a) you still might fail b) and c). (The value of c is debated at length in a separate subthread but let'sjust say that there are more or less shady reasons why this is often a business goal). Since you'll probably validate b) anyway - the validation of either b) or c) is a convenience, because validating b) isn't instant. So you validate to prevent errors and frustration. The question is merely: do I as a business want to have an address with quotes, spaces and backslashes in it, in my database just because it's possible according to the specification? > And once you are doing that, there is no point checking the string for anything other than containing an @. I think there is a legitmate case for a service to simply think "I'd rather lose the business of 1 customer out of a million than worry about backslashes in email addresses". It's not user friendly, and it's not "correct", but it's one of those "good enough" scenaroios.