Последняя ошибка сообщение отложено агентом классификатора

Обновлено: 22.09.2023

Подскажите в чем может быть проблема,так как у меня уже заканчиваються идеи.
Заранее спасиб

• Tipo cambiado Daniil Khabarov Moderator lunes, 25 de octubre de 2010 10:19
• Cambiado Hengzhe Li lunes, 12 de marzo de 2012 6:33 forum merge (От:Exchange Server 2007)

Todas las respuestas

Exchange MVP. _ This posting is provided «AS IS» with no warranties, and confers no rights.

Приветствую категорически Коллеги!

Если вы не против, я реанимирую тему.

Есть сервер Exchange 2010. настроен все работает.

на нем создано два соединителя отправки, один по умолчанию с адресным пространством *, второй для конкретного пространства sc.local, и указаны разные промежуточные узлы.

Также создано правило транспорта для отправителей «Вне организации» отправлять скрытую копию на адрес example@sc.local

Пользователи сообщают о невозможности получения или отправления писем через on-premise Exchange 2016 и 2019. Всему виной автоматически устанавливаемое обновление встроенного антивируса.

The FIP-FS «Microsoft» Scan Engine failed to load. PID: 24608, Error Code: 0x80004005. Error Description: Can’t convert «2201010004» to long.

Важный момент: если перед применением официального скрипта Вы отключали antimalware scanning, то его нужно будет включить вручную после применения официального решения.

UPD: Конкретно в моем случае рестарт MSExchangeTransport не привел к очистке очередей. Но после перезапуска всех служб Exchange почта заработала.

Корпоративные серверы электронной почты на базе технологии Microsoft Exchange начали сбоить в новогоднюю полночь по всему миру. Компания накануне выпустила «лекарство» от проблемы.

Как сообщили в Microsoft «проблема-2022» была связана с проверкой даты в антивирусном программном модуле. Он переставал работать в момент сверки версии файла с идентификаторами вредоносного ПО. Из-за этого письма и скапливались в очереди без отправки.

В прошлом году пользователи Microsoft Exchange по всему миру подверглись волне кибератак. Это зафиксировали эксперты «Лаборатории Касперского».

Exchange 2007: изменения в транспортной архитектуре

Транспортные агенты и правила

Edge или Hub: история о двух ролях

Правилами транспорта можно управлять через консоль Exchange Management Console (EMC) или через оболочку EMS. Правила могут быть реализованы на серверах Exchange 2007 с установленными ролями Edge Transport или Hub Transport. Процесс администрирования правил на серверах с разными ролями идентичен, однако области применения создаваемых наборов правил различаются.

Доступных параметров в правилах транспорта может быть недостаточно, чтобы соответствовать требованиям любой организации, и при этом отсутствует возможность их редактирования. Однако разработчики могут создавать собственные транспортные агенты, позволяющие выполнять те требования, для которых недостаточно базового набора параметров в правилах транспорта.

В состав Exchange входит несколько предварительно настроенных классификаций. Их можно удалить или модифицировать, однако они могут и отвечать потребностям вашей компании. Список встроенных классификаций приведен ниже.

• A/C Privileged (письмо от юриста, конфиденциальное);
• Attachment Removed (вложение удалено);
• Company Confidential (служебное, конфиденциальное);
• Company Internal (служебное)
• Originator Requested Alternate Recipient Mail (письмо с просьбой предоставить отправителю альтернативный адрес);
• Partner (письмо от партнера).

На экране 2 показаны результаты выполнения данной команды.

New-MessageClassification -Name Articles

-DisplayName Windows IT Pro

-SenderDescription «This message

contains information and content

supporting Windows IT Pro magazine

Использование классификаций: настройка Outlook

c:program filesmicrosoftexchange serverscriptsexport-messageclassification. ps1 >> mclass.xml

При повторном экспортировании данных в один и тот же файл XML новое содержимое будет добавлено в конец файла, что сделает файл нечитаемым для службы Outlook. Вы должны либо использовать уникальное имя, либо удалить все файлы XML с тем же именем перед экспортом.

Полный путь и имя файла XML должны совпадать со значением, указанным в параметре AdminClassificationPath.

Совместное использование правил транспорта и классификаций

Используем простую классификацию с именем Articles, созданную ранее. Для начала выполним шаги, описанные в предыдущем разделе. С помощью оболочки EMS добавим описание получателя:

Set-MessageClassification-Identity Articles -RecipientDescription «Alert! Windows IT Pro Article Content!»

RecipientDescription — это необязательный параметр, указываемый при создании классификации. Запустим сценарий экспорта для создания нового файла XML, описывающего внесенное изменение. Если вы хотите сделать несколько изменений, рациональнее будет выполнить их все перед созданием файла XML.

Правила и классификации: одна голова хорошо, а две — лучше

Все функции транспорта (отправка, получение, в интернет/из интернета, внутри организации, между организациями) — всё реализует mailbox-server. На mailbox-сервере есть три компонента, сервиса транспорта (Front End Transport Service, Transport Service и Mailbox Transport Service), каждый из этих сервисов имеет собственную службу в ОС.
Блок-схема, взятая с офф.сайта Microsoft:

Служба Front End Transport service

Логика транспорта в Exchange реализована с помощью коннекторов отправки и получения. Есть коннекторы отправки и есть коннекторы приёма. Что делает коннектор: в нём указано, откуда мы готовы получать почту, с каких адресов, по каким интерфейсам и как мы это готовы делать, с аутентификацией или без.
Поскольку Front End Transport отвечает за приём почты из интернета — коннекторы должны быть обязательно.

Вкладка Scoping — эта вкладка нас интересует больше.
В ней есть два блока.
Remote network settings. Этот блок описывает с каких IP-адресов мы готовы по этому коннектору принимать почту.
Как видим, дефолтный фронтенд коннектор имеет полный диапазон IPv4 и IPv6, т.е. с любого IP-адреса этот коннектор может принимать почту.

Network adapter bindings. По каким сетевым интерфейсам и по какому порту мы готовы принимать почту этим коннектором. По умолчанию — любой интерфейс, 25 порт.

FQDN — Имя, которым сервер будет представляться в рамках SMTP-сессии. Если у вас простая почтовая система из одного сервера — пишем сюда полное имя сервера и не заморачиваемся.

Вкладка Security — настройки аутентификации.
По умолчанию по данному коннектору наш сервер готов принимать почту от серверов Exchange и от анонимных пользователей. + доступны настройки аутентификации, т.е. если какой-то сервер Exchange будет доставлять по этому коннектору — он может аутентифицироваться.

Этот коннектор в реальной жизни используется чтобы получать почту из интернета, т.е. в сервере уже есть коннектор, готовый анонимно принимать почту из интернета, естественно — только для тех получателей, которые есть в компании. Если кто-то анонимно подключится и попробует доставить почту получателю не из вашего домена — данный коннектор такую почту отбросит и она не будет доставлена.

Второй коннектор Client Frontend
Он похож на Default Frontend ServerName, но в закладке Scoping мы видим отличие по порту — этот коннектор слушает 587 порт.

Для чего используется данный коннектор: если есть клиенты, использующие POP3 или IMAP для получения почты, то для отправки почты им нужно использовать протокол SMTP, поэтому, при наличии в компании клиентов POP3, клиенты будут устанавливать со службой Frontend Transport Service соединение по SMTP по 587 порту. Это как раз и есть SMTP с шифрованием. Именно этот коннектор слушает данный порт.

Если зайти на вкладку Security — тут будут отмечены Exchange Users — такая небольшая подсказка.
Если в компании отсутствуют пользователи POP3/IMAP, то данный коннектор можно отключить.

Коннектор Outbound Proxy Frontend
Вкладка Scoping: видим что данный коннектор слушает 717 порт.

Служба Frontend Transport Service отвечает не только за приём почты из интернета, но и за её отправку. Когда внутренние пользователи будут писать письма в интернет, письма будут идти через службу Transport Service, и Transport Service ту почту, которая предназначается для отправки в интернет, будет отдавать на Frontend Transport Service. Так вот, 717 порт — это тот порт ,по которому Frontend Transport Service получает почту от Transport Service. Даже если у нас всего один сервер, письмо от пользователя вначале пойдёт через Mailbox Transport Service, потом на Transport Service и уже по 717 порту Transport Service передаст письмо Frontend Transport Service.

После того как Frontend Transport Service примет коннектором приёма письмо, он передаст это письмо в службу Transport Service. Это одна из основных служб транспорта.

Служба Transport Service.

Microsoft Exchange Transport (MSExchangeTransport)
Данная служба отвечает за то, чтобы принять письмо, обработать его (применить всевозможные транспортные правила), понять кто является получателем данного письма и дальше смаршрутизировать это письмо на другой сервер. Если получатель письма находится на этом же сервере, служба Transport Service по SMTP передаст письмо на службу Mailbox Transport Service и уже эта служба положит письмо в почтовый ящик.
Если получатель находится на другом сервере, то Transport Service по SMTP передаст это письмо на Transport Service другого сервера.

Прежде всего у службы Transport Service есть два коннектора приёма (хотя в ecp их не переименовали и оно там относятся к роли HubTransport, находятся коннекторы там же, где и коннекторы Frontend Transport Service)

Коннектор Default
На вкладке Scoping видим что данный коннектор слушает порт 2525. Коннектор используется для получения почты от службы Frontend Transport Service. Когда Frontend Transport Service получит письмо из интернета, он будет передавать его в службу Transport Service, и вот здесь будет использоваться приём по порту 2525. По этому же порту он будет принимать почту с других Exchange серверов при сценариях внутренней маршрутизации почты. Этот коннектор необходим для сценариев, когда почта идёт из интернета, либо когда почта идёт с других серверов Exchange внутри организации.
Остальные настройки, в целом, аналогичный коннектору Default Frontend

Коннектор Client Proxy
Этот коннектор слушает порт 465. Здесь нужно понимать что этот коннектор слушает почту от сервиса Frontend Transport Service, ту почту, которую отправляют пользователи POP3/IMAP.
Т.е. если почта, полученная от внешних серверов по коннектору Default Frontend проксируется на Transport Service по коннектору Default , т.е. получили по 25 порту, передали на Transport Service по 2525 порту, то почта, полученная от клиентов POP3/IMAP через коннектор Client Frontend по порту 587 — она передаётся на коннектор Client Proxy , который слушает порт 465. Опять же, если таких клиентов нет — этот коннектор тоже можно отключить.

Служба Transport Service принимает письмо, выполняет функции антиспама (если они есть), применяет транспортные агенты, транспортные правила и решает, куда дальше пересылать письмо, в Mailbox Transport service или на другой сервер.

Служба Mailbox Transport Service

Mailbox transport service состоит из двух компонентов (служб): Mailbox Transport Submission Service (MSExchangeSubmission) и Mailbox Transport Delivery Service (MSExchangeDelivery).
Transport Delivery — получает письмо от службы транспорта и кладёт его в базу данных.
Transport Submission — берёт исходящее письмо и передаёт его на службу транспорта.

Если пришло письмо от Mailbox Transport’а, оно попадает в очередь (Delivery Queues), и, если получатель находится на другом сервере в другом сайте AD нашей организации — то доставка будет по SMTP от одной службы транспорта другой службе транспорта другого сервера.
Если получателем является человек, чей почтовый ящик находится на этом же сервере, либо на другом сервере но в этом же сайте AD, то служба транспорта передаёт на компонент Mailbox Transport Delivery (по SMTP).

Что происходит если Mailbox Transport service не доступен по какой-либо причине: письмо зависнет в очереди Delivery queues и будет ждать пока получатель станет доступен.
Просмотреть содержимое очереди можно инструментом Queue Viewer, который находится в Exchange Toolbox.
Просмотрщик очередей для каждого сервера индивидуальный.

Внимание:
Для маршрутизации отправки писем внутри компании, из скольких бы серверов она не состояла, коннекторы отправки создавать не нужно.
Специальные коннекторы для маршрутизации почты внутри компании создаются автоматически! Но они не видны.

Для отправки почты в другие компании (внешним получателям) необходимо создать коннекторы отправки. По умолчанию они не создаются.

Коннекторы отправки:

Коннекторы отправки находятся рядом с коннекторами получения — соседняя вкладка (Mail Flow — Send Connectors).

При разрешении MX Exchange сервер использует те DNS, которые прописаны в настройках сетевого подключения. Если эти DNS разрешают интернет-адреса — отлично, если нет — ставим галку Use the external DNS lookup settings on servers with transport roles и отдельно задаём в свойствах сервера DNS сервера исключительно для разрешения MX-записи для маршрутизации почты.

Галка Scoped send connector:
Когда создаём на одном сервере коннектор, а почтовых серверов в организации несколько, то при доставке почты, которая подпадает под этот коннектор, вся почта будет идти на сервер, владеющий коннектором, а он, в свою очередь, будет маршрутизировать эту почту по коннектору.
Если поставить галку Scoped send connector, то доставлять почту на сервер с коннектором, чтобы он её отправил по коннектору, смогут только те сервера, которые находятся в одном сайте AD с этим же сервером. Эта галка важна в крупных компаниях.

Далее указываем на каком сервере создаётся этот коннектор, просто выбираем его из списка серверов. Если сервер один — выбираем этот сервер.
Нюанс:
Компонент Transport Service умеет отправлять почту в интернет сам, не передавая её компоненту Frontend Transport Service. И более того, он делает это по-умолчанию.

Транспортные правила

Транспортные правила необходимы для решения двух групп задач:
— проверка и обработка любого отправляемого и получаемого письма в вашей организации
— решение типовых задач почтового администратора

По-умолчанию транспортных правил нет.

В мастере создания транспортного правила есть множество заготовок. Если необходимо сделать что-то своё, чего нет в заготовках транспортного правила — сделать это с помощью транспортного правила нельзя.

Принцип работы:
Правило всегда состоит из трёх элементов.

Если правила не противоречат друг-другу — правила применяются все в порядке приоритета.
Проще всего правила создавать в web-интерфейсе. Mail flow — rules.
При создании нового правила можно выбрать одну из заготовок. Либо нажать create a new rule… и собрать правило самому.
Если в открывшемся окне нажать More options — откроются скрытые опции. Скрытые опции рекомендуется открывать всегда. Это справедливо, к слову, не только для транспортных правил, такая кнопка есть почти во всех вкладках Exchange Control Panel, так же известной как ECP.

Важно понимать: транспортные правила прозрачны для конечного пользователя. Единственное — пользователь может увидеть только результат (письмо отклонено, удалено вложение и т.д.).

Настоятельно рекомендуется поэкспериментировать с транспортными правилами!

Естественно весь этот функционал настраивается. Существует специальный командлет Get-TransportService, который позволяет получить информацию о конфигурации транспорта на конкретном сервере. Так же он позволяет добраться до параметров настройки Tracking Logs. Они настраиваются на каждом сервере отдельно.

Менять настройки логирования можно через командлет Set-TransportService.

Через web-интерфейс получить информацию из логов можно в разделе Mail flow — delivery reports.
Выбираем почтовый ящик, по которому необходимо получить информацию, заполняем нужные нам поля (не обязательно) и жмём search.
Если же выполнить командлет Get-MessageTrackingLog, то информацию получим с конкретного сервера. В том случае, если в компании используется несколько почтовых серверов, информация будет неполной.

Такая команда покажет все логи со всех серверов. Стоит учитывать, что логов очень много, тысячи записей. Необходимо применять дополнительные фильтры, подробнее — см. справку по командлету Get-MessageTrackingLog.

Фильтрация логов по отправителю:

Фильтрация логов по отправителю и получателю:

Журналы SMTP протокола

Отдельно, в специальных log-файлах протоколируется всё, что касается SMTP.

• Протоколируют только SMTP сессии
• Настраивается для транспортных сервисов
• Включаются исключительно на уровне коннекторов приёма и отправки
• По-умолчанию включено ведение журнала не на всех коннекторах
• Для диагностики нужно понимать через какие коннекторы шли соединения

SMTP-логи хранят следующую информацию:
date-time
connector-id
session-id
sequence-number
local-endpoint
remote-endpoint
event
data
context

Здесь нужно чётко понимать, что в Exchange сервере существует несколько служб транспорта и есть коннекторы, которые работают на Transport Service, и есть коннекторы, которые работают на Frontend transport service. Необходимо понимать, какие коннекторы используются в какой момент.

С помощью командлета Get-FrontendTransportService | fl *protocol* — можно вывести на экран информацию по логам протокола, который ведётся для коннекторов данной службы.
Get-Transportservice | fl *protocol* — можно получить информацию о логах, которые ведутся для коннекторов этой службы.
Логи ведутся в текстовом формате.
Логирование включается в свойствах протокола в ECP. Если отмечено None — логирование не ведётся, если Verbose — ведётся.

Логи коннектора отправки:
Прежде всего необходимо узнать какая служба выполняет отправку. Для этого необходимо открыть коннектор отправки и проверить, отмечен ли пункт Proxy throught client access server (проксирование через сервер клиентского доступа). Если пункт не отмечен — отправка происходит службой Transportservice, если пункт отмечен — отправка службой FrontendTransportService. Далее смотрим где находятся логи.

Внимание: информация в файлах логов появляется не моментально, может пройти несколько минут, т.к. информация должна быть записана в файл из оперативной памяти.

Если необходимо сохранить переписку определённых пользователей, можно использовать несколько способов.
Можно использовать транспортное правило (копирование на определённый почтовый ящик, к примеру), а можно использовать журналирование.

Журналирование на уровне БД не требует дополнительных лицензий. При включении данного типа журналирования для каждого письма, входящего или исходящего из данной БД, формируется журнал. Нужно понимать, что включение журналирования на уровне БД приводит к громадному количеству дополнительных писем. На каждое отправляемое или получаемое письмо будет формироваться журнал и доставляться получателю этого журнала.

Есть ещё журналирование на уровне получателя — оно требует расширенную клиентскую лицензию на пользователя.
Как оно работает: включаем журнал для конкретного человека. Журнал формируется для каждого отправляемого или получаемого письма этого человека и отправляется на тот почтовый ящик, который указан как место хранения журнала.

Обычно журналирование включается когда необходимо осуществлять слежку за человеком либо сохранять переписку конкретного человека.

Журналирование на уровне БД включается просто:
Открываем свойства нужной БД в ecp и переходим на вкладку maintenance. Поле — Journal Recipient — указываем получателя.

Отправка писем от внешней системы через Exchange Server

Но в большинстве случаев подобные системы не умеют аутентифицироваться и подключаются анонимно.

Чтобы создать возможность отправки почты от внешней системы на внешние адреса через наш Exchange Server — нам необходимо создать ещё один коннектор приёма, который будет слушать входящую почту только с адреса этой системы и именно на этом коннекторе мы откроем Open Relay — сервер пересылки. Сервер будет принимать почту анонимно и рассылать её не только для получателей нашей организации, но и рассылать её получателям в интернете.

В ECP — mail flow — receive connectors:
Создать новый коннектор.
Желательно дать новому коннектору понятное имя, например Allow anonymous from CRM.

Далее необходимо выбрать какая служба транспорта будет обрабатывать данный коннектор. Тут всё зависит от нашей конфигурации почтовой системы. Если сервер один — не критично что именно выбирать.

Далее указываем по каким IP-адресам сервера слушать почту и по какому порту. По-умолчанию все адреса и стандартный 25 порт. Оставляем так, если не важно иное.

Далее указываем с каких адресов будет приниматься почта. В данном случае важно указать IP-адрес нашего внешнего сервера рассылки. Если оставить значение по-умолчанию (0.0.0.0-255.255.255.255) — первый же сервер в интернете, который ищет открытые серверы Open Relay это определит, и мы будем рассылать чужой спам.

Далее открываем свежесозданный коннектор приёма и делаем две вещи, чтобы оно заработало.
— Открываем вкладку security и отмечаем: Transport Layer Security (TLS) и Anonymous users. Включив анонимные подключения по этому коннектору мы всего лишь разрешаем подключаться без аутентификации, т.е. почта будет приниматься только для внутренних адресов. Open Relay отсутствует.
— Дальше работаем через PowerShell.
Нам необходимо добраться до свежесозданного коннектора:

Теперь нам необходимо дать с помощью командлета Add-ADPermissions расширенные права для доставки любому получателю.

Теперь Open Relay должен работать.

Очень важно при открытии Open Relay создавать отдельный коннектор приёма и указать только один адрес, с которого осуществляется приём почты, не нужно указывать диапазон адресов.

Читайте также:

  

• Сообщение на тему клюква

  

• Сообщение на тему визитная карточка москвы

  

• Сообщение на тему человек и мир звуков

  

• Сообщение земноводные нижегородской области

  

• Сообщение о вузах мира

Огромная масштабируемость системы Exchange кроме всех своих преимуществ, несет в себе и большие минусы. Один из таких минусов — сложность в отслеживании почтовых сообщений в логах. Ведь имея несколько транспортных серверов (не дай Бог еще и объединенных в DAG), мы получаем ситуацию, когда письмо проходит через все сервера и оставляет свой след в логах на каждом.

Сейчас я постараюсь хотя бы частично помочь в том, как более-менее результативно отслеживать логи прохождения сообщений.

Принципиальную схему пути сообщения (Exchange 2013 Mail Flow / Transport Pipeline) описывает данный рисунок:

 

Отслеживание писем в Exchange 2013

Мой подход к отслеживанию сообщений в Exchange вот такой:

1. Получаем ID нужного письма с помощью Get-MessageTrackingLog.
2. С помощью Log Parser 2.2 получаем детальный лог по конкретному письму.

Почему нельзя использовать только Get-MessageTrackingLog (ведь он умеет достаточно быстро искать по логам сразу на нескольких серверах)? У Get-MessageTrackingLog есть только одна неприятная особенность: в результатах он отдает записи из логов с некоторой временной меткой (TimeStamp), так вот коммандлет отдает эту метку с точностью до секунды, хотя в текстовых логах хранится время с точностью до тысячной секунды. Так вот многие операции происходят в течение одной единственной секунды, и из-за этого невозможно выстроить хронологию событий.

Именно поэтому мы будем обрабатывать логи через Log Parser 2.2. Это унивесальный парсер логов от Microsoft, который работает с языком SQL в качестве запросов.

Ищем письма с помощью Get-MessageTrackingLog

В составе Exchange 2013 есть замечательный коммандлет Get-MessageTrackingLog. Он позволяет найти нужное сообщение с использованием параметров в качестве фильтра. Самое подробное описание фильтрующих параметров смотрите вот тут: https://technet.microsoft.com/en-us/library/aa997573(v=exchg.150).aspx.

Вот пример, как использовать Get-MessageTrackingLog для поиска MessageId:

Скопируем MessageId и двигаемся дальше.

Пользуемся Log Parser 2.2 и Log Parser Studio

Во-первых нам нужно установить Log Parser 2.2 и Log Parser Studio (GUI для Log Parser 2.2). Вот ссылки:

• https://www.microsoft.com/en-us/download/details.aspx?id=24659 — Log Parser 2.2
• https://gallery.technet.microsoft.com/office/Log-Parser-Studio-cd458765 — Log Parser Studio

Устанавливаем обе программы и запускаем Log Parser Studio — LPS.exe.

Указываем пути, откуда брать логи (полезная статья на эту тему: Перемещаем логи Exchange 2013 из папок по умолчанию с помощью Powershell):

Обратите внимание: указываем логи сразу с двух серверов (если их два)!

Далее создаем новый запрос и устанавливаем тип лог-файлов — EELLOG. Сортировка — по времени.

SELECT * 
FROM '[LOGFILEPATH]'
WHERE message-id = '<MessageId>'
ORDER BY [#Fields: date-time]

Выполняем запрос и получаем результат:

Анализ лога

Теперь вы можете просмотреть, какой путь прошло письмо, и возможно, найдете причину сбоев. В большинстве случаев вам понадобятся следующие поля:

• client-ip
• client-hostname
• server-ip
• server-hostname
• connector-id
• source
• event-id

Последние два упомянутых поля source и event-id — говорят о том, какие действия выполнялись с письмом. Помощь в анализе этих полей вы можете получить в этой статье:

https://technet.microsoft.com/en-us/library/bb124375(v=exchg.150).aspx 

https://technet.microsoft.com/ru-ru/library/bb124375(v=exchg.160).aspx (по-русски)

Для вашего и своего удобства привожу самые полезные сведения тут.

Возможные значения поля event-id

Имя события	Описание
AGENTINFO	Это событие используется агентами транспорта для журналирования пользовательских данных.
BADMAIL	Сообщение отправлено каталогом раскладки или каталогом преобразования и не может быть доставлено и возвращено.
CLIENTSUBMISSION	Сообщение было отправлено из папки «Исходящие» почтового ящика.
DEFER	Доставка сообщения отложена.
DELIVER	Сообщение было доставлено в локальный почтовый ящик.
DSN	Создано уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).
DROP	Сообщение было отклонено без уведомления о доставке (также называемого сообщением возврата или отчетом о недоставке). Например: сообщения о выполненных запросах для утверждения; нежелательные сообщения, удаленные автоматически без отчета о недоставке.
DUPLICATEDELIVER	Сообщение было доставлено получателю повторно. Повторная доставка сообщений может происходить в том случае, если получатель входит в несколько вложенных групп рассылки. Банк данных обнаруживает и удаляет дубликаты сообщений.
DUPLICATEEXPAND	При расширении группы рассылки обнаружен повторяющийся получатель.
DUPLICATEREDIRECT	Альтернативный получатель сообщения уже являлся получателем.
EXPAND	Была расширена группа рассылки.
FAIL	Не удается доставить сообщение. Источники: SMTP, DNS, QUEUE и ROUTING.
HADISCARD	Теневое сообщение было отвергнуто, после того как основная копия была доставлена на следующий узел. Подробнее см. в разделе Теневая избыточность.
HARECEIVE	Теневое сообщение было получено сервером в локальной группе обеспечения доступности баз данных или на сайте Active Directory.
HAREDIRECT	Создано теневое сообщение.
HAREDIRECTFAIL	Не удалось создать теневое сообщение. Сведения сохранены в поле source-context.
INITMESSAGECREATED	Сообщение отправлено контролируемому получателю, поэтому оно отправлено в почтовый ящик вынесения решения для утверждения. Подробнее см. в разделе Управление утверждением сообщений.
LOAD	Сообщение успешно загружено при загрузке.
MODERATIONEXPIRE	Модератор контролируемого получателя не утвердил и не отклонил сообщение, поэтому для него истек срок ожидания. Дополнительные сведения о контролируемых получателях см. в разделе Управление утверждением сообщений.
MODERATORAPPROVE	Модератор контролируемого получателя утвердил сообщение, поэтому оно было доставлено контролируемому получателю.
MODERATORREJECT	Модератор контролируемого получателя отклонил сообщение, поэтому оно не было доставлено контролируемому получателю.
MODERATORSALLNDR	Все запросы для утверждения, отправленные всем модераторам контролируемого получателя, не могли быть доставлены и привели к отправке отчетов о недоставке (также называемых сообщениями возврата).
NOTIFYMAPI	Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере.
NOTIFYSHADOW	Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере, и необходимо создать теневую копию сообщения.
POISONMESSAGE	Сообщение помещено в очередь сообщений о сбое или удалено из нее.
PROCESS	Сообщение успешно обработано.
RECEIVE	Сообщение было получено компонентом получения протокола SMTP службы транспорта или из каталога раскладки или каталога преобразования (источник: SMTP), или сообщение было отправлено из почтового ящика в службу отправки почтовых ящиков (источник: STOREDRIVER).
REDIRECT	Сообщение было перенаправлено другому получателю в результате поиска в Active Directory.
RESOLVE	В результате поиска в Active Directory для получателей сообщения был найден другой адрес электронной почты.
RESUBMIT	Сообщение было автоматически повторно отправлено из сети безопасности. Подробнее см. в разделе Система безопасности.
RESUBMITDEFER	Сообщение, повторно отправленное из сети безопасности, было отложено.
RESUBMITFAIL	Сообщение, повторно отправленное из сети безопасности, не удалось отправить.
SEND	Сообщение было отправлено протоколом SMTP между службами транспорта.
SUBMIT	Служба отправки почтовых ящиков успешно передала сообщение службе транспорта. Для событий SUBMIT свойство source-context содержит следующие данные: MDB   GUID базы данных почтовых ящиков. Mailbox   GUID почтового ящика. Event   Порядковый номер события. MessageClass   Тип сообщения. Например, IPM.Note. CreationTime   Дата и время отправки сообщения. ClientType. Примеры: User, OWA и ActiveSync.
SUBMITDEFER	Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта была отложена.
SUBMITFAIL	Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта не была выполнена.
SUPPRESSED	Передача сообщения была отменена.
THROTTLE	Сообщение было отрегулировано.
TRANSFER	В результате преобразования содержимого, ограничения числа получателей или работы агентов получатели были перемещены в сообщение с ветвлением. Источники: ROUTING или QUEUE.

Возможные значения поля source

Значение источника	Описание
ADMIN	Источник события был введен пользователем. Например, администратор использовал средство просмотра, чтобы удалить сообщение, или отправил файлы сообщений с помощью каталога воспроизведения.
AGENT	Источником события был агент транспорта.
APPROVAL	Источником события была платформа утверждения, используемая для контролируемых получателей. Подробнее см. в разделе Управление утверждением сообщений.
BOOTLOADER	Источником события были необработанные сообщения, которые присутствовали на сервере на момент загрузки. Это относится к типу событий LOAD.
DNS	Источником события было DNS.
DSN	Источником события было уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).
GATEWAY	Источником события был внешний соединитель. Подробнее см. в разделе Внешние соединители.
MAILBOXRULE	Источником события было правило для папки «Входящие». Дополнительные сведения см. в статье Правила для папки «Входящие» в Outlook Web App.
MEETINGMESSAGEPROCESSOR	Источником события был обработчик сообщения о собрании, который обновляет календари в соответствии с обновлениями собрания.
ORAR	Источником события был альтернативный получатель, запрошенный отправителем (ORAR). Вы можете включить или отключить поддержку ORAR на получающих соединителях, используя параметр OrarEnabled в командлете New-ReceiveConnector или Set-ReceiveConnector.
PICKUP	Источником события был каталог раскладки. Подробнее см. в разделе Каталог раскладки и каталог преобразования.
POISONMESSAGE	Источником события был идентификатор сообщения о сбое. Дополнительные сведения о сообщениях о сбое и очереди сообщений о сбое см. в разделе Queues and messages in queues
PUBLICFOLDER	Источником события была общедоступная папка, поддерживающая почту.
QUEUE	Источником события была очередь.
REDUNDANCY	Источником события было избыточное теневое копирование. Подробнее см. в разделе Теневая избыточность.
ROUTING	Источником события был компонент разрешения маршрутизации классификатора в службе транспорта.
SAFETYNET	Источником события была сеть безопасности. Подробнее см. в разделе Система безопасности.
SMTP	Сообщение было отправлено компонентом отправки или получения SMTP службы транспорта.
STOREDRIVER	Источником события была MAPI-отправка из почтового ящика на локальном сервере.