3 ms·

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

by usea 4y ago

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.
CodesInChaos 4y ago
Which people are hurt by rejecting 1, 2, 3, 12, 13 and 14 from this list?

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

by usea 4y ago

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

> 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.

CodesInChaos 4y ago

Which people are hurt by rejecting 1, 2, 3, 12, 13 and 14 from this list?