It used to be that if you wanted to track a message through various Object Model events such as NewInspector and ItemSend, one way to do it was to grab PR_SEARCH_KEY. A customer recently discovered that this doesn’t always work after applying a recent hotfix. Before applying the hotfix, PR_SEARCH_KEY would remain unchanged during the various events. After applying the hotfix, if they were in cached mode they would see the search key change during the send event, but only if the user saved the message, or autosave kicked in, before submitting.
The hotfix in question is 973404. More specifically, the change that broke the customer’s code was to address the issue outlined in 974413. This issue is in how Outlook relates Read Receipts to the sent items using PR_SEARCH_KEY. In this issue, if a user created an item as a draft, perhaps to use as a template for commonly sent mail, then copied the message before sending, the draft item and the new item would have the same search key. This in turn broke the read receipt logic.
The fix we made was that whenever we copy a message in the Drafts folder, we don’t copy the search key, which allows the copy to get a new search key and allows the read receipt logic to function. Couple this with the user saving the message to Drafts while they’re working on it – under this new behavior the saved message now has a new search key. Some of the object model events the customer’s code would see would be for the message actually being submitted, and some were for the item in the draft folder. Before the read receipt fix, these different message objects would all have the same search key. But after the fix, the search keys can be different.
The fix here is not to rely on PR_SEARCH_KEY at all. In the customer’s scenario, they were using PR_SEARCH_KEY to ensure they didn’t “stamp” a message with their properties more than once during the submission process. However, since they were already stamping data on the message, it made sense to just look for their stamp before stamping again.