Служба Exchange 2013 Mailbox Transport

Служба Exchange 2013 Mailbox Transport отвечает за взаимодействие с почтовыми базами данных и фактически состоит из двух отдельных служб Windows — Microsoft Exchange Mailbox Transport Delivery и Microsoft Exchange Mailbox Transport Submission. Каждая из них отвечает за отдельную задачу, но обе взаимодействуют с Транспортной службой на серверах с ролью MBX. В этой статье я расскажу подробно о последней оставшейся службе транспорта Exchange 2013, фундаментально отличающейся от всех остальных.

Это третья статья из серии, посвященной принципам работы служб транспортного конвейера Exchange 2013, а вот полный список:

• Служба Exchange 2013 FrontEnd Transport
• Служба Exchange 2013 Transport
• Служба Exchange 2013 Mailbox Transport
• Служба Exchange 2013 Edge Transport

А также статьи по управлению логированием этих служб:

• Логи Exchange 2013 FrontEnd Transport
• Логи Exchange 2013 Transport
• Логи Exchange 2013 Mailbox Transport
• Логи Exchange 2013 Edge Transport

Не забывайте про официальную документацию.

---

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.

---

Exchange 2013 Mailbox Transport

В Exchange 2013 существуют несколько служб транспорта, назначение которых отличается фундаментально, хоть и задача у них одна единственная — участвовать в транспортировке почтовых данных. В предыдущих статьях я составлял список всех компонентов транспортного конвейера, напомню его и в этой:

• Транспортная служба переднего плана на серверах клиентского доступа (Отображаемое имя — Microsoft Exchange FrontEnd Transport, сокращенное — MSExchangeFrontEndTransport);
• Транспортная служба на серверах почтовых ящиков (Отображаемое имя — Microsoft Exchange Transport, сокращенное — MSExchangeTransport);
• Транспортная служба почтовых ящиков на серверах почтовых ящиков (Реально включает в себя две службы — Microsoft Exchange Mailbox Transport Delivery и Microsoft Exchange Mailbox Transport Submission, сокращенные имена — MSExchangeDelivery и MSExchangeSubmission соответственно);
• Транспортная служба на пограничных транспортных серверах (Отображаемое имя — Microsoft Exchange Transport, сокращенное — MSExchangeTransport).

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

Транспортный конвейер

После рассмотрения в предыдущих статьях службы FrontEnd Transport (Транспортная служба переднего плана — Служба Exchange 2013 FrontEnd Transport) на серверах клиентского доступа и службы Transport (Транспортная служба — Служба Exchange 2013 Transport) на серверах почтовых ящиков мы дошли до последней структурной единицы транспортного конвейера — службы Mailbox Transport (Транспортная служба почтовых ящиков). Также не будет лишним напомнить как вообще выглядит транспортный конвейер Exchange 2013:

В контексте данной статьи нас будет интересовать роль Сервер почтовых ящиков (MBX или MailBox Server) и конкретно одна служба этой роли — Транспортная служба почтовых ящиков. Убрав со схемы все ненужные элементы, получаем:

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

Принцип работы

Хочу напомнить, что всего у Exchange 2013 есть три серверные роли — CAS, MBX и Edge (добавлена в Exchange Server 2013 SP1). Транспортная служба почтовых ящиков принадлежит к роли MBX.

Иллюстрации транспортного конвейера, присутствующие в моей статье, взяты с официальных источников ¹. Стоит отметить, что на изображении и в русской документации потока обработки почты Exchange 2013 присутствуют некоторые различия в переводе. Например на рисунке выше служба MSExchangeSubmission имеет имя Транспортная служба отправки почты в почтовый ящик, в то время как в документации её ещё называют Транспортная служба отправки почтовых ящиков. Оба варианта имеют один и тот же смысл. Вторая служба — MSExchangeDelivery — также имеет два схожих варианта перевода — Транспортная служба доставки почты в почтовый ящик или Служба доставки транспорта почтовых ящиков. Очень сложно не запутаться, но вы постарайтесь.

Попробуем сформулировать основные принципы работы Mailbox Transport:

1. Только Транспортная служба почтовых ящиков взаимодействует с базами данных и делает это она по протоколу RPC. При этом речь идет только о локальных базах данных на конкретно взятом сервере с ролью MBX. С базами данных на других серверах эта служба не работает, а делает это через Транспортную службу на удаленном сервере, связываясь по протоколу SMTP. Вот что пишут по этому поводу в документации:

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

…

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

Разумеется сказанное выше справедливо и для групп доступности баз данных (DAG) для серверов, на которых располагается активная реплика БД.

2. Углубляясь далее можно сказать, что RPC используется в обоих случаях — при доставке сообщений получателю и при их отправке. В первом случае Транспортная служба почтовых ящиков получает сообщение по протоколу SMTP от Транспортной службы на локальном или удаленном сервере и подключается по RPC к базе данных для доставки этого сообщения конечному получателю. Во втором случае также идет соединение с БД по RPC, но уже для извлечения отправляемого сообщения и его дальнейшей передаче Транспортной службе также по SMTP.

3. Поскольку Транспортная служба почтовых ящиков может обращаться к Транспортным службам на других серверах с ролью MBX, должен быть какой-то механизм выбора необходимого сервера для передачи сообщения. Этот механизм есть и он известен по предыдущей статье про Транспортную службу (Служба Exchange 2013 Transport) — это маршрутизация сообщений ², которая использует таблицы маршрутизации для выбора оптимального пути и группы доставки как точки назначения.

Используя все преимущества маршрутизации на основе данных о топологии Active Directory, нужно не забыть про некоторые ограничения, частично озвученные выше — Транспортная служба почтовых ящиков взаимодействует только с Транспортными службами (на локальных или удаленных серверах), связывается по RPC только с локальными базами данных, но не с БД на других серверах, а также находится в одной и той же группе доставки (называемой локальная) с Транспортной службой, поскольку обе они принадлежат одной роли MBX.

4. Транспортная служба почтовых ящиков также использует агентов транспорта для реализации логики обработки сообщений, но, в отличие от Транспортной службы и Транспортной службы переднего плана, пользователям не предоставлено инструментов (SDK) для создания своих агентов.

Ну а теперь переходим к самому интересному.

Соединители приема и соединители отправки

Просматривая соединители приема, созданные по умолчанию на только что установленном сервере, вы обнаружите, что три соединителя принадлежат роли FrontendTransport, а два — HubTransport (название вероятно досталось по наследству от предыдущих версий Exchange). Это Транспортная служба переднего плана на серверах клиентского доступа и Транспортная служба на серверах почтовых ящиков. Места для Транспортной службы почтовых ящиков среди дефолтных соединителей, к сожалению, не нашлось (на самом деле оно и к лучшему, а то и так черт ногу сломит в этих коннекторах:) ).

Принципы работы службы, озвученные в предыдущем разделе выше, на самом деле прямо намекают на существование как минимум одного соединителя приема (от Транспортных служб на локальном и/или удаленных серверах) и одного соединителя отправки (в Транспортную службу на локальном и/или удаленных серверах). Это можно и заметить и из иллюстрации.

Действительно, так оно и есть, служба имеет по одному системному соединителю приема и соединителю отправки:

• Mailbox Proxy Send Connector (SMTP 25/2525 в Транспортную службу на других серверах почтовых ящиков);
• Default Mailbox Delivery <Server Name> (SMTP 475 от Транспортной службы на других серверах почтовых ящиков).

Кстати, первый соединитель в русскоязычной версии Exchange 2013 будет иметь название Соединитель отправки прокси почтовых ящиков, а второй на русскоязычных серверах почему-то все также имеет английское название, но пишется совместно с именем сервера, например вот так: EXCH02\Default Mailbox Delivery EXCH02.

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

Сведем полученные данные в таблицу:

Название	Назначение	Порт	Направление
Mailbox Proxy Send Connector	Отправка	25/2525	К Транспортной службе на локальном или удаленных серверах почтовых ящиков
Default Mailbox Delivery <Server Name>	Прием	475	От Транспортной службы на локальном или удаленных серверах почтовых ящиков

Имея всю необходимую информацию, попробуем изобразить все на иллюстрации:

С окончанием этой статьи вы знаете как функционируют все три ключевые службы транспортного конвейера Exchange 2013:

• Транспортная служба переднего плана — Служба Exchange 2013 FrontEnd Transport;
• Транспортная служба — Служба Exchange 2013 Transport;
• Транспортная служба почтовых ящиков (если кто-то не понял, то в этой статье я рассказывал именно о ней);

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

comments powered by HyperComments