3 ms·

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 servic

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

by LeonM 5y ago

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