Microsoft graph API - пустой список bccRecipients

Question

Это сценарий:

В том же клиенте Azure я использовал одну учетную запись (user_1_address) для отправки электронных писем на другую учетную запись (user_2_address) с помощью Outlook (o365). Я отправил 3 письма: одно, где user_2_address - BCCed, одно - CCed, и одно - получатель TO.

Я использую Microsoft Graph API, чтобы получить список писем, полученных user_2_address в укажите диапазон времени c, используя этот запрос:

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

Я получаю все три письма, которые user_2_address получил от user_1_address. Но в электронном письме user_2 было BCCed список bccRecipients пуст, тогда как он должен содержать user_2_address: (

Я видел этот вопрос об отправке электронного письма из Gmail и B CC пользователя Outlook:

Microsoft graph API: пустое поле B CC

В этом случае также список bccRecipients был пуст, но это было разрешено путем произнесения B CC удаляется при отправке писем из внешнего источника (в данном случае Gmail). Когда для меня это не внешний источник - оба пользователя используют Outlook в одном клиенте.

Итак, мои вопросы:

1. Это желаемое поведение или ошибка?
2. Теперь предположим, что я использую запрос выше, где я получаю все электронные письма, отправитель которых не является user_2_address и это не черновик. Могу ли я предположить, что каждое письмо, которое я получаю, где user_2_address отсутствует в списках ccRecipients и toRecipients, это письмо было отправлено скрытой копии на user_2_address?

Спасибо!

Answer 1

1. Поле b cc в сообщении является только получателем конверта (P1), поэтому всегда следует ожидать, что оно будет пустым (независимо от контекста внутри клиента, на самом деле никакой разницы). Как и другой упомянутый пост, если бы он не был пустым, он нарушил бы RF C и цель B CC, единственным исключением является отправленный элемент (который является просто копией отправленного сообщения)

2. Нет, существует множество сценариев ios, которые могут нарушить этот конкретный лог c, например, на ум приходит перенаправленное письмо. Вы, безусловно, можете уточнить свой набор результатов таким образом, одна вещь, которую вы, возможно, захотите изучить, - это почтовый заголовок X-MS-Exchange-Organization-Recipient-P2-Type:, который должен быть установлен в вашем внутреннем сценарии (вам нужно посмотреть в расширенном свойстве PidTagTransportMessageHeaders, чтобы увидеть его)