Did you know: NDR messages and Group mailboxes

Here’s a fun fact I didn’t know about – apparently any NDR messages addressed to Office 365 Groups are being automatically deleted. But not before they are actually delivered to subscribers of the Group. Let’s demonstrate this with an example.

Select any Office 365 Group in the tenant, then grant yourself Send As permissions to it. You can use the standard Add-RecipientPermission cmdlet to do that. Once the permissions have been added, open Outlook or OWA, compose a new message, then change the From address to match the Group’s address. Assuming you are the one that got the Send As permissions added and they’ve propagated, you should have no issues sending the message as the Group. In my case, the Group I used is named “Default”, as shown below:

SendAsGroupThe message was delivered successfully to my Gmail account, while the other address generated an NDR. In turn, my own account then received the NDR message, being a subscriber of the Default Office 365 Group. Yet, when you open the actual Inbox of the Group, the NDR message is nowhere to be found.

To find out what’s going on, we turn to the message trace functionality. More specifically, we request the detailed message trace information for the last message received in the Group’s mailbox, which just happens to be the NDR. Here are the details:

C:\> Get-MessageTrace -RecipientAddress default2@michev.info | Get-MessageTraceDetail | fl

Message Trace ID : ad723446-2768-4105-9d20-08d73b6c0843
Message ID       : <bae20b14-1d29-4e00-bfb8-27db3b464b46@DB8PR03MB5674.eurprd03.prod.outlook.com>
Date             : 17/09/2019 12:39:08
Event            : Redirect
Action           :
Detail           : The message was directed to vasil@michev.info.
Data             : <root><MEP Name="ServerHostName" String="DB8PR03MB5674"/><MEP Name="SourceContext" String="Redirection Agent"/><MEP Name="DeliveryPriority" String="Normal"/><MEP Name="ReturnPath"
String="&lt;&gt;"/><MEP Name="CustomData" Blob="S:OriginalFromAddress=default2@michev.info"/><MEP Name="SequenceNumber" Long="0"/><MEP Name="RecipientReference" String=""/><MEP
Name="RelatedRecipient" String="vasil@michev.info"/></root>

Message Trace ID : ad723446-2768-4105-9d20-08d73b6c0843
Message ID       : <bae20b14-1d29-4e00-bfb8-27db3b464b46@DB8PR03MB5674.eurprd03.prod.outlook.com>
Date             : 17/09/2019 12:39:08
Event            : Redirect
Action           :
Detail           : The message was directed to vasil@michev.info.
Data             : <root><MEP Name="ServerHostName" String="DB8PR03MB5674"/><MEP Name="SourceContext" String="Redirection Agent"/><MEP Name="DeliveryPriority" String="Normal"/><MEP Name="ReturnPath"
String="&lt;&gt;"/><MEP Name="CustomData" Blob="S:OriginalFromAddress=default2@michev.info"/><MEP Name="SequenceNumber" Long="0"/><MEP Name="RecipientReference" String=""/><MEP
Name="RelatedRecipient" String="vasil@michev.info"/></root>

Message Trace ID : ad723446-2768-4105-9d20-08d73b6c0843
Message ID       : <bae20b14-1d29-4e00-bfb8-27db3b464b46@DB8PR03MB5674.eurprd03.prod.outlook.com>
Date             : 17/09/2019 12:39:08
Event            : Deliver
Action           :
Detail           : The message was successfully delivered to the folder: DefaultFolderType:RecoverableItemsDeletions
Data             : <root><MEP Name="SourceContext" String="08D7399B4D3CC750;2019-09-17T12:39:08.272Z;ClientSubmitTime:"/><MEP Name="MailboxServer" String="AM0PR03MB6180"/><MEP
Name="DeliveryPriority" String="Normal"/><MEP Name="TotalLatency" Integer="1"/><MEP Name="ReturnPath" String="&lt;&gt;"/><MEP Name="ClientName"
String="DB8PR03MB5674.eurprd03.prod.outlook.com"/><MEP Name="CustomData" Blob="S:OriginalFromAddress=default2@michev.info"/><MEP Name="SequenceNumber" Long="0"/><MEP
Name="RecipientStatus" String="DefaultFolderType:RecoverableItemsDeletions-Group Escalation Agent"/><MEP Name="RecipientReference" String=""/></root>

Message Trace ID : ad723446-2768-4105-9d20-08d73b6c0843
Message ID       : <bae20b14-1d29-4e00-bfb8-27db3b464b46@DB8PR03MB5674.eurprd03.prod.outlook.com>
Date             : 17/09/2019 12:39:08
Event            : Spam Diagnostics
Action           :
Detail           :
Data             : <root><MEP Name="CustomData" Blob="S:MID=10814727655556;S:MN=DB8PR03MB5674" /></root>

Message Trace ID : ad723446-2768-4105-9d20-08d73b6c0843
Message ID       : <bae20b14-1d29-4e00-bfb8-27db3b464b46@DB8PR03MB5674.eurprd03.prod.outlook.com>
Date             : 17/09/2019 12:39:08
Event            : Spam Diagnostics
Action           :
Detail           :
Data             : <root><MEP Name="CustomData" Blob="S:MID=10814727655556;S:MN=DB8PR03MB5674" /></root>

Turn your attention to the third entry and the highlighted line. It informs us that the message was successfully delivered to the mailbox, however not in the Inbox folder, but the RecoverableItemsDeletions one. And it also informs us that we can thank the “Group Escalation Agent” for that. The rest is just additional information about the processing of the item, which among other things includes information about sending a copy of the NDR message to my own mailbox, since I’m a subscriber for the Default Group.

Now, as far as evidence goes, having an actual look at the message in it’s parent folder is much better than relying on the message trace data. One way to obtain such evidence is to use the Get-MailboxFolderStatistics cmdlet and check the number of items held in the Deletions folder of the RecoverableItems subtree. Just as well, it shows a total of two entries (the two tests I performed):

C:\> Get-MailboxFolderStatistics default -FolderScope recov | ft Name,Items*,Folder*Size

Name                       ItemsInFolder ItemsInFolderAndSubfolders FolderSize                 FolderAndSubfolderSize
----                       ------------- -------------------------- ----------                 ----------------------
Recoverable Items                      0                        160 0 B (0 bytes)              2.621 MB (2,747,950 bytes)
Audits                                 7                          7 30.38 KB (31,108 bytes)    30.38 KB (31,108 bytes)
Calendar Logging                       5                          5 55.95 KB (57,288 bytes)    55.95 KB (57,288 bytes)
Deletions                              2                          2 192.9 KB (197,495 bytes)   192.9 KB (197,495 bytes)
DiscoveryHolds                       143                        143 2.312 MB (2,424,592 bytes) 2.312 MB (2,424,592 bytes)
SearchDiscoveryHoldsFolder             0                          0 0 B (0 bytes)              0 B (0 bytes)
MigratedMessages                       0                          0 0 B (0 bytes)              0 B (0 bytes)
Purges                                 1                          1 19.13 KB (19,589 bytes)    19.13 KB (19,589 bytes)
SubstrateHolds                         0                          0 0 B (0 bytes)              0 B (0 bytes)
Versions                               2                          2 17.46 KB (17,878 bytes)    17.46 KB (17,878 bytes)

Yet, the number of items is hardly a better indicator than the message trace data. We can improve on that by requesting additional default to be returned in the output, by using the –IncludeOldestAndNewestItems and –IncludeAnalysis switches. This reveals details such as the time the oldest and newest message were received, what the most commonly found item class is, as well as info about the top subject and message size, all of which we can correlate against the copy of the NDR message received in my own mailbox.

But what if we don’t have a copy of the NDR message, for example if no subscribers are configured for the group? Fine, we can also get to the actual messages. Since Outlook and OWA don’t expose any folders from the Group mailbox apart from Inbox, we need to use some EWS-based code. And what’s easier than just using the EWSEditor tool. In case you need detailed instructions on how to use the tool to work with Office 365 Group items, see for example this article. Once you’re familiar with the steps, connect to the Group mailbox, open the Deletions folder, and voila:

SendAsGroup2There you have it, the two NDR messages corresponding to the two tests I performed. Both of them reside in the Deletions folder of the RecoverableItems subtree, and not in the Inbox as one should expect. Why Microsoft decided to configure such behavior I cannot tell, but in case you were wondering why NDR messages never show in your Office 365 Group mailboxes, now you have the answer.

As a homework question, how do you figure messages send on behalf of a Team or Teams channel address will behave? 🙂

4 thoughts on “Did you know: NDR messages and Group mailboxes

  1. Jozef Woo says:

    Hi Vasil, I want to thank you first for all the information you share with the community. I have been seeing your name all over the place with always valuable contributions that have also helped me understand Exchange & M365 better and be a better IT professional overall.

    I also wanted to ask if you know of any resources that dive deep on message trace details. Specifically, the data (XML / MEP) part where it has the scores for Spam Confidence Level etc. You have various values like SCL, BCL, SFV, CIP, etc and I have found this link: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-message-headers?view=o365-worldwide but in the XML I also find an item named simply “Score”. Do you know of any resources that could explain further the details or is this proprietary Microsoft data? Many thanks in advance

    Reply
    1. Vasil Michev says:

      As you’ve mentioned, it’s proprietary Microsoft data, and they don’t want to spill out too many details for the bad actors out there. Support might be able to disclose some additional information on request, so best work with them.

      Reply
  2. Dmitry B says:

    Great stuff, Vasil – as always 😉

    Do you know if MS published an explanation for MEP values in the Data field? You can guess some but not others.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.