Cała poczta zewnętrzna do Office 365 kończy się niepowodzeniem SPF, oznaczona jako śmieci przez EOP w przypadku wdrożenia hybrydowego

Krótko mówiąc: wiarygodne wiadomości e-mail trafiają do folderów wiadomości-śmieci, ponieważ EOP (Exchange Online Protection) stempluje wiadomości e-mail jako wiadomości-śmieci (SCL5) i błąd SPF. Dzieje się tak w przypadku wszystkich domen zewnętrznych (np. Gmail.com/hp.com/microsoft.com) w domenie klienta (contoso.com).

Podstawowe informacje:

Jesteśmy na początku migracji skrzynek pocztowych do Office 365 (Exchange Online). Jest to konfiguracja Hybrid Deployment / Rich-Coexistence, w której:

• On-Premises = Exchange 2003 (Legacy) & 2010 (Zainstalowany do wdrożenia hybrydowego)
• Off-Premises = Office 365 (Exchange Online)
• EOP jest skonfigurowany do sprawdzania SPF.
• Rekordy MX wskazują na wersję lokalną, ponieważ nie zakończyliśmy migracji wszystkich skrzynek pocztowych z wersji lokalnej do Exchange Online.

Problem polega na tym, że gdy użytkownicy zewnętrzni wysyłają wiadomości e-mail do skrzynki pocztowej Office 365 w organizacji (przepływ poczty: Zewnętrzna -> Brama poczty -> lokalne serwery pocztowe -> EOP -> Office 365), EOP wykonuje wyszukiwanie SPF i twarde / miękkie awarie wiadomości o zewnętrznym adresie IP bramy poczty, od której otrzymała wiadomość.

(Lokalne skrzynki pocztowe nie pokazują tego problemu; tylko skrzynki pocztowe migrowane do Office 365 do.)

Ilustracja:

Przykład 1: od Microsoft do 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

Przykład 2: od HP do 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

Przykład 3: z Gmaila do 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

Nagłówki wiadomości z raportem antyspamowym X-Forefront znajdują się na stronie http://pastebin.com/sgjQETzM

Uwaga: 23.1.4.9 to publiczny adres IP lokalnego hybrydowego łącznika serwera Exchange 2010 z Exchange Online.

W jaki sposób zapobiegamy oznaczaniu zewnętrznych wiadomości e-mail jako śmieci w EOP podczas etapu współistnienia wdrożenia hybrydowego?

[12.12.2015]

Ten problem został rozwiązany przez obsługę Office 365 (eskalowany / backendowy zespół), ponieważ nie ma to nic wspólnego z naszymi ustawieniami.

Zaproponowano nam następujące działania:

1. Umieść publicznie IP na białej liście na liście dozwolonych EOP (Próbowałem. Nie pomogło).
2. Dodaj rekord SPF dla naszej domeny: „v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY obejmują: spf.protection.outlook.com -all” (Nie sądzę, że ta sugestia jest poprawna ponieważ EOP nie powinien sprawdzać gmail.com pod naszym adresem SMTP IP, ponieważ nie jest on podany w rekordach SPF gmail.com. Nie wydaje się, że SPF działa.)
3. Upewnij się, że TLS jest włączony (patrz poniżej)

Kluczową częścią jest trzeci punkt. „Jeśli TLS nie jest włączony, przychodzące wiadomości e-mail z lokalnej wymiany nie będą oznaczane jako wewnętrzne / zaufane, a EOP sprawdzi wszystkie rekordy”, powiedział wsparcie.

Wsparcie określiło problem TLS z naszych nagłówków poczty w następującym wierszu:

• X-MS-Exchange-Organization-AuthAs: Anonimowy

Oznacza to, że TLS nie został włączony, gdy EOP otrzymał e-mail. EOP nie traktował przychodzącej wiadomości e-mail jako zaufanej wiadomości e-mail. Prawidłowy powinien wyglądać tak:

• X-MS-Exchange-Organization-AuthAs: Internal

Nie było to jednak spowodowane naszymi ustawieniami; pracownik pomocy technicznej pomógł nam upewnić się, że ustawienia były prawidłowe, weryfikując pełne dzienniki SMTP z naszego serwera Exchange 2010 Hybrid.

Mniej więcej w tym samym czasie ich zespół zaplecza naprawił problem, nie informując nas, co go dokładnie spowodowało (niestety).

Po naprawieniu stwierdziliśmy, że w nagłówkach wiadomości wprowadzono pewne znaczące zmiany, jak poniżej.

W przypadku poczty pochodzącej z Exchange 2003 do Office 365:

• X-MS-Exchange-Organisation-AuthAs: Internal (To był „Anonimowy”)

• SCL = -1 (Było SCL = 5)

• Received-SPF: SoftFail (Było tak samo)

W przypadku zewnętrznych wiadomości e-mail (np. Gmail.com) do usługi Office 365:

• X-MS-Exchange-Organization-AuthAs: Anonimowy (było tak samo)

• SCL = 1 (Było SCL = 5)

• Received-SPF: SoftFail (Było tak samo)

Mimo że sprawdzanie SPF nadal nie powiedzie się dla gmail.com (zewnętrznego) do Office 365, osoba obsługująca powiedziała, że ​​było OK, a wszystkie maile trafiłyby do skrzynki odbiorczej zamiast do folderu śmieci.

Na marginesie, podczas rozwiązywania problemów zespół zaplecza znalazł jeden pozornie niewielki problem z konfiguracją - mieliśmy adres IP z naszego złącza przychodzącego (tj. Publicznego adresu IP serwera hybrydowego Exchange 2010) zdefiniowany na naszej liście dozwolonych adresów IP (sugerowane przez inną obsługę Office 365 osoba jako etap rozwiązywania problemów). Dają nam znać, że nie powinniśmy tego robić, aw rzeczywistości może to powodować problemy z routingiem. Skomentowali, że przy pierwszym przejściu wiadomość e-mail nie była oznaczana jako spam, więc mógł również występować problem. Następnie usunęliśmy adres IP z listy dozwolonych adresów IP. (Jednak problem ze spamem istniał przed wprowadzeniem ustawienia Listy dozwolonych adresów IP. Nie uważaliśmy, że przyczyną była lista dozwolonych adresów).

Podsumowując, „powinien to być mechanizm EOP”, powiedział osoba wspierająca. Dlatego wszystko powinno być spowodowane ich mechanizmem.

Dla wszystkich zainteresowanych wątek dotyczący rozwiązywania problemów z jedną z jego osób wsparcia można obejrzeć tutaj: https://community.office365.com/en-us/f/156/t/403396

Czy jesteś pewien, że przepływ poczty odbywa się bezpośrednio z serwera hybrydowego do O365?

Po uruchomieniu kreatora hybrydowego powinien on utworzyć konektory lokalnie i w O365, które będą traktować przepływ poczty między lasami jako pocztę wewnętrzną. Oznacza to, że ominie sprawdzanie EOP / Spam i nigdy nie powinieneś widzieć tych wiadomości SPF.

Jeśli urządzenie brzegowe modyfikuje nagłówki, może to być przyczyną problemu - między serwerem a O365 nic nie powinno modyfikować nagłówków wiadomości. Upewnij się, że nie masz istniejącego złącza, które może przesłonić te utworzone przez kreatora hybrydowego. Zawsze możesz usunąć istniejące konektory, które zostały utworzone i ponownie uruchomić kreatora, aby je ponownie utworzyć.

Sprawdź zasady transportu w programie Exchange i upewnij się, że nie zmieniają wiadomości przed przejściem do O365, jeśli są one wyłączone, i przetestuj ponownie, aby upewnić się, że to nie problem.

Na koniec (a może najpierw) sprawdź, czy federacja jest poprawnie skonfigurowana. Jeśli nie, to może być przyczyną, dla której Twoja poczta nie jest traktowana poprawnie. W takim przypadku ponowne uruchomienie kreatora Hybrid może również pomóc.

Nie jestem tutaj ekspertem, minęło dużo czasu, odkąd grałem z Exchange, ale postaram się odpowiedzieć najlepiej jak potrafię.

Zastanówmy się nad projektem przez sekundę, dlaczego nie przekierujesz najpierw całego ruchu do EOP, a następnie do lokalnych serwerów Exchange? tracisz tam dobrą funkcjonalność, zdecydowanie ułatwiłoby ci to kontrolowanie spamu z jednego miejsca (zakładając, że jesteś lokalny Exchange ma również filtr antyspamowy).

Przejdźmy teraz do problemu spamu:

1. Przepływ poczty i złącza : Mam wrażenie, że złącza nie są poprawnie skonfigurowane, jeśli wszystkie przychodzące wiadomości e-mail wydają się pochodzić z tego samego adresu IP 23.1.4.9 zamiast adresu IP serwera poczty nadawcy, na pewno sprawdzenie SPF zakończy się niepowodzeniem , ponieważ ma to na celu sprawdzenie adresu IP nadawcy i nazwy domeny tego adresu IP nadawcy. Zdecydowanie poświęciłbym trochę czasu na sprawdzenie konfiguracji łączników, oto dobry link do tego: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. Filtry spamu EOP i filtry połączeń : jeśli konfiguracja adresów IP złączy jest wykonana poprawnie, być może nadszedł czas, aby spojrzeć na filtry spamu / połączeń w EOP, stworzyłbym filtry, aby pominąć sprawdzanie przychodzących wiadomości e-mail z adresu IP 23.1.4.9, ale to sprawiłoby, że wszystkie przychodzące wiadomości e-mail pomijałyby listy kontrolne filtrów antyspamowych, prowadzi to do problemu wspomnianego w poprzednim punkcie, sprawdź łączniki i najlepiej skieruj najpierw przychodzące wiadomości e-mail do EOP.