MessageCopy settings for Sent Items and forwarding

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 shared@domain.com vasil.michev@domain.com test no forw Delivered

29/01/2018 08:02:58 shared@domain.com shared@domain.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:

012918 0930 MessageCopy1

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 shared@domain.com vasil.michev@domain2.com test with forw Delivered

29/01/2018 08:32:31 shared@domain.com shared@domain.com Fw:'test with forw'. Resolved

29/01/2018 08:32:31 shared@domain.com DL@domain.com Fw:'test with forw'. Expanded

29/01/2018 08:32:31 shared@domain.com DLmember1@domain.com Fw:'test with forw'. Failed

In the above, shared@domain.com 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

  1. David Foley says:

    Still an issue in 2023, even worse it seems to copy sent items across Office365 tenants.

    Reply
  2. sanka says:

    HI Vasil,

    Have you got any solution to address this behaviour? also could you please post the code for that message trace?

    Regards,

    Reply
  3. kashif says:

    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.

    Reply
  4. Derek Kowal says:

    Hey Vasil,

    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.

    Reply
    1. Vasil Michev says:

      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.

      Reply
  5. MartyNZ says:

    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.

    Reply
    1. Vasil Michev says:

      I never got a reply back on this… I will try again and let you know if someone bothers to answer.

      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.