December, 2008

The Outlook 2007 MAPI Reference just went live on the MSDN. The docs are propagating their way through the servers, and should start showing up in the table of contents and searches soon. [update: propagation is complete - Live and Google should reindex soon]

This is the MAPI documentation refresh I've been talking about for the last few months. The short version of the story is that the Exchange team was ready to cut the MAPI documentation loose, but the Outlook team wanted to keep it around, so we had to transfer ownership from one team to another. Now, we could have just moved the docs from one node to another and been done with it, but instead we figured this would be a good time to scrub the docs and fix a lot of long standing technical, formatting and art issues.

Some highlights:

• The What's New page: documents what's been added, changed, and removed from the docs. Notably, CMC and CDO documentation was cut, and nearly a thousand properties were added.
• The Samples page: points to a number of updated MAPI samples, including MFCMAPI itself, which now has a go link: http://go.microsoft.com/fwlink/?LinkID=124154
• The Properties node: Under this node you'll find a massive list of properties. We started with the original list from Exchange's MAPI documentation, and added just about every property we could think of. If a property is mentioned in the Exchange Protocol documentation, it's most likely documented here.
• The Interfaces node: This is where you'll find all the MAPI interfaces, such as IMAPIProp. All interface documentation has been scrubbed, and many include references to where you can find the interface used in MFCMAPI.

My favorite addition to the MAPI documentation though, is the "Community Content" banner now on every page. Did we leave something out? Was there something we should have said about a particular property? Just add it to the bottom of the article. This is a great way to keep the content up to date, and we will be paying attention to the comments posted. If we get a chance to do another refresh down the road we may even incorporate the feedback.

Update: Angela is talking about this as well.

Enjoy!

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.