Все статьи

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

Архитектура Exchange 2013

В сравнении с версиями 2010 и 2007, в Exchange 2013 появились серьёзные изменения архитектурного характера. Некоторые из этих изменений влияют исключительно на внутреннюю маршрутизацию почты, но есть и такие, которые оказывают влияние на процесс доставки сообщений. Для понимания работы механизмов доставки сообщений в Exchange 2013 важно понимать, как устроена система.

Серверные роли в Exchange 2013

Для понимания того, как происходит маршрутизация сообщений в новой архитектуре Exchange 2013, необходимо понимание того, как устроены серверные роли в новой архитектуре. Как мы уже говорили, в Exchange 2013 произошли серьезные архитектурные изменения, коснувшиеся в том числе и ролей серверов. Вместо пяти ролей сервера, реализованными в Exchange 2007 и 2010, в редакции 2013 количество серверных ролей сократилось до двух. Оставшиеся серверные роли включают роль сервера клиентского доступа и сервера почтовых ящиков. Важно отметить отсутствие в последней версии Exchange такой важной роли, как роль центрального транспортного сервера Hub Transport. Эта роль была упразднена, а её функции распределены между ролями сервера клиентского доступа и почтовых ящиков. Итак, вот полный список ролей, доступных в Exchange 2013:

• Сервер почтовых ящиков (Mailbox role) 
  
  Данная роль отвечает за все виды действий с активными почтовыми ящиками на сервере, и включает в себя следующие компоненты: Сервер почтовых ящиков содержит все обычные серверные компоненты Exchange 2010:
  • Протоколы клиентского доступа (Client Access protocols)
  • Cлужба транспорта (Hub Transport service)
  • Базы данных почтовых ящиков (Mailbox databases)
  • Единая система обмена сообщениями (Unified Messaging)
    
    
• Сервер клиентского доступа (Client Access role)
  
  Сервер клиентского доступа обеспечивает проверку подлинности и перенаправления сообщений, обеспечивает поддержку функций прокси-сервера и поддерживает протоколы клиентского доступа HTTP, POP, IMAP, SMTP. В редакции 2013, данная роль предполагает исполнение на тонком клиенте. Важно отметить, что роль сервера клиентского доступа не сохраняет данных о состоянии или сеансе, не поддерживает очередей и не хранит сообщений; в дальнейшем мы увидим, как это влияет на доставку сообщений. Сервер клиентского доступа поддерживает следующие протоколы:
  • HTTP (ActiveSync, Outlook Anywhere, Web Services)
  • IMAP
  • POP and SMTP

Чего нет в Exchange 2013

В результате изменений в архитектуре Exchange 2013 многие вещи стали недоступны, встроены или переопределены. Упразднены многие серверные роли – в частности, имевшая ранее важное значение роль Hub Transport. Рассмотрим, что исчезло из Exchange 2013.

Сервисы MAPI

Exchange 2013 более не поддерживает выделенный сервис MAPI. В данной редакции Exchange Server, соединения MAPI инкапсулированы в обёртку RPC-over-HTTPS, что позволяет внешним Интернет-клиентам получать безопасный доступ к Microsoft Exchange Server без необходимости предварительной авторизации в VPN.

Edge Server

В версии Exchange 2013 Microsoft не поставляет роль пограничного транспортного сервера Edge Server. Отдельной сущности Edge Server в Exchange 2013 более не существует, а предоставляемые им сервисы теперь обеспечиваются сервером клиентского доступа. В документации Microsoft отмечается, что при насущной необходимости Exchange 2013 будет работать с ролью Edge Server из состава Exchange 2007 или 2010.

Другие архитектурные изменения

Изменения в архитектуре Exchange 2013 привели к ряду важных последствий. Упразднены многие роли сервера – в Exchange 2013 их осталось всего две. Новые роли разделены таким образом, чтобы резко упростить внедрение в масштабе предприятия. Оставшиеся роли сервера не имеют тесной связи между собой. Сервер почтовых ящиков теперь выполняет все виды нагрузки, связанные с обработкой активных почтовых ящиков, а сервер клиентского доступа отвечает за авторизацию и перенаправление клиентов, а также выполняет роль прокси. Новое распределение ролей весьма логично, т.к. активная копия почтовой базы физически расположена на почтовом сервере. Передача ответственности почтовых ящиков соответствующей серверной роли обеспечивает полный цикл обработки данных в локальной копии почтовой базы данных, что в свою очередь уменьшает количество взаимодействий между сервером почтовых ящиков и сервером клиентского доступа.

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

Транспортный конвейер (Transport Pipeline)

Новая архитектура всего с двумя ролями значительное повлияла на транспортный процесс. Сообщения в Exchange 2013 передаются через транспортный конвейер. Весь входящий SMTP трафик обслуживается новой службой Front End Transport. В текущей редакции Exchange транспортный конвейер состоит из следующих частей:

• Служба Front End Transport

  Служба Front End Transport принадлежит роли сервера клиентского доступа и обслуживает весь внешний трафик SMTP. Данная служба исполняется на сервере клиентского доступа. Служба Front End Transport не сохраняет данных о состоянии или сеансе, исполняя роль прокси для всех входящих и исходящих соединений. Служба Front End Transport обладает следующими свойствами:

  • Служба не анализирует содержимое отправлений и не фильтрует информацию;
  • Данная служба обменивается информацией только с транспортной службой (Transport) на сервере почтовых ящиков;
  • У службы Front End Transport нет постоянной очереди сообщений.
    
    
• Транспортная служба (Transport service)

  Служба Transport выполняется на всех серверах почтовых ящиков. Эта служба используется в Exchange 2013 вместо серверной роли центрального транспортного сервиса Hub Transport, которая была удалена в редакции Exchange 2013. Транспортная служба Transport обрабатывает весь входящий и исходящий трафик SMTP. Транспортная служба Transport обладает следующими свойствами:

  • Данная служба проводит категоризацию сообщений и анализирует их содержимое;
  • Транспортная служба не обменивается информацией с базами данных почтовых ящиков напрямую. Этот функционал возложен на транспортную службу почтовых ящиков Mailbox Transport. Транспортная служба Transport маршрутизирует сообщения между службой Mailbox Transport, транспортной службой Transport, и новой службой Front End Transport;
  • Транспортная служба также не имеет постоянной очереди сообщений.
    
    
• Транспортная служба почтовых ящиков (Mailbox Transport service)

  Служба Mailbox Transport выполняется на всех серверах почтовых ящиков. Данная служба состоит из двух самостоятельных служб:

  • Транспортная служба доставки почтовых ящиков (Mailbox Transport Delivery) принимает сообщения SMTP от транспортной службы Transport на локальный сервер почтовых ящиков или другие серверы почтовых ящиков, и доставляет сообщение через соединение с локальной базой данных почтовых ящиков по протоколу Exchange remote procedure call (RPC);
    
    
  • Служба Mailbox Transport Submission извлекает почтовые сообщения из базы данных почтовых ящиков и предоставляет их для обработки в службу Mailbox Transport. Данная служба не обладает локальной очередью сообщений.

Как мы упоминали ранее, в состав Exchange 2013 более не входит пограничный транспортный сервер Edge Server. Соответственно, внешние сообщения могут обрабатываться одним из следующих способов:

• С использованием сервера клиентского доступа Exchange 2013 (по умолчанию);
• С использованием Edge Server из состава Exchange 2007 или 2010;
• С использованием стороннего почтового шлюза.

Очевидно, по умолчанию предлагается использовать сервер клиентского доступа. В таком сценарии внешние почтовые сообщения будут приняты коннектором получения (Receive) службы Front End Transport, после чего будут маршрутизированы транспортной службе Transport на сервере почтовых ящиков.

В отличие от Exchange 2010 и 2007, Exchange 2013 способен принимать сообщения из Интернет в стандартной конфигурации. Сервер клиентского доступа поставляется с уже настроенным коннектором получения (Receive Connector), что и позволяет принимать сообщения из-за пределов локальной сети. Коннектор Receive по умолчанию назван “Default Frontend <название_сервера>”, и способен обрабатывать анонимные соединения (разрешён доступ анонимным пользователям “Anonymous Users”):

Сообщение может попасть в транспортную службу Transport на сервере почтовых ящиков одним из следующих четырёх способов:

1. Через коннектор получения Receive;
2. Посредством каталогов Pickup и Replay;
3. Через транспортную службу почтовых ящиков Mailbox Transport;
4. Через представление агентом.

Собственно транспортная служба Transport состоит из следующих процессов и компонент:

• Приёмный коннектор SMTP (SMTP Receive): этот коннектор обрабатывает сообщения, полученные транспортной службой Transport. При получении email-сообщения коннектор SMTP Receive проводит инспекцию содержимого, применяет правила транспортировки и проводит проверку на наличие спама и вирусов (если таковая включена). Если сообщение не было блокировано коннектором SMTP Receive, оно попадает в очередь отправки (Submission queue).
  
  
• Отправка – это процесс добавления сообщения в очередь отправки (Submission queue). Существует три способа, которыми сообщение может попасть в очередь отправки:
  • Через коннектор SMTP Receive;
  • Посредством каталогов Pickup и Replay (которые теперь находятся на серверах почтовых ящиков);
  • Посредством агента.
    
    
• Категоризатор (Categorizer) последовательно обрабатывает сообщения из очереди отправки (Submission queue). Процесс состоит из следующих шагов:
  • Определение получателя: на данном шаге анализируется email-адрес получателя и определяется, является ли получатель внутренним (обладателем почтового ящика в данной организации Exchange) или внешним;
  • Определение маршрутизации: на этом шаге определяется конечный пункт назначения сообщения; определяется маршрут до пункта назначения и следующий шаг доставки;
  • Преобразование контента: на этом шаге производится преобразование сообщения в формат, поддерживаемый получателем. Примеры таких преобразований – конверсия кодировок MAPI в MIME, UUENCODE в base64 и т.д. Кроме того, содержимое может быть сконвертировано в выбранный формат представления – к примеру, HTML, RTF или простой текст. 
    
    
• Правила маршрутизации (Mail flow rules) применяются после того, как отработает категоризатор; сообщения добавляются в соответствующую очередь доставки. Та или иная очередь доставки выбирается в зависимости от пункта назначения сообщения. Пунктом назначения может служить локальная база данных почтовых ящиков, DAG (Database Availability Group), сайт Active Directory [AD], AD forest или внешний домен.
  
  
• Отправка SMTP (SMTP Send) направляет сообщения в зависимости от местоположения получателя. Сообщение может быть направлено:
  • Транспортной службе почтового ящика Mailbox Transport на том же сервере почтовых ящиков;
  • Транспортной службе почтового ящика Mailbox Transport на другом сервере почтовых ящиков, который принадлежит той же DAG;
  • Транспортной службе Transport на сервере почтового ящика, принадлежащего другой DAG, сайту Active Directory или AD forest ;
  • Транспортной службе Front End Transport на сервере клиентского доступа, если получатель сообщения – адрес в Интернет.

На приведённой ниже схеме показаны компоненты Exchange 2013 и их взаимосвязи:

Транспортные агенты

Роль транспортных агентов не изменилась с предыдущей редакции Exchange. Транспортные агенты – это пользовательские расширения для обработки сообщений, проходящих через транспортный конвейер.

Организации могут создавать собственные агенты или использовать готовые транспортные агенты из состава поставки Microsoft Exchange. Кроме того, на рынке доступно множество агентов, разработанных сторонними компаниями.

Частный случай применения транспортных агентов – перехват сообщений, полученных по протоколу SMTP, и их конвертация в простой текст. Другой пример – обработка сообщений с целью удаления вложений или добавления обязательной корпоративной подписи. Важно отметить, что транспортные агенты имеют полный доступ ко всем сообщениям, поступающим к ним в обработку. В Exchange не предусмотрено внутренних защитных механизмов или «песочницы»; в результате действия транспортных агентов никак не контролируются и не ограничиваются. Соответственно, ошибки в коде транспортного агента могут привести к нарушению работы всего почтового конвейера. По этой же причине не рекомендуется использование агентов из непроверенных источников и с точки зрения информационной безопасности. В то же время транспортные агенты, полученные из надёжных источников могут принести немалую пользу.

В Exchange 2013 доступно несколько типов транспортных агентов: SmtpReceiveAgent (агент получения), RoutingAgent (агент маршрутизации) и DeliveryAgent (агент доставки). В состав пакета Exchange 2013 входит несколько встроенных транспортных агентов. Большинство встроенных агентов невидимы и недоступны из пользовательского интерфейса. Только небольшую часть транспортных агентов можно увидеть, выполнив команду Get-TransportAgent:

Маршрутизация и категоризация сообщений (Mail Routing and Categorization)

Итак, мы рассмотрели основные изменения в архитектуре Exchange 2013 в сравнении с более ранними версиями. Рассмотрим теперь, как в Exchange 2013 реализованы механизмы маршрутизации и категоризации почты. Эта глава в основном теоретическая; в ней будет много текста и почти не будет иллюстраций. Знакомство с теоретическими основами маршрутизации в Exchange 2013 важно для правильного понимания того, как входящее сообщение достигает конечной точки назначения. Если для вас больший интерес представляет практика, вы можете пропустить эту главу и перейти к следующей части, в которой будет отслежен маршрут почтового отправления через все службы и механизмы Exchange.

Маршрутизация сообщений (Message Routing)

Направление сообщения к месту назначения осуществляется транспортной службой Transport, которая выполняется на всех серверах почтовых ящиков. Решение о том, каким образом будет проложен маршрут для каждого конкретного сообщения, принимается в результате категоризации. Категоризация – важная часть транспортной службы. В процессе категоризации обрабатывается вся входящая почта и определяются действия по доставке в зависимости от точки назначения сообщения. В первой главе мы описали архитектурные изменения в Exchange 2013. В результате этих изменений транспортная служба физически расположена непосредственно на серверах почтовых ящиков, что позволило улучшить процесс маршрутизации. В результате архитектурных изменений процесс маршрутизации получает всю информацию о группах Database Availability Group (DAG). Членство в группе DAG используется в качестве границы маршрутизации.

Что это означает на практике? Использование сайта Active Directory в качестве первичной границы маршрутизации неэффективно при распространении группы DAG на множество сайтов Active Directory. Соответственно, если почтовый ящик принадлежит какой-либо группе DAG, маршрутизация сообщений становится тесно связанной с данной группой. 

Разумеется, если сервер почтовых ящиков не принадлежит ни к одной группе DAG, Exchange 2013 продолжает использовать членство в сайте Active Directory в качестве границы маршрутизации. В этом случае поведение Exchange 2013 не будет отличаться от поведения предыдущих версий.

Сам процесс маршрутизации претерпел существенные изменения в версии Exchange 2013. На рисунке ниже показана работа транспортного конвейера в Exchange 2013:

• В Exchange 2013 отсутствует прямой обмен информацией между транспортной службой Transport и базой данных почтовых ящиков. Вместо этого транспортная служба Transport устанавливает соединение со службой Mailbox Transport, которая в свою очередь связывается с базой данных почтовых ящиков на локальном сервере почтовых ящиков. В случае, если сервер почтовых ящиков принадлежит к группе DAG, принять сообщение для получателя, находящегося в данной конечной точке, может только транспортная служба почтовых ящиков Mailbox Transport на сервере почтовых ящиков, на котором расположена активная копия базы данных почтовых ящиков;
• Удалённые вызовы Remote Procedure Call (RPC) более не используются в целях коммуникации между серверами. Вызовы RPC используются исключительно транспортной службой почтовых ящиков Mailbox Transport при приёме или отправке сообщений в локальную базу данных почтовых ящиков или из неё. Протокол SMTP используется для коммуникации между транспортной службой почтовых ящиков Mailbox Transport и транспортной службой Transport на различных серверах почтовых ящиков;
• На удалённом сайте Active Directory единая для всех направлений очередь сообщений отсутствует. Вместо единой очереди в Exchange 2013 используются раздельные очереди сообщений для каждого пункта назначения в данном сайте Active Directory;
• Связанные коннекторы (к примеру, коннектор получения Receive, связанный с коннектором отправки Send) более не поддерживаются.

Категоризация (Categorization)

Все сообщения, полученные транспортной службой Transport, должны в обязательном порядке пройти категоризацию. Это необходимо для корректной маршрутизации до конечного пункта назначения. В процессе категоризации в первую очередь определяется адресат. Конечный пункт назначения сообщения определяется только после того, как будет определён адресат. Наконец, после определения пункта назначения Exchange вычисляет маршрут, по которому сообщение должно будет проследовать для доставки конечному получателю. Маршрутный пункт назначения определяется следующим образом: 

• База данных почтовых ящиков (mailbox database): данный маршрутный пункт назначения - это все адресаты, имеющие почтовые ящики в пределах организации, обслуживаемой Exchange. Обратите внимание: в Exchange 2013 общие папки рассматриваются в качестве разновидности почтовых ящиков. Соответственно, маршрутизация сообщений адресатам в общих папках не имеет отличий от маршрутизации получателям, имеющим почтовые ящики.
  
  
• Коннектор (Connector): для сообщений SMTP в качестве маршрутного пункта назначения используется коннектор отправки Send. Для сообщений, отправленных не по протоколу SMTP, в качестве пункта назначения используется или коннектор агента доставки Delivery Agent, или внешний коннектор Foreign. 
  
  
• Сервер расширения групп рассылки (Distribution Group expansion server) используется в качестве маршрутного пункта назначения, если группа рассылки имеет выделенный сервер расширения, ответственный за расширение списка членов группы.

В Exchange 2013 введено новое понятие группы доставки - Delivery Group. В архитектуре Exchange 2013, каждому пункт назначения маршрутизации соответствует один или несколько транспортных серверов. Роль транспортного сервера может выполнять или сервер почтовых ящиков Exchange, или транспортный сервер Exchange 2010 Hub Transport. Эти транспортные серверы получили названия групп доставки - Delivery Group. Группы доставки несут ответственность за маршрутизацию сообщения до конечной точки назначения.

Процесс усложняет ещё и тот факт, в группе доставки могут сосуществовать транспортные серверы разных версий. Если маршрутный пункт назначения – база данных почтовых ящиков, то версия транспортного сервера в группе доставки будет совпадать с версией Exchange в базе данных почтовых ящиков. Если же маршрутный пункт назначения – коннектор или сервер расширения группы рассылки, то группа доставки может состоять из множества серверов почтовых ящиков Exchange 2013 и транспортных серверов Exchange 2010 Hub Transport.

В Exchange 2013 определено пять типов групп доставки:

• Маршрутизируемая группа DAG (Routable DAG): множество серверов почтовых ящиков, принадлежащих к группе DAG. Данная группа доставки обслуживает базы данных почтовых ящиков в группе в качестве маршрутного пункта назначения. После того, как сообщение прибывает в транспортную службу Transport на сервере почтовых ящиков, принадлежащем группе DAG, транспортная служба Transport маршрутизирует сообщение транспортной службе почтовых ящиков Mailbox Transport, находящейся на сервере почтовых ящиков в группе DAG, на котором расположена активная копия базы данных почтовых ящиков пункта назначения. После этого сообщение доставляется в локальную базу данных почтовых ящиков транспортной службой почтовых ящиков Mailbox Transport на сервере почтовых ящиков пункта назначения. Обратите внимание, что группа DAG определяет границу группы доставки даже тогда, когда группа DAG содержит серверы почтовых ящиков, расположенные в разных сайтах Active Directory; 
  
  
• Группа доставки почтового ящика (Mailbox delivery group): множество серверов Exchange одной версии, находящихся в единственном сайте Active Directory. В данном случае граница доставки определяется сайтом Active Directory. Базы данных почтовых ящиков, расположенные на серверах почтовых ящиков Exchange 2010, обслуживаются транспортными серверами Exchange 2010 Hub Transport, расположенными в сайте Active Directory. В то же время базы данных почтовых ящиков, расположенных на серверах почтовых ящиков Exchange 2013 в сайте Active Directory, не принадлежащем группе DAG, обслуживаются транспортной службой Transport на серверах почтовых ящиков Exchange 2013 в сайте Active Directory.
  
  Между Exchange 2010 и 2013 есть существенные различия в способе, которым сообщения доставляются в базу данных почтовых ящиков:
  • Exchange 2010: в этой версии Exchange сообщение может прийти на любой транспортный сервер Exchange 2010 Hub Transport в целевом сайте Active Directory. Драйвер, отвечающий за сохранение сообщений на транспортном сервере, использует вызовы RPC для записи сообщения в целевую базу данных почтовых ящиков;
  • Exchange 2013: сообщение приходит на целевой сервер почтовых ящиков в сайте Active Directory. Транспортная служба Transport использует SMTP для доставки сообщения транспортной службе почтовых ящиков Mailbox Transport, которая и осуществляет доставку сообщения в локальную базу данных почтовых ящиков через RPC. 
    
    
• Исходные серверы коннектора (Connector source servers): гетерогенное множество транспортных серверов Exchange 2010 Hub Transport или серверов почтовых ящиков Exchange 2013, с точки зрения коннектора отправки Send рассматриваемое в качестве исходного сервера; коннектор агента доставки  Delivery Agent либо внешний коннектор Foreign. Коннектор является маршрутным пунктом назначения, обслуживаемым данной группой маршрутизации. В случае, если коннектор находится в области конкретного сервера, только этому серверу разрешено производить маршрутизацию сообщений к пункту назначения, определённому коннектором. Данная группа доставки может иметь в своём составе транспортные серверы Exchange 2010 Hub Transport или серверы почтовых ящиков Exchange 2013, расположенные в разных сайтах Active Directory; 
  
  
• Сайт Active Directory (Active Directory site): иногда сайт Active Directory не является конечным пунктом назначения сообщения. В этом случае перед тем, как достигнуть конечного пункта назначения, сообщение должно пройти через транспортный сервер Exchange 2010 Hub Transport либо сервер почтовых ящиков Exchange 2013, расположенный в данном сайте Active Directory;
  
  
• Список серверов (Server list): множество из одного или нескольких транспортных серверов Exchange 2010 Hub Transport или серверов почтовых ящиков Exchange 2013, сконфигурированных в качестве серверов расширения группы рассылки. В данном случае, маршрутным пунктом назначения, обслуживаемым данной группой, будет являться сервер расширения группы рассылки.

Членство в группе доставки не является эксклюзивным. К примеру, сервер почтовых ящиков Exchange 2013 может одновременно являться членом группы DAG и в то же время выполнять роль исходного сервера при коннекторе отправки Send. С точки зрения баз данных почтовых ящиков в группе DAG, данный сервер почтовых ящиков принадлежит к маршрутизируемой группе доставки DAG. В то же время с точки зрения коннектора отправки Send, тот же сервер служит коннектором группы доставки исходного сервера.

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

1. Наиболее эффективным маршрутом считается маршрут с наименьшей стоимостью. Стоимость маршрута доставки вычисляется суммированием стоимости IP-связей сайтов, через которые должно будет пройти сообщение на пути к конечному пункту назначения. Если получателем является коннектор, система вычисляет сумму стоимостей, назначенных адресному пространству и стоимости достижения выбранного коннектора. При наличии более чем одного маршрута, выбирается маршрут с наименьшей общей стоимостью;
2. При наличии нескольких маршрутов с одинаковой стоимостью, будет выбран самый короткий маршрут (с наименьшим количеством узлов);
3. Если число доступных маршрутов всё ещё более одного, Exchange 2013 отдаст приоритет маршруту по названию ближайшего к пункту назначения сайта Active Directory. Предпочтение будет отдано сайту Active Directory, название которого ближе к началу алфавита. Если ближайший к пункту назначения сайт Active Directory один и тот же для всех маршрутов, система рассмотрит названия предыдущих сайтов.

Отслеживаем маршрут сообщения

Новая архитектура Exchange 2013 с двумя серверными ролями оказала значительное влияние на транспортный процесс. Попробуем проследить весь маршрут сообщения, полученного системой Exchange с момента получения и до момента доставки в конечный пункт назначения. В этой части статьи мы рассмотрим работу транспортной службы Front End Transport и транспортной службы почтовых ящиков Mailbox Transport. В заключительной части статьи мы рассмотрим функционирование очередей.

Маршрутизация сообщений службой Front End Transport

Новая транспортная служба Front End Transport отвечает за приём и отправку внешних сообщений по протоколу SMTP. Служба Front End Transport принимает соединения по протоколу SMTP, выполняет фильтрацию и определяет маршрут к оптимальному серверу почтовых ящиков перед началом процесса доставки.  

Служба Front End Transport всегда располагается на сервере клиентского доступа, и именно она играет роль централизованной точки входа и выхода для всего SMTP-трафика организации. Служба Front End Transport не сохраняет данных о состоянии или сессии. Эта служба принципиально отличается подходом к приему и доставке сообщений: в ней нет постоянных транспортных очередей. Соответственно, Front End Transport представляет собой исключительно SMTP прокси. В свою очередь, это означает, что если служба Front End Transport не может подключиться к серверу почтовых ящиков или если сервер не способен принять сообщение, то отправителю сразу же возвращается код ошибки, означающий необходимость повторить попытку.

Обработка исходящих сообщений осуществляется транспортной службой Transport, выполняющейся на серверах почтовых ящиков. Эта служба обменивается информацией со службой Front End Transport Service через коннекторы отправки Send. Служба Front End Transport выполняет роль прокси для исходящих сообщений при условии, что параметр FrontEndProxyEnabled соответствующего коннектора Send в управляющей оболочке Exchange Management Shell установлен в значение $True, либо если выбран параметр “Proxy through client access server” в административном центре Exchange Administration Center: 

Как мы знаем, в Exchange 2013 в компании Microsoft отказались от роли центрального транспортного сервера Hub Transport. Её функции выполняет в основном служба Mailbox Transport. Это единственная служба, которая поддерживает связь со службой Front End Transport.

Для обработки входящих сообщений служба Front End Transport пытается найти активную транспортную службу Transport на соответствующем сервере почтовых ящиков. Помните, мы говорили о том, что у службы Front End Transport отсутствует транспортная очередь? Этот факт имеет важное значение: если найти активную транспортную службу не удаётся, то служба Front End Transport принимает решение о недоступности почтового сервиса, и попытка доставки сообщения заканчивается сообщением об ошибке.

Корректная база данных почтовых ящиков для каждого получателя определяется опросом Active Directory. Служба Front End Transport осуществляет поиск группы доставки и связанной с ней информации о маршруте по каждой базе данных почтовых ящиков. Роль группы доставки может исполнять Routable DAG, группа доставки почтовых ящиков или сайт Active Directory.

В зависимости от числа и типа получателей, служба Front End Transport производит одно из следующих действий (Таблица 1):

Маршрутизация почтовой транспортной службы Mailbox Transport

Транспортная служба доставки в почтовые ящики Mailbox Transport Delivery доставляет входящие сообщения, принимая почту от транспортной службы Transport по протоколу SMTP. После этого осуществляется соединение с локальной базой данных почтовых ящиков с использованием Remote Procedure Call (RPC).

Исходящие сообщения изымаются из локальной базы данных почтовых ящиков по протоколу RPC службой транспортной службой Mailbox Transport Delivery, после чего сообщения передаются транспортной службе Transport по протоколу SMTP.

Служба Mailbox Transport не сохраняет данных о сессии или состоянии и не поддерживает транспортной очереди.

Что же произойдёт, когда пользователь отправит сообщение? В первую очередь будут определены базы данных почтовых ящиков, соответствующие каждому получателю. Эта работа выполняется службой Mailbox Transport Submission путём опроса Active Directory. Информация о маршруте извлекается путём поиска группы доставки для каждой базы данных почтовых ящиков. Группой доставки может служить Routable DAG, группа доставки почтовых ящиков или сайт Active Directory.

В зависимости от количества и типа получателей, служба Mailbox Transport Submission выполнит одно из действий, описанных в Таблице 1.

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

Если получатель не находится в активной копии локальной базы данных почтовых ящиков, служба Mailbox Transport Delivery отклоняет сообщение с генерацией соответствующего сообщения об ошибке доставки сообщения, которое и передаётся транспортной службе Transport. Именно так и происходит в случаях, когда активная копия базы данных почтовых ящиков была недавно перемещена на другой сервер, а сообщение было неправильно маршрутизировано транспортной службой Transport на сервер почтовых ящиков, содержащий неактивную копию базы данных почтовых ящиков.

Если такое происходит, служба Mailbox Transport Delivery может сгенерировать один из следующих кодов ошибки:

• Повторить попытку доставки;
• Создать отчёт о невозможности доставки;
• Использовать альтернативный маршрут;

Отслеживание транспортных потоков

Для понимания того, как устроен транспортный поток в Exchange 2013, необходимо обратить внимание на то, как службы Front End Transport и Mailbox Transport маршрутизируют сообщения. Проще всего понять, как работает транспортный поток, можно на примере конкретного сообщения. Давайте проследим, как именно почтовое сообщение проходит через транспортные службы Exchange 2013.

Так же, как и в предыдущих версиях Exchange, в Exchange 2013 создаются отчёты о доставке, которые можно использовать для отслеживания входящих и исходящих сообщений. Обратите внимание, что таким образом можно отслеживать только сообщения, отправленные с использованием Outlook или Outlook Web App, но не через POP или IMAP.

Однако в Exchange 2013 появился более интересный механизм, позволяющий проследить путь сообщения через журнал отслеживания доставки - Message Tracking Logs. Как мы уже обсуждали, в Exchange 2013 роль центрального транспортного сервера Hub Transport была удалена, а ее функции разделены между ролями сервера клиентского доступа и почтовых ящиков. Соответственно, роль командлета TransportServer теперь выполняют два новых командлета:

• Командлет Get-TransportService возвращает информацию о конфигурации транспорта для транспортной службы Transport на серверах почтовых ящиков либо для серверов Edge Transport;
• Командлет Get-MailboxTransportService возвращает информацию о конфигурации транспорта для транспортной службы почтовых ящиков Mailbox Transport на серверах почтовых ящиков.

Итак, давайте отследим путь сообщения, отправленного локальным пользователем Test1 с почтовым ящиком на сервере MBX1 локальному пользователю Test2 с почтовым ящиком на сервере MBX2. Для того, чтобы получить информацию о данном конкретном сообщении, можно использовать любой из двух описанных выше командлетов. Для примера используем первый из них:

Get-TransportService | Get-MessageTrackingLog –ResultSize Unlimited –Start “01/09/2013” –Sender test1@e2013.advsoft.info -Recipients test2@e2013.advsoft.info –MessageSubject “Mail flow example” | Sort TimeStamp | Select ClientHostname, ServerHostname, ConnectorId, Source, EventId

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

1. Служба Mailbox Transport Submission использует Store Driver для соединения с базой данных почтовых ящиков по протоколу RPC, и извлекает сообщение:
   ClientHostname : MBX1.e2013.advsoft.info
   ServerHostname :
   MBX1 ConnectorId :
   Source : STOREDRIVER
   EventId : RECEIVE
   
   
2. После того, как по имени получателя сообщения будут получены данные о соответствующей ему базе данных почтовых ящиков, служба Mailbox Transport Submission осуществляет поиск группы доставки. В нашем тестовом сценарии такой группой доставки является группа доставки почтового ящика. В результате драйвер Store Driver передаёт сообщение на концентратор селектора Hub Selector. После этого сообщение будет отправлено на соответствующий сервер по протоколу SMTP.
   
   Обратите внимание, что в нашем тестовом сценарии сообщение не проходило через транспортную службу Transport. Это легко проверить, остановив службу Microsoft Exchange Transport на исходном сервере почтовых ящиков и повторив тестовый сценарий. Сообщение будет отправлено даже с остановленной транспортной службой Transport:
   
   ClientHostname : MBX1
   ServerHostname : MBX2.e2013.advsoft.info 
   ConnectorId :
   Source : STOREDRIVER
   EventId : SUBMIT
   
   
3. Далее сообщение принимается транспортной службой Transport на сервере почтовых ящиков MBX2. Сообщение отправляется службой Mailbox Transport Submission сервера MBX1 с использованием коннектора по умолчанию. Для отправки используется протокол SMTP. Именно в этот момент производится анализ и фильтрация содержимого сообщения. Транспортная служба Transport на сервере почтовых ящиков MBX2 инспектирует содержимое сообщения, применяет правила транспортировки и проверяет сообщение на предмет спама и вирусов (если такая проверка включена). Если сообщение успешно проходит все проверки, оно будет добавлено в очередь отправки Submission Queue:
   
   ClientHostname : MBX1.e2013.advsoft.info 
   ServerHostname : MBX2
   ConnectorId : MBX2\Default MBX2
   Source : SMTP
   EventId : RECEIVE
   
   
4. Категоризатор осуществляет выборку сообщения из очереди отправки Submission Queue. Сообщение обрабатывается категоризатором, после чего добавляется в очередь доставки. Та или иная очередь доставки выбирается на основании пункта назначения сообщения. В нашем тестовом сценарии пунктом назначения является база данных почтовых ящиков:
   
   ClientHostname : MBX2
   ServerHostname :
   ConnectorId :
   Source :
   AGENT
   EventId : AGENTINFO
   
   
5. Транспортная служба Transport отправляет сообщение транспортной службе доставки в почтовые ящики Mailbox Transport Delivery по протоколу SMTP:
   
   ClientHostname : MBX2
   ServerHostname : MBX2.e2013.advsoft.info 
   ConnectorId : Intra-Organization SMTP Send Connector
   Source : SMTP
   EventId : SEND
   
   
6. Служба Mailbox Transport Delivery получает сообщение:
   
   MBX2.e2013.advsoft.info 
   ServerHostname : MBX2
   ConnectorId : MBX2\Default Mailbox Delivery MBX2
   Source : SMTP
   EventId : RECEIVE
   
   
7. Служба Mailbox Transport Delivery устанавливает соединение с базой данных почтовых ящиков, используя Store Driver через RPC. Сообщение записывается в базу данных почтовых ящиков:
   
   ClientHostname : MBX2
   ServerHostname : MBX2
   ConnectorId :
   Source : STOREDRIVER
   EventId : DELIVER

В результате получается следующая схема:

Транспортные очереди

Наконец, пришло время поговорить о транспортных очередях. Как мы помним, в архитектуре Exchange 2013 произошли важные архитектурные изменения в сравнении с предыдущими версиями продукта. В серверах Edge Server, использующихся в Exchange 2007 и 2010, присутствовала транспортная очередь сообщений. В Exchange 2013 нет ни серверов Edge Server, ни транспортных очередей в большинстве служб, ответственных за доставку сообщений. Из трёх служб, несущих транспортную нагрузку, транспортная очередь присутствует только в транспортной службе Transport. Службы Front End Transport и Mailbox Transport собственных очередей не имеют.

Такая архитектура ведёт к важным последствиям в процессе доставки сообщений. При использовании сервера клиентского доступа в качестве основного почтового шлюза необходимо чётко понимать, что при отсутствии или недоступности сервера почтовых ящиков, способного принять сообщение, отправитель мгновенно получит сообщение об ошибке. Для обычной переписки эта особенность не представляет особой проблемы, т.к. большинство почтовых серверов осуществляет несколько попыток доставки в течение 24, 48 или 72-часового периода. Проблемы начинаются при использовании других устройств и приложений.

Если у вас есть нестандартный коннектор получения Receive Connector для приложений, принтеров или других устройств, принадлежащих организации Exchange 2013, то этот коннектор лучше создавать на серверах почтовых ящиков вместо серверов клиентского доступа именно по этой причине.

Заключение

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

Глоссарий

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

Mailbox Server – сервер почтовых ящиков
Client Access Server – сервер клиентского доступа
Edge Server - пограничный транспортный сервер
Transport Pipeline – транспортный конвейер
Hub Transport - центральный транспортный сервис

Теги: Exchange Server