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