8 ms·

Office 365 leaking BCC domain name

235 points by bouke 5y ago

kevingadd 5y ago
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?
- oneeyedpigeon 5y ago
  Isn't this mandatory anyway? Is To: optional?
  - Tepix 5y ago
    Yes
  - mkl 5y ago
    "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.
  - ajross 5y ago
    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.
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
pcl 5y ago
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.
- macintux 5y ago
  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.
- raverbashing 5y ago
  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?
  - Cthulhu_ 5y ago
    > 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.
- dogma1138 5y ago
  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.
  - bombcar 5y ago
    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.
- 5y ago
LeonM 5y ago
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.
- bouke 5y ago
  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.
  - mkl 5y ago
    "Sending to" or "sending to two"?
    - bouke 5y ago
      Fixed, thanks.
  - LeonM 5y ago
    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.
deleted 5y ago
[deleted]
jonathanlydall 5y ago
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.
CA0DA 5y ago
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.
swiley 5y ago
Hotmail is the new Yahoo of email providers.
- jasdine817 5y ago
  Hotmail hasn't existed for at least a decade.
cocobende 5y ago
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.
- DoctorOW 5y ago
  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.
anonu 5y ago
possible interim solution: put your email as the first recipient in the bcc field
hedora 5y ago
PSA: Gmail sends the BCC list to each recipient.
- aynyc 5y ago
  Is that true? What about GSuite?
- mig39 5y ago
  Really? Where?
- thricegr8 5y ago
  I cannot confirm this.
johnklos 5y ago
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?

235 points by bouke 5y ago

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?

oneeyedpigeon 5y ago
Isn't this mandatory anyway? Is To: optional?
- Tepix 5y ago
  Yes
- mkl 5y ago
  "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.
- ajross 5y ago
  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.

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

pcl 5y ago

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.

macintux 5y ago
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.
raverbashing 5y ago
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?
- Cthulhu_ 5y ago
  > 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.
dogma1138 5y ago
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.
- bombcar 5y ago
  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.
5y ago

LeonM 5y ago

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.

bouke 5y ago
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.
- mkl 5y ago
  "Sending to" or "sending to two"?
  - bouke 5y ago
    Fixed, thanks.
- LeonM 5y ago
  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.

deleted 5y ago

[deleted]

jonathanlydall 5y ago

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.

CA0DA 5y ago

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.

swiley 5y ago

Hotmail is the new Yahoo of email providers.

jasdine817 5y ago
Hotmail hasn't existed for at least a decade.

cocobende 5y ago

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.

DoctorOW 5y ago
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.

anonu 5y ago

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

hedora 5y ago

PSA: Gmail sends the BCC list to each recipient.

aynyc 5y ago
Is that true? What about GSuite?
mig39 5y ago
Really? Where?
thricegr8 5y ago
I cannot confirm this.

johnklos 5y ago

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?