As several of you have noted, we recently released an update for the MAPICDO package. This is the update you have all been waiting for, as it is now possible to build an RPC/HTTP enabled profile to connect to Exchange 2013. What several of you have also noticed is that this update did NOT come with any guidance for HOW to build such a profile. Such guidance does exist, but hasn’t been published yet. I had delayed commenting on this new package until the guidance was ready, but it’s taking longer than I thought it would.
I’m working with the team responsible for publishing the guidance to get it out the door. We’ve almost got it ready, so I expect to see it up on the download site (or the Exchange blog) any day now. Once that guidance is published, Dave will most likely publish an updated version of his How to Build a Profile For MFCMAPI guidance. I’ll link to both as soon as they’re public.
http://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:
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 188.8.131.52).
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.