6 ms·

While the RFC allows a lot of weird email address edgecases, I see little reason to allow most of these when a user signs up to my service. How many legitimate

While the RFC allows a lot of weird email address edgecases, I see little reason to allow most of these when a user signs up to my service. How many legitimate users will use quoted strings, dotless domains or even IP addresses?

roflyear 4y ago
Well, why block them unless you have a good reason to?
- mgkimsal 4y ago
  it implies support, and may place more burden on testing. if you test with XYZ only, but also allow ABC... then ABC stops working... you'll have pissed off customers.
  - c22 4y ago
    Whereas if you block ABC outright you'll just have pissed off people who aren't customers!
    - mgkimsal 4y ago
      Sure, but that's a different story. You might piss them off and lose customers. You may also be knowingly increasing your support costs. For the average company trying to navigate these sorts of decisions, supporting users with emails like "a$123@1-2-3.12397.museum" probably isn't high on their list of priorities, regardless of whether it's "valid" or not.
      - roflyear 4y ago
        Yeah not really talking about those addresses tho. Plenty of sites reject stuff like hi+whatever@whatever.com which is not super uncommon...
jcranmer 4y ago
The basic rule of thumb I use this: are you implementing email at the MTA level (needing to build/parse RFC 5321 commands or RFC 5322 blobs directly), or are you using email closer to a "universal internet ID" purpose (i.e., application perspective)? If you are in the former category, then yes, follow the spec to the letter. If you're in the latter, then screw the precise guidelines of the spec and reject emails that are very unlikely to be valid: no quoted localparts, no IP address literals. In addition, go ahead and say that email is case-insensitive (more precisely, case-preserving).
usea 4y ago
There is no reason to block them, and doing so hurts people.
- JumpCrisscross 4y ago
  > no reason to block them Sure there is. It may signal more edge-case behavior to come. If you're building a developer tool, you should probably support it. But if you're building a consumer product, that may not be a customer you want.
  - usea 4y ago
    That's true. If you're already in the business of hurting people, then it's a good way of identifying those you're trying to hurt. I pass no judgment here. I only mean to admit my incorrect assumption.
    - JumpCrisscross 4y ago
      > already in the business of hurting people, then it's a good way of identifying those you're trying to hurt What? Some customers cost more to serve than they will ever make you. Still serving them may make sense. But often it doesn’t. If you’re bootstrapping a gummy bear start-up, a customer who pings you weekly with edge-case support tickets is unlikely worth the engineering effort to appease. If you’re building an AWS competitor, on the other hand, you may want to hire them.
- jcranmer 4y ago
  If you try to handle email precisely correctly according to the specification, you will find that users will complain that you're handling email incorrectly. The biggest aspect of this is case-sensitivity: local parts are officially case sensitive, but the overwhelming practice is that email addresses are case insensitive, and people expect to find email addresses via case-insensitive lookup. As I say in my sibling comment, there are generally two purposes you might have with an email address. If your primary purpose is actually handling email, then that is when you need to be perfectly precise for email. But if your purpose is in using the email address as some sort of "universal internet ID"--this is true for the vast majority of uses of email addresses--then restricting the set of potentially valid email addresses is not only valid but a good idea. Quoted string local-parts and IP address literals in lieu of domains are things which are generally broken by middleware software that deals with email addresses anyways, to such a degree that there is no way anyone who has such an email address is using it as anything other than a "do you actually support this" email address--it can't be a valid unique-ish identifier for them. Additionally, allowing them to creep into parts of your system may break assumptions of other databases, which increases the chance of weird, deep failures that may cause security vulnerabilities. That alone is a pretty good reason to block them.
SAI_Peregrinus 4y ago
Does it matter? Even if the email is a bog-standard USERNAME@gmail.com, you've got no way to know if the email is real until you send a challenge email to the address. If you have to do that anyway, why bother validating anything unnecessary?
- davchana 4y ago
  Correct. Anytime a site ask me for an email before giving me a file, a code or download, I use something@gmail.com (the literal word something) & most of the time the site gives me what I am looking for. If they send that link in email only, then I use a temporary email.
  - mariusor 4y ago
    I own a similar email address, and I have to say that I absolutely hate the people that do what you do. I can't tell you how many real services people sign up for, while using a "something@gmail.com" address. There are only a couple that include a "someone used my email address to sign up" link to remove my email from their account. Sigh.
    - dns_snek 4y ago
      It doesn't have to be a real domain or a potentially-valid address. I will usually use something like spam@gmail.com, root@localhost, or info@TheirWebsite.com. Last one likely gives them a taste of their own medicine.
    - pooper 4y ago
      My case is not so bad but I get a few password reset links from different services every week.
- CodesInChaos 4y ago
  1,2,3,14 add a lot of complexity which increases the potential for bugs and security issues. 12 is almost certainly a typo 13 is probably a spammer Also <input type=email> will reject several of these as well, so if you have such an edge-case email in your database, you'll run into issues with html forms.
mkehrt 4y ago
How many legitimate users will use pluses or dots which you forgot to allow in your email validator? How many legitimate users will use capital letters, which I had to add to an in-production email validator on an app with millions of MAUs? Just send a confirmation email to whatever string they provide you.
- zzo38computer 4y ago
  > Just send a confirmation email to whatever string they provide you. You might want to first check that it is not a local address, and to reject it if it is (unless it is being used for an internal registration service). You should also reject it if the destination is unreachable (in which case it is not possible to send a confirmation email, anyways).
- marwis 4y ago
  > How many legitimate users will use pluses or dots which you forgot to allow in your email validator? Millions?

roflyear 4y ago

Well, why block them unless you have a good reason to?

mgkimsal 4y ago
it implies support, and may place more burden on testing. if you test with XYZ only, but also allow ABC... then ABC stops working... you'll have pissed off customers.
- c22 4y ago
  Whereas if you block ABC outright you'll just have pissed off people who aren't customers!
  - mgkimsal 4y ago
    Sure, but that's a different story. You might piss them off and lose customers. You may also be knowingly increasing your support costs. For the average company trying to navigate these sorts of decisions, supporting users with emails like "a$123@1-2-3.12397.museum" probably isn't high on their list of priorities, regardless of whether it's "valid" or not.
    - roflyear 4y ago
      Yeah not really talking about those addresses tho. Plenty of sites reject stuff like hi+whatever@whatever.com which is not super uncommon...

jcranmer 4y ago

The basic rule of thumb I use this: are you implementing email at the MTA level (needing to build/parse RFC 5321 commands or RFC 5322 blobs directly), or are you using email closer to a "universal internet ID" purpose (i.e., application perspective)? If you are in the former category, then yes, follow the spec to the letter. If you're in the latter, then screw the precise guidelines of the spec and reject emails that are very unlikely to be valid: no quoted localparts, no IP address literals. In addition, go ahead and say that email is case-insensitive (more precisely, case-preserving).

usea 4y ago

There is no reason to block them, and doing so hurts people.

JumpCrisscross 4y ago
> no reason to block them Sure there is. It may signal more edge-case behavior to come. If you're building a developer tool, you should probably support it. But if you're building a consumer product, that may not be a customer you want.
- usea 4y ago
  That's true. If you're already in the business of hurting people, then it's a good way of identifying those you're trying to hurt. I pass no judgment here. I only mean to admit my incorrect assumption.
  - JumpCrisscross 4y ago
    > already in the business of hurting people, then it's a good way of identifying those you're trying to hurt What? Some customers cost more to serve than they will ever make you. Still serving them may make sense. But often it doesn’t. If you’re bootstrapping a gummy bear start-up, a customer who pings you weekly with edge-case support tickets is unlikely worth the engineering effort to appease. If you’re building an AWS competitor, on the other hand, you may want to hire them.
jcranmer 4y ago
If you try to handle email precisely correctly according to the specification, you will find that users will complain that you're handling email incorrectly. The biggest aspect of this is case-sensitivity: local parts are officially case sensitive, but the overwhelming practice is that email addresses are case insensitive, and people expect to find email addresses via case-insensitive lookup. As I say in my sibling comment, there are generally two purposes you might have with an email address. If your primary purpose is actually handling email, then that is when you need to be perfectly precise for email. But if your purpose is in using the email address as some sort of "universal internet ID"--this is true for the vast majority of uses of email addresses--then restricting the set of potentially valid email addresses is not only valid but a good idea. Quoted string local-parts and IP address literals in lieu of domains are things which are generally broken by middleware software that deals with email addresses anyways, to such a degree that there is no way anyone who has such an email address is using it as anything other than a "do you actually support this" email address--it can't be a valid unique-ish identifier for them. Additionally, allowing them to creep into parts of your system may break assumptions of other databases, which increases the chance of weird, deep failures that may cause security vulnerabilities. That alone is a pretty good reason to block them.

SAI_Peregrinus 4y ago

Does it matter? Even if the email is a bog-standard USERNAME@gmail.com, you've got no way to know if the email is real until you send a challenge email to the address. If you have to do that anyway, why bother validating anything unnecessary?

davchana 4y ago
Correct. Anytime a site ask me for an email before giving me a file, a code or download, I use something@gmail.com (the literal word something) & most of the time the site gives me what I am looking for. If they send that link in email only, then I use a temporary email.
- mariusor 4y ago
  I own a similar email address, and I have to say that I absolutely hate the people that do what you do. I can't tell you how many real services people sign up for, while using a "something@gmail.com" address. There are only a couple that include a "someone used my email address to sign up" link to remove my email from their account. Sigh.
  - dns_snek 4y ago
    It doesn't have to be a real domain or a potentially-valid address. I will usually use something like spam@gmail.com, root@localhost, or info@TheirWebsite.com. Last one likely gives them a taste of their own medicine.
  - pooper 4y ago
    My case is not so bad but I get a few password reset links from different services every week.
CodesInChaos 4y ago
1,2,3,14 add a lot of complexity which increases the potential for bugs and security issues. 12 is almost certainly a typo 13 is probably a spammer Also <input type=email> will reject several of these as well, so if you have such an edge-case email in your database, you'll run into issues with html forms.

mkehrt 4y ago

How many legitimate users will use pluses or dots which you forgot to allow in your email validator? How many legitimate users will use capital letters, which I had to add to an in-production email validator on an app with millions of MAUs? Just send a confirmation email to whatever string they provide you.

zzo38computer 4y ago
> Just send a confirmation email to whatever string they provide you. You might want to first check that it is not a local address, and to reject it if it is (unless it is being used for an internal registration service). You should also reject it if the destination is unreachable (in which case it is not possible to send a confirmation email, anyways).
marwis 4y ago
> How many legitimate users will use pluses or dots which you forgot to allow in your email validator? Millions?