Коротше кажучи: законні електронні листи висаджуються у папки з небажаною поштою, оскільки EOP (Exchange Online Protection) відмічає повідомлення електронної пошти як непотрібні (SCL5) та SPF-невдалі. Це відбувається з усіма зовнішніми доменами (наприклад, gmail.com/hp.com/microsoft.com) до домену клієнта (contoso.com).
Довідкова інформація:
Ми на початку переміщення поштових скриньок до Office 365 (Exchange Online). Це конфігурація гібридної розгортання / Rich-Coexistence, де:
- В приміщенні = 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-звітом, зверніться до http://pastebin.com/sgjQETzM
Примітка: 23.1.4.9 - це загальнодоступна IP-адреса локального гібридного роз'єму сервера Exchange 2010 до Exchange Online.
Як ми зупиняємо те, щоб зовнішні електронні листи відзначалися непотрібними EOP під час стадії співіснування гібридної розгортання?
[Оновлення 2015-12-12]
Цю проблему було виправлено підтримкою Office 365 (команда ескалації / резервного копіювання), оскільки вона не має нічого спільного з нашими налаштуваннями.
Нам запропонували наступне:
- Білий список загальнодоступних IP-адрес у списку дозволів EOP (Спробував. Це не допомогло.)
- Додати запис SPF для нашого домену: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY включають: spf.protection.outlook.com -all" (Не думаю, що ця пропозиція є дійсною оскільки EOP не повинен перевіряти gmail.com щодо нашої SMTP-адреси IP, оскільки він не вказаний у SPF-записах gmail.com. Це не схоже на те, як працює SPF.)
- Переконайтеся, що TLS увімкнено (див. Нижче)
Ключова частина - третій пункт. "Якщо TLS не ввімкнено, вхідна електронна пошта з локальної біржі не буде позначена як внутрішня / довірна електронна пошта, і EOP перевірить усі записи", - йдеться в службі підтримки.
Підтримка визначила проблему TLS з наших заголовків пошти наступним рядком:
- X-MS-Exchange-Organization-AuthAs: Anonymous
Це означає, що 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: Anonymous (Це було те саме)
SCL = 1 (це було SCL = 5)
Отримано-SPF: SoftFail (було те саме)
Незважаючи на те, що перевірка SPF все ще є помилковою для помилки gmail.com (зовнішня) для Office 365, служба підтримки сказала, що це нормально, і всі листи надійдуть у папку "Вхідні" замість папки "Небажана".
Як зауваження, під час усунення несправностей команда бекендера знайшла одну, здавалося б, незначну проблему з конфігурацією - у нас IP-адресу від вхідного з'єднувача (тобто загальнодоступного гібридного сервера Exchange Exchange 2010) визначено в нашому списку дозволів IP-адрес (запропоновано іншою підтримкою Office 365 особи як крок усунення несправностей). Вони дають нам знати, що нам не потрібно цього робити, і насправді це може спричинити проблеми маршрутизації. Вони прокоментували, що при первинному пропуску електронний лист не позначався як спам, тому тут також можлива проблема. Потім ми видалили IP із списку дозволів IP. (Однак проблема зі спамом існувала ще до того, як було встановлено налаштування списку дозволів IP-адрес. Ми не думали, що причиною є список дозволів.)
На закінчення, "це має бути механізм ЕОП", - сказала особа, яка підтримує. Тому вся справа повинна бути викликана їх механізмом.
Для всіх, хто цікавиться, порядок усунення несправностей з одним із їхніх осіб із підтримки можна переглянути тут: https://community.office365.com/en-us/f/156/t/403396