About Sharing SMTP Domain

Попробую разобраться в объединении SMTP доменов между несколькими системами.

Когда это необходимо?

Основаных сценариев, которые были на моей практике несколько:

1. Миграция с одной почтовой системы в другую.
2. Объединение пространства имен при слиянии/присоединении компаний.
3. Пересылка всех сообщений с одного сервера на другой для конкретных доменов.

Предположим, что оба сервера Exchange.

Сервер в организации Exchange1 принимает сообщения для определенного домена, например domain.com. Если почтовый ящик находится на Exchange1 сообщение доставляется в п/я. В случае если в почтовой организации получатель не найден сообщение направялется на Exchange2. Алгоритм действия сервера Exchange2 идентичен и в случае, если адресат в domain.com не найден в локальной организации сообщение будет направлено на Exchange1.

Настройки на Exchange1:

• Internal Relay: domain.com
• Send Connector. — в качестве smart host указан Edge сервер организации Exchange2, авторизация для SMART HOST отключена, параметр Address Space — domain.com.

Настройки на Exchange2 идентичны:

• Internal Relay: domain.com
• Send Connector. — в качестве smart host указан Edge сервер организации Exchange1, авторизация для SMART HOST отключена, параметр Address Space — domain.com.

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

Предлагается каждое входящее сообщение на сервере Exchange1 тегировать (вставлять в заголовок метку) и если это сообщение вернется серверу повторно, но уже с тэгом — удалять данное сообщение или отправлять NDR.

Для настройки необходимо создать по два транспортных правила на Exchange1 и два транспортных правила на Exchange2. Разница в настройках только в значении тэга.

На сервере Exchange1 транспортное правило вставляет в заголовки всех входящих сообщений строку X-LoopDetect со значением 1 кроме случаев когда в сообщении уже существует X-LoopDetect со значением 2(это сообщения тэгируемые сервером Exchange2).

Другое транспортное правило отправляет NDR или удаляет все сообщения в заголовке которых находится строка X-LoopDetect со значением 1.

!!! В ходе экспериментов мне пришлось изменить приоритет правил. Правило, которое удаляет тегированные сообщения должно быть с меньшим приоритетом.

Если оставить приоритет, как указано на картинках в правиле с тегом необходимо добавить исключение  X-LoopDetect со значением 1 и включить настройку Stop Processing more rule. Два данных правила должны быть в самом конце общего списка правил, иначе сообщения не будут проходить другие правила из-за настройки «Stop Processing more rule». В этой конфигурации, сообщения поступившние на сервер вначале будут тегироваться и благодаря «Stop Processing more rule» будут отправляться на Exchange2, но когда сообщения будут поступать с тэгом X-LoopDetect  = 1, они не будут обрабатываться данным правилом а будут обработаны правилом, которое удаляет или генерирует NDR. 

P.S. Получилось сумбурно, но я хотел описать, что существуют варианты настройки правил.

На сервере Exchange2 так же можно создать идентичные правила, разница будет лишь в том, что значение X-LoopDetect необходимо поставить 2, а в исключении указать значение X-LoopDetect=1.

 

Зачастую антиспам системы, ключая встроенный в Exchange фильтр Recipient Filter, выполняют запросы в AD на предмет существования в организации адреса назначения и если его не существует, то сервер не принимает сообщение.

Если получатель находится в организации Exchange2, а в Exchange1 его нет — то агенты фильтрации получателей вполне могут удалить данное сообщение.

Существуе несколько вариантов решения данного вопроса:

1. Настройка системы фильтрации, так чтобы сообщения, отправляемые на не существующие в организации адреса не фильтровались.
2. Создание контактов или mail enable user (MEU — объекты имеющие почтовый адрес, но не имеющие почтовый ящик), которые фактически будут отображать получателей в другой организации.

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

В крайнем случае можно отключить проверку на наличие объектов в AD. Настройка проверки адресатов в AD регулируется с помощью команды Set-RecipientFilterConfig  и параметра RecipientValidationEnabled.

Проверка получателей напрямую зависит от типа домена в Exchange организации:

• Для доменов Internal relay по-умолчанию проверка не производится. И вправду это не очень логично, так как Internal relay подразумевает, что получателя в организации может и не быть. Но мы можем регулировать это поведение.
• Для авторитативных доменов проверка происходит всегда и если адресат не найден в AD, сообщение блокируется.

В случае если есть желание включить проверку адресатов для Internal Relay необходимо с помощью командлета Set-AcceptedDomain  включить  $True параметра AddressBookEnabled. По умолчанию для Internal relay доменов значение параметра AddressBookEnabled — $false.

В итоге мы получаем следующую схему с вариантами:

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

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

Как я говорил в самом начале основными сценариями объединения пространства SMTP является миграция или слияние. В этом случае необходимо синхронизировать списки пользователей в адресных книгах. На самом деле для этого и создаются контакты в одной организации, которые представляют почтовые ящики в другой организации и наборот.