I’m repeating myself – I did use a variation on this title before. In this case, suppose you’re using a custom transport provider, like MrXP, and you’re delivering to a regular (not wrapped) PST. In Outlook 2003, this worked great. If you had rules set up, they all got fired on delivery. In Outlook 2007 though, this stopped working.
The basic design of a transport provider is this:
1 – Outlook’s protocol handler has a function which will get messages from the transport.
2 – The transport provider implements a function called StartMessage. This function takes a new LPMESSAGE as a parameter. The transport provider is expected to fill out this message with details, then save it.
3 – When StartMessage returns, the protocol handler calls a function to handle firing the new mail notifications
4 – Outlook is listening for these notifications. One listener is responsible for determining if rules should be run on the message or if the message should enter the item prop pipeline.
Remember from our work with the wrapped PST that the PST is an Item Proc store, so the listener will never run rules directly on the message. So the only way the message will get rules fired on it is if it enters the item proc pipeline. And the only way for the message to enter the item proc pipeline is for it to have ITEMPROC_FORCE and NON_EMS_XP_SAVE set during the SaveChanges call.
Great, except it doesn’t work. Suppose you go into MrXP and add both of those flags to SaveChanges. You’ll see no change in behavior. That’s where the February update comes in. It turns out that between the transport calling SaveChanges and the save actually happening in the PST, there was some code validating the flags passed in. This code had the side effect of stripping the ITEMPROC_FORCE and NON_EMS_XP_SAVE flags. The hotfix corrects this code to allow the flags through.
I’ve updated MrXP up on CodePlex to start passing the flags. With the updated MrXP and with the February update applied, you should see rules start working again.