Office 365 leaking BCC domain name | Hacker News Reader

Office 365 leaking BCC domain name

reddit.com

235 pointsbouke45 comments

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!

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

I think this is what most people do, and why this hasn't come up before.

Anecdote: I've never done this and couldn't have fathomed a reason to have done so before this.

I do it because otherwise some mail programs complain if you ONLY have BCC recipients (and it looks a bit strange).

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.

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

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

I generally avoid bcc, since it's too easy for the blind recipient to hit "respond" and cause havoc.

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.

I agree that using Bcc in combination with public recipients is perilous. Using it for all recipients is, however, quite desirable and I wish more organizers used it.

Edit: ah yes I see what's the idea now.

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

I only use BCC when I need to remove a distribution list or people from the main thread and I mention that in the email response.

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.

Exactly - I use it for “these two people and I are sending this group an email” where the other two are cc: and the group is bcc so replies are routed to me or to my team and not the entire group.

In the past I loved Mutt's bounce feature (bound to the 'b' key by default) which basically allowed me to Bcc anyone for any email I already received. I don't believe it works anymore today because of common anti-spam measures but it was a great way to deal with misdirected mail (by accident or on purpose).

It’s often important that the BCC’d folk can see who the overt recipients were, though.

I think the proper solution to this is using the Reply-To header.

That works fine with the solution proposed above: Forward the message after sending, it will include all details on date/subject/recipients just not cause a reply-to-all to actually go to all.

We already have that, it is the existing commonplace forward; not the blind forward suggested above, which by definition would strip the original To and Cc fields.

There's no reason the blind forward cannot include the original email's recipient list as well.

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

There is a reason why not, and it’s that mail clients reply based on the header fields, not the envelope recipients.

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.

That's a really good idea. It's what I do manually in practice whenever I want to "BCC" someone.

I recently had a support case I opened with Microsoft and their support also initially said that my reported behaviour was "normal" so should be expected. Turns out they had just reproduced the behaviour on their side and assumed it was "intended".

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.

I don't see how one of the receiver's addresses can end up in the Authentication-Results header.

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.

The problem also appears when sending to different domains not hosted by O365 (in fact: Google Apps). The domain name of the first bcc still appears in the headers received by the second bcc.

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.

"Sending to" or "sending to two"?

Fixed, thanks.

If Microsoft is adding an Authentication-Results header to outbound email where the receiver address is used in the header, then this is a bad bug.

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 agree that it shouldn't happen. But it does, I've reproduced the issue with different recipients. Send a message having only A and B as bcc. The header of the message received by B contains the domain name of recipient A.

It sounds like there's at least a simple workaround: Include a noreply email address in the To field (or your own address, I suppose). That will capture reply and reply all and should prevent sending a domain for BCC.

I wonder if this undesirable behavior is according to some spec?

Isn't this mandatory anyway? Is To: optional?

Yes

"To" is optional. When I email groups of students (sometimes hundreds at once), I pile all the addresses into the BCC field, and usually nothing else.

You got two answers that skipped the reason: "To:" is a RFC822 header field. It's data in the message. Transport of a message to its destination is handled by a different layer (SMTP) which has its own addressing scheme that is stored outside of the the message[1]. It's entirely possible to omit the To: header, or include a value that doesn't match the actual recipient.

[1] 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.

It looks like this user may have not provided a replication test case, which caused Microsoft technical support to not treat this as high priority. Seems to be a common problem with large company technical support.

Did anyone just tried to reproduce? Because I tried several times without anything related to my Bcc domains in the Authentication-Results header, or anywhere else.

Did you try having a Google apps domain as the first recipient? Both the OP and the Reddit comments were able to reproduce that way.

Microsoft is too big and dumb to care until some large company complains or the issue picks up traction on social media or in the news.

What a way to run a company, huh?

possible interim solution: put your email as the first recipient in the bcc field

Hotmail is the new Yahoo of email providers.

Hotmail hasn't existed for at least a decade.

PSA: Gmail sends the BCC list to each recipient.

Is that true? What about GSuite?

Really? Where?

I cannot confirm this.

Reply on news.ycombinator.com