4 ms·

Microsoft appears to be adding the header `Authentication-Results` to all outbound e-mail. This header contains the first recipient's domain name, regardless of

by bouke 5y ago

Microsoft appears to be adding the header `Authentication-Results` to all outbound e-mail. This header contains the first recipient's domain name, regardless of whether this recipient is specified as to/cc/bcc. The whole point of a bcc is that it doesn't disclose anything about the bcc recipient to other recipients. So disclosing the bcc recipient's domain name is a serious privacy problem!

bombcar 5y ago
So a workaround is to always to: yourself on a bcc-only email.
- koheripbal 5y ago
  I think this is what most people do, and why this hasn't come up before.
  - davidmurdoch 5y ago
    Anecdote: I've never done this and couldn't have fathomed a reason to have done so before this.
    - bombcar 5y ago
      I do it because otherwise some mail programs complain if you ONLY have BCC recipients (and it looks a bit strange).
tallanvor 5y ago
Bear in mind that I'm far from an expert on email transit, but it looks to me like an early Microsoft MTA adds that authentication-realm entry and it's probably used for routing (I suspect they route emails primarily for O365 email through one set of MTAs to keep things internal, and domains not on O365 get sent through a different set). So, Using Authentication-Realm for this purpose, provided everything is formatted properly, isn't a bug. Nor is it to not remove this per the RFC at https://tools.ietf.org/html/rfc7001#section-5 https://tools.ietf.org/html/rfc7001#section-5. Nor is it against the spec for Google to not remove it, since it's not forged and pretending to be a Google MTA that added it. You're right that you're potentially leaking a domain name, but if you're BCC'ing two different organizations where a dangerous situation would result from one of those organizations knows that the other received it, then you've already made a bad decision.
- laGrenouille 5y ago
  > if you're BCC'ing two different organizations where a dangerous situation would result from one of those organizations knows the other received it Agreed. But, I think the real problem comes from sending a BCC'd email to hundreds of recipients and accidentally exposing the first person's information to everyone else.
  - bigyikes 5y ago
    My email’s domain is my last name, so this is a problem for me. This would be even more of a problem if my last name started with an A, since many email lists are sorted by lady name.
- ajross 5y ago
  > but if you're BCC'ing two different organizations where a dangerous situation would result from one of those organizations knows that the other received it, then you've already made a bad decision I don't know that I buy that. The easiest way to get around a security critique is to respond "but this isn't a security problem", which is fundamentally what you and MS are doing. The problem with that logic is that most security problems (and all the interesting ones!) don't look like security problems until they become so. Maybe people are too young to remember, but XSS and SQL injection were genuine surprises at one point, being vulnerabilities in a part of a system that no one thought was subject to "security" issues. This has the same smell. The more justifiable response here is to recognize that RFC822 long ago made an interface promise that at least "looks like" a privacy thing: BCC copies are blind. And software that violates that promise should be presumptively insecure, not excused away because other areas of the system may be equally insecure (or, worse, because the practical impact seems low). Shorter version: BCC clearly should be private because its users expect it to be private, and no other reason should be required.

by bouke 5y ago

bombcar 5y ago

So a workaround is to always to: yourself on a bcc-only email.

koheripbal 5y ago
I think this is what most people do, and why this hasn't come up before.
- davidmurdoch 5y ago
  Anecdote: I've never done this and couldn't have fathomed a reason to have done so before this.
  - bombcar 5y ago
    I do it because otherwise some mail programs complain if you ONLY have BCC recipients (and it looks a bit strange).

tallanvor 5y ago

Bear in mind that I'm far from an expert on email transit, but it looks to me like an early Microsoft MTA adds that authentication-realm entry and it's probably used for routing (I suspect they route emails primarily for O365 email through one set of MTAs to keep things internal, and domains not on O365 get sent through a different set). So, Using Authentication-Realm for this purpose, provided everything is formatted properly, isn't a bug. Nor is it to not remove this per the RFC at https://tools.ietf.org/html/rfc7001#section-5 https://tools.ietf.org/html/rfc7001#section-5. Nor is it against the spec for Google to not remove it, since it's not forged and pretending to be a Google MTA that added it. You're right that you're potentially leaking a domain name, but if you're BCC'ing two different organizations where a dangerous situation would result from one of those organizations knows that the other received it, then you've already made a bad decision.

laGrenouille 5y ago
> if you're BCC'ing two different organizations where a dangerous situation would result from one of those organizations knows the other received it Agreed. But, I think the real problem comes from sending a BCC'd email to hundreds of recipients and accidentally exposing the first person's information to everyone else.
- bigyikes 5y ago
  My email’s domain is my last name, so this is a problem for me. This would be even more of a problem if my last name started with an A, since many email lists are sorted by lady name.
ajross 5y ago
> but if you're BCC'ing two different organizations where a dangerous situation would result from one of those organizations knows that the other received it, then you've already made a bad decision I don't know that I buy that. The easiest way to get around a security critique is to respond "but this isn't a security problem", which is fundamentally what you and MS are doing. The problem with that logic is that most security problems (and all the interesting ones!) don't look like security problems until they become so. Maybe people are too young to remember, but XSS and SQL injection were genuine surprises at one point, being vulnerabilities in a part of a system that no one thought was subject to "security" issues. This has the same smell. The more justifiable response here is to recognize that RFC822 long ago made an interface promise that at least "looks like" a privacy thing: BCC copies are blind. And software that violates that promise should be presumptively insecure, not excused away because other areas of the system may be equally insecure (or, worse, because the practical impact seems low). Shorter version: BCC clearly should be private because its users expect it to be private, and no other reason should be required.