Транспорт сообщений в Exchange 2016

В этой статье я кратко опишу как работает транспорт сообщений в Microsoft Exchange Server 2016.
В Exchange 2016 осталось всего две роли — сервер почтовых ящиков (Mailbox-server) и пограничный транспортный сервер (Edge), который для полноценной работы почтовой системы не обязателен. Отсюда следует что роль Mailbox-server является полнофункциональным транспортом, Edge же — функциональное дополнение, реализующее некоторые возможности. О необходимости внедрения Edge до сих пор идут споры.

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

Служба Front End Transport service

Microsoft Exchange Frontend Transpor (MSExchangeFrontEndTransport)
отвечает исключительно за приём почты из интернета и за маршрутизацию полученных сообщения на сервер внутри (mailbox-server или другие серверы, по ситуации). Так же он отвечает за отправку сообщений в интернет. Имя службы — Microsoft Exchange Frontend Transport.

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

Если переключиться в ecp (https://server.name.ru/ecp), зайти в раздел mail flow — receive connectors: увидим что по умолчанию в Exchange сервере есть пять коннекторов приёма. Три из них закреплены за службой Front End Transport Service (на скриншоте ниже коннекторов шесть, коннектор «From Portal» создан вручную).


Коннектор Default Frontend <ServerName>
У каждого коннектора есть ряд параметров, который нас интересуют в первую очередь.
Вкладка General — тут нас интересует Maximum receive message size (MB) — максимальный объём принимаемого сообщения — думаю, всё понятно из названия.
Protocol logging — по умолчанию выбрано Verbose — тут выбираем, ведётся ли логирование по этому коннектору. None — логирование по этому коннектору не ведётся, Verbose — соответственно, логирование ведётся.

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

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

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

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

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

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

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

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

Коннектор Outbound Proxy Frontend <ServerName>
Вкладка 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 другого сервера.

Если по какой-то причине письмо доставить не удаётся — данное письмо зависает в очереди сообщений Delivery Queues.
Очередь сообщений — это такая специальная база данных, где хранятся все письма, которые по какой-то причине не удалось доставить. Письма там хранятся не бесконечно и через определённое время, если они так и не были доставлены, удаляются.

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

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

Коннектор Client Proxy <ServerName>
Этот коннектор слушает порт 465. Здесь нужно понимать что этот коннектор слушает почту от сервиса Frontend Transport Service, ту почту, которую отправляют пользователи POP3/IMAP.
Т.е. если почта, полученная от внешних серверов по коннектору Default Frontend <ServerName>  проксируется на Transport Service по коннектору Default <ServerName>, т.е. получили по 25 порту, передали на Transport Service по 2525 порту, то почта, полученная от клиентов POP3/IMAP через коннектор Client Frontend <ServerName> по порту 587 — она передаётся на коннектор Client Proxy <ServerName>, который слушает порт 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.
Просмотрщик очередей для каждого сервера индивидуальный.

Если откажет служба Mailbox Transport Submission service — перестанут уходить письма из почтовых ящиков, они зависнут в папке «исходящие» в Outlook.

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

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

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

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


Name — имя коннектора, ни на что не влияет, но рекомендуется давать такое имя коннектору, чтобы было понятно за что этот коннектор отвечает. Т.к. коннекторов отправки может быть значительно больше одного, в дальнейшем можно будет легко запутаться.
Есть преднастроенные типы коннекторов. Обычно используют вариант Custom и выставляют настройки руками.
Следующий экран: каким образом письмо будет доставляться далее. Всегда есть два варианта:
MX record associated with recipient domain. MX запись. Сервер пытается найти MX запись в DNS. Для интернет почты это базовый вариант работы.
Route mail through smart host. Отправлять почту на какой-то смарт-хост. Этот вариант используется если в DMZ есть какой-то «SMTP-relay» (Barracuda, hMail, exim), т.е сервер шлёт всю исходящую почту на это устройство и оно пересылает почту в интернет. В своей практике я однажды встречал exim, настроенный как smtp-relay для Exchange 2007.

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

Дальше: адресное пространство. Для какого домена будет срабатывать данный коннектор. Если делаем коннектор для интернета — самое простое — поставить символ «*».
Но можно сделать коннектор для конкретного домена просто указав его в поле Full Qualified Domain Name (FQDN).

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

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

В коннекторе отправки на вкладке general есть галка Proxy through client access server. Если галка не стоит — почта будет уходить минуя Frontend transport service. Это было важно в те времена, когда сервер клиентского доступа можно было сделать отдельным сервером. (прошлые версии Exchange).
Нам без разницы как будет уходить почта в интернет, разница будет исключительно в логах.
Внимание: это касается только отправки сообщений!

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

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

Все транспортные правила создаются на уровне организации, т.е. они применяются для всех отправляемых и получаемых сообщений в организации. Нельзя создать транспортное правило, чтобы оно применялось для конкретного сервера.
Транспортные правила срабатывают на этапе получения или отправки сообщения.
За применение транспортных правил отвечает служба Transport Service (там, где очередь сообщений) — после проверки антиспамом и до помещения в очередь.

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

Транспортные правила — это очень удобный способ решать повседневные задачи администратора. Например:
Необходимо чтобы в интернет могли отправлять почту только сотрудники определённой группы (банки, госструктуры и т.д.)
Для всех сообщений, отправляемых за пределы организации, должна подставляться определённая подпись (текст, логотип, информация о компании)
Или чтобы все сообщения на адрес директора проходили премодерацию.
Задач множество.

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

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

  1. Условие. Тут говорится к какой почте будет применяться это правило. Условие является опциональным компонентом. Если условие не задать — правило будет применяться ко всем сообщениям.
  2. Исключения. В каком случае транспортное правило не срабатывает. Так же опциональный компонент.
  3. Действие. Что с сообщением делать. Удалять, пересылать, вырезать вложение и прочее…

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

Транспортными правилами можно делать копии сообщений. К примеру, если надо всю входящую почту для определённого сотрудника копировать на адрес другого сотрудника (это же можно делать и в настройках почтового ящика).
И многое другое.

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

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

Журналы отслеживания сообщений

Часто бывает необходимо понять было ли отправлено сообщение, кому было отправлено, было ли доставлено и если не было — на каком этапе произошёл сбой. Для решения этих задач используются Message Tracking Logs.

  • Детальное отслеживание всех сообщений проходящих через серверы Exchange
  • Журналы о перемещении сообщений ведутся на каждом сервере
  • Журналы отслеживания включены по умолчанию и находятся на системном диске
  • Краткая информация получается через EAC, детальная — в EMS (Exchange Management Shell, Powershell)

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

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

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

Get-TransportService | Get-MessageTrackingLog

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

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

Get-MessageTrackingLog -Sender admin@ITSberg.ru

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

Get-MessageTrackingLog -Sender admin@ITSberg.ru -Recipients n.jvank@yandeks.ru

фильтрация по отправителю, получателю и теме сообщения

Get-MessageTrackingLog -Sender admin@ITSberg.ru -Recipients n.jvank@yandeks.ru -MessageSubject TestSubject1

Журналы 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 — указываем получателя.

Журналирование на уровне пользователя:
Ecp — compliance management — journal rules
Необходимо создать правило — нажимаем «создать новое» и создаём правило просто заполняя поля.
Рекомендуется для получателей журналов использовать отдельный почтовый ящик в отдельной БД.

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

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

Если внешняя система умеет аутентифицироваться, т.е она может представиться каким-то внутренним пользователем нашего домена — в таком случае Exchange позволит отправить письма вовне от имени этого пользователя.

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

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

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

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

Type — Custom

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

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

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

 Get-ReceiveConnector "ServerName\Allow anonymous from CRM"

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

Get-ReceiveConnector "ServerName\Allow anonymous from CRM" | Add-ADPermissions -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-Accept-Any-Recipient

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

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

Добавить комментарий