Konfiguracja Sophos Firewall Mail Protection w MTA Mode

W MTA mode Sophos Firewall samodzielnie odbiera wiadomości, skanuje je i dostarcza do wewnętrznego serwera poczty lub kolejnego mail hop. Przepływ działa tylko wtedy, gdy rekord MX, automatyczna reguła MTA, SMTP route and scan Policy, relay, TLS i weryfikacja odbiorców są ze sobą zgodne.

Konfiguracja składa się z sześciu kroków: określenia przepływu i ścieżki awaryjnej, włączenia MTA mode, dodania domeny, utworzenia route and scan Policy, zabezpieczenia relay oraz zmiany rekordu MX. Następnie należy zweryfikować pocztę przychodzącą i wychodzącą za pomocą poleceń zewnętrznych, kwarantanny, spool i logów.

Kiedy warto użyć MTA mode

Mail Protection na zaporze sprawdza się głównie w świadomie zaprojektowanych środowiskach on-premises i hybrydowych, w których trzeba chronić lokalny Exchange lub inny serwer poczty. Dla Microsoft 365, Google Workspace i wielu środowisk wyłącznie chmurowych Sophos Email albo inna chmurowa brama pocztowa jest zwykle czytelniejszą architekturą. Dwie bramy w szeregu komplikują kwarantannę, nagłówki, TLS, SPF/DKIM/DMARC i diagnostykę.

Jeśli Exchange Online ma świadomie korzystać z MTA firewalla, Konfiguracja Sophos Firewall MTA z Microsoft 365 opisuje pełną ścieżkę EOP, relay, łącznik, MX i SPF.

Należy rozróżnić trzy funkcje Sophos Firewall:

• MTA mode: zapora odbiera, skanuje i routuje pocztę.
• Legacy mode: przezroczyste przetwarzanie proxy istniejącej ścieżki SMTP. Konfiguracja Mail Protection w Legacy mode opisuje NAT, reguły, polityki skanowania i weryfikację.
• SMTP Relay w Device Access: określa strefy, z których MTA jest osiągalny. Poczta przychodząca z Internetu wymaga WAN; relay wychodzący ogranicza się dodatkowo do konkretnych serwerów wewnętrznych.

Pobieranie istniejących wiadomości ze skrzynki przez POP3 lub IMAP jest osobnym zadaniem. Skanowanie i testowanie POP3 oraz IMAP na Sophos Firewall opisuje zaufanie TLS, opcjonalną politykę, regułę zapory i test odbiorczy.

Wymagane są ważna licencja Email Protection, działający routing i DNS, znany publiczny adres IP, wewnętrzny serwer z portem docelowym oraz zaplanowane strategie TLS, kwarantanny i wycofania zmiany. Według aktualnego zestawienia Sophos MTA mode nie jest dostępny na XGS 87/87w ani XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation i SXL2 Live Protection wymagają dostępu do Internetu. Routing poczty, skanowanie malware, filtrowanie MIME i SPX mogą nadal działać z odpowiednią licencją w środowisku airgap, ale aktywny MTA nie oznacza dostępności wszystkich kontroli ochronnych.

Kompleksowa konfiguracja MTA mode

1. Określenie przepływu i ścieżki awaryjnej

Dla poczty przychodzącej publiczny rekord MX wskazuje adres, na którym Sophos Firewall przyjmuje TCP 25. Zapora skanuje wiadomość i dostarcza ją do serwera wewnętrznego. Stara reguła DNAT nie może pozostawiać tego serwera bezpośrednio osiągalnego z Internetu bez kontroli, ponieważ pozwoliłoby to ominąć MTA. Publikowanie serwera przez DNAT wyjaśnia ogólną logikę DNAT.

Dla poczty wychodzącej tylko przewidziany serwer wysyła przez zaporę. Ścieżka, smarthost, PTR/rDNS, HELO, SPF, DKIM i DMARC muszą odpowiadać publicznej tożsamości nadawcy. Ogólna reguła LAN to WAN jest zbyt szeroka; baza reguł powinna jednoznacznie wskazywać dozwolonego nadawcę SMTP. Zasady Sophos Firewall opisują kolejność reguł.

Przed migracją należy udokumentować:

• bieżący rekord MX, priorytet i TTL;
• nowy publiczny adres zapory i wewnętrzny serwer docelowy;
• istniejące reguły DNAT i SMTP oraz konektory serwera;
• nadawców testowych dla obu kierunków;
• poprzedni MX lub ścieżkę poczty jako fallback;
• monitoring kolejki serwera, spool zapory i kwarantanny.

TTL należy obniżyć z wyprzedzeniem, jeśli może być potrzebne szybkie wycofanie. Zmiany produkcyjnego MX wykonuje się w oknie serwisowym.

2. Konfiguracja MTA mode i podstawowych ustawień SMTP

W Email > General settings wybrać w razie potrzeby Switch to MTA mode. Sophos Firewall tworzy regułę Any-to-Any Auto added firewall policy for MTA dla SMTP i SMTPS. Nie wolno jej edytować i powinna pozostać na początku listy. Przejście do Legacy mode usuwa ją, a powrót tworzy ponownie.

Następnie ustawić:

1. W SMTP hostname wpisać nazwę domeny, na przykład example.com, a nie hostname serwera wewnętrznego. Wartość pojawia się w HELO i bannerze SMTP powiadomień systemowych.

   Sprawdzić odpowiedź API XML: Dokumentacja SFOS 23 podaje status 506 z Message.AVGeneralConfInvalidSmtpNtfyHostname dla operacji Email Configuration w API XML. Jest to status operacji, a nie kod statusu HTTP. Klucz nie został rozwinięty do treści komunikatu i nie jest angielskim komunikatem błędu; nie pozwala ustalić konkretnych reguł walidacji. Jeśli pojawi się taka odpowiedź, sprawdzić przesłaną wartość nazwy hosta dla powiadomień, rzeczywistą odpowiedź operacji i zapisaną konfigurację przed uznaniem zmiany za udaną. Dodatkowy wiersz w dokumentacji nie dowodzi, że takie zachowanie podczas działania wprowadzono po raz pierwszy w SFOS 23.

2. Włączyć Reject based on IP reputation, aby odrzucać nadawców o złej reputacji.

3. W SMTP TLS configuration wybrać publicznie zaufany certyfikat, a Allow invalid certificate dopuszczać tylko dla udokumentowanych wyjątków.

4. Włączyć Disable legacy TLS protocols, o ile udokumentowane stare systemy tego nie wykluczają. Opcja wyłącza protokoły starsze niż TLS 1.1, lecz nie wymusza wyłącznie aktualnych wersji TLS.

5. Włączyć Scan outgoing mails, jeśli wiadomości wychodzące także mają być skanowane.

Z Require TLS negotiation należy postępować ostrożnie: jeśli SFOS nie zestawi wymaganego TLS, usuwa pocztę do danego celu lub z określonej domeny nadawcy. Pomoc SFOS 22/23 ostrzega, że połączenie i weryfikacja SMTP TLS używają adresu IP domeny zamiast jej nazwy; wiele domen na jednym IP może więc powodować błędy certyfikatu. To ostrzeżenie dokumentacji, a nie dowód algorytmu dopasowywania certyfikatów we wdrożonym buildzie.

Skip TLS negotiation wybiera zdalne hosty pocztowe lub sieci dla nieszyfrowanych połączeń SMTP; udokumentowany limit to 512 wpisów hostów. Nie jest to rozwiązanie problemu błędnego certyfikatu. Allow invalid certificate jest wyjątkiem od weryfikacji partnera TLS, a nie przejściem na tekst jawny. Nie zakładać pierwszeństwa przy nakładaniu się list Require i Skip ani przejścia na tekst jawny po niepowodzeniu wymaganego TLS. Wyjątki ograniczać i dokumentować, a przed ich zmianą sprawdzić rzeczywisty wynik połączenia i weryfikacji certyfikatu we wdrożonym buildzie.

Ustalenie globalnych limitów SMTP przed politykami

Ustawienia w Email > General settings dotyczą wszystkich wiadomości i są przetwarzane przed politykami SMTP oraz POP-IMAP. Reject based on IP reputation nie jest więc akcją pojedynczej polityki: SFOS sprawdza adres IP nadawcy przed kontrolami spamu polityki SMTP. Blocked senders również działa globalnie, ale blokuje tylko pocztę przychodzącą.

W SMTP settings opcja Don’t scan emails greater than określa maksymalny rozmiar wiadomości dla globalnego skanowania SMTP. 0 oznacza 51,200 KB, a nie brak limitu. Dla większych wiadomości dostępne są Accept, Reject i Drop. Accept dostarcza bez skanowania, Reject odrzuca i informuje nadawcę, a Drop usuwa bez powiadomienia. Wybór należy udokumentować jako świadomą lukę w skanowaniu lub decyzję o dostarczeniu oraz przetestować wiadomością tuż poniżej i powyżej limitu.

Ustawienia SMTP DoS settings ograniczają równoczesne połączenia, liczbę wiadomości na połączenie, odbiorców na wiadomość oraz tempo wiadomości i połączeń. SFOS ustala maksymalną liczbę połączeń na podstawie pamięci RAM i procesora. Udokumentowane wartości domyślne to 1000 wiadomości na połączenie i 100 odbiorców na wiadomość. Własne wartości należy wyprowadzić z rzeczywistego wolumenu poczty; zbyt niski limit może potraktować prawidłowe listy dystrybucyjne lub skanery jak atak.

W Advanced SMTP settings SFOS może odrzucać nieprawidłowe HELO lub brak RDNS, a po włączeniu Do strict RDNS checks nazwę hosta, która nie rozwiązuje się z powrotem do źródłowego adresu IP. Tych kontroli nie należy wprowadzać równocześnie z szerokim wyjątkiem. Najpierw trzeba zarejestrować w logu rzeczywiste ścieżki partnerów, newsletterów i aplikacji, a następnie przetestować je osobno.

Banner wychodzący może używać Inline, no conversion, opcji MIME part albo Off. Skanowanie SMTP lub SMTPS musi być aktywne w pasującej regule zapory. Ponieważ banner zmienia body i może unieważnić istniejący podpis DKIM, podpis należy dodać po tej zmianie albo wyraźnie potwierdzić u odbiorcy, że planowany podpis pozostaje prawidłowy.

Przed aktualizacją zapisać także limity tempa SMTP. Udokumentowane zakresy to 1–1000 wiadomości na połączenie, 1–512 odbiorców na wiadomość, 1–1000 wiadomości na host na minutę i 1–100 połączeń na host na sekundę. Domyślne wartości obu limitów tempa wynoszą odpowiednio 1000 i 100. Podczas migracji SFOS zachowuje obsługiwane wartości tempa wiadomości i połączeń, ale wartości przekraczające maksimum przywraca do domyślnych. Po aktualizacji porównać zapisane wartości, a nie tylko stary eksport konfiguracji.

3. Dodanie domeny jako Address Group

1. Otworzyć Email > Address group > Add.
2. Ustawić Group type na Email address/domain, a Type na Manual.
3. Dodać chronioną domenę, na przykład example.com.
4. Zapisać grupę.

Podczas tworzenia grupy przed zapisaniem podać także czytelną Name. Istniejącą grupę edytować przez Edit w Email > Address group; import pliku rozpocząć przez Import. RBL (IPv4) przyjmuje adresy IPv4, a RBL (IPv6) adresy IPv6. Email address/domain obsługuje wpisy ręczne albo import CSV/tekstu. Dopasowanie RBL używa IP nawiązującego połączenie i akcji wskazanej w policy SMTP; nadal obowiązuje osobno udokumentowane odrzucanie SPF/RBL. Zachować domyślne nazwy Premium RBL services i Standard RBL services, chyba że wyraźnie zaplanowana zmiana wymaga inaczej.

Address Groups nie ograniczają się do domen pocztowych. Group type może mieć wartość Email address/domain, RBL IPv4 albo RBL IPv6. Ten sam adres może należeć do kilku grup, co pozwala tworzyć oddzielne cele policy bez kopiowania lub zmiany nazwy wpisu.

W przypadku większych list SFOS może zaimportować plik CSV lub tekstowy zawierający maksymalnie 400 adresów albo domen. Nieprawidłowe i zduplikowane wpisy są pomijane. Po imporcie należy sprawdzić liczbę wpisów i kilka przykładów, zanim grupa zostanie przypisana do policy produkcyjnej.

Nowe SMTP route and scan Policies planuje się dla domen, nie pojedynczych adresów odbiorców. Zmigrowane pojedyncze adresy mogą nadal działać, ale nie można ich dodawać ani edytować w aktualnych zasadach.

4. Utworzenie SMTP route and scan Policy

Otworzyć Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Nadać czytelną nazwę, na przykład Inbound example.com to Exchange.
2. W Protected domain wybrać Address Group.
3. Wybrać Route by:
   • Static host: stały adres IP serwera; przy awarii zapora próbuje kolejnego hosta z listy.
   • DNS host: nazwa DNS, na przykład mailserver.example.com; wiele rekordów A jest używanych między dostawami, a niedostępne serwery są pomijane.
   • MX: dostawa na podstawie rekordu MX.
4. Dla Static host wybrać serwer w Host list. W razie potrzeby utworzyć IP host w Hosts and services > IP host.
5. Ustawić Global action na Accept dla świadomie chronionych domen. Reject odrzuciłoby wszystkie wiadomości przychodzące i wychodzące związane z tymi domenami i powiadomiło nadawcę.
6. Włączyć Spam protection i Malware protection zgodnie z założeniami operacyjnymi.
7. File protection i Data protection włączyć dopiero po poznaniu wpływu na załączniki, duże wiadomości, SPX i DKIM.
8. Zapisać zasadę.

Aby zmienić istniejącą politykę SMTP route and scan, w Email > Policies and exceptions wybrać Edit przy odpowiedniej polityce, zmienić wymagane ustawienia i zapisać politykę. Następnie ponownie sprawdzić dopasowanie polityki i dostarczenie za pomocą kontrolowanej wiadomości testowej.

Przy Route by MX rekord MX rozwiązany przez zaporę nie może wskazywać tej samej zapory, bo powstanie pętla routingu. Zapora musi poprawnie rozwiązywać cele wewnętrzne; przy split DNS pomagają DNS Request Routes.

Opcja Route inbound mail through gateway jest potrzebna tylko w szczególnych projektach, np. dla serwerów w strefie WAN, zastosowania pierwotnej reguły do celów LAN/DMZ lub wyboru konkretnej bramy przy wielu łączach. Nie należy jej włączać bez konkretnej potrzeby routingu.

5. Zabezpieczenie dostępu przychodzącego i relay wychodzącego

W Administration > Device access zezwolić na SMTP Relay ze wszystkich stref, które muszą osiągać MTA. Poczta z Internetu wymaga WAN; wychodząca dodatkowo strefy serwera wewnętrznego, zwykle LAN lub DMZ. Następnie w Email > Relay settings > Host-based relay ograniczyć dostęp do konkretnych serwerów, skanerów lub aplikacji.

Szerokie uprawnienia hostów lub sieci tworzą ryzyko open relay. Drukarki i aplikacje wysyłające pocztę należy dokumentować jako konkretne obiekty hostów. Zabezpieczanie dostępu do Sophos Firewall wyjaśnia Device Access.

Listy Allow i Block nie działają zgodnie z zasadą, że Block ma zawsze pierwszeństwo. Jeśli ten sam host lub sieć występuje na obu listach Host-based relay albo Upstream host, SFOS zezwala na relay. Przed aktywacją należy usunąć takie nakładanie i wykonać test negatywny ze źródła bez uprawnień.

Dozwolony host nie omija też skanowania poczty. Jeśli SFOS nie może przeskanować źródłowego adresu IP dopuszczonego do host-based relay, odrzuca go. Zezwolenie na relay nie potwierdza więc ani skutecznego skanowania treści, ani dostarczenia; oba elementy sprawdza się rzeczywistą wiadomością testową i logami MTA.

SMTP route and scan Policy nie obsługuje SMTP AUTH. Dla urządzeń niezawodną metodą jest więc Host-based relay. Istnieją osobne Authenticated relay settings dla użytkowników i grup, lecz według Sophos nie obsługują one zgodnego z RFC standardu SMTP Authentication, więc trzeba sprawdzić zgodność klienta. Czym innym jest logowanie zapory do upstream smarthost, gdzie SFOS obsługuje PLAIN i LOGIN. Jako smarthost nie wolno podawać adresu interfejsu tej samej zapory, ponieważ tworzy to pętlę routingu.

Jeśli poczta wychodząca używa smarthost, skonfigurować Email > General settings > Smarthost settings: wybrać Hostname, ustawić Port (domyślnie 25) i tylko jeśli serwer tego wymaga, włączyć Authenticate device with smarthost oraz bezpiecznie podać dane logowania. Kieruje to pocztę wychodzącą przez pośredni MTA; nie uprawnia klientów do relay przez zaporę. Wymagania TLS i końcową publiczną tożsamość nadawcy dostosować do tego dodatkowego etapu oraz zapisać poprzednie ustawienia do wycofania zmiany.

Relay upstream i serwery pocztowe w chmurze

Upstream host w Email > Relay settings określa, które wcześniejsze źródła SMTP mogą dostarczać pocztę przychodzącą; Host-based relay określa hosty uprawnione do relay wychodzącego. Skonfigurować te zakresy oddzielnie. Jeśli inna brama jako pierwsza odbiera pocztę publiczną, do listy upstream dodać jej rzeczywiste sieci źródłowe, nie adres docelowego serwera pocztowego. W obu sekcjach pasujące zezwolenia mają pierwszeństwo przed nakładającymi się blokadami.

Dla serwera w chmurze włączyć SMTP Relay w jego strefie źródłowej, zwykle WAN, i ograniczyć wychodzący relay oparty na hostach do rzeczywistych adresów źródłowych serwera. Serwer w chmurze również musi zezwalać na planowane połączenie relay z zaporą. Oddzielić publiczny MX wskazujący zaporę od celu dostarczenia rozwiązywanego przez SFOS: procedura chmurowa wymienia oba cele MX bez wyjaśnienia rozdzielenia DNS. Użyć osobnego hosta DNS, celu statycznego lub świadomie utrzymywanego split DNS; Route by MX nie może kierować poczty z powrotem do zapory.

Procedura chmurowa zaleca też przejście do Legacy i z powrotem, gdy brakuje automatycznej reguły. Usuwa to i odtwarza regułę oraz zmienia bieżące przetwarzanie poczty. Nie stosować tego jako nieplanowanej naprawy: najpierw zapisać polityki, kolejki i ścieżkę awaryjną, a potem zbadać brakującą regułę z pomocą wsparcia. Zatwierdzoną zmianę trybu wykonać w oknie serwisowym, powtarzając testy poczty przychodzącej, wychodzącej i odrzucenia niedozwolonego relay.

Starsze przykłady chmurowe i finansowe wskazują nazwę serwera wychodzącego jako SMTP hostname, natomiast nowsza konfiguracja MTA wymaga domeny, nie hostname serwera. Dla powiadomień systemowych stosować nowszą wskazówkę dotyczącą domeny; ustawienie to nie określa tożsamości każdej przekazywanej wiadomości. Podobnie weryfikacja DKIM poczty przychodzącej używa publicznego klucza DNS nadawcy i nie wymaga utworzenia klucza podpisywania poczty wychodzącej tylko dlatego, że opis MTA wymienia podpisywanie obok weryfikacji.

Wiele interfejsów WAN lub adresów IP aliasów

MTA sam tworzy wychodzące połączenie SMTP. Jeśli możliwych jest kilka publicznych adresów nadawcy, zwykła reguła klienta nie wystarczy. Sophos rozróżnia trzy przypadki: przy jednym interfejsie WAN i wielu adresach IP aliasów tworzy się regułę SNAT z wybranym publicznym Translated source. Przy wielu interfejsach WAN bez aliasu tworzy się trasę SD-WAN dla SMTP, SMTP(S) i SMTPS_465. Gdy występują zarówno liczne interfejsy WAN, jak i aliasy, łączy się SNAT z trasą SD-WAN.

Reguła SNAT pozostawia cel i usługę bez zmian, używa zaplanowanego łącza WAN jako interfejsu wyjściowego i tłumaczy na MASQ lub wybrany adres IP aliasu. Trasa SD-WAN używa grupy internetowej jako celu, trzech usług SMTP, planowanej bramy głównej i opcjonalnej bramy zapasowej. Brama zapasowa ma sens tylko wtedy, gdy rzeczywiście dopuszcza wychodzący TCP 25, a jej publiczny adres również uwzględniono w rekordzie SPF domeny pocztowej.

W tym oficjalnym przebiegu dla wielu łączy WAN Sophos wymaga kolejności static, vpn, sdwan_policyroute i włącza SD-WAN dla ruchu generowanego przez system. Polecenia należy wykonać w Device Console (opcja 4 menu CLI), nie w Advanced Shell. Najpierw odczytać obie wartości początkowe, wprowadzić zmiany, a następnie ponownie je sprawdzić:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

Kolejność tras działa globalnie i nie jest odizolowanym przełącznikiem poczty. Przed zmianą trzeba udokumentować wszystkie nakładające się ścieżki statyczne, VPN i SD-WAN oraz obie odczytane wartości. Przy wycofaniu należy odtworzyć pełną poprzednią kolejność za pomocą system route_precedence set ... i przywrócić system-generate-traffic do początkowego stanu enable albo disable. Następnie sprawdza się nie tylko liczniki SMTP, lecz także rzeczywiście użyty adres źródłowy, dostarczenie, wynik SPF i awarię bramy głównej. Sprawdzanie routingu SD-WAN dla ruchu generowanego przez system opisuje ogólną bezpieczną procedurę i wycofanie.

W trasie SD-WAN opcja Route only through specified gateways celowo uniemożliwia przejście na inne bramy: gdy wybrane bramy są nieosiągalne, zapora odrzuca ruch. Zdecydować, czy jest to lepsze od nieplanowanego IP nadawcy, i przetestować tę awarię. Wybrać obiekty IPv4 lub IPv6 zgodne z rzeczywiście opublikowaną ścieżką poczty; nie kopiować grupy Internet IPv4 do projektu IPv6.

6. Zmiana rekordu MX

Publiczny MX zmienić na adres zapory dopiero po przygotowaniu reguły MTA, domeny, policy, relay i wewnętrznej ścieżki dostawy. Natychmiast wysłać zewnętrzną wiadomość testową i sprawdzić ją w Log Viewer lub Mail logs, na serwerze wewnętrznym i w skrzynce.

Jeśli zewnętrzni nadawcy nie osiągają zapory lub wiele prawidłowych wiadomości jest odrzucanych, przywrócić udokumentowaną poprzednią ścieżkę. Z powodu pamięci podręcznej DNS wycofanie nie zadziała natychmiast wszędzie. Dlatego starą i nową ścieżkę należy równolegle utrzymywać i monitorować co najmniej do czasu wygaśnięcia najdłuższego wcześniej obowiązującego TTL. Jeśli zapora przyjmuje, lecz nie dostarcza, najpierw sprawdzić routing, DNS, TLS, recipient verification i logi serwera.

Świadomy wybór ochrony

Działania dla spamu, malware i danych wrażliwych

Dla spamu przychodzącego, prawdopodobnego spamu i poczty masowej jawnie wybrać działanie: None dostarcza bez zmian, Warn dodaje skonfigurowany prefiks tematu, Quarantine zatrzymuje wiadomość, a Drop odrzuca bez powiadomienia nadawcy. Ustawić odpowiednie prefiksy tematu dla spamu i poczty masowej. Te wybory nie zastępują odrębnego odrzucania SPF/RBL.

Dla malware Selected antivirus action oferuje None, Drop i Quarantine; Notify sender skonfigurować oddzielnie. Quarantine unscannable content obejmuje treści niemożliwe do zbadania, w tym uszkodzone, zaszyfrowane lub skompresowane pliki, zbyt duże wiadomości i wewnętrzne błędy skanowania. Zakończone dostarczenie nie dowodzi przeskanowania wszystkich załączników. Zero-Day Protection ma własny maksymalny rozmiar analizy: większe pliki nie są analizowane przez tę usługę. Przetestować ten limit oddzielnie od globalnego rozmiaru SMTP i limitów odrzucania File protection.

W Data protection wybrać dokładną Data control list, jej działanie i ewentualnie SPX template: Accept dostarcza, Accept with SPX szyfruje i dostarcza, a Drop odrzuca bez powiadomienia. Notify sender jest osobnym wyborem. Przypisanie SPX na poziomie domeny szyfruje całą pasującą pocztę wychodzącą; użyć wyzwalacza Data Control, jeśli szyfrowane mają być tylko wiadomości pasujące do danych finansowych. Przykład hasła odbiorcy używa Specified by recipient i zatrzymuje wiadomość do rejestracji hasła. Szablon, Reply Portal i rejestrację skonfigurować razem według połączonego runbooka SPX, a następnie przetestować wiadomość pasującą i niepasującą zamiast tylko włączać Data protection.

Korzystanie z własnych typów plików i Data Control Lists

W MTA mode własny typ pliku tworzy się w Email > Policies and exceptions > File type > Add na podstawie szablonu, rozszerzeń plików albo typów MIME. Rozszerzenia wpisuje się bez kropki na początku. Edytować można tylko własne typy. Nowy typ nie jest też automatycznie dodawany do istniejących policy: trzeba otworzyć konkretną SMTP route and scan Policy, dodać go w File protection i ponownie zapisać policy. Pozytywny test załącznika oraz podobny test negatywny potwierdzają dopasowanie lepiej niż sama nazwa obiektu.

W File protection > Block file types opcja All blokuje wiadomości z załącznikami; nie oznacza skanowania wszystkich załączników. None zezwala na załączniki w ramach tego filtra plików, ale nie omija kontroli malware, spamu, Data Protection ani innych kontroli. Pomoc policy podaje, że wybrane nagłówki MIME wypełniają MIME whitelist, zezwalając na te typy i blokując pozostałe. Nagłówki MIME i rozszerzenia nie dowodzą nieszkodliwej zawartości. Sprawdzić dozwolone i blokowane załączniki we wdrożonym buildzie przed zastosowaniem szczegółowej konfiguracji whitelist.

Data Control List składa się z Content Control Lists, czyli CCL, dla zdefiniowanych typów treści, takich jak dane finansowe lub osobowe. Podczas dodawania w Email > Data control list > Add należy filtrować CCL według Type i Region oraz wybrać tylko rzeczywiście potrzebne wpisy. Akcja jest definiowana dopiero w powiązanej policy. Kontrolowane dopasowanie i podobna treść bez dopasowania pozwalają sprawdzić, czy match i akcja współdziałają bez zbędnych false positives.

Spam protection to więcej niż akcja dla spamu. Dopasowania SPF i RBL powodują bezpośrednie odrzucenie wiadomości i nie podlegają zwykłym akcjom dla spam lub probable spam. Greylisting celowo tymczasowo odrzuca wiadomość i wymaga ponownej próby serwera nadawcy.

Dla Reject based on BATV należy najpierw skonfigurować wspólny BATV secret w Email > General settings > Advanced SMTP settings. Na wielu własnych systemach MX używa się tego samego secret. SFOS łączy go ze znacznikiem czasu i adresem nadawcy, tworząc podpis Return-Path, który wygasa po siedmiu dniach. Dlatego błąd BATV należy porównać z secret, czasem systemowym, ścieżką nadawcy i wiekiem podpisu, zamiast ukrywać go za szerokim wyjątkiem bez terminu.

Recipient verification blokuje wiadomości do nieznanych odbiorców:

• With callout: pyta serwer docelowy. Jeśli jest chwilowo niedostępny, SFOS po określonym czasie akceptuje odbiorców zamiast trwale blokować cały przepływ.
• In Active Directory: sprawdza przez Simple, SSL lub STARTTLS z timeoutem 30 sekund. Podać serwer AD, Bind DN i Base DN. Bind DN to pełna nazwa wyróżniająca, w tym CN skonfigurowanej tożsamości bind; Base DN jest punktem początkowym wyszukiwania w katalogu. Użyć wartości właściwych dla własnego katalogu. Przykład administratora w pomocy nie dowodzi konieczności uprawnień Domain Admin. Wybrać transport zgodny z wdrożoną polityką zaufania i bezpieczeństwa; sama etykieta SSL lub STARTTLS nie dowodzi poprawnej weryfikacji certyfikatu.

Malware Protection może używać jednego lub dwóch skanów antywirusowych. Dla Zero-Day Protection przy jednym skanie Sophos musi być silnikiem głównym. Sophos Firewall Zero-Day Protection wyjaśnia ograniczenia i decyzje o dopuszczeniu plików.

Według pomocy policy SFOS 22/23 Single antivirus wybiera silnik główny tylko dla poczty przychodzącej; poczta wychodząca korzysta z obu silników. Dual antivirus skanuje najpierw silnikiem głównym, potem pomocniczym. Silnik główny, Sophos lub Avira, wybiera się globalnie w Email > General settings. Wybór Avira wyłącza Zero-day protection w policy SMTP z pojedynczym skanowaniem antywirusowym; Sophos musi być główny, aby używać Zero-Day Protection z jednym skanem. Pomoc ustawień ogólnych opisuje pojedynczy skan jako użycie wyłącznie silnika głównego, bez rozróżnienia kierunku z tabeli policy. Ta różnica dokumentacji nie dowodzi rzeczywistego użycia silników: sprawdzić build, policy, kierunek poczty i stan ochrony przed zmianą i po niej. Zapisać wcześniejsze ustawienia; przywrócenie wyboru silnika nie dowodzi ponownego włączenia Zero-day protection.

Limit polityki Drop message greater than w File protection nie jest tym samym co globalne zachowanie dla zbyt dużych wiadomości: w tym miejscu większe wiadomości są usuwane. SFOS sprawdza także widoczną treść i treść formatów pakietowych, takich jak docx, xlsx, pptx, odt, ods, odp i odg. Pozytywny test wyłącznie z nieopakowanym plikiem tekstowym nie potwierdza więc, jak te same informacje zostaną potraktowane w dokumencie Office.

Po włączeniu DKIM verification SFOS rozróżnia niezgodność skrótu, nieprawidłowy podpis lub niedostępny klucz publiczny oraz brak podpisu DKIM. Dla każdego wyniku można wybrać Accept, Quarantine lub Reject. Według Sophos wiadomości podpisane DKIM z RSA-SHA1 lub kluczem o długości poza zakresem od 1024 do 4096 bitów trafiają do kwarantanny. Tę kontrolę poczty przychodzącej należy testować oddzielnie od podpisywania wychodzącego.

Przy poczcie wychodzącej ważna jest kolejność przetwarzania. Szyfrowanie SPX, prefiksy tematu, File lub Data Protection i bannery wychodzące mogą zmienić header lub body po dodaniu podpisu DKIM. Weryfikacja DKIM u odbiorcy wtedy zawiedzie. Trzeba ustalić, czy podpisuje serwer wewnętrzny, Sophos Firewall czy późniejsza brama.

Podpisywanie wychodzących wiadomości przez DKIM na firewallu

Jeżeli podpisywać ma Sophos Firewall, dla każdej domeny nadawcy dodać podpis w Email > General settings > DKIM signing > Add. Domain to FQDN domeny pocztowej, a Key selector to dokładnie ten selektor, który następnie zostanie opublikowany w publicznym DNS. Nazwa taka jak fw01 lub zurich ułatwia zrozumienie późniejszej rotacji kluczy, ale nie jest funkcją bezpieczeństwa.

SFOS wymaga prywatnego klucza RSA o długości od 1024 do 2048 bitów między -----BEGIN RSA PRIVATE KEY----- i -----END RSA PRIVATE KEY-----. Dla nowych konfiguracji rozsądnym wyborem jest 2048 bitów. Nie należy używać RSA-SHA1. Według Sophos firewall nie akceptuje klucza 1024-bitowego wygenerowanego przez PuTTYgen, dlatego również tam trzeba wybrać 2048 bitów. Klucz prywatny należy przechowywać wyłącznie na firewallu i nigdy nie umieszczać go w DNS, zgłoszeniach ani publicznej dokumentacji.

Po zapisaniu u autorytatywnego dostawcy DNS opublikować rekord TXT DKIM selektora z kluczem publicznym. Dopiero gdy rekord jest rozwiązywany z zewnątrz, wysłać nową wiadomość testową przez przewidzianą wychodzącą ścieżkę MTA. Otrzymany nagłówek musi zawierać oczekiwany selektor i domenę, a weryfikacja DKIM u odbiorcy musi się udać. Jeśli brakuje podpisu, sprawdzić domenę nadawcy, dopasowanie policy i Scan outgoing mails. Jeśli weryfikacja nie powiedzie się, najpierw porównać rekord DNS, selektor, użyty klucz oraz późniejsze zmiany wykonywane przez SPX, bannery, File Protection lub Data Protection.

Konfiguracja i testowanie szyfrowania poczty SPX wyjaśnia współdziałanie szablonu, priorytetu wyzwalaczy, modelu hasła i Reply Portal.

Bezpieczna automatyzacja ustawień MTA przez XML API

W automatyzacji ustawienia globalne, grupy adresowe i polityki SMTP pozostają odrębnymi obiektami docelowymi. Najpierw odczytać build, aktywny tryb poczty, zapisane wartości i zależne polityki; przygotować kopię zapasową oraz precyzyjny plan wycofania zmiany. Wysłać potwierdzone żądanie z jawnie wskazaną operacją tylko dla potrzebnego obiektu docelowego. Następnie porównać odpowiedź operacji, ponownie odczytany stan i wynik odpowiedniego testu przepływu poczty. Także po błędzie lub przekroczeniu limitu czasu najpierw sprawdzić przez ponowny odczyt, czy coś zostało już zapisane, zamiast ponawiać żądanie zapisu w ciemno. Dostęp, przechowywanie sekretów i analizę odpowiedzi opisuje Zabezpieczanie dostępu do XML API.

Dokumentacja referencyjna obiektów SFOS 22/23 nie zawiera gotowych payloadów produkcyjnych. Przykłady XML, tabele parametrów i pomoc WebAdmin mogą podawać różną pisownię, wartości lub ustawienia domyślne. Puste komórki wartości domyślnych ani Any nie potwierdzają bezpiecznej pustej wartości ani zachowania pól pominiętych w żądaniu. Nierozwinięte stałe $EMAILPROTECTION{…} nie są potwierdzonymi literałami API. Jeśli składnia, operacja lub skutek pozostają niewyjaśnione, zatrzymać się przed zapisem i skorzystać z API help zainstalowanego buildu lub uzyskać oficjalne wyjaśnienie. Same różnice w dokumentacji nie dowodzą zmiany produktu.

Rozróżnianie globalnych ustawień SMTP, TLS i relay

W EmailConfiguration limit skanowania SMTP i wartości DoS należą do SMTPSSettings, a odrębne wartości POP/IMAP do POPIMAPSettings. Pola o tej samej nazwie DontScanEmailsGreaterThan nie wolno przypisać do niewłaściwego protokołu. RecipientHeaders z powtarzanym Header dotyczy rozpoznawania odbiorców POP/IMAP, a nie routingu SMTP. Bannery znajdują się w GeneralSettings. Podobnie SMTPTLSConfiguration i POPSIMAPTLSConfiguration stanowią odrębne konteksty: TLSCertificate, AllowInvalidCertificate i DisableTLS1 nie dają się jednoznacznie wskazać za pomocą pojedynczej nazwy pola bez określenia kontekstu. Wyjątek SMTP nie może niezauważenie osłabić także zabezpieczeń POP/IMAP. Po zapisaniu ponownie odczytać oba konteksty osobno i przetestować tylko zamierzoną ścieżkę poczty.

BypassSpamCheck w SMTPSSettings opisuje według tabeli API pomijanie skanowania antyspamowego dla uwierzytelnionego ruchu. Tabela podaje wartość domyślną Disable, natomiast przykład XML ustawia Enable. Nie przyjmować przykładu jako bezpiecznej konfiguracji domyślnej: przed zmianą wyjaśnić, jaki ruch w danym buildzie jest uznawany za uwierzytelniony i która kontrola antyspamowa jest pomijana. Zamierzony wyjątek ograniczyć do wąskiego zakresu i sprawdzić jego wpływ na wiadomości pasujące oraz niepasujące do wyjątku; nie uznawać innych obszarów skanowania za automatycznie wyłączone z kontroli.

Źródło wartości liczbowych SMTP ma znaczenie: tabela API podaje dla DontScanEmailsGreaterThan 1024 KB, dla MaximumConnections 5000 w zakresie 1–20000, a dla MaximumConnectionsHost 100 w zakresie 1–10000. Dla MaximumEmailsConnection podaje wartość domyślną 100, natomiast przykład XML zawiera 1000; pomoc WebAdmin również podaje 1000. MaximumRecepientsEmail to pisownia użyta w źródle, z wartością domyślną 100 i zakresem 1–512. Dla EmailsRate i ConnectionsRate tabela API podaje wartości domyślne 1000 i 100, w obu przypadkach z zakresem 1–20000; pomoc WebAdmin ogranicza natomiast tempo do 1–1000 na minutę oraz 1–100 na sekundę i określa maksymalną liczbę połączeń na podstawie sprzętu. Dlatego nie przyjmować maksymalnych wartości z tabel jako aktualnych limitów interfejsu ani wartości z przykładów jako domyślnych. Opisane powyżej limity WebAdmin i kontrola aktualizacji pozostają miarodajne dla tego procesu; automatyzacja musi porównywać wartości rzeczywiście zapisane w danym buildzie.

Dalsze rozbieżności składni wykluczają import przykładu w ciemno: VerifySendersIPReputation ma w przykładzie XML wartość Enable, ale tabela API podaje on/off przy wartości domyślnej Disable; SMTPSDosSettings opisano tam jako Integer z wartością domyślną Disable, natomiast przykład zawiera Enable. W przypadku bannera teksty z przykładów różnią się od wartości tabeli inline_plain, mimepart, off. Nie „naprawiać” samodzielnie tych zapisów, lecz przed wysłaniem żądania potwierdzić prawidłową pisownię i wartości. Osobno uwzględnić istniejącą uwagę dotyczącą Email Configuration, status 506.

AdvancedSMTPSetting również jest ustawieniem globalnym. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks i ScanOutboundEmails sterują opisanymi powyżej kontrolami HELO/RDNS oraz poczty wychodzącej. FirewallRelateInboundMails dotyczy odrębnej ścieżki przez bramę i reguły zapory; przykład podaje Disable, a tabela Turn on/Turn off. Dla sekretu BATV przykład zawiera BATVSecret, natomiast tabela BATVsecret. Przed zapisem potwierdzić wielkość liter i prawidłowe wartości; nie przedstawiać żadnego z tych wariantów jako przetestowanego payloadu. Użyć wspólnego sekretu z chronionego magazynu; nie używać sekretu z przykładu ani nie kopiować sekretu do zgłoszenia, repozytorium lub logu żądań. Zaplanować zmianę sekretu na wszystkich objętych nią systemach MX, a następnie sprawdzić BATV i zwykłą wysyłkę.

W RelaySettings występują HostBased i UpstreamHost, każde z własnymi listami AllowRelay i BlockRelay. Pod nimi znajdują się HostsOrNetworks i powtarzane wpisy HostsOrNetwork. Ta sama nazwa elementu końcowego nie oznacza więc tego samego zakresu relay. AuthenticatedRelaySettings zawiera osobno AuthenticatedRelay oraz UsersOrGroups z UsersOrGroup. Grupy otwarte lub gościnne pokazane w przykładzie producenta nie są bezpiecznym wyborem. Użyć tylko zaplanowanych tożsamości i obiektów hostów, usunąć nakładanie się list, a następnie sprawdzić dozwoloną wysyłkę oraz niedozwolony relay z odrębnego źródła.

W SmarthostSettings opcja UseSmarthost włącza pośredni etap dla poczty wychodzącej; SmarthostList z powtarzanym Hostname wybiera cele, a Port port docelowy. Tabela API podaje 1–65535, ale nie podaje domyślnego portu; 25 występuje w przykładzie oraz jako wartość domyślna w pomocy WebAdmin. AuthenticateDevicewithSmarthost jest odrębną opcją: bezpiecznie podać Username i Password tylko wtedy, gdy logowanie jest wymagane. Tabela API podaje dla obu przełączników aktywacji wartość domyślną Disable, natomiast przykład włącza oba. passwordform="encrypt" jest składnią hasła z przykładu, a nie zgodą na ponowne użycie zaszyfrowanych wartości z innej zapory. Niewyjaśnione pochodzenie lub wymagania importu oznaczają konieczność wstrzymania żądania. Następnie sprawdzić cel, TLS, uwierzytelnianie i dostarczenie przez ten etap, a nie tylko zezwolenie na relay.

Precyzyjna zmiana grup adresowych i polityk SMTP

Dla MTA przewidziano przykładowy obiekt MTAAddressGroup, a nie podobnie nazwany AVASAddressGroup z innego kontekstu poczty. Name identyfikuje grupę. GroupType określa odpowiednią listę: tabela API rozróżnia RBLIPv4, RBLIPv6, IPAddress i EmailAddressOrDomain oraz pola wpisów RBLName, IPAddressNetwork i EmailAddressDomain. Przykład domeny pocztowej używa EmailAddressList z powtarzanym EmailAddressDomain i EmailImportType ustawionym na Manual. Dla Import i EmailAddressFile wyjaśnić sposób przesyłania pliku właściwy dla buildu: tekst opisu sprzecznie przypisuje pole pliku do importu ręcznego. Sukces HTTP nie potwierdza ani wszystkich zaimportowanych wpisów, ani ostatecznego składu grupy. Odczytać liczbę wpisów, pominięte wpisy i konkretne wartości domen, zanim polityka zacznie używać grupy.

Dla Delete Address Group strony SFOS 22/23 podają wiersze statusów, ale nie zawierają definicji parametrów ani przykładu usunięcia. Nie można z tego wywnioskować ani dokładnej tożsamości obiektu dla operacji Remove, ani działającego żądania. Nie wstawiać po prostu Name lub obiektu używanego do tworzenia do payloadu Remove. Najpierw sprawdzić użycie w konfiguracjach poczty, spamu i archiwizacji; dokładną operację i jej pełne żądanie uzyskać z zainstalowanej API help lub w ramach oficjalnego wyjaśnienia. Do tego czasu nie wykonywać automatycznego usuwania. Po zatwierdzonym usunięciu ponownie sprawdzić, czy usunięto dokładnie zamierzoną grupę oraz czy wymagane odwołania i przepływ poczty pozostały nienaruszone.

W SMTPPolicy pole Name określa tożsamość polityki; DomainList z DomainName wiąże chronione domeny. RouteBy, DNSHostName i RouteList z HostName, routingid i routingorder opisują różne ścieżki dostarczenia, a nie kolejne nazwy domen. Tabela API podaje MX jako domyślną trasę, ale przykład zawiera alternatywne teksty tras zamiast jednej wartości. Przed zmianą sprawdzić routing względem rzeczywistych wyników rozwiązywania DNS, aby nie powstała pętla do zapory.

Zagnieżdżone sekcje SpamProtection, MalwareProtection, FiletypeFilter i DataProtection mają niezależne pola statusu. Tabela API podaje dla nich domyślnie OFF, choć przykład ustawia je na ON. Globalna akcja Accept nie włącza więc automatycznie wszystkich kontroli. Podobnie pole SPX domeny SPXEncryption i pole DataProtectionSPXTemplate dotyczące dopasowania nie są zamienne; DataProtectionPolicy musi wskazywać istniejącą, odpowiednią Data Control List. Wcześniej sprawdzić wymagania dotyczące silników, Zero-Day i BATV oraz model hasła SPX. Tabela opisuje weryfikację odbiorców jako wychodzącą, a pomoc WebAdmin jako przychodzącą; nie wywodzić z tego nowego kierunku weryfikacji. Testy pozytywne i negatywne dla poszczególnych kierunków oraz zapisane wartości polityki rozstrzygają, czy zaplanowana koncepcja ochrony została wdrożona.

Dla Data Control List przykład XML pokazuje MTADataControlList, a w nim Name oraz Signatures z powtarzanym Signature. Etykiety tabeli name i signaturename nie są potwierdzoną instrukcją serializowania ich jako tagów XML pisanych małymi literami. Wcześniej potwierdzić MTA Mode, odczytać dostępne sygnatury i wybrać tylko odpowiednie CCL. Sama lista nie powoduje działania ochronnego: dopiero powiązanie przez DataProtectionPolicy i akcja w polityce SMTP realizują tę koncepcję. Następnie ponownie odczytać listę i powiązanie oraz sprawdzić kontrolowane dopasowanie i podobny przypadek bez dopasowania.

Nie utożsamiać DKIM i wyjątków z routingiem

W DKIMVerification aktywacją steruje VerifactionStatus, rzeczywiście zapisany w przykładzie w ten sposób. ActionForVerifactionFail jest innym selektorem niż ActionForSignatureInvalid lub ActionForSignatureNotFound: pierwszy dotyczy błędów weryfikacji skrótu lub podpisu, drugi brakującego albo nieprawidłowego składniowo publicznego klucza DNS, a trzeci braku podpisu. Nie poprawiać po cichu literówek w pierwszych dwóch tagach. Przykład XML podaje Pass, natomiast tabela parametrów i pomoc WebAdmin podają Accept obok Quarantine i Reject. Nie potwierdza to zamienności wartości API; przed wysłaniem żądania wyjaśnić kontrakt API danego buildu i osobno przetestować wszystkie trzy przypadki poczty przychodzącej.

W DKIMSigning domenę podpisującą identyfikuje Domain, a nie Name; dokumentacja referencyjna usuwania również wymaga Domain. Przy tworzeniu i zmianie KeySelector i PrivateRSAKey są polami obowiązkowymi. Według pomocy WebAdmin domena może mieć wiele podpisów, natomiast dokumentacja usuwania podaje tylko domenę: przy wielu selektorach wcześniej wyjaśnić dokładny zakres usuwania i nie zakładać, że usunięcie dotyczy konkretnego selektora. Klucze prywatne i dane dostępowe API przechowywać w sposób chroniony oraz usuwać z odpowiedzi i logów; następnie sprawdzić DNS i nowy odebrany podpis zgodnie z opisem powyżej.

Globalna lista dla poczty przychodzącej używa MtaBlockedSenders z BlockedEmailAddresses i powtarzanym EmailAddress; tabela API dopuszcza pojedyncze adresy lub domeny z symbolem wieloznacznym, takie jak *@example.com. Lista ta nie zastępuje pełnej polityki antyspamowej i w opisanym tutaj kontekście MTA dotyczy tylko wiadomości przychodzących. Przed zmianą odczytać zakres i istniejące wpisy, a następnie przetestować nadawcę pasującego i niepasującego do listy.

Osobno API opisuje AntiSpamTrustedDomain z DomainList i powtarzanym DomainName jako wyjątek pozwalający omijać skanowanie poczty dla zaufanych domen. Źródło to nie określa, które dokładnie skanery są pomijane. Dlatego nie wymyślać ścieżki w GUI, nie gwarantować „wyłączenia wszystkich skanów” ani nie mylić zaufanych domen z chronionymi domenami routingu. Przed dodaniem lub usunięciem wyjaśnić dokładną listę domen, wymagany wyjątek i jego wpływ na skanowanie w zainstalowanym buildzie; ograniczyć zakres i zweryfikować wyjątek z ustaloną datą przeglądu oraz wiadomościami pasującymi i niepasującymi.

Dla Delete Trusted Domain tabela parametrów podaje DomainName jako obowiązkową tablicę dopuszczającą wiele wartości, ale nie zawiera przykładu usunięcia. Dlatego nie przenosić bez weryfikacji zagnieżdżonej struktury z przykładu Add do żądania usunięcia; wcześniej potwierdzić wartości docelowe i pełną strukturę żądania w zainstalowanej API help lub uzyskać oficjalne wyjaśnienie.

Globalny selektor silnika to MalwareProtection z PrimaryAntiVirusEngine, dla którego tabela API podaje domyślnie Sophos. Nie jest to zagnieżdżony element polityki o tej samej nazwie i nie włącza samodzielnie zakresów skanowania. Wpływ na pojedyncze i podwójne skanowanie oraz Zero-Day Protection kontrolować w objętych zmianą politykach przed zmianą i po niej, zgodnie z opisem powyżej.

Odpowiedzi właściwe dla obiektów jako pomoc diagnostyczna

Poniższe przyporządkowania pochodzą z wierszy statusów SFOS 22/23. Liczby to kody operacji XML, a nie kody HTTP; Message.* to nierozwinięte klucze źródłowe, a nie potwierdzone treści komunikatów ani jednoznaczne przyczyny błędów. Ogólne zasady bezpieczeństwa API opisane powyżej obowiązują także tutaj: przed każdą ponowną próbą porównać rzeczywistą odpowiedź i zapisany stan, nie usuwać zależności na podstawie przypuszczeń i zatrzymać się, jeśli stan częściowego wykonania pozostaje niewyjaśniony.

• Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. Ostatnie trzy wiersze sprawiają, że weryfikacja wyniku importu jest szczególnie ważna; nie zakładać, że cały plik został odrzucony lub przyjęty. Edit Address Group wymienia w tych źródłach tylko 200 → Message.AddrGrpUpdateSuccess i 500 → Message.AddrGrpUpdateFail; nie przedstawiać kodów Add jako udokumentowanych odpowiedzi Edit.
• Delete Address Group: 504, 505 i 506 odwołują się każdy do Message.AddrGrpForeignKeyExists; 507 do Message.AddrGrpEmailArcKeyExists. To samo przyporządkowanie symboliczne nie określa, którego odwołania dotyczy odpowiedź. Sprawdzić użycie i rzeczywisty stan grup; te odpowiedzi nie zastępują brakującego kontraktu usuwania.
• Add Data Control List i Update Data Control List: w obu przypadkach 502 → Message.DLPAddSameName i 545 → Message.MTAModeDisableCheck. Klucz dla Update również zawiera „Add”; nie zmieniać jego nazwy. Sprawdzić nazwy, tryb i zapisaną listę, nie ustalając przyczyny na podstawie samego klucza.
• Add SMTP Policy i Edit SMTP Policy: w obu przypadkach 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck i 545 → Message.MTAModeDisableCheck. Tylko Add SMTP Policy wymienia 502 → Message.SMTPProfileduplicateName. Dla 543 źródło rozróżnia Message.SMTPProfileSenderGenSPXAdd dla Add i Message.SMTPProfileSenderGenSPXEdit dla Edit. Porównać powiązania domen, nazwy, tryb i zależności SPX z rzeczywistym stanem; nie uruchamiać automatycznej zmiany nazw ani osłabiania ochrony.
• Email Configuration: 505 → Message.ASConfigSubOperationFail występuje w obu wersjach. Przed ponowną próbą odczytać wszystkie objęte operacją podsekcje SMTP, POP/IMAP i TLS; nie zakładać pełnego sukcesu ani pełnego wycofania. Dodatkowy wiersz SFOS 23 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname nadal podlega zastrzeżeniom opisanym powyżej.

Walidacja przepływu poczty

Poniższe polecenia wykonać z systemu poza własną siecią:

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Zastąpić example.com i mail.example.com rzeczywistymi wartościami. Polecenia testują DNS, TCP 25 i STARTTLS, ale nie uprawnienie relay ani pełne dostarczenie. openssl s_client pozostaje interaktywny po handshake; zakończyć go Ctrl+C.

Przetestować co najmniej:

• wiadomość zewnętrzną do prawidłowego odbiorcy;
• przy włączonej Recipient verification wiadomość zewnętrzną do nieprawidłowego odbiorcy;
• wiadomość wychodzącą przez właściwy serwer;
• test spamu lub malware zgodny z policy;
• STARTTLS i prezentowany łańcuch certyfikatów;
• działanie kwarantanny i dostawę po zwolnieniu;
• zablokowaną próbę relay z niedozwolonego źródła;
• brak dostawy omijającej MTA przez starą regułę DNAT.

Zapisywać wyłącznie zaobserwowane wyniki odbioru: prawidłowa wiadomość testowa musi mieć w Mail logs stan Delivered i dać się prześledzić po Message-ID do skrzynki docelowej. Oczekiwać odrzucenia nieprawidłowego odbiorcy tylko wtedy, gdy weryfikacja odbiorców jest włączona, wybrana metoda weryfikacji działa przez dostępną autorytatywną ścieżkę weryfikacji, a odrzucanie jest skonfigurowane. W przypadku With callout odróżnić ten test negatywny od udokumentowanego wyjątku: SFOS akceptuje odbiorców, gdy docelowy serwer pocztowy jest nieosiągalny przez określony czas. Dokumentacja nie podaje długości tego czasu; nie zakładać, że ten sam wyjątek dotyczy In Active Directory. Przy wyłączonej weryfikacji odrzucenie nie jest oczekiwanym wynikiem tego testu negatywnego. Niedozwolona próba relay nie może utworzyć wiadomości, a zwolnienie z kwarantanny musi pokazać późniejsze dostarczenie dla tego samego Message-ID.

Do pierwszej kontroli służą Email > Mail logs, Email > Mail spool, Email > SMTP quarantine i Log Viewer. Do głębszej analizy zapisać czas testu, nadawcę, odbiorcę, temat, źródłowy IP i Message-ID oraz skorelować:

• MTA: smtpd_main.log
• odrzucenia: smtpd_reject.log
• błędy skanowania: smtpd_error.log
• wewnętrzne błędy MTA: smtpd_panic.log
• anti-spam: sasi.log
• legacy SMTP proxy: awarrensmtp.log
• POP/IMAP proxy: warren.log

Usługi i logi Sophos Firewall wyjaśniają przypisanie i dostęp przez Advanced Shell.

W Mail logs pole Result oznacza stan dostarczenia, a Reason opisuje powód skanowania lub policy. Rejected oznacza, że SFOS odrzucił wiadomość i powiadomił nadawcę. Dropped odrzuca ją bez powiadomienia, a Bounced pojawia się po kilku nieudanych próbach dostarczenia. Tych stanów nie należy utożsamiać, ponieważ powodują inne odpowiedzi i ścieżki diagnostyczne. Pozostałe wyniki to Delivered, Quarantined i ręczne Deleted; powody można filtrować między innymi według Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM i BATV.

Obsługa kwarantanny i Mail spool

W Email > SMTP quarantine filtrować według okresu, nadawcy, odbiorcy, tematu i przyczyny:

• Release: dostarczyć wiadomość.
• Delete: usunąć wiadomość.
• Release and report: zwolnić i zgłosić SophosLabs tylko false positive oznaczone jako Spam lub Probable spam.

Wiadomości z wirusami lub uznane za złośliwe przez Zero-Day Protection nie mogą zostać zwolnione. Usuwanie wpisów Zero-Day Protection wymaga prawa zapisu w profilu administratora. Po zapełnieniu kwarantanny starsze wiadomości są usuwane.

Digest kwarantanny otrzymują tylko użytkownicy, którzy co najmniej raz uwierzytelnili się na zaporze. Domyślnie SFOS nie stosuje ustawień digestu do aliasów; trzeba je przypisać wraz z adresem podstawowym w Email > Quarantine settings > Change user’s quarantine digest settings albo w obiekcie użytkownika. Digest może wtedy obejmować spam do adresów podstawowych i aliasów. Wiadomości do aliasów nadal nie pojawiają się w samym User Portal.

Konfiguracja i testowanie raportu kwarantanny Sophos Firewall opisuje konfigurację, przypisanie użytkowników, link zwalniania i pełny test funkcjonalny.

Email > Mail spool zawiera wiadomości niedostarczone lub zakończone błędem. SFOS ponawia dostawę przez trzy dni i odrzuca wiadomości po kolejnych czterech; odrzucone pozostają w Mail logs. Rosnący spool sygnalizuje więc problem z routingiem, DNS, TLS, policy lub serwerem, a nie powód do wielokrotnego Retry bez diagnozy.

Filtr statusu rozróżnia Queued, Failed, SPX blocked, Zero-day protection i Error. SPX blocked oczekuje, aż odbiorca utworzy hasło; Zero-day protection oczekuje na analizę. Pobierać lub usuwać można tylko wiadomości w error queue. Usuwanie lub ponowne wysyłanie wiadomości Zero-Day Protection wymaga od profilu administratora praw odczytu i zapisu do Zero-Day Protection Activity. Jeśli przycisku brakuje, najpierw należy sprawdzić status i profil, zamiast obchodzić ograniczenie restartem usługi.

Kwarantanna i spool zajmują lokalny storage. Monitorować wolne miejsce, stan SSD i System Health; zobacz Czyszczenie storage i reports oraz Kontrola SSD Health. W HA logi i reports są oddzielne dla każdego node i nie synchronizują się, dlatego sprawdzić oba. Klastry HA Sophos Firewall opisują podstawy.

Troubleshooting

Poczta zewnętrzna nie dociera

Sprawdzić MX, A/AAAA, publiczny IP, TCP 25 i SMTP Relay z WAN. Następnie potwierdzić MTA mode, zgodność chronionej domeny z policy oraz brak starej reguły DNAT lub reguły o wyższym priorytecie zmieniającej ścieżkę. Brak połączenia w smtpd_main.log wskazuje, że problem prawdopodobnie występuje przed Mail Protection.

Zapora przyjmuje, ale nie dostarcza

Sprawdzić serwer wewnętrzny, route, DNS, port, TLS i recipient verification. Static host, DNS host i MX mają różne ścieżki rozwiązywania i failover. Skorelować logi reject i error zapory z logami serwera.

Wiele wiadomości pozostaje w spool

Najpierw sprawdzić Email > Mail spool i logi MTA. Częstą przyczyną jest reguła nad automatyczną regułą MTA, która już dopasowuje SMTP. W Rules and policies > Firewall rules sprawdzić nowe reguły w pozycji Top, automatyczne reguły IPsec lub hotspot i inne nakładanie. Nie przesuwać reguł bez analizy; liczy się rzeczywisty match SMTP.

Dopiero po potwierdzeniu, że przyczyną jest nowa nakładająca się reguła, przesunąć ją w Rules and policies > Firewall rules na tyle niżej, aby przewidziana reguła SMTP była ponownie oceniana. Następnie ponownie sprawdzić dostarczenie i spool za pomocą kontrolowanej wiadomości; inne wymagane połączenia muszą nadal korzystać z przewidzianych dla nich reguł.

NC-177930 naprawiono w SFOS 22.0 MR2: wiadomości pozostawały w spool po awarii mailpoller. Na starszej wersji należy uwzględnić firmware w diagnozie. Użyć kontroli aktualizacji do SFOS 22, aby wybrać build docelowy, przygotować zmianę i ponownie przetestować przepływ poczty.

Sophos Fusion zgłasza Invalid API request

W SFOS 22.0 MR1 Release i Delete mogły zawieść, gdy zaporę otwarto przez Sophos Fusion (dawniej Sophos Central). Objaw Invalid API request jest rejestrowany jako NC-182056, a NC-181904 oznacza poprawkę nieudanego zwalniania przez Sophos Fusion. Bezpieczne obejście to bezpośrednie logowanie do lokalnego WebAdmin i akcja w Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 naprawia problem. Jeśli błąd trwa, osobno sprawdzić profil administratora, dostęp do Sophos Fusion i uprawnienia lokalne. Przy aktualizacji zastosować pełny proces zatwierdzania, przygotowania, weryfikacji i troubleshootingu opisany w Aktualizacja firmware Sophos Firewall: przygotowanie i najlepsze praktyki.

Nie można włączyć Reject based on RBL

NC-144563 to problem ograniczony do SFOS 20.0.2 MR2 Build 378: jeśli zmieniono nazwy domyślnych grup RBL w Email > Address group, nie można włączyć opcji Reject based on RBL podczas tworzenia polityki SMTP route and scan. W istniejącej polityce po wyłączeniu tej opcji nie można jej ponownie włączyć. Nie udokumentowano wersji z poprawką.

Domyślne grupy nazywają się Premium RBL services oraz Standard RBL services. Najpierw udokumentować dokładny build i aktualne nazwy grup. Jeśli oba warunki są spełnione, przywrócić oryginalne nazwy domyślnych RBL, ponownie otworzyć politykę i sprawdzić opcję. Nie mylić niestandardowych RBL z tymi dwiema grupami systemowymi.

W innych buildach albo przy niezmienionych nazwach domyślnych wyszarzona opcja nie potwierdza NC-144563. Osobno sprawdzić typ polityki, Spam protection, licencję Email Protection oraz pozostałą konfigurację.

Prawidłowy nadawca jest uznawany za spam

Sprawdzić domenę nadawcy, SPF/DKIM/DMARC, nagłówki, reputację, policy match i odbiorców. Dopiero potem utworzyć wąski wyjątek z datą przeglądu. Bezpieczne tworzenie i testowanie wyjątków poczty opisuje pełny proces określania zakresu, testowania i wycofywania zmian.

Systemy wewnętrzne nie mogą używać relay

Sprawdzić strefę źródłową w Administration > Device access, host w Email > Relay settings > Host-based relay i logi MTA. Jeśli skaner oczekuje standardowego SMTP AUTH, Host-based relay jest zwykle pewniejszy. Osobny, niezgodny z RFC Authenticated relay trzeba przetestować z konkretnym klientem.

Operacyjna lista kontrolna

• Sprawdzono licencję, obsługę modelu, DNS i wymagane usługi internetowe.
• Udokumentowano MX, TTL, publiczną i wewnętrzną ścieżkę oraz fallback.
• Automatyczna reguła MTA jest niezmieniona i na początku.
• Żadna stara reguła DNAT nie omija Mail Protection.
• Przetestowano Address Group, cel routingu i policy match.
• Rozdzielono przychodzący SMTP Relay z WAN i wychodzące uprawnienia hostów.
• Zrozumiano wpływ SPF/RBL, recipient verification, TLS, DKIM, SPX i bannerów.
• Wykonano zewnętrzne testy pozytywne i negatywne.
• Monitorowane są kwarantanna, spool, storage i logi.
• Mailflow jest ponownie testowany po aktualizacjach firmware.

Do dłuższej retencji i korelacji użyć Central Firewall Reporting lub wysyłania logów Sophos Firewall do SIEM.

FAQ