4 ms·
How is it better to have "simple" emails?
by yreg 5y ago
How is it better to have "simple" emails?
- alkonaut 5y agoIt 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 agoThe 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 agoBeing 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 agoSure. 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.
- jobigoud 5y agoThis is usually done to catch what they think has a high chance of being a user error, even if otherwise valid.
- yreg 5y agoAnd 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.