3 ms·

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,

by 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
    - ratww 5y ago
      Sure. But my whole point is that all the other reasons are not legitimate, the whole point of blocking + is to cover the company's ass, there's no legitimate potential issues with notification, or even to prevent errors. It's just BS rationalisation.

by ratww 5y ago

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
  - ratww 5y ago
    Sure. But my whole point is that all the other reasons are not legitimate, the whole point of blocking + is to cover the company's ass, there's no legitimate potential issues with notification, or even to prevent errors. It's just BS rationalisation.