Security Design Change for Office 365 Public Folders Causes Inbound Email to NDR

Last week I wrote about two changes initiated by Microsoft without the benefit of good customer communication. Here’s another example from Office 365 that came to light recently, brought to my attention by David Petree of AppRiver.

By default, public folders are not mail-enabled. If you want users to have the ability to post new items to public folders, you have to mail-enable the folders by running the Mail-EnablePublicFolder cmdlet or by updating the folder properties through EAC. The net effect is that Exchange populates properties on the folder to allow it to receive mail, including an SMTP address.

Because it’s an SMTP address, people outside your company can use it to send messages to the public folders. This is a useful feature that companies have used ever since public folders existed to accept inbound information into a common repository that can be accessed by many users.

Until that is, the Office 365 team decided that they should introduce a design change to increase the level of security for inbound items that are routed by email into public folders. The design change was duly put into effect to the consternation of many who found that external parties then received NDRs when they attempted to send email to public folders.

What Microsoft had done was to remove the ability of “Anonymous” (non-authenticated) users to create items in mail-enabled public folders. Users within the domain could still email items to the folders because the default public folder client permission assigned to internal users is "author", meaning that anyone can create an item in a folder. After the change was enforced, the lack of permisson forced Exchange to NDR any inbound message sent to a public folder if it had not been enabled for anonymous access.

You can check the client permissions that are in place on all public folders to a file by running the code:

Get-PublicFolder "" -Recurse | Get-PublicFolderClientPermission | Out-File -FilePath "c:TempPFPerms.txt"

>The design change is a fix to an acknowledged problem that is described in the Exchange 2013 CU5 release notes, which say: "Public Folders located on servers running Exchange 2013 SP1 or later accept messages from senders external to the Exchange organization, regardless of the configuration of the public folder. This issue may allow public folders to receive spam and other unwanted messages." In other words, the fact that mail-enabled public folders accepted inbound messages without an administrator assigning any permission was a bug and not by design. Microsoft has fixed this bug in Exchange 2013 CU6 and, as is the norm in these cases, the fix showed up in Office 365 because Exchange Online runs code that is several weeks ahead of the next cumulative update scheduled for delivery to on-premises customers.

The fix restores the situation to the way that mail-enabled public folders should behave and restores parity to the way that they behave in Exchange 2010.

All of this is fine, but what do you do if you have deployed some public folders to receive inbound traffic? The solution is simple. You have to set permission on any public folders that you want to receive unauthenticated messages. For instance, this code adds the necessary permission to all public folders so that the Anonymous pseudo-user is allowed to create items in those folders.

Get-PublicFolder “” –Recurse | Add-PublicFolderClientPermission -User Anonymous -AccessRights “CreateItems"

This code is a very large hammer to crack a small nut and is not recommended because it adds the permission to every public folder including the root. However, it’s strange that Microsoft didn’t come up with a way to automatically add the necessary permission to every mail-enabled public folder in Office 365 tenant domains before they introduced the change. On the other hand, it can be argued that this would be a bad thing too because adding the permissions automatically might not be what customers want. 

In any case, the real problem here is communication once again. Despite the much-vaunted Office 365 change management process and the new Office 365 roadmap that lists all the features Microsoft is working on, the fact remains that they never communicated the design change and its impact to customers before it was turned on. That shouldn’t happen.

Time for more engineers and product managers to be re-educated about the Office 365 change management process? Or perhaps even some imagination put into the change process so that Microsoft might actually think about how features are used and how a change might disrupt users. Would that be too much to ask?

Follow Tony @12Knocksinna