Przejdz do tresci
Avanet

Sophos Email Mailflow: systematyczna naprawa Microsoft 365

Sophos Email

Gdy Sophos Email Mailflow przestaje działać w Microsoft 365, nie należy na chybił trafił usuwać łączników ani reguł transportowych. Najpierw trzeba sprawdzić stan domeny w Sophos Fusion (dawniej Sophos Central), uruchomić Run a Quick Test i porównać tę samą wiadomość w Microsoft Message Trace oraz Sophos Message History. Dopiero potem naprawia się właściwą ścieżkę.

Szybka ścieżka: Connected z zielonym znacznikiem oznacza aktywne połączenie Mailflow. Not Connected z czerwonym krzyżykiem wymaga kontroli połączenia lub uprawnień. Wykrzyknik i View Details wskazują regułę albo łącznik zmieniony bezpośrednio w Microsoft 365. Przy błędzie 552 należy najpierw szukać powielonych nagłówków Sophos i Microsoft — często oznaczają, że usługa podpisu ponownie skierowała wiadomość przez Sophos.

Ten runbook dotyczy wyłącznie Sophos Email w trybie Mailflow (MFR). Rekordy MX nadal wskazują Microsoft 365, a reguły transportowe i łączniki Microsoft kierują pocztę do Sophos i z powrotem. W trybie Gateway rekordy MX wskazują Sophos, więc diagnostyka i usuwanie przebiegają inaczej. Nie wolno stosować instrukcji Gateway do domeny Mailflow. Wdrożenie i planowaną migrację opisuje Konfiguracja Sophos Email Mailflow dla Microsoft 365.

Wymagania i bezpieczny punkt wyjścia

Potrzebny jest dostęp administracyjny do Sophos Fusion oraz konto mogące udzielić zgody aplikacji Sophos Email i wymaganych uprawnień przepływu poczty Exchange Online. Domeny Microsoft 365 muszą kwalifikować się do Mailflow, a potrzebni użytkownicy i grupy muszą być zsynchronizowani.

Przed zmianą należy zapisać:

  • domenę, nadawcę, odbiorcę, czas UTC, Internet Message-ID i pełne nagłówki;
  • stan Mailflow Connection oraz ewentualnie Post Delivery;
  • nazwy, stan i priorytet reguł i łączników Sophos, usługi podpisu i innych usług;
  • wyniki Microsoft Message Trace i Sophos Message History;
  • ostatnią działającą konfigurację i właściciela każdej zmiany.

W jednym teście zmienia się jeden czynnik. Nie usuwać utworzonej przez Sophos domeny xgeconnector.com, gdyż może to przerwać przepływ i przetwarzanie. Pozornie osieroconego łącznika nie usuwa się bez udokumentowania przypisania domeny i ścieżki wycofania.

1. Sprawdzenie połączenia i stanu domeny

  1. W Sophos Fusion otworzyć Global Settings.
  2. Wybrać Products and Services > Email > M365 Mailflow Domains.
  3. Sprawdzić domenę:
    • zielony znacznik, Connected: połączenie działa;
    • czerwony krzyżyk, Not Connected: wskazać kursorem i kliknąć zielony znacznik, aby połączyć ponownie;
    • wykrzyknik, View Details: zbadać zmianę w Microsoft 365.
  4. Kliknąć ikonę testu. W Run a Quick Test wpisać kontrolowany adres odbiorcy i wybrać Proceed. Test może potrwać kilka minut.
  5. Po niepowodzeniu użyć najpierw Run The Test Again, a następnie Reconnect, jeśli błąd pozostaje.

Udany Quick Test przywraca zielony znacznik, lecz nie dowodzi dostarczenia end-to-end. Następnie należy wysłać kontrolowaną wiadomość przychodzącą i wychodzącą i prześledzić obie do odbiorcy w Microsoft Message Trace i Sophos Message History.

Gdy Reconnect nie tworzy reguł lub łączników

Sprawdzić wymagane przypisania ról aplikacji Sophos Mailflow w tenancie. Uprawnienia przepływu poczty Exchange Online muszą być dostępne przez rolę administratora Exchange. Automatyczna naprawa wymaga ważnej zgody i tych uprawnień.

Jeżeli Reconnect nadal zawodzi, nie powtarzać ręcznego usuwania. Zachować stan, wynik Quick Test, nazwy reguł i łączników oraz Message-ID i przekazać sprawę do Sophos Support; może być potrzebne ręczne czyszczenie.

2. Obsługa alertu o zmienionych obiektach Mailflow

Sophos monitoruje wyłączanie, usuwanie i modyfikację reguł i łączników wymaganych przez Mailflow. Audyt Microsoft 365 musi być włączony, a aplikacja Sophos Email musi mieć uprawnienie organizacji Read activity data. Dla domen skonfigurowanych przed 12 kwietnia 2022 r. nadaje się je przez rozłączenie i ponowne połączenie; późniejsze konfiguracje powinny już je mieć.

Alerty mają poziom High, Medium lub Low. Wszystkie pojawiają się w Sophos Fusion; tylko High i Medium wysyłają też e-mail administratorom i superadministratorom oraz zmieniają stan domeny. W Alerts należy je zgrupować, otworzyć Mail Flow Rules i w View Details sprawdzić domenę, czas, obiekt i zmianę.

  • Znana zmiana nazwy listy: sprawdzić synchronizację nowej grupy, zaktualizować ją w ustawieniach domeny M365 i zapisać.
  • Zmiana zamierzona: udokumentować i uruchomić Run a Quick Test; zachować tylko po sukcesie.
  • Zmiana nieznana lub przypadkowa: ustalić zdarzenie audytu Microsoft 365 i autora. Cofnąć zrozumianą błędną zmianę i powtórzyć test. Gdy naprawa jest niejasna lub test zawodzi, użyć Reconnect, aby Sophos odtworzył albo włączył wymagane obiekty.

Sam alert nie dowodzi przerwania poczty. Planowana zmiana również nie jest bezpieczna tylko dlatego, że jest znana — rozstrzygają Quick Test i testy dostarczenia.

3. Naprawa SPF po powrocie do Microsoft 365

W Mailflow poczta wychodząca idzie z Microsoft 365 do Sophos i wraca do Microsoft 365. SPF może zawieść, jeśli regionalny nadawca Sophos nie jest autoryzowany w rekordzie SPF domeny.

v=spf1 include:spf.protection.outlook.com -all

Należy dodać domenę include opublikowaną dla regionu Sophos Fusion:

v=spf1 include:spf.protection.outlook.com include:<sophos-spf-domain> -all

<sophos-spf-domain> to symbol zastępczy, nie wartość do publikacji. Aktualną wartość regionalną pobiera się z Sophos Email domain information. Należy utrzymać jeden rekord TXT SPF na domenę i nie zmieniać końcowego mechanizmu bez analizy. Po propagacji DNS sprawdzić TXT i wysłać test wychodzący; SPF musi przejść dla oczekiwanej trasy.

4. Naprawa przekazywania i Microsoft DLP

Automatycznie przekazana na zewnątrz wiadomość jest odrzucana

Microsoft 365 przepisuje przez SRS envelope-from (P1 From). Jeśli Header-From nadal zawiera domenę zewnętrzną nieskonfigurowaną w Sophos Email, Sophos może odrzucić wiadomość. Sophos nie przekazuje ogólnie poczty pochodzącej z zewnątrz, gdyż tworzyłoby to ryzyko podobne do open relay i szkodziło reputacji.

  1. W Microsoft 365 Security Center otworzyć Policies & rules > Threat policies > Rules > Enhanced filtering.
  2. Wybrać łącznik dopuszczający pocztę przychodzącą z Sophos Email.
  3. Włączyć Automatically detect and skip the last IP address dla organizacji.
  4. Ustawić dotknięte przekazywanie tak, aby nadawcą była lokalna skrzynka chronionej domeny.
  5. Powtórzyć test z tym samym źródłem i celem; porównać nagłówki, Message Trace i Message History.

Nie dodawać dowolnych domen zewnętrznych do Sophos ani szerokiego wyjątku relay.

Microsoft DLP wysyła podwójne powiadomienia

Jeśli reguła DLP uruchamia się podczas obu przejść Mailflow, należy wykluczyć z niej tylko udokumentowane adresy IP nadawcy Sophos Email:

  1. Zalogować się jako administrator do portalu Microsoft Purview DLP.
  2. Edytować politykę i regułę w Advanced DLP rules > Customize advanced DLP rules.
  3. Wybrać Add exception > Except if sender IP address is i podać wyłącznie aktualne regionalne adresy Sophos z informacji o domenie.
  4. Zapisać i powtórzyć dla każdej dotkniętej reguły.
  5. Kontrolowaną wiadomością potwierdzić, że ocena DLP działa, ale powstaje jedno powiadomienie.

Nie rozszerzać wyjątku na zbędne zakresy; DLP pozostanie skuteczne dla innych tras.

5. Błąd 552 i usługi podpisu

Typowy NDR:

552 5.6.0 Headers too large (32768 max)

Sprawdzić pełne nagłówki. Powielone grupy, np. X-Sophos-Antispam, X-LASED-Hits, X-Microsoft-Antispam-Message-Info lub X-Microsoft-Antispam-Message-Info-Original, wskazują wielokrotne przetwarzanie. Dla CodeTwo lub Exclaimer błędna trasa często wygląda tak:

Microsoft 365 > Sophos > Microsoft 365 > signature service > Microsoft 365 > Sophos > Microsoft 365 > recipient

Docelowo każdy serwis przetwarza wiadomość raz:

Microsoft 365 > signature service > Microsoft 365 > Sophos > recipient

Sprawdzić łączniki i reguły usługi podpisu i Sophos. CodeTwo lub Exclaimer musi działać przed wychodzącą ścieżką Sophos; usunąć lub zawęzić nakładające się reguły, które ponownie kierują pocztę do Sophos. Regułę zewnętrzną ustawić zgodnie z aktualnymi zaleceniami dostawcy. Message Trace i nagłówki muszą pokazać jedno przejście przez każdy serwis.

Ograniczone obejście bez pętli

Jeśli nie ma podwójnej trasy, lecz duży nagłówek diagnostyczny nadal przekracza limit, utworzyć w Exchange Admin Center, Mail flow > Rules:

  • Apply this rule if: A message header > includes any of these words; nagłówek X-Sophos-Email-ID, słowo True.
  • Do the following: Modify the message properties > remove a message header; nagłówek X-Microsoft-Exchange-Diagnostics-untrusted.
  • Pozostałe wartości zostawić domyślne. Regułę umieścić po regułach prefilter i redirect Sophos Email; jeśli mają domyślne priorytety 0, 1 i 2, użyć priorytetu 3.

Najpierw wyeksportować lub udokumentować kolejność. Potem przetestować wiadomość dotkniętą i zwykłą. Reguła zmniejsza nagłówki, ale nie naprawia pętli. Usuwanie nagłówków Microsoft w Sophos przez .* też jest tylko tymczasowe; przy powielonych nagłówkach Sophos należy naprawić routing.

Oczekiwane zachowanie: dwie etykiety poufności

Microsoft 365 może dwukrotnie zastosować tę samą sensitivity label do poczty wychodzącej: przed wysłaniem do Sophos i po powrocie. Jeśli Message Trace pokazuje tę trasę bez pętli, jest to oczekiwane zachowanie Mailflow, a nie dowód drugiego skanowania Sophos. Nie zmieniać łączników tylko z tego powodu.

Walidacja, wycofanie i eskalacja

Naprawa jest zakończona, gdy:

  • domena pokazuje Connected w M365 Mailflow Domains, a Quick Test przechodzi;
  • wiadomość przychodząca i wychodząca są zgodne w Microsoft Message Trace i Sophos Message History i zostały dostarczone;
  • nagłówki pokazują tylko oczekiwane przejścia Sophos, Microsoft i usługi podpisu;
  • SPF przechodzi, a testy przekazywania lub DLP dają dokładnie oczekiwany wynik;
  • nie pojawiają się nowe alerty Mailflow High ani Medium.

Aby świadomie wycofać ręcznie, odłączyć domenę krzyżykiem obok Connected w M365 Mailflow Domains. Sophos usuwa aplikacje, łączniki i reguły utworzone dla domeny; może to potrwać kilka minut. Przed ponownym połączeniem sprawdzić usunięcie w App registrations w Microsoft Entra Admin Center oraz Mail flow > Rules i Mail flow > Connectors w Exchange Admin Center. Następnie połączyć z ważną zgodą.

Rozpoznanie blokady RBL Gateway przed wykryciem Mailflow

Jeśli wiadomość przychodząca zostaje odrzucona, dzienniki Sophos Gateway pokazują odrzucenie RBL, ale Sophos Message History nie zawiera odpowiadającego zdarzenia Mailflow, nadal aktywne połączenie Gateway mogło zastosować listę blokowania w czasie rzeczywistym, zanim Sophos zdołał wykryć połączenie Mailflow i przekazać wiadomość. Należy skorelować tę samą wiadomość i ten sam czas UTC w dziennikach Gateway, Microsoft Message Trace oraz Mailflow Message History. W takim przypadku brak zdarzenia Mailflow nie dowodzi awarii łącznika Mailflow.

Nie należy szeroko omijać ani globalnie wyłączać RBL. Nie wolno też przedłużać równoległego przetwarzania: po zweryfikowaniu Mailflow w obu kierunkach trzeba niezwłocznie usunąć stare połączenie Gateway zgodnie z planem migracji.

To kontrolowana naprawa, nie doraźne sprzątanie. W produkcji najpierw określić okno, alternatywną trasę i kryterium przerwania. Podczas migracji Gateway do Mailflow zachować udokumentowaną trasę Gateway tylko jako planowane wycofanie; Gateway i Mailflow nie mogą jednocześnie kierować tej samej domeny produkcyjnej przez Sophos, bo grożą podwójne skany i pętle. Jeśli obiekty pozostają, właściciel jest nieznany lub Reconnect zawodzi mimo uprawnień, zatrzymać zmiany i przekazać Sophos Support domenę, Message-ID, czasy UTC, nagłówki, ślady, Quick Test i spis obiektów.