3 ms·
user+detail@domain.com user@domain.com The 'detail' is optional, and doesn't infer any privacy. It's kind of like if you get mail delivered to: nprateem, of
by oarsinsync 7y ago
user+detail@domain.com
user@domain.com
The 'detail' is optional, and doesn't infer any privacy.
It's kind of like if you get mail delivered to:
nprateem, office 2, university of ycombinator
and instead they only store:
nprateem, university of ycombinator
Odds are, mail will still be delivered to you, but it might not come to office 2, and might come to office 1 instead. It's not what you wanted, but there's absolutely no impact to your privacy by them stripping away additional details.
- nprateem 7y agoIf you decide you no longer want to receive email from user+detail@domain.com it's easy to set up a blacklist filter. If they circumvent that and email you at user@domain.com you've lost that alias and easy way of blacklisting them. And presumably if someone had wanted to be contacted at user@domain.com they would have provided that email in the first place. So I don't think your analogy holds.
- oarsinsync 7y agoFair, the analogy doesn't hold onto the functions provided, but RFC 5233 is very clear that the user+detail separation does not provide any privacy protections, nor can it. The 'user' part is still public information, as is what it's used for. There should be no expectation of privacy for information being used per specification design. The usability trade-off is a shame, but the solution was half-baked at best, and is primarily useful when combined with privacy-sacrificing public email providers. When you have greater control of your email, distinct 'user' parts can be used, which does provide the privacy aspect desired.