top of page

​

HUB.

Управление доставкой сообщений.

Для начала разберемся, какие сценарии отправки и получения почты существуют.

Предположим, что у нас есть сайт в Москве. В нем два сервера: Mailbox (MB) и HUB Transport (HT).

1. Внутри сети. Петя, который находится на MB отправляет письмо Васе, который находится на этом же Mailbox'е. Письмо уходит на HT, т.е. на HUB Transport этого сайта. HUB Transport этого сайта определяет, что письмо предназначено для пользователя, находящегося на этом же сервере и возвращает его на MB.

2. Интернет. HUB Transport доставляет почту на сервера в интернете и получает почту с них.

3. Удаленные офисы. Предположим что есть офис в Ростове, со своим  HUB Transport'ом (HT2) и Mailbox'ом (MB2). Вася, расположенный в MB отправляет письмо Пете, расположенному в MB2. В таком случае, письмо идёт на HT, потом доставляется на HT2, и HT2 доставляет его на MB2.

4. Edge. Если Edge установлен, именно он отвечает за отправку и прием почты из интернета. Т.е. почта идёт не сразу на HUB, а сначала на Edge. Итак, Edge, получив письмо, закидывает его на HUB, а далее все по обычному сценарию. Это Relay.

5. Другая организация. Например у вас есть дружественная организация. Можно настроить, чтобы  HUB мог отправлять почту этой организации.

6. Внешний пользователь. Предположим, есть Вася, который подключен к CAS по POP3. POP3 это протокол получения почты. А доставка осуществляется на HUB по протоколу SMTP. Итого, Вася скачивает почту с CAS по POP3, а когда ему надо отправить почту, он обращается к HUB'у. 

​

На рисунке ниже примерно отображено описанное выше:

​

Рисунок1

Меню изучения Exchange 2010

Обратите внимание. Там, где взаимодействие показано черными стрелками - это SMTP, т.е. 25 порт. Зелеными стрелками - MAPI.

​

HUB transport сервер всегда должен находится в том сайте AD, где есть хотя бы один Mailbox. Точнее сказать, HUB нужен в каждом сайте, где есть Mailbox. Логика простая. Mailbox-серверу нужно отправить почту. Для этого он оповещает HUB о том, что есть почта. Оповестить он может только тот HUB, который находится с ним в одном сайте AD. Например, Московский Mailbox не может оповестить HUB в Ростове. Поэтому если кто-то в Москве отправляет почту, доставить её может только HUB Москвы. Т.е. каждая площадка - отдельный HUB.

​

Теперь давайте разбираться с логикой работы HUB. Итак, HUB отправляет и получает почту. 

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

Представьте, что на HUB'е в Москве нет ни одного коннектора приема. В таком случае, почта будет ходить только между пользователями внутри сайта Москвы, ведь здесь соединения идут по MAPI.

По умолчанию созданы 2 коннектора приема. Как видите на рисунке, на сервере VAN-EX1 есть 2 коннектора.

Рассмотрим коннектор Default.

Вкладка General.

FQDN имя - это имя, которым сервер будет представляться, когда кто-то установит с ним SMTP-сессию.

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

Protocol logging level - вести ли логи SMTP-соединений по этому коннектору. По умолчанию они не ведутся. Если включите, логи можно посмотреть в C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive

Вкладка Network.

В верхней части указано, по каким сетевым интерфейсам и по каким портам мы готовы принимать почту. Как видите, по умолчанию, любой HUB Transport принимает по любому интерфейсу по 25 порту.

В нижней части описано, откуда мы готовы принимать. По рисунку видно, что наш HUB может принимать почту откуда угодно, т.е. полный диапазон IPv4 и IPv6.  

​

Вкладка Permission Groups.

Здесь мы определяем, кто имеет право доставлять нам почту по этому коннектору.

Exchange servers - это другие Exchange серверы, т.е. HUB'ы в нашей организации.

Legacy Exchange servers - это старая версия Exchange, 2003-я.

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

Давайте поставим галку. Пригодится для дальнейших тестов.

На вкладке Authentication перечислены протоколы и механизмы аутентификации, которые будут доступны, если кто-то пытается с нами аутентифицироваться. Есть встроенная Windows аутентификация, есть Exchange Server аутентификация, есть Basic и прочее. Т.е. под любого клиента можно всё подстроить. Естественно, если мы разрешаем доставку анонимным юзерам, то настройка аутентификации не нужна. А вот если нам пытается доставить почту другой HUB-сервер, то уже надо смотреть настройки аутентификации.

​

Переходим к следующему, второму, встроенному коннектору Client.

На вкладке General всё аналогично.

На вкладке Network указан 587 порт. Это SMTP с использованием TLS-шифрования. Например, когда подключается Outlook Express. Поставлялся он с XP. Сейчас можно скачать отдельно и настроить на WIN7 и 8.

В нашей существующей организации коннектор Client нам не нужен. Мы можем его просто выключить.

​

Проверить работоспособность коннекторов мы можем через telnet. Как настроить telnet смотрите здесь. 

Используйте команду telnet имя_сервера(или ip) порт. В нашем случае набираем telnet van-ex1 smtp. На экране видим приветствие. 

Помните, мы говорили про имя FQDN на вкладке General? Вот в этом приветствии оно и фигурирует в самом начале.

Далее набираем EHLO

Набираем mail from: и указываем от имени кого отправляем письмо. Например, bill@microsoft.com. Сервер отвечает OK.

Далее указываем, кому мы пишем письмо. Например, у нас есть ящик mail@tvoydomain.ru. Набираем rcpt to:mail@tvoydomain.ru.

Сервер отвечает Ok. 

Далее вводим команду data. Жмём Enter.

Указываем тему письма subject:temapisma. Жмём Enter.

Набираем текст письма. Жмём Enter, ставим точку (она заканчивает текст) и снова Enter.

Проверяем! Заходим на наш ящик mail@tvoydomain.ru и видим письмо.

​

Чтобы выйти из smtp сессии наберите команду quit.

​

Как убедиться, что это письмо обработал коннектор Default? Просто отключите его и наберите telnet van-ex1 smtp. У вас не получится подключиться.

При выключенных коннекторах вы без проблем можете пользоваться почтой внутри сети. Отправьте сами себе письмо. Всё придет. Работать ведь будет по MAPI. И SMTP тут не причём.

​

Мы рассматривали коннекторы приема. Теперь поговорим о коннекторах отправки. Зайдите в Organization Configuration -> Hub Transport на вкладку Send Connectors. Вы ничего не увидите. Коннекторов отправки по умолчанию нет.

Запомните, внутри организации вам коннекторы отправки не нужны. Даже если у вас много сайтов AD и в каждом сайте у вас стоит Exchange (например HUB, как на рисунке с Москвой и Ростовом), коннекторы отправки для доставки почты внутри организации не нужны. 

​

Давайте посмотрим как почта будет работать внутри организации. Смотрите на рисунок. У нас есть 5 сайтов. В каждом сайте есть Exchange, т.е. CAS, HUB и Mailbox. Сайты соединены сайт-линками, т.е. site link. Нужны они для того, чтобы AD понимала, как у вас построена сеть.  Если вы создаете сайт линк между Москвой и СПБ, AD считает, что между этими филиалами есть канал. Если сайт линк не создан, то AD считает, что канала нет. Т.е. по факту, структура сайтов отражает вашу реальную структуру сети. Можно вообще связать сайты каждый с каждым. Но мы рассматриваем ситуацию, как на картинке.

Цифры - это приоритет канала, типа его цена. Т.е. репликация AD будет идти по каналу с меньшей ценой, т.е. меньшим приоритетом.

А теперь представьте. В каждом филиале у вас Exchange. Вы не создали ни одного коннектора отправки. Есть только коннекторы приема. Как всё это будет работать? Из Source Site Вася отправил письмо Пете в Destination Site. HUB верхнего сайта получает письмо. Он должен определить, если ли пользователь Петя вообще. Он обращается к AD и выясняет что Петя есть. Дальше HUB'у надо понять, где находится Mailbox, в котором находится ящик Пети. Он опять идёт в AD и узнает, что Mailbox находится в другом сайте. HUB-отправитель сначала попытается установить SMTP-соединение по 25-му порту с HUB-получателем и доставить письмо напрямую. Если у вас сеть полностью маршрутизируемая, всё прокатит. Но на рисунке схема иная. Поэтому HUB 

доставить письмо не сможет. Когда произойдёт этот облом, HUB-отправитель решит, что теперь надо отправлять по нормальному. Т.е. надо базироваться на структуре сайтов AD, передавая письмо через промежуточные HUB'ы. Поехали. В первую очередь HUB выбирает наиболее дешевый маршрут. Т.е. тот, где десятки (20 против 40). Если не прокатит, то будет выбран более дорогой. Если маршруты одинаковые по цене, то приоритета нет и HUB выбирает наиболее короткий (т.е. тот, где меньше сайт линков). Если всё одинаковое (и приоритет, и количество сайт линков), то передача будет идти через тот сайт, который начинается с более ранней буквы алфавита. Если первая буква одинаковая, берется вторая и т.д. Двух сайтов с одинаковыми именами быть не может, поэтому результат в итоге будет достигнут.

Итого, на каждом HUB'е при такой структуре должен быть только коннектор приема. И всё будет гуд.

​

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

​

Создадим коннектор отправки.

Вводим любое имя и выбираем тип. Тип предопределяет некоторые настройки. Выберем Custom и настроим всё вручную.

Address space описывает, в каком случае будет выбираться этот коннектор отправки. Например, можно создать отдельный коннектор отправки для компании Microsoft. 

Но мы хотим сделать КО для всего интернета. Нажимаем Add.В поле Address space указываем *

Жмём Ок.

Внизу есть галка Scoped send connector.

Вернемся к самому первому рисунку.

Предположим, что коннектор отправки мы создаем на HUB'е в Москве, т.е. на HT. Вася находящийся в MB2, может передает письмо только своему HT2. Напрямую на HT он передать не может. Это за него будет делать HT2. Итак. Внимание! При отсутствующей галке Scoped send connector, HT2 будет отправлять почту на HT, а он уже отправлять эту почту в интернет. Если же вы поставите галку, то отправлять почту в интернет смогут только те HUB'ы, которые находятся в одном

сайте AD с HT. Т.е. все HUB'ы, которые расположены в сайте Москвы, будут сливать почту на HT, на котором мы создаем коннектор, а он будет отправлять эту почту в интернет. А HT2 в нашем примере будет получать отлуп. 

Галку ставить не будем. Идём дальше.

Определяемся, как отправлять почту.

Можно выбрать MX-записи. Т.е. наш сервер лезет в DNS, берет MX-запись для интересующего домена, разрешает A-запись в IP и т.д.

Либо можно выбрать Route ... smart hosts. Здесь явно указываем IP или имя сервера. Здесь можно прописать Edge или любой другой Relay. 

Если мы выбрали использование MX-записей, возникает вопрос - какой DNS-сервер будет их разрешать. По умолчанию это будет DNS сервер, который указан в свойствах сетевого подключения вашего сервера (основной сервер DNS). Если вы не хотите, чтобы обращение шло к вашему основному DNS, поставьте галку Use the External DNS и тогда запросы этого коннектора будут идти к альтернативным серверам, которые вы укажите в сетевом подключении.  

И на последнем этапе, выбираем, на каком сервере мы будем создавать коннектор. У нас сервер один, поэтому тут без вариантов.

При желании можно создать один коннектор и раскидать его по всем серверам (по Москве, по Ростову и т.д.).

С коннекторами приема такое не прокатит. Там нужно явно указывать сервер. 

Давайте разберемся, как работает механизм доставки почты.

Представим ситуацию - Вася пишет письмо Пете. Нажимает отправить. Письмо попадает в папку "Исходящие". Причём не путайте "Исходящие" и "Отправленные". Далее на Mailbox сервере срабатывает служба Microsoft Exchange Mail Submission (на картинке по центру). Эта служба берет из AD 

информацию о том, какие HUB'ы работают в том же сайте AD, где располагается Mailbox. Ведь для того, чтобы Mailbox мог доставить письмо, ему нужно обратиться к HUB'у. Представим, что у нас два HUB'а и оба они в одном сайте. Mailbox берет любой из этих HUB'ов и говорит, что у меня есть письмо на доставку. На HUB'е , получившем уведомление, срабатывает служба Store driver. Эта служба лезет на Mailbox и забирает письмо из почтового ящика пользователя. После того, как HUB забрал письмо, в самом ящике письмо из "Исходящих" перемещается в "Отправленные". Хотя до отправки пока ещё далеко.

Итак, HUB забрал письмо. Он не может обрабатывать письма на лету, ему нужно какое-то время. Поэтому HUB кладет письмо в очередь. На HUB'е есть специальный

компонент - Submission queue или Очередь сообщений. Это база данных, в которой хранятся сообщения, которые ещё не доставлены.

Итак, письмо положено в очередь. Принцип её работы - кто первый в неё попал, тот (при равных условиях) из неё первым и уйдёт. Есть конечно накладки, типа, сервер-получатель не доступен. Тогда письмо может висеть в очереди какое-то время.

БД очереди реализована на том же движке, что и сама БД Exchange, где хранятся ящики. Т.е. Jet. 

Итак, письмо лежит в очереди. Подходит его черёд на обработку. Срабатывает компонент Categorizer (Категоризатор). Он берет по письму из очереди и начинает обрабатывать.  Категоризатор должен ответить на следующие вопросы:

1. Письмо предназначена для внутреннего пользователя или для внешнего? Это легко выяснить, обратившись к AD.

2. Если письмо для внутреннего пользователя, надо выяснить, в каком сайте находится этот внутренний пользователь, в какой БД и через какой HUB нужно осуществлять маршрут.

3. Далее проверяется, соответствует ли письмо установленным требованиям. Например, подходит ли оно по размеру.

И как только выбран маршрут и проверено, что письмо соответствует условиям, устанавливается SMTP-сессия и письмо доставляется.

Итак, Категоризатор выяснил куда отправить письмо и произошла попытка установки SMTP-сессии. Но сервер-получатель по какой-то причине недоступен. В таком случае письмо возвратиться обратно в очередь. И в течении определенного времени оно там хранится, в надежде на повторную доставку. Если следующие попытки оказались не успешными и письмо пролежало достаточно долго, пользователю-отправителю отправляется "non delivery report" (NDR), т.е. инфа о том, что письмо доставлено не было.

     Для теста отправим письмо на несуществующий адрес в нашем домене blablabla@adatum.com. Письмо в очереди лежат не будет. Нам сразу вернется NDR. HUB сразу поймёт, что мы отправляем внутреннему пользователю, т.к. указан домен adatum.com, за который мы отвечаем. HUB обратиться к AD, а там такого юзера нет. Поэтому нам вернется NDR с пометкой, что введенный вами адрес не может быть найден.

     Теперь отправим тестовое письмо наружу. Например, на blablabla@life.ru. Предположим, что у нас есть коннектор для life.ru, но выхода в интернет у нашего почтового сервера нет. HUB определит, что письмо не для внутреннего пользователя, а для интернета. Далее HUB выберет коннектор. После этого письмо застрянет в очереди. Давайте на неё посмотрим. 

     Набираем команду Get-Queue.

Как видно на рисунке, у нас во всех очередях суммарно висит 4 письма в очереди. NextHopDomain - это куда эти письма должны быть доставлены. Т.е. у нас 3 письма должны быть доставлены на van-ex2. Но он у нас потушен, поэтому письма висят. И одно письмо должно быть доставлено на life.ru, которое мы ранее отправили. Из командной строки не очень удобно работать с очередью, поэтому перейдём в EMC и в Toolbox выберем инструмент Queue Viewer.

Обратите внимание на столбец Delivery Type. Например на рисунке видно, что van-ex2 работает по MAPI. Т.е. наш HUB положит письмо в БД на Mailbox-сервер с именем van-ex2, т.к. они в одном сайте AD. Давайте посмотрим на эту очередь (двойной клик).

В очереди van-ex2 три письма. Откуда? Вспоминайте репликацию общих папок, которую мы обсуждали.

Репликация ОП происходит следующим образом: файлы рубятся на куски по 300 Кб, отправляются по почте и собираются на той стороне. То что вы видите на рисунке (3 письма в очереди) и есть письма репликации общих папок. Van-ex2, напомню, сейчас погашен, поэтому письма висят.

Но нас больше интересует Live.ru. 

Обратите внимание. Напротив Live.ru сразу указывается код ошибки. В нашем случае "DNS query failed", т.е. не удалось разрешить DNS-запись. Ещё может быть "Сервер-получатель недоступен" и прочее.

Итак, откроем очередь live.ru и посмотрим, что можно сделать с письмом в очереди.

Письмо можно удалить (Remove), причём как с отправкой оповещения, так и без него.

Suspend (приостановить) - поставить на паузу, т.е. повторных попыток доставить письмо не будет. Оно просто будет лежать в очереди.

Если щелкнуть ПКМ на самой очереди (не на письме), там помимо Suspend есть функция Retry, т.е. сделать повторную доставку, не дожидаясь тайм-аута.     

     Параметры очереди (сколько письмо будет лежать в очереди, что с ним потом делать и прочее) можно сконфигурировать вручную. Перейдите в Server Configuration -> Hub Transport. Выберите сервер -> ПКМ -> Свойства.

     Обратите внимание на вкладку External DNS Lookups. Помните в коннекторах была галка "Использовать альтернативный список серверов"? Вот здесь можно этот список прописать. Например 8.8.8.8

Вкладка Limits.

     Представим, что наш Hub пытается доставить письмо на какой-то другой сервер. Но этот сервер выключен и не отвечает.

Повторная доставка будет осуществляться каждые 10 минут. А именно столько минут, сколько указано в поле Outbound connection failure retry interval. И продолжаться этот процесс будет в течении 2-х дней (поле Maximum time since submission). Через 2 дня пользователю-отправителю будет отправлен NDR.

Через 4 часа попыток пользователю-отправителю придёт информация, что письмо застряло в очереди и пока не было доставлено (поле Notify sender when message...). 

     Рассмотрим другую ситуацию. Наш Hub пытается доставить письмо на какой-то другой сервер. Но сессия устанавливается и рвётся (например срабатывает Gray-лист). Повторная попытка доставки будет через 300 секунд (поле Transient failure retry interval). И таких попыток доставки будет 6 штук (поле Transient failure retry attempts). Т.е. в течении 

получаса Hub будет пытаться доставить письмо. Потом, соответственно, будет отправлен NDR. Если сервер-получатель доступен и отвечает, что принять не может (например, нет такого юзера или ящик переполнен), NDR будет отправлен отправителю сразу же.

Подведем итоги.

Любой Hub Transport имеет коннекторы отправки и коннекторы получения. Коннекторы получения нужны всегда, за исключением, когда Hub перекидывает или получает почту от пользователей, которые подключены по MAPI внутри вашей площадки. Коннекторы отправки не нужны, если вы отправляете почту внутри вашей организации (в таком случае всё делается на основе сайтов). Коннекторы отправки нужны, если вы отправляете почту в интернет, на Edge, либо в другую организацию Exchange. 

​

Кстати, забыл упомянуть про очередь Unreachable. В нее будут попадать письма, для которых нет коннекторов, по которым это письмо должно быть обработано. У нас в этой очереди писем нет и она не видна (вернитесь к команде Get-Queue и скриншоту). Давайте удалим созданный нами ранее send connectors (коннектор отправки), который мы назвали "To internet". Перезапустим службу транспорта командой Restart-Service MSExchangeTransport. И отправим письмо в интернет, например на адрес blabla@blabla.ru

Как видим, появилась очередь Unreachable, в которой теперь лежит одно письмо, как раз и отправленное нами.

​

​

Подведем окончательные итоги и закрепим материал.

​

Есть сайт в Москве, где мы установили Exchange-сервер. Под "Exchange-сервер" подразумеваем установку всех ролей на один сервер. Установка дефолтная, все настройки по умолчанию. Завели на сервере 10 юзеров и хотим, чтобы они обменивались почтой.

Нужно ли вам дополнительно создавать коннекторы отправки или приема? Нет.

Как только вам необходимо отправить письмо в интернет, вы создаете коннектор отправки.

Мы устанавливаем второй Exchange-сервер в этом же сайте AD. Также заводим 10 юзеров. Вы хотите, чтобы юзеры между разными Exchange-серверами обменивались сообщениями друг с другом.

Нужно ли вам дополнительно создавать коннекторы отправки или приема? Нет.

Поднимаем ещё один сайт AD и настраиваем между сайтами site link. Разворачиваем в новом сайте Exchange-сервер. Нужно ли вам дополнительно создавать коннекторы отправки или приема? Нет.

Коннектора приема, который есть по умолчанию, вполне достаточно. Коннектор отправки, внутри одной организации Exchange, не нужен.

Далее. Мы хотим, чтобы Exch3 принимал почту из интернета для всей организации. Что надо сделать? На коннекторе приема (например на том, который уже есть по умолчанию) необходимо поставить анонимный доступ. Также необходимо прописать MX-Записи, которые будут разрешаться в IP-адрес нашего сервера Exch3.

Рассмотрим  разные вариации.

На Exch2 мы удалили (или отключили) коннектор приема. Юзер на Exch1 отправляет почту юзеру на Exch2. Дойдёт ли это письмо? Дойдёт. Hub, находясь с Mailbox в одном сайте, осуществляет доставку в почтовый ящик этого  Mailbox по MAPI напрямую в БД.

Усложняем вариации. Отключаем коннектор приема на Exch3. Юзер на Exch1 отправляет почту юзеру на Exch3. Дойдёт ли это письмо? Нет. Как мы уже говорили, Hub, находясь с Mailbox в одном сайте, осуществляет доставку в почтовый ящик этого  Mailbox по MAPI. Положить письмо в БД, которая находится в другом сайте, Hub не может. Он должен передать его на Hub, расположенный в другом сайте. Т.е. в нашем примере, между Exch1 и Exch3 устанавливается SMTP-соединение. Коннектор отправки внутри организации не нужен. А коннектор приема нужен в любом случае. А на Exch3 мы его отключили. 

​

Переходите к следующей странице: Edge Server.

bottom of page