А ми повертаємося до основної теми статті.
Процес створення з'єднувача відправки через веб-інтерфейс виглядає досить просто. У мінімальній конфігурації поштової інфраструктури - єдиний поштовий сервер, безпосередньо приймає підключення з інтернету - настройка коннектора впирається в наступні кроки:
Задаємо ім'я з'єднувача і вказуємо його тип. Оскільки наша інфраструктура являє собою найпростіший варіант з єдиним сервером, досить вибрати тип з'єднувача «Настроюваний» або «Інтернет» (відмінності між ними будуть розглянуті пізніше):
Після цього нам залишається зіставити новий з'єднувач з єдиним наявним у нас на даний момент сервером:
[PS] C: \ Windows \ system32> New-SendConnector -Name «Send Connector 01» -AddressSpaces *
Разом, виконавши цю команду, ви отримаєте цілком робочий коннектор відправки, але є ряд параметрів, до налаштування яких потрібно підійти більш уважно. Для початку варто подбати про повне доменне ім`я (fqdn) сервера, яке буде відправлятися у відповідях на HELO \ EHLO-запити. Якщо ви не вкажете нічого, то отримаєте наступний результат 3:
За замовчуванням функція Fqdn встановлено значення $ null. Це означає, що значення за замовчуванням параметра FQDN - повне доменне ім'я сервера поштових скриньок або прикордонного сервера, що містить з'єднувач відправки.
Чому це потрібно зробити? Справа в тому, що більшість серверів звіряють mx-запис домена, з якого йде лист, із записом, яку повертає сервер-відправник на HELO \ EHLO-запит. Якщо ці записи ідентичні, то все добре, але якщо вони відрізняються, то сервер-одержувач може просто підвищити рейтинг спаму і в кінцевому рахунку лист може не потрапити одержувачу. У мене такі ситуації виникали при роботі з великими enterprise-клієнтами, у яких зазвичай дуже жорсткі політики антиспаму: мої колеги скаржилися, що клієнти не отримують від них листи. Проблема звичайно ж була на моєму боці і я допустив її просто через неуважність (ситуацію ускладнював також той факт, що в продакшені я маю справу з доменом .local, який розуміється не збігається з публічним доменом організації).
можна налаштувати з'єднувач відправки в службі транспорту сервера поштових скриньок для маршрутизації вихідної пошти через інтерфейсний транспортний сервер в локальному сайті Active Directory за допомогою параметра FrontEndProxyEnabled командлет Set-SendConnector. тим самим консолідувавши маршрутизацію електронної пошти зі служби транспорту.
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
Отже, з огляду на сказане вище, повна команда для створення з'єднувача відправки матиме вигляд:
[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
Як ви можете бачити, різниці немає абсолютно ніякої, хіба що в назві. Для чого тоді робити зайвий тип з'єднувача мені не зрозуміло. Можливо різниця в них є на якомусь більш глибокому рівні. Якщо знайду відповідь, обов'язково розпишу в цій статті.