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.
8 thoughts on “MessageCopy settings for Sent Items and forwarding”
Still an issue in 2023, even worse it seems to copy sent items across Office365 tenants.
Have you got any solution to address this behaviour? also could you please post the code for that message trace?
I though only i am facing this issue
thanks for writing an article for this rare scenario and validating what i figured out but can seem to convince around me.
Did you hear back from MS on this one? Also, is there any way to work around this problem? I need the sent items to save in the sent folder of the shared mailbox but the people that are in the forwarding group are very unhappy with their sent folders getting flooded.
Nope, it seems that nobody cares about this issue 🙂 As for a workaround, you can try using an Inbox rule to do the forward, instead of the forwarding setting.
We are also experiencing this unexpected behaviour.
Exchange 2016 CU9. For the shared mailbox MessageCopyForSendOnBehalfEnabled = $true. Forwarding to a DL is also set on the shared mailbox under Exchange Mail Flow.
Whenever a delegate sends a message on behalf of the shared mailbox all members of the forwarding distro receive a copy of the delegates message into their Sent Items folder in their personal mailbox. Turning off the forward on the shared mailbox in Mail Flow stops the copying of other delegates sent items to all members of the forwarding distro.
This behaviour did not occur in Exchange 2010.
Expected behaviour is the shared mailbox Sent Items should receive a copy into Sent Items and the actual sender should receive a copy into their Sent Items. Other members of the forwarding distro on the shared mailbox should NOT receive a copy of other delegates sent item into their personal mailbox Sent Items.
do you have any more information about this behavior?
We have a problem which occurs, because of this “feature” and we are not sure, if this is by design or just something like a bug.
More about the problem with here:
I never got a reply back on this… I will try again and let you know if someone bothers to answer.