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 является миграция или слияние. В этом случае необходимо синхронизировать списки пользователей в адресных книгах. На самом деле для этого и создаются контакты в одной организации, которые представляют почтовые ящики в другой организации и наборот.

 

Простые операции в Exchange

Иногда бывает проще где-то записать для себя операции, которые выполняешь не так часто.

Операции с базами данных

• Перемещение всех п/я базы md01 в базу md02

Get-Mailbox -Database «md01» -ResultSize Unlimited | New-MoveRequest -TargetDatabase «md02»

• Перемещение одного п/я Mailbox01 в базу md02

New-MoveRequest -Identity «Mailbox01» -TargetDatabase «md02»

• Перемещение служебных и архивных почтовых ящиков из базы md01 в базу md02

Get-Mailbox -Database md01  -Arbitration | New-MoveRequest -TargetDatabase md02

Get-Mailbox -Database md01 -Archive | New-MoveRequest -TargetDatabase md02

• Перемещение п/я из текстового файла

Get—Content C\Adminusers.txt | New—MoveRequest —TargetDatabase «md02»

• Просмотр статистики перемещения почтовых ящиков в базу данных «md02»

Get-MoveRequestStatistics -MoveRequestQueue «md02»

• Отображение статистики завершенных перемещений п/я

Get-MoveRequest | where {$_.status -eq “Completed”}

• Удаление завершенных запросов перемещений

Get-MoveRequest | where {$_.status -eq “Completed”} | Remove-MoveRequest

• Операция сидинга базы данных с указанием сервера источника

Например, DAG группа из трех серверов mailexch1,mailexch2,mailexch3. Необходимо добавить пассивную БД maildb на сервер mailexch3 с указанием сервера источника mailexch2.

Создаем копию, без операции сидинга (заполнения БД)

Add-MailboxDatabaseCopy -Identity maildb -MailboxServer mailexch3 -ActivationPreference 3 -SeedingPostponed

• Выполняем операцию сидинга

Update-MailboxDatabaseCopy -Identity maildb\mailexch3 -SourceServer mailexch2 -DeleteExistingFiles

• Просмотр статуса репликации баз данных на локальном сервере

Get-MailboxDatabaseCopyStatus

Name Status CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
—- —— ————— —————— ——————— ——————
archive\EXCH-03 Healthy 0 0 27.05.2020 0:28:10 Healthy
standard\EXCH-03 Healthy 0 0 27.05.2020 0:30:27 Healthy
extended\EXCH-03 Healthy 0 0 27.05.2020 0:27:51 Healthy
shared\EXCH-03 Healthy 0 0 27.05.2020 0:28:10 Healthy

Данный вывод говорит о том, что на сервере EXCH-03 на данный момент, нет ни одной активной базы данных, пассивные базы данных находятся в рабочем состоянии и все журналы транзакции были скопированы и записаны в базу данных.

Статусы баз данных можно просмотреть https://docs.microsoft.com/ru-ru/exchange/high-availability/manage-ha/monitor-dags?view=exchserver-2019

Иногда удобнее просмотреть статусы всех баз данных

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus * | ft -AutoSize

Name Status CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
—- —— ————— —————— ——————— ——————
standard\EXCH-01 Healthy 0 0 27.05.2020 0:41:41 Healthy
extended\EXCH-01 Mounted 0 0 Healthy
archive\EXCH-01 Healthy 0 0 27.05.2020 0:35:44 Healthy
shared\EXCH-01 Mounted 0 0 Healthy
standard\EXCH-02 Mounted 0 0 Healthy
extended\EXCH-02 Healthy 0 0 27.05.2020 0:41:02 Healthy
archive\EXCH-02 Mounted 0 0 Healthy
shared\EXCH-02 Healthy 0 0 27.05.2020 0:28:10 Healthy
archive\EXCH-03 Healthy 0 0 27.05.2020 0:35:44 Healthy
standard\EXCH-03 Healthy 0 0 27.05.2020 0:41:41 Healthy
extended\EXCH-03 Healthy 0 0 27.05.2020 0:41:02 Healthy
shared\EXCH-03 Healthy 0 0 27.05.2020 0:28:10 Healthy

В выводе выше, можно увидеть статус Mounted — это активная база данных, к которой подключены почтовые клиенты.

Так же просмотреть все активные базы данных и их некоторые свойства.

Get-MailboxDatabaseCopyStatus * -Active | Select Name,Status,MailboxServer,ActivationPreference
,ContentIndexState

Name : extended\EXCH-01
Status : Mounted
MailboxServer : EXCH-01
ActivationPreference : 2
ContentIndexState : Healthy

Name : shared\EXCH-01
Status : Mounted
MailboxServer : EXCH-01
ActivationPreference : 1
ContentIndexState : Healthy

Name : standard\EXCH-02
Status : Mounted
MailboxServer : EXCH-02
ActivationPreference : 2
ContentIndexState : Healthy

Name : archive\EXCH-02
Status : Mounted
MailboxServer : EXCH-02
ActivationPreference : 1
ContentIndexState : Healthy

Edge Синхронизация

• Просмотр состояние Edge подписки

Test-EdgeSynchronization

• Запуск синхронизации

Start-EdgeSynchronization