Microsoft Way

Неожиданное MapiExceptionNotAuthorized при отправке письма в общую папку

Как выясняется, со странными проблемами сталкиваюсь не только я 😉
Несколько лет назад я сам столкнулся с подобной проблемой: при отправке сообщения в mailenabled общую папку от имени внутреннего пользователя, пользователь в ответ получает:
550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: «MapiExceptionNotAuthorized
Вроде бы, очевидная и частая проблема, когда для отправки и папку обязательна аутентификация, а входящая почта исходит от анонимного отправителя (любая внешняя почта, собственно). Вот только ситуация-то была ровно обратной:

1. Сам отправитель является хозяином папки
2. Права «анонимного пользователя» = Author
3. Права «по умолчанию» = Author
4. Папка не требует обязательной аутентификации отправителей
5. Сообщение от любого внешнего источника в папку доставляется корректно. При этом несущественно, через какой smtp коннектор получена почта (внешний анонимный или внутренний с аутентификацией отправителя).
6. Проблема наблюдается только для какого-то ряда внутренних отправителей, на первый взгляд совершенно несвязанных друг с другом (разные департаменты, различные полномочия, большой разброс времени создания учетной записи)

И даже более того: после создания новой mailenabled общей папки и внимательного назначения для нее прав, была проведена серия тестов:

1. Письмо с smtp адресом отправителя изнутри организации, возвращается с NDR.
2. Письмо с smtp адресом отправителя извне, ложится в папку.
3. Если добавить пользователю произвольный внешний smtp адрес, а затем отослать письмо с этим адресом отправителя. То на основной адрес пользователя сваливается NDR.
4. Действо из предыдущего пункта совершенно безболезненно проходит с отправкой на адреса почтовых ящиков пользователей организации.

Учитывая то, что тестирование проводилось в том числе для свежесозданных пользователей… Впору было начинать верить в происки к потусторонних сил.

Но потусторонние силы оказались не виноваты 😉
В AD для целей поддержки какого-то решения удаленного доступа, проверяющего права пользователя на вход путем LDAP запросов, был создан контейнер в который помещены несколько групп. Для целей безопасности, доступ к данному контейнеру был обеспечен только для контроллеров домена, администраторов и специально созданного пользователя с минимальным набором прав (гость домена).
Поскольку серверы Exchange прав на доступ к данным группам не имели, у всех пользователей, включенных в одну из данных групп безопасности, и возникала проблема невозможности доставки сообщений.
Ну а «свежесозданные пользователи» заводились путем копирования учетных записей нескольких администраторов и одной из тестовых учетных записей…тоже входящей в какую-то «секретную» группу.