Назад | Перейти на главную страницу

Exchange Online: странное поведение при маршрутизации почты

Я перехожу с Exchange 2010 на Office 365 / Exchange Online для клиента в эти выходные. Мы настроили Cutover Migration, который успешно продвигался в течение нескольких недель.

В настоящее время записи MX для example.com указывают на: mx1.antispamprovider.com, mx2.antispamprovider.com и т. Д.

Этот облачный провайдер защиты от спама (который мы контролируем) настроен для доставки почты на mail.example.com, который преобразуется в статический IP-адрес, за которым сервер Exchange 2010 от Example Co находится за NAT.

Все хорошо, все хорошо.

В качестве дымового теста я решил, что буду подключаться через telnet к конечной точке почты Exchange Online (порт 25 example-com.mail.protection.outlook.com) и отправить тестовое письмо от себя на существующий лицензированный почтовый ящик Exchange Online, а затем войти в систему как этого пользователя на outlook.office365.com и у меня возникает это теплое нечеткое ощущение, когда я вижу свое сообщение telnet ...

... полдюжины сообщений telnet позже, и ни одно не было доставлено, несмотря на получение 250 Queued Mail for Delivery каждый раз заставляет меня чесать затылок.

Что ж, наверное, он помещен в карантин Exchange Online Protection ...

... Проверил защиту (спам, рассылка, вредоносное ПО, фишинг, политика и т. Д.) И трассировка сообщений тоже ничего не показывает (на всякий случай пробовал «Новое и улучшенное» и старую).

По прихоти я решил войти в интерфейс управления провайдера защиты от спама и о чудо, все мои сообщения telnet показаны как доставленные на сервер Exchange 2010.

Итак, как, черт возьми, прямой telnet к конечной точке почты Exchange Online, конечная точка, которая настроена как авторитетная, например, example.com, волшебным образом ретранслирует сообщения telnet через (предположительно) поиск записи MX, а не принимает и не доставляет на локальную Почтовый ящик Exchange Online?

Я не решаюсь на самом деле изменить место доставки в поставщике антиспама, опасаясь создания цикла.

EDIT: заголовки подтверждают, что он действительно маршрутизируется через Интернет посредством поиска MX.

tl; dr:

Exchange Online (EO) принимает почту для доставки, но фактически не вставляет почту в почтовый ящик EO, несмотря на то, что он лицензирован и является авторитетным для example.com. Заголовки подтверждают, что MS EO / EOP ретранслирует на ток Записи MX, которые указывают на локальный Exchange.

Я заметил, что вы используете прямую миграцию, она создаст новые почтовые ящики непосредственно в Exchange Online, поэтому будет два одинаковых почтовых ящика, один в Exchange 2010, а другой в Exchange Online. Таким образом, запись MX является ключевым моментом.

Когда я отправляю сообщение на адрес user1@example.com, поскольку запись MX для example.com указывает на облачного провайдера антиспама, это сообщение будет доставлено этому провайдеру. И в соответствии с вашей конфигурацией этот провайдер доставляет это сообщение в Exchange 2010. Ошибки нет.

Ссылка: перенос электронной почты с помощью метода переключения Exchange https://docs.microsoft.com/en-us/Exchange/mailbox-migration/cutover-migration-to-office-365?redirectSourcePath=%252fen-us%252farticle%252fCutover-migration-to-Office-365-9496e93c -1e59-41a8-9bb3-6e8df0cd81b4

Возможная задержка маршрутизации электронной почты: электронная почта, отправляемая локальным пользователям, почтовые ящики которых были перенесены в Office 365, направляется в их локальные почтовые ящики Exchange до тех пор, пока запись MX не будет изменена.

После миграции вам необходимо изменить запись MX. И теперь вам не нужно было использовать этого облачного поставщика защиты от спама, Microsoft Exchange Online Protection (EOP) предоставляет встроенные возможности фильтрации вредоносных программ и спама, которые помогают защитить входящие и исходящие сообщения от вредоносного программного обеспечения и помогают защитить вашу сеть от спам передается по электронной почте. Администраторам не нужно настраивать или поддерживать технологии фильтрации, которые включены по умолчанию. Однако администраторы могут выполнять настройки фильтрации для конкретной компании в центре администрирования Exchange (EAC).