Вкратце: законные письма попадают в папки нежелательной почты, поскольку EOP (Exchange Online Protection) помечает сообщения электронной почты как нежелательные (SCL5) и SPF-сбои. Это происходит со всеми внешними доменами (например, gmail.com/hp.com/microsoft.com) с доменом клиента (contoso.com).
Справочная информация:
Мы находимся в начале миграции почтовых ящиков в Office 365 (Exchange Online). Это конфигурация гибридного развертывания / расширенного сосуществования, где:
- On-Premises = Exchange 2003 (Legacy) и 2010 (установлен для гибридного развертывания)
- Вне помещения = Office 365 (Exchange Online)
- EOP настроен для проверки SPF.
- Записи MX указывают на локальные данные, так как мы еще не завершили миграцию всех почтовых ящиков из локальной системы в Exchange Online.
Проблема заключается в том, что когда внешние пользователи отправляют сообщения электронной почты на почтовый ящик Office 365 в организации (поток почты: Внешний -> Почтовый шлюз -> Локальные почтовые серверы -> EOP -> Office 365), EOP выполняет поиск SPF и аппаратно / программно сообщения о сбое с внешним IP-адресом почтового шлюза, с которого он получил почту.
(Локальные почтовые ящики не показывают эту проблему; только почтовые ящики, перенесенные в Office 365, делают.)
Иллюстрация:
Пример 1: от Microsoft до O365
Authentication-Results: spf=fail (sender IP is 23.1.4.9)
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9;
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5
Пример 2: от HP до O365
Authentication-Results: spf=none (sender IP is 23.1.4.9)
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none
(message not signed) header.d=none; Received-SPF: None
(protection.outlook.com: hp.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-SCL: 5
Пример 3: из Gmail в O365
Authentication-Results: spf=softfail (sender IP is 23.1.4.9)
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com;
dkim=fail (signature did not verify) header.d=gmail.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
gmail.com discourages use of 23.1.4.9 as permitted sender)
X-MS-Exchange-Organization-SCL: 5
Заголовки сообщений с X-Forefront-Antispam-Report см. По адресу http://pastebin.com/sgjQETzM.
Примечание. 23.1.4.9 - это общедоступный IP-адрес локального гибридного соединителя сервера Exchange 2010 с Exchange Online.
Как мы не дадим EOP помечать внешние электронные письма как нежелательные на этапе сосуществования гибридного развертывания?
[2015-12-12 Обновление]
Эта проблема была исправлена службой поддержки Office 365 (расширенная / бэкэнд-команда), поскольку она не имеет ничего общего с нашими настройками.
Нам предложили следующее:
- Белый список публичных IP-адресов в EOP Allow List (пробовал. Не помогло.)
- Добавьте запись SPF для нашего домена: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY include: spf.protection.outlook.com -all" (Не думаю, что это предложение действительно поскольку EOP не должен проверять gmail.com по нашему IP-адресу SMTP, поскольку он не указан в записях SPF на gmail.com. Это не похоже на работу SPF.)
- Убедитесь, что TLS включен (см. Ниже)
Ключевой частью является третий пункт. «Если TLS не включен, входящая электронная почта от локального Exchange не будет помечена как внутренняя / доверенная, и EOP проверит все записи», - сказали в службе поддержки.
Служба поддержки определила проблему TLS из наших почтовых заголовков по следующей строке:
- X-MS-Exchange-Organization-AuthAs: анонимный
Это указывает, что TLS не был включен, когда EOP получил электронную почту. EOP не рассматривал входящую почту как доверенную. Правильный должен быть таким:
- X-MS-Exchange-Organization-AuthAs: внутренний
Однако это не было вызвано нашими настройками; Служба поддержки помогла нам убедиться в правильности наших настроек, проверив подробные журналы SMTP с нашего гибридного сервера Exchange 2010.
Примерно в то же время их бэкэнд-команда исправила проблему, не сообщая нам, что именно ее вызвало (к сожалению).
После того, как они это исправили, мы обнаружили, что заголовки сообщений претерпели некоторые существенные изменения, как показано ниже.
Для внутренней почты из Exchange 2003 в Office 365:
X-MS-Exchange-Organization-AuthAs: Внутренняя («Аноним»)
SCL = -1 (было SCL = 5)
- Получил-SPF: SoftFail (было так же)
А для внешних писем (например, gmail.com) в Office 365:
X-MS-Exchange-Organization-AuthAs: анонимно (было так же)
SCL = 1 (было SCL = 5)
Получил-SPF: SoftFail (было так же)
Несмотря на то, что проверка SPF по-прежнему не проходит успешно для gmail.com (внешнего) для Office 365, специалист службы поддержки сказал, что все в порядке, и все письма будут отправляться в папку «Входящие» вместо папки «Хлам».
В качестве примечания, во время устранения неполадок бэкэнд-группа обнаружила одну, казалось бы, незначительную проблему конфигурации - у нас был IP-адрес нашего входящего соединителя (т. Е. Общедоступный IP-адрес гибридного сервера Exchange 2010), определенный в нашем списке разрешенных IP-адресов (предложенный другой службой поддержки Office 365). человек как шаг устранения неполадок). Они дают нам знать, что нам не нужно этого делать, и на самом деле это может вызвать проблемы с маршрутизацией. Они отметили, что при первом прохождении электронная почта не была помечена как спам, поэтому здесь также была возможная проблема. Затем мы удалили IP-адрес из списка разрешенных IP-адресов. (Однако проблема со спамом существовала до того, как была настроена настройка списка разрешенных IP-адресов. Мы не думали, что причина - список разрешений.)
В заключение, «это должен быть механизм EOP», сказал человек поддержки. Поэтому все это должно быть вызвано их механизмом.
Для тех, кто заинтересован, ветку по устранению неполадок с одним из их сотрудников поддержки можно посмотреть здесь: https://community.office365.com/en-us/f/156/t/403396.