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.)
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:
- Umieść publicznie IP na białej liście na liście dozwolonych EOP (Próbowałem. Nie pomogło).
- 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.)
- 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
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:
źródło