Configurare Sophos Firewall Mail Protection in modalità MTA

In MTA mode, Sophos Firewall accetta direttamente le email, le analizza e le consegna al server di posta interno o al mail hop successivo. Il mailflow funziona solo se record MX, regola MTA automatica, SMTP route and scan Policy, relay, TLS e verifica dei destinatari sono coordinati.

La configurazione comprende sei passaggi: definire mailflow e percorso di fallback, attivare MTA mode, aggiungere il dominio, creare la route and scan Policy, proteggere il relay e modificare il record MX. Infine si convalidano mailflow in entrata e in uscita con comandi esterni, quarantena, spool e log.

Quando è adatto MTA mode

Mail Protection sul firewall è indicato soprattutto per ambienti on-premises e ibridi progettati consapevolmente, nei quali proteggere un Exchange locale o un altro server di posta. Per Microsoft 365, Google Workspace e molti ambienti esclusivamente cloud, Sophos Email o un altro cloud email gateway offre in genere un’architettura più chiara. Due gateway in sequenza complicano quarantena, header, TLS, SPF/DKIM/DMARC e troubleshooting.

Se Exchange Online deve utilizzare consapevolmente l’MTA della firewall, Configurare Sophos Firewall MTA con Microsoft 365 descrive l’intero percorso EOP, relay, connettore, MX e SPF.

Occorre distinguere tre funzioni di Sophos Firewall:

• MTA mode: il firewall accetta, analizza e instrada le email.
• Legacy mode: elaborazione proxy trasparente di un percorso SMTP esistente. Configurare Mail Protection in Legacy mode spiega NAT, regole, policy di scansione e verifica.
• SMTP Relay in Device Access: controlla da quali zone è raggiungibile l’MTA. La posta Internet in entrata richiede WAN; il relay in uscita viene inoltre limitato a server interni specifici.

Il recupero dei messaggi esistenti tramite POP3 o IMAP è un’attività separata. Analizzare e testare POP3 e IMAP su Sophos Firewall descrive attendibilità TLS, policy opzionale, regola firewall e collaudo.

Servono una licenza Email Protection valida, routing e DNS funzionanti, un IP pubblico noto, il server interno con porta di destinazione e strategie definite per TLS, quarantena e fallback. Secondo l’attuale panoramica Sophos, MTA mode non è disponibile su XGS 87/87w e XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation e SXL2 Live Protection richiedono accesso a Internet. Routing email, scansione antimalware, filtro MIME e SPX possono continuare a funzionare con la licenza adatta in un ambiente airgap, ma un MTA attivo non implica che siano disponibili tutti i controlli di protezione.

Configurare MTA mode end-to-end

1. Definire mailflow e percorso di fallback

Per il mailflow in entrata, il record MX pubblico punta all’indirizzo sul quale Sophos Firewall accetta TCP 25. Il firewall analizza il messaggio e lo consegna al server interno. Una vecchia regola DNAT non deve lasciare quel server direttamente raggiungibile da Internet senza analisi, altrimenti l’MTA può essere aggirato. Pubblicare un server con DNAT spiega la logica DNAT generale.

Per il mailflow in uscita, solo il server previsto invia attraverso il firewall. Percorso di invio, smarthost, PTR/rDNS, HELO, SPF, DKIM e DMARC devono corrispondere all’identità pubblica del mittente. Una regola generica LAN to WAN è troppo ampia; la base di regole deve identificare chiaramente il mittente SMTP autorizzato. Comprendere le regole Sophos Firewall tratta l’ordine delle regole.

Prima della migrazione documentare:

• record MX attuale, priorità e TTL;
• nuovo indirizzo pubblico del firewall e server di destinazione interno;
• regole DNAT e SMTP esistenti e connettori del server di posta;
• mittenti di test in entrata e in uscita;
• vecchio MX o percorso email come fallback;
• monitoraggio di coda del server, spool del firewall e quarantena.

Ridurre il TTL per tempo se potrebbe servire un rollback rapido. Le modifiche al record MX produttivo vanno eseguite in una finestra di manutenzione.

2. Configurare MTA mode e le impostazioni SMTP di base

In Email > General settings, selezionare Switch to MTA mode se necessario. Sophos Firewall crea la regola Any-to-Any Auto added firewall policy for MTA per SMTP e SMTPS. Non modificarla e mantenerla in cima all’elenco. Il passaggio a Legacy mode la elimina; il ritorno a MTA mode la ricrea.

Configurare quindi le impostazioni di base:

1. In SMTP hostname, inserire il nome di dominio, ad esempio example.com, non l’hostname del server interno. Il valore compare in HELO e nel banner SMTP delle notifiche generate dal sistema.

   Verificare la risposta dell’API XML: La documentazione di SFOS 23 riporta lo stato 506 con Message.AVGeneralConfInvalidSmtpNtfyHostname per l’operazione Email Configuration dell’API XML. Si tratta di uno stato dell’operazione, non di un codice di stato HTTP. La chiave non è risolta e non costituisce un messaggio di errore in inglese; non permette di dedurre regole di validazione specifiche. Se compare questa risposta, verificare il valore dell’hostname inviato per le notifiche, la risposta effettiva dell’operazione e la configurazione salvata prima di considerare riuscita la modifica. La riga aggiuntiva nella documentazione non dimostra che questo comportamento in esecuzione sia stato introdotto per la prima volta in SFOS 23.

2. Attivare Reject based on IP reputation per rifiutare connessioni da mittenti con cattiva reputazione.

3. In SMTP TLS configuration, scegliere un certificato pubblicamente attendibile e consentire Allow invalid certificate solo per eccezioni documentate.

4. Attivare Disable legacy TLS protocols, salvo esigenze documentate di sistemi legacy. L’opzione disattiva protocolli precedenti a TLS 1.1, ma non impone automaticamente solo versioni TLS attuali.

5. Attivare Scan outgoing mails se occorre analizzare anche i messaggi in uscita.

Usare Require TLS negotiation con cautela: se SFOS non riesce a stabilire la connessione TLS richiesta, elimina le email verso la destinazione interessata o provenienti dal dominio mittente configurato. La guida SFOS 22/23 avverte che connessione e convalida SMTP TLS usano l’indirizzo IP del dominio anziché il suo nome; più domini sullo stesso IP possono quindi causare errori di certificato. È un’avvertenza della documentazione, non una prova dell’algoritmo di verifica dei certificati nel build distribuito.

Skip TLS negotiation seleziona host di posta remoti o reti per connessioni SMTP non cifrate; il limite documentato è di 512 voci host. Non è una soluzione a un certificato errato. Allow invalid certificate è un’eccezione alla convalida del peer TLS, non un passaggio al testo in chiaro. Non presumere una precedenza se le liste Require e Skip si sovrappongono, né un fallback in chiaro dopo il fallimento di TLS obbligatorio. Limitare e documentare le eccezioni e verificare il risultato effettivo della connessione e del certificato nel build distribuito prima di modificarle.

Definire i limiti SMTP globali prima delle policy

Le impostazioni in Email > General settings si applicano a tutte le email e vengono elaborate prima delle policy SMTP e POP-IMAP. Reject based on IP reputation non è quindi un’azione di una singola policy: SFOS controlla l’IP del mittente prima dei controlli antispam della policy SMTP. Anche Blocked senders è globale, ma blocca solo le email in entrata.

In SMTP settings, Don’t scan emails greater than definisce la dimensione massima dei messaggi per la scansione SMTP globale. 0 significa 51,200 KB, non illimitato. Per i messaggi più grandi sono disponibili Accept, Reject e Drop. Accept consegna senza scansione, Reject rifiuta e informa il mittente, mentre Drop elimina senza notifica. Questa scelta viene documentata come lacuna di scansione o decisione di consegna consapevole e testata con un messaggio appena sopra e appena sotto il limite.

Gli SMTP DoS settings limitano connessioni simultanee, email per connessione, destinatari per email e velocità di email e connessioni. SFOS imposta le connessioni massime in base a RAM e processore. I valori predefiniti documentati sono 1000 email per connessione e 100 destinatari per messaggio. I valori personalizzati vengono ricavati dal volume email reale; un limite troppo basso può trattare liste di distribuzione o scanner legittimi come un attacco.

In Advanced SMTP settings, SFOS può rifiutare un HELO non valido o l’assenza di RDNS e, con Do strict RDNS checks, un nome host che non si risolve nuovamente nell’IP sorgente. Questi controlli non vengono introdotti insieme a un’eccezione estesa. Prima si registrano nel log i percorsi reali di partner, newsletter e applicazioni, poi li si testa singolarmente.

Un banner in uscita può usare Inline, no conversion, l’opzione MIME part oppure Off. La scansione SMTP o SMTPS deve essere attiva nella regola firewall corrispondente. Poiché un banner modifica il body e può invalidare una firma DKIM esistente, si firma dopo questa modifica oppure si verifica espressamente presso il destinatario che la firma prevista rimanga valida.

3. Aggiungere il dominio come Address Group

1. Aprire Email > Address group > Add.
2. Impostare Group type su Email address/domain e Type su Manual.
3. Aggiungere il dominio protetto, ad esempio example.com.
4. Salvare il gruppo.

Durante la creazione, inserire anche un Name chiaro prima di salvare. Per un gruppo esistente usare Edit in Email > Address group; avviare l’importazione di un file con Import. RBL (IPv4) accetta indirizzi IPv4 e RBL (IPv6) indirizzi IPv6. Email address/domain supporta voci manuali o importazione CSV/testo. Il match RBL usa l’IP di connessione e l’azione specificata nella policy SMTP; resta applicabile il comportamento di rifiuto SPF/RBL documentato separatamente. Mantenere i nomi predefiniti Premium RBL services e Standard RBL services, salvo una modifica pianificata esplicitamente.

Le Address Group non sono limitate ai domini di posta. Group type può essere Email address/domain, RBL IPv4 o RBL IPv6. Lo stesso indirizzo può appartenere a più gruppi, consentendo di creare destinazioni di policy separate senza copiare o rinominare la voce.

Per elenchi più estesi, SFOS può importare un file CSV o di testo contenente fino a 400 indirizzi o domini. Le voci non valide e duplicate vengono ignorate. Dopo l’importazione, controllare il numero di voci e alcuni esempi prima di assegnare il gruppo a una policy di produzione.

Le nuove SMTP route and scan Policy sono progettate per domini, non per singoli indirizzi destinatario. Gli indirizzi individuali migrati possono continuare a funzionare, ma non possono essere aggiunti o modificati nelle policy attuali.

4. Creare una SMTP route and scan Policy

Aprire Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Inserire un nome chiaro, ad esempio Inbound example.com to Exchange.
2. In Protected domain, scegliere l’Address Group.
3. Selezionare Route by:
   • Static host: IP fisso del server interno; in caso di errore il firewall prova l’host successivo nell’elenco.
   • DNS host: nome DNS come mailserver.example.com; più record A vengono distribuiti tra le consegne e i server non disponibili vengono saltati.
   • MX: consegna basata su un record MX.
4. Per Static host, selezionare il server in Host list. Se necessario, creare il relativo IP host in Hosts and services > IP host.
5. Impostare Global action su Accept per i domini che si intende proteggere. Reject rifiuterebbe tutti i messaggi in entrata e in uscita associati a tali domini e informerebbe il mittente.
6. Attivare Spam protection e Malware protection in base al concetto operativo.
7. Attivare File protection e Data protection solo dopo averne compreso gli effetti su allegati, messaggi grandi, SPX e DKIM.
8. Salvare la policy.

Per una policy SMTP route and scan esistente, aprire Email > Policies and exceptions, selezionare Edit per la policy interessata, modificare le impostazioni necessarie e salvare la policy. Verificare quindi nuovamente la corrispondenza della policy e la consegna con un messaggio controllato.

Con Route by MX, l’MX risolto dal firewall non deve puntare nuovamente allo stesso firewall, altrimenti si crea un loop di routing. Il firewall deve risolvere correttamente le destinazioni interne; per lo split DNS sono utili le DNS Request Routes.

L’opzione Route inbound mail through gateway serve solo per design particolari, come server di destinazione nella zona WAN, applicazione della regola originale a destinazioni LAN/DMZ o selezione di un gateway specifico con più connessioni Internet. Non attivarla senza un requisito di routing concreto.

5. Proteggere l’accesso in entrata e il relay in uscita

In Administration > Device access, consentire SMTP Relay da ogni zona che deve raggiungere l’MTA. La posta Internet in entrata richiede WAN; quella in uscita richiede anche la zona del server interno, normalmente LAN o DMZ. In Email > Relay settings > Host-based relay, limitare poi l’accesso ai server, scanner o applicazioni specifici.

Autorizzazioni ampie di host o reti creano un rischio di open relay. Se stampanti o applicazioni devono inviare email, documentarle come oggetti host specifici. Proteggere l’accesso a Sophos Firewall spiega le basi di Device Access.

Le liste Allow e Block non seguono il principio per cui Block ha sempre la precedenza. Se lo stesso host o la stessa rete compare in entrambe le liste di Host-based relay o Upstream host, SFOS consente il relay. Prima dell’attivazione eliminare queste sovrapposizioni ed eseguire un test negativo da una sorgente non autorizzata.

Un host consentito non evita neppure la scansione della posta. Se SFOS non riesce ad analizzare un IP sorgente autorizzato per host-based relay, lo rifiuta. Un’autorizzazione di relay non dimostra quindi né la corretta scansione del contenuto né la consegna; entrambe vanno verificate con un messaggio reale e i log MTA.

La SMTP route and scan Policy non supporta SMTP AUTH. Per i dispositivi, Host-based relay è quindi il metodo affidabile. Esistono anche Authenticated relay settings separati per utenti e gruppi; Sophos segnala però che non supportano uno standard SMTP Authentication conforme alle RFC, quindi va testata la compatibilità del client. Diversa è l’autenticazione del firewall verso uno smarthost upstream, per la quale SFOS supporta PLAIN e LOGIN. Non usare mai come smarthost un IP di interfaccia dello stesso firewall, perché crea un loop di routing.

Più interfacce WAN o indirizzi IP alias

L’MTA crea autonomamente la connessione SMTP in uscita. Se sono possibili più indirizzi pubblici del mittente, una normale regola client non è quindi sufficiente. Sophos distingue tre casi: con un’interfaccia WAN e più indirizzi IP alias si crea una regola SNAT con la Translated source pubblica desiderata. Con più interfacce WAN e nessun alias si crea una route SD-WAN per SMTP, SMTP(S) e SMTPS_465. Se sono presenti più interfacce WAN e indirizzi alias, si combinano SNAT e route SD-WAN.

La regola SNAT mantiene invariati destinazione e servizio, usa come interfaccia di uscita la linea WAN prevista e traduce in MASQ o nell’IP alias desiderato. La route SD-WAN usa come destinazione il gruppo Internet, i tre servizi SMTP e il gateway primario previsto, più un backup opzionale. Un backup è utile solo se TCP 25 in uscita è realmente consentito e se anche quell’indirizzo pubblico è incluso nel record SPF del dominio email.

Per questo workflow multi-WAN ufficiale, Sophos richiede la precedenza static, vpn, sdwan_policyroute e abilita SD-WAN per il traffico generato dal sistema. Eseguire i comandi nella Device Console (opzione 4 del menu CLI), non nella Advanced Shell. Leggere prima entrambi i valori iniziali, applicare le modifiche e quindi verificarli di nuovo:

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

La route precedence è globale e non è un interruttore isolato per la posta. Prima della modifica vanno documentati tutti i percorsi statici, VPN e SD-WAN sovrapposti e i due valori letti. Per il rollback, ripristinare l’intero ordine precedente con system route_precedence set ... e riportare system-generate-traffic allo stato iniziale enable o disable. Dopo, verificare non solo i contatori SMTP, ma anche l’IP sorgente realmente utilizzato, la consegna, il risultato SPF e il guasto del gateway primario. Verificare il routing SD-WAN per il traffico generato dal sistema descrive la procedura generale di sicurezza e rollback.

6. Modificare il record MX

Modificare l’MX pubblico verso l’indirizzo del firewall solo quando regola MTA, dominio, policy, relay e percorso di consegna interno sono pronti. Inviare subito un messaggio esterno di test e verificare che compaia in Log Viewer o Mail logs, venga consegnato al server interno e raggiunga la mailbox.

Se i mittenti esterni non raggiungono il firewall o vengono rifiutati molti messaggi legittimi, ripristinare il percorso precedente documentato. A causa delle cache DNS, il rollback non è immediatamente efficace ovunque. Mantenere quindi operativi in parallelo sia il vecchio sia il nuovo percorso e monitorarli almeno fino alla scadenza del TTL precedente più lungo. Se il firewall accetta i messaggi ma non li consegna, controllare prima routing, DNS, TLS, recipient verification e log del server.

Scegliere consapevolmente le protezioni

Utilizzare tipi di file personalizzati e Data Control List

In MTA mode, un tipo di file personalizzato si crea in Email > Policies and exceptions > File type > Add a partire da un template, da estensioni o da tipi MIME. Le estensioni vanno inserite senza il punto iniziale. Solo i tipi personalizzati sono modificabili. Un nuovo tipo, inoltre, non viene aggiunto automaticamente alle policy esistenti: occorre aprire la specifica SMTP route and scan Policy, aggiungerlo in File protection e salvare nuovamente la policy. Un test positivo con un allegato e un test negativo simile confermano il match meglio del solo nome dell’oggetto.

In File protection > Block file types, All blocca i messaggi con allegati; non significa analizzare tutti gli allegati. None consente gli allegati per questo filtro dei file, senza aggirare controlli antimalware, antispam, Data Protection o altri controlli. La guida delle policy afferma che gli header MIME selezionati popolano la MIME whitelist, consentendo quei tipi e bloccando i rimanenti. Header MIME ed estensioni non provano che il contenuto sia innocuo. Verificare allegati consentiti e bloccati nel build distribuito prima di applicare una ricetta precisa di whitelist.

Una Data Control List è composta da Content Control List, o CCL, per tipi di contenuto definiti, come dati finanziari o personali. Durante la creazione in Email > Data control list > Add, filtrare le CCL per Type e Region e selezionare solo le voci effettivamente necessarie. L’azione viene definita solo nella policy collegata. Un match controllato e un contenuto simile senza match verificano che corrispondenza e azione funzionino insieme senza falsi positivi non necessari.

Spam protection non è solo l’azione applicata allo spam. Gli errori SPF e RBL vengono rifiutati direttamente e non seguono le normali azioni per spam o probable spam. Greylisting rifiuta intenzionalmente un messaggio in modo temporaneo e richiede al server mittente di riprovare.

Per Reject based on BATV, occorre prima configurare un BATV secret comune in Email > General settings > Advanced SMTP settings. Su più sistemi MX della stessa organizzazione si usa lo stesso secret. SFOS lo combina con timestamp e indirizzo del mittente per creare la firma Return-Path, che scade dopo sette giorni. Un errore BATV viene quindi confrontato con secret, ora di sistema, percorso del mittente ed età della firma, invece di essere nascosto con un’eccezione ampia senza scadenza.

Recipient verification impedisce messaggi verso destinatari sconosciuti:

• With callout: interroga il server di destinazione. Se è temporaneamente indisponibile, SFOS accetta i destinatari dopo un periodo definito invece di bloccare permanentemente tutto il mailflow.
• In Active Directory: verifica tramite Simple, SSL o STARTTLS con timeout di 30 secondi. Specificare server AD, Bind DN e Base DN. Bind DN è il nome distinto completo, incluso il CN dell’identità di bind configurata; Base DN è il punto di partenza delle ricerche nella directory. Usare valori adatti alla propria directory. L’esempio di amministratore nella guida non dimostra la necessità di privilegi Domain Admin. Scegliere un trasporto conforme alla policy di fiducia e sicurezza distribuita; la sola etichetta SSL o STARTTLS non prova la corretta convalida del certificato.

Malware Protection può utilizzare una o due scansioni antivirus. Per Zero-Day Protection con scansione singola, Sophos deve essere il motore principale. Sophos Firewall Zero-Day Protection spiega limiti e decisioni di rilascio.

Secondo la guida delle policy SFOS 22/23, Single antivirus seleziona il motore principale solo per la posta in entrata; quella in uscita usa entrambi i motori. Dual antivirus analizza prima con il motore principale e poi con quello secondario. Il motore principale, Sophos o Avira, si seleziona globalmente in Email > General settings. Scegliere Avira disattiva Zero-day protection nelle policy SMTP con scansione antivirus singola; Sophos deve essere principale per usare Zero-Day Protection con una sola scansione. La guida delle impostazioni generali descrive la scansione singola come uso del solo motore principale, senza la distinzione di direzione della tabella delle policy. Questa differenza documentale non prova quali motori siano effettivamente usati: verificare build, policy, direzione della posta e stato di protezione prima e dopo una modifica. Registrare le impostazioni precedenti; ripristinare la scelta del motore non dimostra la riattivazione di Zero-day protection.

Il limite di policy Drop message greater than in File protection non equivale al comportamento globale per i messaggi troppo grandi: a questo punto i messaggi più grandi vengono eliminati. SFOS controlla inoltre i contenuti visibili e quelli dei formati impacchettati come docx, xlsx, pptx, odt, ods, odp e odg. Un test positivo solo con un file di testo non impacchettato non dimostra quindi come le stesse informazioni vengano trattate in un documento Office.

Con DKIM verification attivo, SFOS distingue un hash non corrispondente, una firma non valida o una chiave pubblica non disponibile e l’assenza di firma DKIM. Per ogni risultato si possono scegliere Accept, Quarantine o Reject. Secondo Sophos, i messaggi firmati DKIM che usano RSA-SHA1 o una chiave fuori dall’intervallo da 1024 a 4096 bit vengono messi in quarantena. Questa verifica in entrata viene testata separatamente dalla firma in uscita.

Per i messaggi in uscita conta l’ordine di elaborazione. Cifratura SPX, prefissi dell’oggetto, File o Data Protection e banner in uscita possono modificare header o body dopo l’applicazione di una firma DKIM. La convalida DKIM fallisce quindi presso il destinatario. Occorre decidere se firmare sul server interno, su Sophos Firewall o su un gateway successivo.

Firmare i messaggi in uscita con DKIM sul firewall

Se deve firmare Sophos Firewall, aggiungere una firma per ogni dominio mittente in Email > General settings > DKIM signing > Add. Domain è il FQDN del dominio email; Key selector è esattamente il selettore che verrà poi pubblicato nel DNS pubblico. Un nome come fw01 o zurich rende più comprensibili le successive rotazioni delle chiavi, ma non è una funzione di sicurezza.

SFOS richiede una chiave RSA privata da 1024 a 2048 bit tra -----BEGIN RSA PRIVATE KEY----- e -----END RSA PRIVATE KEY-----. Per le nuove configurazioni, 2048 bit è la scelta appropriata. Non utilizzare RSA-SHA1. Secondo Sophos, il firewall non accetta una chiave da 1024 bit generata con PuTTYgen, quindi anche lì si devono scegliere 2048 bit. La chiave privata deve rimanere esclusivamente sul firewall e non deve mai comparire nel DNS, nei ticket o nella documentazione pubblica.

Dopo il salvataggio, pubblicare presso il provider DNS autoritativo il record TXT DKIM del selettore con la chiave pubblica. Solo quando il record è risolvibile dall’esterno si invia un nuovo messaggio di test attraverso il percorso MTA in uscita previsto. L’header ricevuto deve contenere il selettore e il dominio attesi e la verifica DKIM del destinatario deve riuscire. Se manca la firma, controllare il dominio mittente, il match della policy e Scan outgoing mails. Se la verifica fallisce, confrontare prima il record DNS, il selettore, la chiave utilizzata e le modifiche successive dovute a SPX, banner, File Protection o Data Protection.

Configurare e testare la crittografia email SPX spiega come interagiscono template, priorità dei trigger, modello di password e Reply Portal.

Convalidare il mailflow

Eseguire i seguenti comandi da un sistema esterno alla propria rete:

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

Sostituire example.com e mail.example.com con i valori reali. I comandi verificano DNS, TCP 25 e STARTTLS, ma non l’autorizzazione al relay né la consegna completa. openssl s_client rimane interattivo dopo l’handshake; terminarlo con Ctrl+C.

Testare almeno questi casi:

• messaggio esterno a un destinatario valido;
• con Recipient verification attiva, messaggio esterno a un destinatario non valido;
• messaggio in uscita tramite il server previsto;
• test spam o malware conforme alla policy;
• STARTTLS e catena di certificati presentata;
• azione di quarantena e consegna dopo il rilascio;
• tentativo di relay bloccato da una fonte non autorizzata;
• nessuna consegna diretta che aggiri l’MTA tramite una vecchia regola DNAT.

Registrare soltanto risultati di accettazione osservati: il messaggio di test valido deve risultare Delivered in Mail logs ed essere tracciabile tramite Message-ID fino alla mailbox di destinazione. Con recipient verification attiva, il destinatario non valido deve essere rifiutato; se la verifica è disattivata, il rifiuto non è l’esito previsto di questo test negativo. Il tentativo di relay non autorizzato non deve creare alcun messaggio e il rilascio dalla quarantena deve mostrare la successiva consegna dello stesso Message-ID.

Per il primo controllo usare Email > Mail logs, Email > Mail spool, Email > SMTP quarantine e Log Viewer. Per un’analisi più approfondita annotare orario del test, mittente, destinatario, oggetto, IP sorgente e Message-ID e correlare questi file:

• MTA: smtpd_main.log
• rifiuti: smtpd_reject.log
• errori di scansione: smtpd_error.log
• errori interni MTA: smtpd_panic.log
• anti-spam: sasi.log
• proxy SMTP legacy: awarrensmtp.log
• proxy POP/IMAP: warren.log

Servizi e log Sophos Firewall spiega la corrispondenza e l’accesso tramite Advanced Shell.

In Mail logs, Result indica lo stato di consegna, mentre Reason descrive il motivo di scansione o della policy. Rejected significa che SFOS ha eliminato il messaggio e informato il mittente. Dropped lo elimina senza notifica; Bounced compare dopo più tentativi di consegna non riusciti. Questi stati non sono equivalenti, perché producono risposte e percorsi diagnostici diversi. Altri risultati sono Delivered, Quarantined e Deleted manualmente; tra i motivi si possono filtrare Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM e BATV.

Gestire quarantena e Mail spool

In Email > SMTP quarantine, filtrare per periodo, mittente, destinatario, oggetto e motivo della quarantena:

• Release: consegnare il messaggio.
• Delete: eliminare il messaggio.
• Release and report: rilasciare e segnalare a SophosLabs solo falsi positivi classificati Spam o Probable spam.

I messaggi infetti da virus o classificati dannosi da Zero-Day Protection non possono essere rilasciati. Per eliminare voci Zero-Day Protection, il profilo amministratore richiede il permesso di scrittura per la funzione. Quando la quarantena è piena, i messaggi più vecchi vengono rimossi.

Solo gli utenti che si sono autenticati almeno una volta sul firewall ricevono i digest di quarantena. Per impostazione predefinita, SFOS non applica le impostazioni del digest agli alias: assegnarli insieme all’indirizzo primario in Email > Quarantine settings > Change user’s quarantine digest settings o nell’oggetto utente. Il digest può quindi includere lo spam inviato agli indirizzi primari e alias. I messaggi agli alias continuano a non comparire nello User Portal.

Configurare e testare il riepilogo di quarantena Sophos Firewall spiega configurazione, assegnazione utenti, link di rilascio e test funzionale completo.

Email > Mail spool contiene messaggi non ancora consegnati o falliti. SFOS ritenta la consegna per tre giorni e scarta i messaggi dopo altri quattro; i messaggi scartati restano visibili in Mail logs. Uno spool crescente segnala quindi problemi di routing, DNS, TLS, policy o server e non è un motivo per selezionare ripetutamente Retry senza diagnosi.

Il filtro di stato distingue Queued, Failed, SPX blocked, Zero-day protection e Error. SPX blocked attende che il destinatario crei una password; Zero-day protection attende l’analisi. Solo i messaggi nella error queue possono essere scaricati o eliminati. Per eliminare o inviare nuovamente messaggi Zero-Day Protection, il profilo amministratore necessita di permessi di lettura e scrittura per Zero-Day Protection Activity. Se manca un pulsante, controllare prima stato e profilo anziché aggirare il limite riavviando un servizio.

Quarantena e spool usano storage locale. Monitorare spazio libero, stato SSD e System Health; vedere Pulire storage e report e Controllare SSD Health. In HA, log e report sono separati per node e non sincronizzati, quindi controllare entrambi. Cluster HA Sophos Firewall tratta le basi.

Troubleshooting

Le email esterne non arrivano

Controllare MX, A/AAAA, IP pubblico, TCP 25 e SMTP Relay da WAN. Verificare poi che MTA mode sia attivo, che il dominio protetto corrisponda alla policy e che nessuna vecchia regola DNAT o regola con priorità superiore modifichi il percorso previsto. Se smtpd_main.log non mostra connessioni, il problema si trova probabilmente prima di Mail Protection.

Il firewall accetta ma non consegna

Controllare server interno, route, DNS, porta di destinazione, TLS e recipient verification. Static host, DNS host e MX usano percorsi di risoluzione e failover diversi. Correlare i log reject ed error del firewall con quelli del server.

Molti messaggi rimangono nello spool

Controllare prima Email > Mail spool e i log MTA. Una causa frequente è una regola sopra quella MTA automatica che esegue già il match SMTP. In Rules and policies > Firewall rules, controllare nuove regole in posizione Top, regole IPsec o hotspot generate automaticamente e altre sovrapposizioni. Non spostare regole alla cieca; conta il loro effettivo match SMTP.

Solo dopo aver confermato che la nuova regola sovrapposta è la causa, spostarla più in basso in Rules and policies > Firewall rules, quanto basta affinché la regola SMTP prevista venga nuovamente valutata. Verificare quindi di nuovo la consegna e lo spool con un messaggio controllato; le altre connessioni necessarie devono continuare a utilizzare le regole previste.

NC-177930 è stato corretto in SFOS 22.0 MR2: i messaggi rimanevano nello spool dopo un crash di mailpoller. Se il problema compare su una versione precedente, includere il firmware nella diagnosi. Usare il controllo di upgrade a SFOS 22 per scegliere la build di destinazione, preparare la modifica e ritestare poi il flusso di posta.

Sophos Fusion mostra Invalid API request

Su SFOS 22.0 MR1, Release e Delete potevano fallire quando il firewall veniva aperto tramite Sophos Fusion (in precedenza Sophos Central). Il sintomo Invalid API request è registrato come NC-182056; NC-181904 identifica la correzione del rilascio non riuscito da Sophos Fusion. Il workaround sicuro è accedere direttamente al WebAdmin locale ed eseguire l’azione in Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 corregge il problema. Se persiste, controllare separatamente profilo amministratore, accesso a Sophos Fusion e permessi locali. Per un aggiornamento, seguire il processo completo di approvazione, preparazione, verifica e troubleshooting in Aggiornamento firmware di Sophos Firewall: preparazione e best practice.

Impossibile attivare Reject based on RBL

NC-144563 è un caso specifico per SFOS 20.0.2 MR2 Build 378: se i gruppi RBL predefiniti in Email > Address group sono stati rinominati, non è possibile attivare Reject based on RBL durante la creazione di una policy SMTP route and scan. In una policy esistente, dopo aver disattivato l’opzione non è più possibile riattivarla. Non è documentata una versione corretta.

I gruppi predefiniti si chiamano Premium RBL services e Standard RBL services. Prima documentare il build esatto e i nomi attuali dei gruppi. Se entrambe le condizioni sono soddisfatte, ripristinare i nomi originali delle RBL predefinite, riaprire la policy e verificare l’opzione. Non confondere le RBL personalizzate con questi due gruppi di sistema.

Su altri build, o se i nomi predefiniti non sono stati modificati, un’opzione non selezionabile non dimostra NC-144563. Verificare separatamente il tipo di policy, Spam protection, la licenza Email Protection e il resto della configurazione.

Un mittente legittimo viene classificato come spam

Controllare dominio mittente, SPF/DKIM/DMARC, header, reputazione, policy match e destinatari interessati. Solo dopo creare un’eccezione ristretta con data di revisione. Creare e testare in sicurezza le eccezioni email illustra l’intero processo di definizione dell’ambito, test e rollback.

I sistemi interni non possono usare il relay

Controllare la zona sorgente in Administration > Device access, l’oggetto host in Email > Relay settings > Host-based relay e i log MTA. Se uno scanner richiede SMTP AUTH standard, Host-based relay è generalmente più affidabile. L’Authenticated relay separato e non conforme alle RFC va testato con il client specifico.

Checklist operativa

• Verificati licenza, supporto del modello, DNS e servizi Internet necessari.
• Documentati MX, TTL, percorsi pubblico e interno e fallback.
• Regola MTA automatica invariata e in cima.
• Nessuna vecchia regola DNAT aggira Mail Protection.
• Address Group, destinazione di routing e policy match testati.
• SMTP Relay in entrata da WAN e autorizzazioni host in uscita separati correttamente.
• Compresi gli effetti di SPF/RBL, recipient verification, TLS, DKIM, SPX e banner.
• Eseguiti test esterni positivi e negativi.
• Monitorati quarantena, spool, storage e log.
• Mailflow ritestato dopo gli aggiornamenti firmware.

Per conservazione e correlazione più lunghe, usare Central Firewall Reporting o inviare i log Sophos Firewall a un SIEM.

FAQ