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

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

Короче говоря: законные электронные письма попадают в папки нежелательной почты, поскольку EOP (Exchange Online Protection) помечает сообщения электронной почты как нежелательные (SCL5) и SPF-неудачные. Это происходит со всеми внешними доменами (например, gmail.com/hp.com/microsoft.com) в домен клиента (contoso.com).

Справочная информация:

Мы находимся в начале миграции почтовых ящиков в Office 365 (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 как нежелательные на этапе сосуществования гибридного развертывания?

[Обновление от 12 декабря 2015 г.]

Эта проблема была исправлена ​​службой поддержки Office 365 (расширенной / серверной группой), поскольку она не имеет ничего общего с нашими настройками.

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

  1. Внесите общедоступный IP-адрес в белый список в разрешенном списке EOP (пробовал. Не помогло).
  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 из заголовков наших писем по следующей строке:

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

Однако это не было вызвано нашими настройками; Специалист службы поддержки помог нам убедиться в правильности наших настроек, проверив подробные журналы SMTP с нашего гибридного сервера Exchange 2010.

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

После того, как они это исправили, мы обнаружили, что заголовки сообщений претерпели некоторые существенные изменения, как показано ниже.

Для внутренней почты из Exchange 2003 в Office 365:

А для внешней почты (например, gmail.com) в Office 365:

Хотя проверка SPF по-прежнему не работает для gmail.com (внешнего) по отношению к Office 365, сотрудник службы поддержки сказал, что все в порядке, и все письма будут отправляться во входящие, а не в папку нежелательной почты.

В качестве примечания: во время устранения неполадок бэкэнд-группа обнаружила одну, казалось бы, незначительную проблему конфигурации - у нас был IP-адрес нашего входящего коннектора (то есть общедоступный IP-адрес гибридного сервера Exchange 2010), определенный в нашем списке разрешенных IP-адресов (предложенном другой службой поддержки Office 365. человек как шаг устранения неполадок). Они сообщают нам, что нам не нужно этого делать, и на самом деле это может вызвать проблемы с маршрутизацией. Они отметили, что при первом проходе электронное письмо не было помечено как спам, поэтому здесь также была возможная проблема. Затем мы удалили IP из списка разрешенных IP-адресов. (Однако проблема со спамом существовала до настройки списка разрешенных IP-адресов. Мы не думали, что причиной этого был список разрешенных IP-адресов.)

В заключение, «это должен быть механизм EOP», - сказал сотрудник службы поддержки. Следовательно, все это должно быть вызвано их механизмом.

Для всех, кто заинтересован, тему устранения неполадок с одним из их специалистов службы поддержки можно посмотреть здесь: https://community.office365.com/en-us/f/156/t/403396

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

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

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

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

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

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

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

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

  1. Почтовый поток и коннекторы: У меня такое ощущение, что соединители настроены неправильно, если все ваши входящие электронные письма, похоже, исходят с одного и того же IP-адреса 23.1.4.9, а не с 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.