Соединители отправки Exchange 2013 необходимы для возможности отправлять почту внешним получателям. Не создав ни одного соединителя вы сможете обмениваться почтовыми сообщениями только внутри организации среди тех доменов, которые обслуживает непосредственно ваш Exchange 2013.
Вы задумывались для чего Exchange 2013 целых пять дефолтных соединителей получения и ни одного для отправки? Может быть вы также слышали про системные соединители? Узнать об этом вы сможете в статьях по принципам работы транспортных служб Exchange 2013:
А мы возвращаемся к основной теме статьи.
Эта статья является второй из цикла, в котором освещены вопросы обязательных задач по настройке сервера Exchange 2013 сразу после его установки. Если вам интересны другие задачи, рекомендую обратиться к головной статье по настройке – Настройка Exchange 2013 или основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.
Соединители отправки Exchange 2013 для единственного сервера
Процесс создания соединителя отправки через веб-интерфейс выглядит достаточно просто. В минимальной конфигурации почтовой инфраструктуры – единственный почтовый сервер, непосредственно принимающий подключения из интернета – настройка коннектора упирается в следующие шаги:
Зайти через браузер в EAC – https://server-fqdn/ecp – Поток обработки почты\Соединители отправки\Создать (значок “+”)
Задаем имя соединителя и указываем его тип. Поскольку наша инфраструктура представляет собой наипростейший вариант с единственным сервером, достаточно выбрать тип соединителя “Настраиваемый” или “Интернет” (различия между ними будут рассмотрены позже):
Далее необходимо определить будет ли в пересылке почты участвовать промежуточный узел или почта идет получателю сразу с нашего сервера. Промежуточных серверов у нас пока нет, оставляем все как есть:
Указываем адресное пространство, которое будет обслуживать этот соединитель. Поскольку у меня задача отправлять почту любому получателю, нужно нажать “+” и в поле “*Полное доменное имя (FQDN):” просто вписать знак “*” (без кавычек разумеется):
После этого нам остается сопоставить новый соединитель с единственным имеющимся у нас на данный момент сервером:
Коннектор создан.
В официальной документации на Technet есть целый раздел 1, который посвящен настройке почтового сервера после его установки. В этом разделе также есть информация о настройке потока обработки почты 2, в котором рассматриваются также и соединители отправки Exchange 2013. Однако почему-то там нет инструкций по созданию коннектора через Powershell. Тем не менее все же существуют командлеты специально для этой задачи. Более того, создание простого коннектора с параметрами по умолчанию (рассмотрено выше) представляет из себя просто элементарную задачу:
[PS] C:\Windows\system32>New-SendConnector -Name “Send Connector 01” -AddressSpaces *
Итого, выполнив эту команду, вы получите вполне рабочий коннектор отправки, но есть ряд параметров, к настройке которых нужно подойти более внимательно. Для начала стоит позаботиться о полном доменном имени (fqdn) сервера, которое будет отправляться в ответах на HELO\EHLO-запросы. Если вы не укажете ничего, то получите следующий результат 3:
По умолчанию для параметра Fqdn установлено значение $null. Это означает, что значение по умолчанию параметра FQDN — полное доменное имя сервера почтовых ящиков или пограничного сервера, содержащего соединитель отправки.
Страшного в этом ничего нет, к тому же если ваш домен AD совпадает с публичным доменом организации, как в моем случае – зарегистрированный домен bissquit.com, домен AD – corp.bissquit.com. Мой сервер будет по умолчанию возвращать fqdn exch02.corp.bissquit.com. Однако лучше все же указать другой адрес – mx-адрес вашего домена (речь идет о домене, который будет использоваться на вашем Exchange как основной). В моем случае это домен bissquit.com.
Почему это нужно сделать? Дело в том, что большинство серверов сверяют mx-запись домена, с которого идет письмо, с записью, которую возвращает сервер-отправитель на HELO\EHLO-запрос. Если эти записи идентичны, то все хорошо, но если они отличаются, то сервер-получатель может просто повысить рейтинг спама и в конечном счете письмо может не попасть получателю. У меня такие ситуации возникали при работе с крупными enterprise-клиентами, у которых обычно очень жесткие политики антиспама: мои коллеги жаловались, что клиенты не получают от них письма. Проблема конечно же была на моей стороне и я допустил её просто по невнимательности (ситуацию усугублял также тот факт, что в продакшене я имею дело с доменом .local, который разумеется не совпадает с публичным доменом организации).
Также не помешает сделать активным параметр FrontendProxyEnabled (хотя и его значение по умолчанию $False), чтобы маршрутизировать сообщения через сервер клиентского доступа. Этот параметр появился в Exchange 2013 и его активация позволяет “упорядочить” поток почты, хотя и непонятно каким образом это скажется на производительности. На официальных источниках встречается следующая информация 4 5:
можно настроить соединитель отправки в службе транспорта сервера почтовых ящиков для маршрутизации исходящей почты через интерфейсный транспортный сервер в локальном сайте Active Directory посредством параметра FrontEndProxyEnabled командлета Set-SendConnector, тем самым консолидировав маршрутизацию электронной почты из службы транспорта.
На принцип маршрутизации почты проливает свет также статья на блогах Technet 6:
If the message is going to an external recipient it will use the correct send connector and either send directly to internet or proxy through the FET Service (Set-SendConnector <name> -FrontEndProxyEnabled $true)
То есть можно сделать вывод, что без активации этого параметра почта будет направляться транспортной службой напрямую.
Итак, учитывая сказанное выше, полная команда для создания соединителя отправки будет иметь вид:
[PS] C:\Windows\system32>New-SendConnector -Name “Send Connector 01” -AddressSpaces * -Fqdn mail.bissquit.com -FrontendProxyEnabled $true
Теперь рассмотрим различия между типами соединителя – а именно между “Настраиваемый” и “Интернет”, как и обещал в начале статьи. Если создать два коннектора с идентичными настройками, но чтобы один имел тип “Настраиваемый” (Custom), а другой имел тип “Интернет” (Internet) и после этого изучить их свойства через вывод командлета Get-SendConnector 7, то результат будет следующий:
На скриншоте сведены результаты выполнения этих двух команд:
[PS] C:\Windows\system32>Get-SendConnector “Send Connector 01” | Format-List
[PS] C:\Windows\system32>Get-SendConnector “Send Connector 02” | Format-List
Как вы можете видеть, разницы нет абсолютно никакой, разве что в названии. Для чего тогда делать лишний тип соединителя мне не понятно. Возможно разница в них есть на каком-то более глубоком уровне. Если найду ответ, обязательно распишу в этой статье.
Notes:
