Home » Exchange Server » Causes of MapiExceptionNotAuthorized Error Sending to Public Folders

Causes of MapiExceptionNotAuthorized Error Sending to Public Folders

In some scenarios a mailbox user sending emails to a mail-enabled Public Folder may receive an undeliverable message in reply.

The message contains the following error details:

This error can occur under a variety of configurations relating to Public Folder client permissions.

External Senders

External senders will receive the error if the Public Folder does not permit “Anonymous” to create new items.

To grant this access run the following command in the Exchange Management Shell.

Internal Senders

Internal senders are able to be authenticated by the Exchange server, and so are not treated as Anonymous. For internal senders the user must have at least Create Items permissions on the Public Folder. For general use Public Folders this can be granted as the “Default” permission.

To grant this access run the following command in the Exchange Management Shell.

Internal Senders Alternate Scenario

Because internal senders are being authenticated by the Exchange server their group membership is taken into consideration. When the Exchange server receives a new item from an internal sender it takes the following basic steps:

  1. Maps the sender address to a user account object (this occurs even if the email was not sent by the user themselves, eg was sent via Telnet)
  2. Enumerates the user's group membership
  3. Assesses the group membership against the ACLs on the Public Folder
  4. Permits or denies the mail item depending on the ACL

Because of this process the Exchange server must have Read access to the groups that the sender is a member of, including direct membership and indirect membership (eg by nested groups).

If the Exchange server cannot read a group object it will deny the mail item and the user will receive the undeliverable message with “MapiExceptionNotAuthorized”.  The reason for this is that it is designed to fail in a secure way (ie, “I can't verify your access therefore I will deny you”), rather than an insecure way (ie “I can't verify your access therefore I will permit you”).

With that in mind you would need to investigate all of the direct and indirect group membership for the user and try to locate a group object that does not have the Exchange Servers group with Read access in its ACL.  Most commonly this will occur when the group is in a Domain in the Forest that has not been prepped for Exchange, or is in an OU where permissions inheritance has been disabled.

Correcting the ACL on the group objects should resolve the undeliverable “MapiExceptionNotAuthorized” error in those cases.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

14 comments

  1. Kirk Lashbrook says:

    “If the Exchange server cannot read a group object it will deny the mail item… ”

    Very helpful info !

    I’ve had to troubleshoot this issue for internal users randomly not being able to send messages to a public folder. It’s not always the “CreateItems” permission on the PF that we would all check first.

  2. Paul Mattson says:

    Thanks!

    The problem was resolved for us when I gave the anonymous user only the “Create items” permission on that public folder.

    I didn’t need to use powershell, Just:
    -RightClick the folder in Outlook
    -Click Permissions
    -Select Anonymous
    -Permission Level DropDown to “Contributor”
    -Unchecked “Folder visible”

    Works perfectly – Thanks again!

  3. Lee says:

    This didn’t work for me.

    Giving Anonymous or Default user the create item works but it is not what we want due to the strict permissions on the Public Folder.

    We have an Exchange 2010 resource forest and FIM provisions the distribution group into this forest. The source forest will retain all user accounts and access is via a “linked mailbox” It seems that the resource forest is not able to expand out the Distribution group (which has the create item permission).

    Seen this before?

  4. Mohamed sassi says:

    What if we have a tree :
    folder1 disabled Email
    folder2 enabled mail
    folder2 is a subfolder of folder1
    Do we have to make the same operation for the 2 folders?
    (default,anonymous)–>create items for the 2 folders ?
    Regards

Leave a Reply

Your email address will not be published. Required fields are marked *