Вся внешняя почта в Office 365 с ошибками SPF, помеченная EOP как нежелательная в гибридном развертывании

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

Нам предложили следующее:

1. Белый список публичных IP-адресов в EOP Allow List (пробовал. Не помогло.)
2. Добавьте запись 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.)
3. Убедитесь, что 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.

Вы уверены, что поток почты идет прямо с вашего гибридного сервера на O365?

Когда вы запустили гибридный мастер, он должен был создать соединители локально и в O365, который будет направлять поток почты между лесами как внутреннюю почту. Это означает, что он будет обходить проверки EOP / Spam, и вы никогда не должны видеть эти сообщения SPF.

Если ваше пограничное устройство модифицирует заголовки, это может быть причиной вашей проблемы - между вашим сервером и O365 ничто не должно изменять заголовки сообщений. Убедитесь, что у вас нет существующего соединителя, который может перекрывать тот, который был создан мастером Hybrid. Вы всегда можете удалить существующие соединители, которые были созданы, и повторно запустить мастер, чтобы воссоздать их.

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

Последняя (или, может быть, первая) проверка, что ваша федерация настроена правильно. Если это не так, может быть, поэтому ваша почта не обрабатывается правильно. В этом вам поможет и повторный запуск мастера Hybrid.

Здесь я не эксперт, я очень давно играл с Exchange, но постараюсь ответить как можно лучше.

Давайте на секунду обсудим дизайн. Почему бы вам сначала не направить весь трафик на EOP, а затем на локальные серверы Exchange? вы теряете там хорошую функциональность, это определенно облегчит вам контроль спама из одного места (предположим, что вы локальный сервер Exchange также имеет антиспам-фильтр).

Теперь перейдем к проблеме спама:

1. Поток почты и соединители . У меня такое ощущение, что соединители настроены неправильно, если кажется, что все ваши входящие электронные письма исходят с одного и того же 23.1.4.9 IP-адреса, а не IP-адреса почтового сервера отправителя, так что проверки SPF не пройдут , поскольку его целью является проверка IP-адреса отправителя и доменного имени этого IP-адреса отправителя. Я бы определенно потратил некоторое время на рассмотрение настройки соединителей, вот хорошая ссылка для этого: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. Спам-фильтры EOP и фильтры подключений : если настройка IP коннекторов выполнена правильно, возможно, пришло время взглянуть на фильтры спама / подключения в EOP, я бы создал фильтры для обхода проверки входящих электронных писем с IP-адреса 23.1.4.9, но это заставит все входящие электронные письма обходить контрольные списки фильтра нежелательной почты, это приведет вас к проблеме, упомянутой в предыдущем пункте, проверьте ваши соединители и, предпочтительно, сначала направьте входящую электронную почту на EOP.