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.
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.
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.
I wish that email clients instead had a "blind forward" feature, which would simply send a second email after sending the first, to the blind recipients.
Such a scheme would presumably not suffer this leak, either.
Basically I only use it when someone sends out an email with too many recipients and I want to reduce the audience because I know it will get out of hand.
I think the proper solution to this is using the Reply-To header.
The OP's point is that it should be a simple 1 step process instead of a multi step process.
I suspect they are further suggesting that email clients should modify their behavior so that when someone enters recipients in the BCC list, instead of BCC'ing the recipients, it auto forwards the mail to them (if they do that it would also make sense to pick a different title than BCC to avoid further confusion).
A separate “blind forward” field in a mail client could be a nice addition, but it too falls apart because drafts might be started in one client and completed in another.
In practice, deviating from existing MTA and MUA behaviour as specified in RFCs - included the handling of the Bcc header - produces innumerable edge cases and interoperability gotchas, which is why we try not to fuck with them much. The worst case scenario being, all too commonly, some well-intended script installed by a frustrated sysadmin that tries to fix an impedance mismatch and ends up inadvertently creating either a software laser or an open relay.
> I generally avoid bcc, since it's too easy for the blind recipient to hit "respond" and cause havoc
So what's your proposed alternative?
I guess in most cases Microsoft Support just responds with whether or not you are using their products as intended and are observing the expected behaviour, with expected behaviour actually being what the observed behaviour is when they try on their side. Unless there is some actual error, they don't seem to apply much initiative in deciding whether or not the observed behaviour actually makes sense.
To their credit for my case, when I pointed out that given a slightly (but not very) different scenario my behaviour was actually unusual, they then tried to work to report it to the development team.
My issue was that when I imported a code-signing certificate into Key Vault HSM with a particular algorithm, most fields would show up blank in the Portal UI. When I was unable to succesfully use the certificate to code sign our software, I assumed something went wrong with the import somehow, hence the certificate details not showing correctly. Importing certificate with a different algorithm would show the details, so it's something about the way that Key Vault/Portal UI handles that algorithm.
Ultimately it turned out that the problem was that the algorithm was actually unsupported by the code signing tool (it was my first time doing setting up EV code signing), but as I pointed out to the support agent, were it not for the problem on the UI, I wouldn't have assumed a potential problem with the way the the certificate was imported.
Frustratingly I only chose that algorithm initially because it was advised by a "helpful" person in a Github issue for the code signing tool I was using. I later saw that that same person within hours commented in another issue that although Azure Key Vault supports the new algorithm, the tool doesn't work with it, but they didn't respond back in my issue that what they suggested to me won't actually work.
Authentication-Results are added by the receiving email service and authenticates the 'from' address (not the 'to', 'cc' or 'bcc').
Maybe this is a really specific circumstance where both addresses in the bcc are hosted by O365, so they may be handled internally instead of being send via SMTP.
Or maybe the reporter on reddit is just confused and thought that the header was added by o365 upon sending.
I tried reproducing this with an O365 account, but couldn't reproduce the reported behaviour.
Update: maybe your receiving SMTP is overwriting this header in the received message. I've tested with Google Apps as the second bcc recipient, and it shows the first bcc's domain name. Using a different e-mail host as the recipient, the header was overwritten. So this could mean that O365 is still disclosing the bcc's domain name to the receiving SMTP server, but that receiving server is overwriting the header when processing the message making it harder to investigate.
Authentication-Results are not supposed to be added by the sender anyway, and it should be used to verify the sender (from) address, not the receiver address.
Again, I wasn't able to reproduce this bug. When sending from o365 to Gmail the Authentication-Results is added by Gmail, not by o365.
Email receivers are not supposed to overwrite headers (as this can also break DKIM signatures), they should only add headers. So I highly doubt that is happening.
I wonder if this undesirable behavior is according to some spec?
 And the reason for that is that message recipients in the era of UUCP had to store the "route" to the destination in-band and often needed to be munged per-site to be useful.
What a way to run a company, huh?