The Magic Behind OWA Likes

Limited Social Reactions in Email

When I wrote about the range of reactions now available in Teams to respond to messages, I made the point that Microsoft has some work to do to include reaction data in the compliance records captured for personal and channel conversations. I knew that OWA is the only Outlook client to support “like” reactions for email, but I realized that I hadn’t checked how it captures reactions so that they can be used in eDiscovery cases. This prompted me to investigate the matter.

Only OWA Lets You Like Email

OWA is the only Outlook client to allow users to react to email with a like. Whenever OWA opens a message, OWA checks for any likes and displays the number of likes and the people who liked the message (Figure 1).

Figure 1: OWA displays information about likes received by a message (image credit: Tony Redmond)

mobile support liking “regular” email. In addition, neither client supports the display of a like if given in OWA.

Internal Likes Only

Likes don’t work if messages go outside the tenant. In other words, it doesn’t matter if a recipient in another tenant likes your message because you’ll never see it. No mechanism exists to information back to your tenant for OWA to count and display.

Using Content Search to Find Liked Items

Microsoft doesn’t document how likes work in OWA, so how can we find the evidence to understand what we see happen in the client? I choose to start looking with an Office 365 content search.

The results returned by the search showed that a message sent between two users which was liked by the recipient turns up three times. Two copies are explainable: they are the copy sent by the originator and the copy received by the recipient. The text of these messages can be viewed in the search preview.

The third copy is different. It can’t be viewed. It is dated after the copy delivered to the recipient mailbox (Figure 2).

Figure 2: A Like for a message revealed by an Office 365 content search (image credit: Tony Redmond)

Drawing a Blank

And when the message file is downloaded from search results, it proves to be blank (Figure 3). The message sender is the recipient whereas the sender in the case of the other two messages is the person who created the original message. In short, this is a message intended to store some information in its MAPI attributes rather than ever being displayed to an end user.

Figure 3: A blank MSG file downloaded from content search results (image credit: Tony Redmond)

Tracking Down the Hidden Message

The evidence from the search indicates that OWA creates a special hidden message item for each like and stores it in the mailbox of the person who gives the like. To discover where the hidden item is stored, we export the results of the content search to a PST and then look in the Manifest.xml for the search export. Here we find:

<Tag TagValue="Exchange\Exchange.pst\[email protected] (Primary)\Recoverable Items\Purges\Salernes Project" TagDataType="Text" TagName="TargetPath"/>
<Tag TagValue="Salernes Project" TagDataType="Text" TagName="#Subject"/>
<Tag TagValue="2019-07-08T16:24:54" TagDataType="DateTime" TagName="#DateSent"/>
<Tag TagValue="[email protected], Primary, 31e2ece4-5426-48e0-8ce2-a96df7c316b3\[email protected] (Primary)\Recoverable Items\Purges" TagDataType="Text" TagName="#OriginalUrl"/

The output tells us that the hidden item is stored in the Purges sub-folder of Recoverable Items. This is logical because users and clients can’t get to items held in the Purges folder.

Looking for Properties

The hidden item is enough to record that someone liked a message, but OWA hardly checks every mailbox in a tenant (multiple servers, across potentially tens of thousands of mailboxes) to discover these items each time it needs to display a list of likes. A more efficient mechanism is needed and it’s likely to be associated with the original item.

The MFCMAPI utility can be used to examine at the internal properties of items in a mailbox. After firing it up, I navigated to the Sent Items folder and found the relevant item. It was then a matter of looking through the properties for something that might be related to likes. The IsLiked property seems to be a Boolean to show whether an item is liked, but the LikerNames property is what we’re looking for because it stores a list of names of users who have liked a message (Figure 4).

Figure 4: MFCMAPI reveals the LikerNames property (image credit: Tony Redmond)

The Fog Clears

Everything comes together. When someone likes a message, OWA creates a hidden item in the Purges folder to record the fact. At the same time, OWA updates the LikerNames property for the original message with the name of the person who just liked it. When OWA next displays the message, it notes that the message has some likes and displays the count and list of names.

Why Is this Important?

Microsoft is quite within its rights not to document an internal mechanism like this. However, when someone likes a message, it’s a strong and overt reaction to the message content that could have meaning in an eDiscovery case where investigators are looking for evidence of illegal activity. The fact that a message is read is interesting, but a message could be read by being displayed in Outlook’s read message pane for a period. A like is a much stronger indicator that the recipient read and understood the content.

Understanding how this information is captured and can be found is important for those interested in compliance and eDiscovery. For that reason, I feel It would be best if Microsoft documented the mechanism – and updated that blank message so that it included some text to make its purpose immediately obvious. Something like “James Ryan read and acknowledged the message titled Salernes Project with message identifier 18813913883 on 20-Jul-2019 19:15:29 UTC” would make it a lot easier to understand and collate like responses with the original messages when browsing search results.