Partilhar via

Exchange 2013 Recipient Properties On Sent Items

  • Artigo

https://msdn.microsoft.com/en-us/library/ee159108(v=exchg.80).aspxIf you’ve got an application that processes e-mails paying attention to the PR_RECEIVED_BY_* and PR_RCVD_REPRESENTING_* properties, you may notice these properties showing up on e-mails in the Sent Items folders of your users. That is, messages submitted by a user who doesn’t explicitly mark themselves as a recipient will still appear (in these properties) as if they received the message. This may interfere with your logic, especially if you have a need to distinguish mails a user sent from mails a user received.

Before we get into an explanation of why this is happening, some workarounds:

  • PR_MESSAGE_RECIP_ME, PR_MESSAGE_TO_ME, PR_MESSAGE_CC_ME: These Boolean properties will be true or false depending on whether the user is in the recipient list, specifically as either a TO or CC recipient. Together, these properties will cover every case except for when the user was BCC’d.
  • PR_TRANSPORT_MESSAGE_HEADERS: Typically only present on inbound message.
  • PR_SENDER_SMTP_ADDRESS: Typically only present on inbound messages. There are several related properties in the PR_SENDER_* family with the same quality.

Together, you should be able to use these properties to heuristically decide if a message was, from the user’s perspective, sent or received. And do note that any algorithm you put together here will by necessity be a heuristic. There is no single property that tracks whether a message in a user’s mailbox was sent by the user, received by the user, neither, or both.

Now – when/why does Exchange 2013 stamp these properties? When first: It appears Exchange 2013 will stamp these properties when Outlook (any version) submits a mail from a profile with only one Exchange mailbox in it. These properties will then be present on the copy of the message which ends up in Sent Items (or wherever the sent copy is to be saved). If the profile contains multiple Exchange accounts (aka Multi-Ex, possible in Outlook 2010 and higher), then Exchange 2013 does not appear to stamp these properties on the message that ends up in Sent Items.

Why: Exchange 2013 has a completely new store, written in managed code (the old, native, store.exe no longer exists). As part of this work, we found that it was possible for the transport to attempt to deliver a message multiple times. Part of the work involved in making sure this didn’t happen was to ensure these properties were set on messages as we processed them for transport. The difference in behavior with Multi-Ex is attributable to the fact that Outlook builds the messages it intends to submit differently in Multi-Ex.

It was suggested to me that this change in behavior means our documentation is now incorrect. I do not agree with this assessment. For instance, here’s a snippet from the MSDN documentation of PR_RECEIVED_BY_NAME:

Contains the display name of the messaging user who receives the message...These properties are an example of the address properties for the messaging user who receives the message. They must be set by the incoming transport provider.

And the [MS-OXOMSG] protocol doc:

The PidTagReceivedByName property ([MS-OXPROPS] section 2.961) contains the e-mail message receiver's display name, as specified by the DisplayName field of the RecipientRow structure ([MS-OXCDATA] section 2.8.3.2).

Note that the documentation does not indicate anything about what should or should not be present on sent items. It only documents these properties in relation to received messages. What happens with sent messages is undefined behavior, so any behavior is acceptable, as is changing behavior. I’m sending this article over to the protocol team, however, so they can note this behavior with respect to Exchange 2013.

Comments

  • Anonymous
    February 19, 2013
    (Part 1 of 2) As disclosure, I work for CA Technologies, and I am the one who reported this issue. We have had the need to differentiate between sent mails and received mails in our product for a long time, and just like Stephen mentions, we have always done it heuristically because there is indeed no single property in a message that specifically, explicitly, and reliably indicates if a message is sent, received, neither, or both (NB: but since you mention it, Stephen, I would suggest that would be a very useful property to have!). Since all the way back to 2000, we’ve used a range of PR_RECEIVED_BY_* properties (PR_RECEIVED_BY_ENTRYID, mainly) as a primary indicator of whether a message was received or sent. In some cases this was not enough, and we have needed to test secondary attributes. In particular, PR_RECEIVED_BY_* properties were always set on Exchange sent mails prior to late 2002(), but the behaviour had been stable since then, with PR_RECEIVED_BY_ENTRYID in particular being always and only set on actually received mails; it was never set on a sent mail message copy (e.g. what ends up in Sent Items). () I only have dates, not versions of Exchange, but since Exchange 2003 became available around then, it’s plausible that the behaviour change occurred there. With this unexpected change of behaviour in Exchange 2013 (even if this only happen with single Exchange account profiles; it’s the typical use case), we have had to rethink our algorithm. What we’re now doing, which may be useful for other developer to know, is compare PR_SENDER_ENTRYID with PR_RECEIVED_BY_ENTRYID. If the values are different, then we tag the message as received (obviously by a different user). If PR_RECEIVED_BY_ENTRYID is not present, or is identical to PR_SENDER_ENTRYID, then we tag the message as sent (it may also be posted rather than sent, but that’s a different issue). The limitation therefore is that we can’t distinguish anymore the sent copy from the received copy of a message sent by a user to himself (they’re both tagged as ‘sent’), but for our purpose that’s acceptable. That algorithm works for all versions of Exchange that we know of. (continued…)

  • Anonymous
    February 19, 2013
    (Part 2 of 2) [The limitation therefore is that we can’t distinguish anymore the sent copy from the received copy of a message sent by a user to himself (they’re both tagged as ‘sent’), but for our purpose that’s acceptable. That algorithm works for all versions of Exchange that we know of.] If making the latter distinction is important to you, then I wouldn’t use PR_MESSAGE_RECIP_ME, because as Stephen points out, it wouldn’t be true if a user sent a message to himself using Bcc. Using PR_TRANSPORT_MESSAGE_HEADERS seems great, since that should only be set when a message goes through a Hub Transport server (Exchange 2007 onwards), unfortunately I observed occasions when this was set on a sent mail, i.e. on the copy of the message that I would expect to have stayed in the mailbox (not to have gone through a Hub Transport), and that was with Exchange 2010. So this wouldn’t be reliable either (and of course it doesn’t work on Exchange 2000 and 2003 for internal mails, as these don’t transit through SMTP; they never get a PR_TRANSPORT_MESSAGE_HEADERS). PR_SENDER_SMTP_ADDRESS seems promising, as I only saw that set on received messages when testing with Exchange 2010, but my worry is that it is set at the same time as PR_TRANSPORT_MESSAGE_HEADERS, and consequently could also be wrongly set (I lost my sent mails with the PR_TRANSPORT_MESSAGE_HEADERS oddly set, and couldn’t reproduce, so I couldn’t confirm that PR_SENDER_SMTP_ADDRESS may also be ‘wrongly’ set), so I wouldn’t rely on that either. Incidentally, while I cannot deny that Stephen is semantically correct when he points out that the documentation saying that these properties “must be set by the incoming transport provider” doesn’t imply that they couldn’t also be set in other circumstances (like it so happens now!), i.e. that you have an implied undefined behaviour unless it’s explicitly defined, my opinion is that this is disingenuous in this context. So when I read for PR_RECEIVED_BY_ENTRYID “Contains the entry identifier of the messaging user who actually receives the message”, and “It must be set by the incoming transport provider”, in my opinion it is reasonable to expect that this means the property is only set under these circumstances. Thanks for having passed this on for a documentation update, Stephen. Many thanks to Stephen, as this investigation shed light on the reasons for the change of behaviour with Exchange 2013. Philippe