Daily Blog #385:Exploring Extended MAPI Part 2

Hello Reader,
           In the last post in this series we discussed the Extended MAPI data resident within Outlook and Exchange messages. In this post we will look at what within the Extended MAPI data changes when a user marks the message as unread but performs no other action against it.

First I made a new message and I sent it to myself, you can see the message below
As you can see from the above screenshot I have installed a Outlook extension called OutlookSpy which will expose all the Extended MAPI properties being stored within this message. If I
look at the Extended MAPI data within the iMessage store for this message I would see the following.

Notice that there is no PR_LAST_VERB_EXECUTED entry within this message, this because none of the tracked actions have occurred. This means that the PR_LAST_VERB_EXECUTED property is not created as part of the base message structure and instead is created when an action occurs. This is good to know because that would mean the presence of the LAST_VERB_EXECUTED regardless of what its storing means that at least one action occurred against this message.

This next part of the testing surprised me. I made the message unread and based on the fact that the PR_LAST_VERB_EXECUTED has an entry for Unread I assumed that this property would be set when I made a message unread. Here is the iMessage Extended MAPI data after making the message unread.

There is still no PR_LAST_VERB_EXECUTED, meaning that making an email unread is not a tracked agent, at least not from the base state of the message. I am going to attempt a couple of different actions against the message to see how this changes.

While it is true that there is no PR_LAST_VERB_EXECUTED property notice that the PR_LAST_MODIFICATION_TIME is set to 8:23PM 6/6/2018. This was interesting to me as you can see in the following screenshot the PR_CREATION_TIME which tracks when this message was stored within this message archive is set to 8:11PM 6/6/2018. All of these times are in UTC.

So based on the first round of testing it would appear as though making an item unread does not set an explicit property, but noticing a difference between the PR_LAST_MODIFICATION_TIME and the PR_CREATION_TIME is a clue that some change occurred to the message. IF that message is also in an unread state, meaning that if it hadn't been changed back to unread by the user and is in fact untouched, that it more than likely was made unread after the fact.

I am going to continue to test the actions that get recorded by Outlook and Exchange in this series. For your reference I am using Outlook 2016 32bit and Windows 10. 

Post a Comment