One of the common requests with delegate access to different types of mailboxes in Exchange is the option to store both the original message and any replies in the same place. Over the years, we have seen different features and workarounds that enable this functionality, and overall it has gotten better.
In the Office 365 world, a new feature that takes care of this request was announced back in March 2015 on the EHLO blog. Namely, the feature included the introduction of the MessageCopyForSendOnBehalfEnabled and the MessageCopyForSentAsEnabled parameters. It took a bit longer than expected to get the feature actually released, but it finally started working as advertised around the middle of 2016. In the on-premised world, the feature was introduced with CU9 for Exchange Server 2013.
Towards the end of 2016, Microsoft also started flighting in this feature for User mailboxes, with the release of CU4 for Exchange Server 2016. It again took them several months to enable this across all of Office 365, but the enrollment process has since completed and you can now happily use this feature across any and all Shared or User mailboxes. The only difference being that the feature is enabled by default for Shared mailboxes, while for User mailboxes you need to toggle it.
Few months back though, a user on the Microsoft Tech Community pointed out a peculiar issue with this feature. Here is the scenario description:
- You have a Shared mailbox configured with either of the MessageCopyForSentAsEnabled or MessageCopyForSendOnBehalfEnabled setting
- You have configured forwarding on the Shared mailbox, pointing to some distribution group address
- You sent a message on behalf of or as the Shared mailbox
- The message is stored in both the delegate and Shared mailbox as expected
- A copy of the message is also stored in the Sent Items folder of each member of the DG
It is the last bit that’s the interesting part. For whatever reason, when forwarding is enabled for the mailbox, any copies of messages sent as or on behalf of said mailbox will also be forwarded. As usual, examples make things easier to understand, so here’s how the message trace for a “regular” Send As event will look like:
Received Sender Address Recipient Address Subject Status -------- -------------- ----------------- ------- ------ 29/01/2018 08:02:58 firstname.lastname@example.org email@example.com test no forw Delivered 29/01/2018 08:02:58 firstname.lastname@example.org email@example.com Fw:'test no forw'. Failed
The first entry is the actual sending of the email, with the expected Receive, Submit, Send External and Spam diagnostics events. Nothing interesting there, so I won’t bore you with the details. The second entry shows what triggers the copying of the sent message to the Shared mailbox. Although a Drop event is triggered, this is the actual copying of the message. Here’s a more detailed view:
As seen from the above trace, the task is performed by an agent running on the ExO Transport servers, namely the SharedMailboxSentItemsAgent. And yes, the process is an actual transport event, not a direct store write, so it’s still a subject of anti-spam checks.
Now, once you enable forwarding on the shared mailbox, things get a little more interesting. The flow is as follows: the message is sent to the designated recipient, then the SharedMailboxSentItemsAgent picks it up and copies to the shared mailbox. So far, the steps are identical with the previous scenario. But since this is an actual message that passed the transport pipeline, at this point the forwarding settings are honored (Redirect event) and the message is sent to the designated forwarding address. In this case, a distribution group, which in turn means that an Expand DL event will be triggered next. Lastly, another Drop event is triggered to facilitate the actual copying of the message to the Sent Items folder of any and all members of the DG!
Here is how it all looks like in a summary view (you can get the Event information by querying the detailed message trace for each of these entries):
Received Sender Address Recipient Address Subject Status -------- -------------- ----------------- ------- ------ 29/01/2018 08:32:31 firstname.lastname@example.org email@example.com test with forw Delivered 29/01/2018 08:32:31 firstname.lastname@example.org email@example.com Fw:'test with forw'. Resolved 29/01/2018 08:32:31 firstname.lastname@example.org DL@domain.com Fw:'test with forw'. Expanded 29/01/2018 08:32:31 email@example.com DLmember1@domain.com Fw:'test with forw'. Failed
In the above, firstname.lastname@example.org is the Shared mailbox, DL@domain.com is the address of the DL to which forwarding is configured and DLmember1@domain.com is one of the members of said DL.
The behavior is easy to reproduce, however my attempts to establish whether this is a feature or a bug have been in vain. Considering the “copy sent messages” feature relies on a Transport agent, I guess this behavior is to be expected, although personally I think it would have made more sense to have an exception coded for this particular scenario. As it seems, the devs simply overlooked the scenario where both the “forwarding” and “copy sent messages” features are enabled. Then again, there’s no harm done, as the messages land directly in the Sent Items folder and users do not get “flooded” with copies, in case of unintentional (mis)configuration of these two features. Anyway, it is good to at least be aware of this behavior, hence the present article 🙂
P.S. Another interesting observation is that the message trace shows the subject prepended with the “Fw” prefix, however the actual message in the Sent Items folder of any of the DG members doesn’t have the prefix. Guess that’s another oddity of the process.