outlookmicrosoft-graph-apimicrosoft-graph-mailbcc

Microsoft graph API - empty bccRecipients list

This is the Scenario:

In the same Azure tenant, I used one account (user_1_address) to send emails to the other account (user_2_address) using outlook (o365). I sent 3 emails, one where user_2_address is BCCed, one CCed, and one when it's the TO recipient.

I'm using Microsoft graph API to get a list of emails received by user_2_address in a specific time range, using this query:

https://graph.microsoft.com/v1.0/users/{<user_2_id>}/messages?$filter=
receivedDateTime ge <some date> and receivedDateTime lt <some other date> 
and isDraft eq false 
and sender/emailAddress/address ne '<user_2_address>'

I'm getting all the three emails user_2_address had received from user_1_address. But in the email user_2 was BCCed the bccRecipients list is empty, when it should contain user_2_address :(

I have seen this question about sending an email from Gmail and BCC an outlook user:

Microsoft graph API: empty BCC field

In that case, also the bccRecipients list was empty, but it was resolved by saying the BCC is removed when sending the emails from an external source (Gmail in that case). When for me it's not an external source - both users are using outlook in the same tenant.

So my questions are:

  1. Is it the desired behaviour, or is it a bug?
  2. Now, let's say I'm using the query above where I get all emails where the sender is not the user_2_address and it's not a draft. Can I assume that every email I get where user_2_address is not in the ccRecipients and toRecipients lists - that email was BCCed to user_2_address?

Thanks!

Solution

    1. The bcc field in a Message is an envelope (P1) recipient only so you should always expect that it will be blank (no matter the context inside a tenant really make no difference). Like the other post referenced if it wasn't blank it would break the RFC and the purpose of a BCC, the only exception is the sent item (which is just a copy of the sent message)

    2. No there are many scenarios that would break that particular logic eg forwarded email is one the comes to mind. You could certainly refine you result set that way, one thing you might want to examine is the X-MS-Exchange-Organization-Recipient-P2-Type: mail header that should get set in your internal to internal scenario (you need to look at the PidTagTransportMessageHeaders extended property to see it)