It was recently brought to my attention by a client that was just migrated to Exchange 2010 that their read receipts were not processing correctly. I decided to reproduce this issue, and sure enough I had the same problem. The reason I say this is a bug with Exchange 2010 is that I have tested this scenario on Exchange 2003, Exchange 2010 (with RU4), and Exchange 2010 SP1 Beta. I have also tested with Outlook 2007 and 2010 clients.
This issue is common to email that flows through an Exchange 2010 HUB server, regardless of what Outlook client is used. If the mailboxes are homed on Exchange 2010 SP1 Beta and the email flows through an Exchange 2010 (with RU4) HUB server, this issue persist. If the mailboxes are homed on Exchange 2010 (with RU4) and the email only flows through an Exchange 2010 SP1 Beta HUB server, the receipts are processed normally. Now let’s look at the issue in detail.
When sending an email, a user has the option to request a delivery receipt and a read receipt.
After the delivery and read receipt appear in my Inbox, I should be able to go look at the original message in the Sent Items and view the tracking information.
So how does this tracking information get tracked and processed by Exchange? When a user tags the original message to request a delivery and read receipt, a property tag gets attached to the message: PR_REPORT_TAG. This property tag is used to match the original message and the receipts and update the tracking information in Outlook and should exist in all related messages (original, delivery receipts, and read receipts). We can use a tool like MFCMAPI, to view the properties of the different messages.
Read receipts are generated by Exchange and for some reason the Exchange 2010 HUB is removing the PR_REPORT_TAG property from the read receipt during transport. Again, if the PR_REPORT_TAG is not in the message, it will not update the tracking information in the original message. The tag must be present and the value match between all of the related messages.
Note: Again, I have tested this scenario on Exchange 2010 SP1 Beta and it works as expected. Not sure if Microsoft will release a patch for Exchange 2010.
I will talk about a “workaround” in by next blog post about end-user Message Tracking and Delivery Reports.