SOLVED

Current default behaviour for saving sent items in delegate and shared mailboxes is wrong

Iron Contributor

Current default behaviour is for emails to only be saved in the sent items of the email sender.

 

I am struggling to think of how this could have ever been seen as the sensible default behaviour?

 

Here's a quick scenario to illustrate:

There is a person (the delegator) who has a couple of delegates set up who are allowed to send as them.

If any of these delegates sends an email the email they sent, by Microsoft's bizarre default, will only have a copy of the sent email put into the "Sent Items" folder of the sender and not the delegator. Just think on this for a moment and, hopefully, you will quickly see the folly of such a default behaviour.

 

That's right, the delegator is not able to either see the email one of the delegates sent on their behalf or as them and they also don't know who will have sent the email. The usual end to this scenario would be for the recipient to tell the delegator which delegate is in the "sent on behalf of" header. But if it was "Sent as" there's still no way of telling which delegate sent it without both delegates being asked.

 

In every case, where this has been discovered, without fail, the delegator and delegates have requested to set copies to be placed in the delegators "Sent Items".

 

Microsoft have an article that covers this subject: https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/automa...

 

Now, Microsoft have worked out that you will want to be able to easily set sent items to be put into the "Sent Items" folder on a regular shared mailbox and have introduced a simple check box for this in the MS 365 Admin Console. However, there are three further changes they need to make to complete this painfully incomplete awakening to their folly:

1. The default behaviour for shared mailboxes, regardless of whether they are regular shared mailboxes or delegate shared, should be for all sent items to at least be put into the "Sent Items" of the delegator or  shared mailbox!

2. The check boxes they have set up in the Admin Console currently, to allow this for regular shared mailboxes, needs to be flipped to be a check box to disable this function, for the few circumstances (still struggling to think of examples when this might be sensible) it might be required to be off.

3. Failing the two items above, replicate the check boxes to allow sent items to be copied to the "Sent Items" folder of the delegator for all emails the delegates might send as or on behalf of the delegator.

5 Replies
Generally speaking I don't disagree, however what you are referring to "delegate shared" mailboxes is regular user mailboxes in practice. Changing defaults for those is not something to take lightly, given all the privacy and compliance implications. But yes, it would've been easy to add an UI option for this.

@Vasil Michev, Thanks for the response, Vasil. I am aware that delegate shared mailboxes are based upon user mailboxes (don't forget resource delegate mailboxes too, though they are not relevant here).

 

I appreciate there would be privacy and compliance issues here, which is my precise point for raising the folly of the current default setting.

 

I was wondering if you could confirm to me any examples of a scenario where it would be compliant for legal or privacy purposes for someone to send an email as someone else and the delegator not have any record of the email in their "Sent Items"? Because this describes the current default, whereby delegates, with send as permissions, are able to send emails with no copy, by default, going into the delegator's Sent Items. By the current default "logic" to be legally and privacy compliant, you would have to change this default, to allow a copy of sent items to be placed into the delegator's Sent Items, as that is the ONLY way, currently, to allow the delegator to see any emails their delegate has sent, as them. This logic also applies to delegates with send on behalf of rights and equally fails to make sense as the DEFAULT behaviour.

 

I am happy to be proved wrong by any examples of how this default behaviour makes sense in the majority of use cases, for simple business communications or legal requirements.

best response confirmed by deejinoz (Iron Contributor)
Solution

In the absence of Microsoft changing any default behaviours, they need to change the Admin Center UI for user mailboxes so that they reflect what can be seen in the shared mailboxes UI, where they have a subsection called "Sent items" where tick boxes can be used to manage this behaviour and can show admins, at a glance, what the status is for this behaviour.

As I said, it already exists in the Admin Center all they need to do is extend their own logic!

However, in the absence of any arguments to support that the current default behaviour actually makes sense, beyond some unsubstantiated and vague comments about compliance, my point about the current behaviour being wrong stands.

I have found an official MS doc that states it is possible to manage this in the "New EAC". However, following my initial happiness, I was deeply disappointed that the article was simply misleading and wrong and the ability to manage saving sent items anywhere in the MS 365 portal only applies in the Admin Centre for shared mailboxes. This article can be found here:
https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/automa...

My issue about it's inaccuracies are raised here:
https://github.com/MicrosoftDocs/OfficeDocs-Exchange/issues/3017

Yep. Raised it through the GitHub channel and they removed references to doing this in the EAC from their documentation.
1 best response

Accepted Solutions
best response confirmed by deejinoz (Iron Contributor)
Solution

In the absence of Microsoft changing any default behaviours, they need to change the Admin Center UI for user mailboxes so that they reflect what can be seen in the shared mailboxes UI, where they have a subsection called "Sent items" where tick boxes can be used to manage this behaviour and can show admins, at a glance, what the status is for this behaviour.

As I said, it already exists in the Admin Center all they need to do is extend their own logic!

However, in the absence of any arguments to support that the current default behaviour actually makes sense, beyond some unsubstantiated and vague comments about compliance, my point about the current behaviour being wrong stands.

View solution in original post