On my article about enabling rules in the Wrapped PST, Richard pointed out that when you do this, read receipts stop working. We’ve investigated this and found that there’s something a little extra you have to do to get read receipts to fire.
Remember that we’re using ITEMPROC_FORCE to push the messages through the Item Proc pipeline. As I described earlier, that pipeline handles rules, junk mail, and spam processing. It also handles firing read receipts. Let’s take a look at how read receipts fit in to MAPI and the PST provider:
- The MAPI properties PR_READ_RECEIPT_REQUESTED and PR_NON_RECEIPT_NOTIFICATION_REQUESTED indicate that a receipt has been requested.
- The nontransmittable MAPI property PR_MESSAGE_FLAGS has two flags, MSGFLAG_RN_PENDING and MSGFLAG_NRN_PENDING, which also indicate that a receipt has been requested.
- When the MAPI spooler delivers a message to the PST provider, the PST provider reads the PR_READ_RECEIPT_REQUESTED and PR_NON_RECEIPT_NOTIFICATION_REQUESTED properties and sets the equivalent flags in PR_MESSAGE_FLAGS.
- Further along in the process of saving the message, the PST provider, seeing the flags set in PR_MESSAGE_FLAGS, sends out read receipts when the message is delivered.
Now – with ITEMPROC_FORCE, we’re breaking this a bit – we’re skipping the spooler. Since the message isn’t being delivered from the spooler, we skip the step where we translate the properties into flags. And since no flags are set, we don’t send out receipts.
So – if you’re using ITEMPROC_FORCE, and read receipts are important, you need to implement a little extra logic. If you would normally set the receipt properties, also set the equivalent receipt flags. Receipts should then start working.