Сообщение отложено агентом классификатора

Обновлено: 02.05.2024

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

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 создавать отдельный коннектор приёма и указать только один адрес, с которого осуществляется приём почты, не нужно указывать диапазон адресов.

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