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 del 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:

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.
Attivare Reject based on IP reputation per rifiutare connessioni da mittenti con cattiva reputazione.
In SMTP TLS configuration, scegliere un certificato pubblicamente attendibile e consentire Allow invalid certificate solo per eccezioni documentate.
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.
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.

Prima di un aggiornamento, registrare anche i limiti di frequenza SMTP. Gli intervalli documentati sono 1–1000 email per connessione, 1–512 destinatari per email, 1–1000 email per host al minuto e 1–100 connessioni per host al secondo. Le frequenze predefinite sono rispettivamente 1000 e 100. Durante la migrazione, SFOS mantiene le frequenze email e di connessione supportate, ma ripristina il valore predefinito per quelle superiori al massimo. Confrontare i valori salvati dopo l’aggiornamento, non soltanto la vecchia configurazione esportata.

3. Aggiungere il dominio come Address Group

Aprire Email > Address group > Add.
Impostare Group type su Email address/domain e Type su Manual.
Aggiungere il dominio protetto, ad esempio example.com.
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:

Inserire un nome chiaro, ad esempio Inbound example.com to Exchange.
In Protected domain, scegliere l’Address Group.
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.
Per Static host, selezionare il server in Host list. Se necessario, creare il relativo IP host in Hosts and services > IP host.
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.
Attivare Spam protection e Malware protection in base al piano operativo.
Attivare File protection e Data protection solo dopo averne compreso gli effetti su allegati, messaggi grandi, SPX e DKIM.
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.

Se la posta in uscita usa uno smarthost, configurare Email > General settings > Smarthost settings: selezionare Hostname, impostare Port (predefinito 25) e, solo se richiesto dal server, abilitare Authenticate device with smarthost e inserire le credenziali in modo sicuro. Questo instrada la posta in uscita tramite un MTA intermedio; non autorizza i client al relay attraverso il firewall. Mantenere requisiti TLS e identità pubblica finale del mittente coerenti con questo hop aggiuntivo e registrare le impostazioni precedenti per il rollback.

Relay upstream e server ospitati nel cloud

Upstream host, in Email > Relay settings, controlla quali sorgenti SMTP a monte possono consegnare email in entrata; Host-based relay controlla gli host autorizzati al relay in uscita. Configurare questi ambiti separatamente. Se un altro gateway riceve per primo la posta pubblica, inserire nella lista upstream le sue effettive reti sorgenti, non l’indirizzo del server di destinazione. In entrambe le sezioni, una corrispondenza nella lista consentita prevale su un blocco sovrapposto.

Per un server ospitato nel cloud, abilitare SMTP Relay nella sua zona sorgente, normalmente WAN, e limitare il relay in uscita basato su host agli indirizzi sorgenti effettivi del server. Anche il server cloud deve consentire la connessione di relay prevista con il firewall. Separare il record MX pubblico diretto al firewall dalla destinazione di consegna risolta da SFOS: la procedura cloud cita entrambe le destinazioni MX senza spiegare la separazione DNS. Usare un host DNS distinto, una destinazione statica o uno split DNS mantenuto consapevolmente; Route by MX non deve mai rinviare la posta al firewall.

La procedura cloud consiglia anche di passare a Legacy e tornare indietro se manca la regola automatica. Questo elimina e ricrea la regola e modifica l’elaborazione della posta attiva. Non usarlo come riparazione improvvisata: registrare prima policy, code e percorso di fallback, poi esaminare la regola mancante con il supporto. Qualsiasi cambio di modalità approvato va eseguito in una finestra di manutenzione, ripetendo i test in entrata, in uscita e di rifiuto del relay.

I vecchi esempi cloud e dati finanziari richiedono il nome del server in uscita come SMTP hostname, mentre la configurazione MTA più recente richiede il dominio, non l’hostname del server. Seguire l’indicazione più recente per le notifiche di sistema; questa impostazione non stabilisce l’identità di ogni messaggio inoltrato. Analogamente, la verifica DKIM in entrata usa la chiave pubblica DNS del mittente e non richiede la creazione di una chiave di firma in uscita solo perché la panoramica MTA cita insieme firma e verifica.

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.

Nella route SD-WAN, Route only through specified gateways impedisce deliberatamente il fallback ad altri gateway: se quelli selezionati non sono raggiungibili, il firewall scarta il traffico. Decidere se questo sia preferibile a un IP mittente imprevisto e provare tale scenario di guasto. Scegliere oggetti IPv4 o IPv6 adatti al percorso di posta effettivamente pubblicato; non copiare un gruppo Internet IPv4 in un progetto IPv6.

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

Azioni per spam, malware e dati sensibili

Per spam in entrata, probabile spam e posta massiva, scegliere esplicitamente l’azione: None consegna senza modifiche, Warn aggiunge il prefisso dell’oggetto configurato, Quarantine trattiene il messaggio e Drop lo scarta senza avvisare il mittente. Impostare i prefissi per spam e posta massiva secondo necessità. Queste scelte non sostituiscono il rifiuto separato SPF/RBL.

Per il malware, Selected antivirus action offre None, Drop e Quarantine; configurare Notify sender separatamente. Quarantine unscannable content copre i contenuti non ispezionabili, inclusi file danneggiati, cifrati o compressi, messaggi troppo grandi ed errori interni di scansione. Una consegna completata non dimostra che tutti gli allegati siano stati analizzati. Zero-Day Protection ha una propria dimensione massima di analisi: i file più grandi non vengono analizzati da questo servizio. Provare tale limite separatamente dalla dimensione SMTP globale e dai limiti di scarto di File protection.

In Data protection, selezionare la Data control list esatta, la sua azione e, se necessario, lo SPX template: Accept consegna, Accept with SPX cifra e consegna e Drop scarta senza notifica. Notify sender è una scelta separata. Un’assegnazione SPX a livello di dominio cifra tutta la posta in uscita corrispondente; usare un trigger Data Control se devono essere cifrate solo le corrispondenze con dati finanziari. L’esempio con password del destinatario usa Specified by recipient e trattiene il messaggio fino alla registrazione della password. Configurare insieme template, Reply Portal e registrazione nel runbook SPX collegato, poi provare un messaggio corrispondente e uno non corrispondente, anziché limitarsi ad abilitare Data protection.

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. I messaggi con esito negativo del controllo SPF o con una corrispondenza 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.

Automatizzare in sicurezza le impostazioni MTA tramite API XML

Per le automazioni, impostazioni globali, Address Group e policy SMTP restano destinazioni distinte. Leggere prima il build, la modalità di posta attiva, i valori salvati e le policy dipendenti; preparare un backup e un percorso di ripristino mirato. Inviare la richiesta confermata, con un’operazione esplicita, solo per la destinazione necessaria. Confrontare poi la risposta dell’operazione, lo stato riletto e il test del mailflow pertinente. Anche dopo un errore o un timeout, rileggere prima lo stato per verificare se sia già stato salvato qualcosa, anziché ripetere alla cieca la richiesta di scrittura. Proteggere l’accesso all’API XML spiega accesso, archiviazione dei secret e valutazione delle risposte.

I riferimenti agli oggetti SFOS-22/23 non sono payload pronti per la produzione. Esempi XML, tabelle dei parametri e guida WebAdmin possono riportare grafie, valori o impostazioni predefinite diversi. Le celle vuote dei valori predefiniti o Any non confermano né un valore vuoto sicuro né il comportamento dei campi omessi. Le costanti $EMAILPROTECTION{…} non risolte non sono valori letterali API confermati. Se sintassi, operazione o effetto non sono chiariti, fermarsi prima della scrittura e consultare la API help del build installato oppure richiedere un chiarimento ufficiale. Le sole differenze documentali non dimostrano una modifica del prodotto.

Distinguere le impostazioni globali SMTP, TLS e relay

In EmailConfiguration, il limite di scansione SMTP e i valori DoS appartengono a SMTPSSettings, mentre i valori POP/IMAP separati appartengono a POPIMAPSettings. Il campo omonimo DontScanEmailsGreaterThan non deve essere associato al protocollo sbagliato. RecipientHeaders con elementi Header ripetuti riguarda il riconoscimento dei destinatari POP/IMAP, non il routing SMTP. I banner si trovano in GeneralSettings. Anche SMTPTLSConfiguration e POPSIMAPTLSConfiguration sono contesti distinti: TLSCertificate, AllowInvalidCertificate e DisableTLS1 non possono essere indirizzati in modo univoco con un unico nome di campo privo di qualificazione. Un’eccezione SMTP non deve allentare anche i controlli POP/IMAP senza che ciò venga rilevato. Dopo il salvataggio, rileggere separatamente entrambi i contesti e testare solo il percorso di posta previsto.

BypassSpamCheck in SMTPSSettings descrive, secondo la tabella API, l’esclusione del traffico autenticato dalla scansione antispam. La tabella indica il valore predefinito Disable, mentre l’esempio XML imposta Enable. Non adottare l’esempio come configurazione predefinita sicura: prima di una modifica, chiarire quale traffico sia considerato autenticato nel build specifico e quale controllo antispam venga aggirato. Limitare strettamente l’ambito di un’eccezione voluta e verificarne l’effetto sui messaggi corrispondenti e non corrispondenti; non considerare automaticamente esclusi gli altri ambiti di scansione.

La provenienza dei valori numerici SMTP è importante: la tabella API indica per DontScanEmailsGreaterThan il valore 1024 KB, per MaximumConnections il valore 5000 nell’intervallo 1–20000 e per MaximumConnectionsHost il valore 100 nell’intervallo 1–10000. Per MaximumEmailsConnection indica il valore predefinito 100, mentre l’esempio XML riporta 1000; anche la guida WebAdmin indica 1000. MaximumRecepientsEmail è la grafia della fonte, con valore predefinito 100 e intervallo 1–512. Per EmailsRate e ConnectionsRate, la tabella API indica i valori predefiniti 1000 e 100, entrambi con intervallo 1–20000; la guida WebAdmin limita invece le frequenze a 1–1000 al minuto e 1–100 al secondo rispettivamente e determina i massimi delle connessioni in base all’hardware. Non adottare quindi i massimi della tabella come limiti attuali dell’interfaccia, né i valori degli esempi come valori predefiniti. I limiti WebAdmin descritti sopra e il controllo dell’upgrade restano determinanti per questa procedura; le automazioni devono confrontare i valori effettivamente salvati nel build.

Ulteriori conflitti di sintassi impediscono di importare gli esempi alla cieca: VerifySendersIPReputation mostra Enable nell’esempio XML, ma la tabella API riporta on/off con valore predefinito Disable; SMTPSDosSettings vi è descritto come intero con valore predefinito Disable, ma nell’esempio compare come Enable. Per il banner, i testi di esempio si contrappongono ai valori della tabella inline_plain, mimepart, off. Non «correggere» autonomamente queste indicazioni: confermare la grafia e i valori validi prima di una richiesta. Considerare separatamente l’avvertenza esistente relativa a Email Configuration, stato 506.

Anche AdvancedSMTPSetting è globale. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks e ScanOutboundEmails controllano le verifiche HELO/RDNS e in uscita spiegate sopra. FirewallRelateInboundMails riguarda il percorso separato tramite gateway e regole firewall; l’esempio indica Disable, la tabella Turn on/Turn off. Per il secret BATV, l’esempio mostra BATVSecret, mentre la tabella riporta BATVsecret. Confermare maiuscole/minuscole e valori validi prima della scrittura; non usare queste varianti come payload completo senza chiarire il formato per la build installata. Utilizzare il secret condiviso da un archivio protetto; non copiare né il secret di esempio né il secret effettivo in ticket, repository o log delle richieste. Pianificare la rotazione del secret su tutti i sistemi MX interessati e verificare poi BATV e l’invio normale.

In RelaySettings esistono HostBased e UpstreamHost, ciascuno con proprie liste AllowRelay e BlockRelay. Al loro interno si trovano HostsOrNetworks e voci HostsOrNetwork ripetute. Lo stesso nome di elemento foglia non implica quindi lo stesso ambito di relay. AuthenticatedRelaySettings contiene separatamente AuthenticatedRelay e UsersOrGroups con UsersOrGroup. I gruppi aperti o guest mostrati nell’esempio del produttore non costituiscono una scelta sicura. Usare solo le identità e gli oggetti host pianificati, eliminare le sovrapposizioni tra le liste e verificare poi l’invio consentito e il relay non autorizzato da una sorgente separata.

In SmarthostSettings, UseSmarthost attiva l’hop intermedio in uscita; SmarthostList con elementi Hostname ripetuti seleziona le destinazioni, mentre Port seleziona la porta di destinazione. La tabella API indica 1–65535, ma nessuna porta predefinita; 25 compare nell’esempio e come valore predefinito nella guida WebAdmin. AuthenticateDevicewithSmarthost è separato: fornire in modo sicuro Username e Password solo se è necessaria l’autenticazione. La tabella API indica Disable come valore predefinito per entrambi gli interruttori di attivazione, mentre l’esempio li attiva entrambi. passwordform="encrypt" è la sintassi della password nell’esempio, non un’autorizzazione a riutilizzare valori cifrati di un altro firewall. Se la provenienza o i requisiti di importazione non sono chiariti, interrompere la richiesta. Verificare poi destinazione, TLS, autenticazione e consegna attraverso questo hop, non soltanto l’autorizzazione al relay.

Modificare in modo mirato Address Group e policy SMTP

Per l’MTA è previsto l’oggetto di esempio MTAAddressGroup, non l’oggetto dal nome simile AVASAddressGroup dell’altro contesto di posta. Name identifica il gruppo. GroupType determina la lista appropriata: la tabella API distingue RBLIPv4, RBLIPv6, IPAddress e EmailAddressOrDomain, oltre ai campi delle voci RBLName, IPAddressNetwork e EmailAddressDomain. L’esempio del dominio di posta usa EmailAddressList con elementi EmailAddressDomain ripetuti ed EmailImportType impostato su Manual. Per Import ed EmailAddressFile, chiarire la procedura di caricamento file adatta al build: il testo descrittivo associa in modo contraddittorio il campo del file all’importazione manuale. Un esito HTTP positivo non conferma né tutte le voci importate né la composizione finale del gruppo. Rileggere numero di voci, voci omesse e valori concreti dei domini prima che una policy utilizzi il gruppo.

Per Delete Address Group, le pagine SFOS-22/23 forniscono righe di stato, ma nessuna definizione dei parametri e nessun esempio di eliminazione. Da queste informazioni non si può ricavare né l’identità esatta dell’oggetto per Remove né una richiesta funzionante. Non inserire semplicemente Name o l’oggetto di creazione in un payload Remove. Verificare prima gli utilizzi nelle configurazioni di posta, spam e archiviazione; ricavare l’operazione esatta e la relativa richiesta completa dalla API help installata oppure da un chiarimento ufficiale. Fino ad allora, non eseguire eliminazioni automatiche. Dopo un’eliminazione approvata, verificare nuovamente che sia stato rimosso esattamente il gruppo previsto e che i riferimenti necessari e il mailflow siano intatti.

In SMTPPolicy, Name è l’identità della policy; DomainList con DomainName associa i domini protetti. RouteBy, DNSHostName e RouteList con HostName, routingid e routingorder descrivono percorsi di consegna diversi, non ulteriori nomi di dominio. La tabella API indica MX come valore predefinito della route, ma l’esempio contiene testi di routing alternativi anziché un unico valore. Verificare preventivamente il routing rispetto alla risoluzione DNS effettiva, per evitare un loop verso il firewall.

Le sezioni annidate SpamProtection, MalwareProtection, FiletypeFilter e DataProtection hanno campi di stato indipendenti. La tabella API indica OFF come valore predefinito per questi campi, sebbene l’esempio li imposti su ON. Un’azione globale Accept non attiva quindi automaticamente tutti i controlli. Analogamente, il campo SPX di dominio SPXEncryption e il campo DataProtectionSPXTemplate relativo alla corrispondenza rilevata non sono intercambiabili; DataProtectionPolicy deve fare riferimento a una Data Control List esistente e appropriata. Verificare preventivamente i prerequisiti dei motori, di Zero-Day e di BATV, oltre al modello di password SPX. La tabella descrive la verifica dei destinatari come applicata in uscita, la guida WebAdmin come applicata in entrata; non dedurne una nuova direzione di verifica. I test positivi e negativi per direzione e i valori salvati della policy determinano se il modello di protezione pianificato è stato attuato.

Per la Data Control List, l’esempio XML mostra MTADataControlList, contenente Name e Signatures con elementi Signature ripetuti. Le etichette di tabella name e signaturename non costituiscono un’istruzione confermata a serializzarle come tag XML in minuscolo. Confermare preventivamente MTA Mode, leggere le firme disponibili e scegliere solo le CCL appropriate. La lista da sola non genera alcuna azione di protezione: soltanto l’associazione tramite DataProtectionPolicy e l’azione nella policy SMTP attuano il modello. Rileggere poi la lista e l’associazione e verificare una corrispondenza controllata e un contenuto simile senza corrispondenza.

Non equiparare DKIM ed eccezioni al routing

In DKIMVerification, VerifactionStatus, scritto effettivamente così nell’esempio, controlla l’attivazione. ActionForVerifactionFail è un selettore diverso da ActionForSignatureInvalid o ActionForSignatureNotFound: il primo riguarda errori di verifica dell’hash o della firma, il secondo una chiave pubblica DNS assente o sintatticamente non valida, il terzo una firma assente. Non correggere silenziosamente gli errori ortografici dei primi due tag. L’esempio XML indica Pass, mentre la tabella dei parametri e la guida WebAdmin indicano Accept insieme a Quarantine e Reject. Questo non conferma che i valori API siano intercambiabili; prima di una richiesta, chiarire il contratto API del build e testare separatamente tutti e tre i casi in entrata.

In DKIMSigning, Domain identifica il dominio di firma, non Name; anche il riferimento per l’eliminazione richiede Domain. In fase di creazione e modifica, KeySelector e PrivateRSAKey sono campi obbligatori. Secondo la guida WebAdmin, un dominio può avere più firme, mentre il riferimento per l’eliminazione cita solo il dominio: in presenza di più selettori, chiarire preventivamente l’ambito esatto dell’eliminazione, senza dedurre che sia possibile eliminare per selettore. Archiviare in modo protetto le chiavi private e le credenziali API e rimuoverle da risposte e log; verificare poi DNS e la nuova firma ricevuta come descritto sopra.

La lista globale in entrata usa MtaBlockedSenders con BlockedEmailAddresses ed elementi EmailAddress ripetuti; la tabella API consente singoli indirizzi o domini con wildcard come *@example.com. Questa lista non sostituisce una policy antispam completa e, nel contesto MTA qui descritto, si applica solo ai messaggi in entrata. Prima di una modifica, leggere l’ambito e le voci esistenti; testare poi un mittente corrispondente e uno non corrispondente.

Separatamente, l’API descrive AntiSpamTrustedDomain con DomainList ed elementi DomainName ripetuti come eccezione per aggirare la scansione della posta per domini attendibili. Questa fonte non specifica esattamente quali scanner vengano aggirati. Non inventare quindi un percorso nell’interfaccia grafica, non garantire che «tutte le scansioni siano disattivate» e non confondere i Trusted Domains con i domini protetti di routing. Prima della creazione o della rimozione, chiarire la lista esatta dei domini, l’eccezione necessaria e l’effetto sulla scansione nel build installato; limitare strettamente l’ambito e verificare l’eccezione con una data di revisione e messaggi corrispondenti e non corrispondenti.

Per Delete Trusted Domain, la tabella dei parametri indica DomainName come array obbligatorio con più valori possibili, ma non fornisce alcun esempio di eliminazione. Non adottare quindi senza verifica la struttura annidata dell’esempio Add come richiesta di eliminazione; confermare preventivamente i valori di destinazione e la struttura completa della richiesta nella API help installata oppure tramite un chiarimento ufficiale.

Il selettore globale del motore è MalwareProtection con PrimaryAntiVirusEngine, il cui valore predefinito nella tabella API è Sophos. Non è l’elemento omonimo annidato nella policy e non attiva autonomamente gli ambiti di scansione. Controllare gli effetti su Single-/Dual-Scanning e Zero-Day Protection, come descritto sopra, nelle policy interessate prima e dopo una modifica.

Risposte specifiche degli oggetti come ausilio diagnostico

Le associazioni seguenti provengono dalle righe di stato SFOS-22/23. I numeri sono codici di operazione XML, non codici HTTP; Message.* sono chiavi della fonte non risolte, non testi di messaggi confermati né cause di errore univoche. Le regole generali di sicurezza API descritte sopra valgono anche qui: confrontare la risposta effettiva e lo stato salvato prima di ogni nuovo tentativo, non rimuovere dipendenze sulla base di supposizioni e fermarsi se lo stato parziale non è chiarito.

Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. Le ultime tre righe rendono particolarmente importante la verifica dell’importazione; non presumere che l’intero file sia stato scartato o acquisito. Edit Address Group riporta in queste fonti solo 200 → Message.AddrGrpUpdateSuccess e 500 → Message.AddrGrpUpdateFail; non presentare i codici Add come risposte Edit documentate.
Delete Address Group: 504, 505 e 506 rimandano ciascuno a Message.AddrGrpForeignKeyExists; 507 a Message.AddrGrpEmailArcKeyExists. La stessa associazione simbolica non determina quale riferimento sia interessato. Verificare gli utilizzi e i gruppi effettivamente presenti; queste risposte non sostituiscono il contratto di eliminazione mancante.
Add Data Control List e Update Data Control List: ciascuno riporta 502 → Message.DLPAddSameName e 545 → Message.MTAModeDisableCheck. Anche la chiave Update contiene «Add»; non rinominarla. Verificare nomi, modalità e lista salvata, senza stabilire una causa dalla sola chiave.
Add SMTP Policy e Edit SMTP Policy: ciascuno riporta 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck e 545 → Message.MTAModeDisableCheck. Solo Add SMTP Policy riporta 502 → Message.SMTPProfileduplicateName. Per 543, la fonte distingue Message.SMTPProfileSenderGenSPXAdd per Add e Message.SMTPProfileSenderGenSPXEdit per Edit. Confrontare associazioni dei domini, nomi, modalità e dipendenze SPX con lo stato reale; non attivare rinominazioni automatiche o allentamenti della protezione.
Email Configuration: 505 → Message.ASConfigSubOperationFail compare in entrambe le versioni. Prima di un nuovo tentativo, rileggere tutte le sottosezioni SMTP, POP/IMAP e TLS interessate, senza presumere un successo completo o un rollback completo. La riga aggiuntiva di SFOS-23 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname resta soggetta alle precisazioni indicate sopra.

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. Attendersi il rifiuto del destinatario non valido soltanto quando la verifica dei destinatari è attiva, il metodo di verifica selezionato funziona attraverso un percorso di verifica autorevole raggiungibile e il rifiuto è configurato. Per With callout, distinguere questo test negativo dall’eccezione documentata: SFOS accetta i destinatari quando il server di posta di destinazione è irraggiungibile per un periodo definito. La documentazione non specifica tale periodo; non presumere che la stessa eccezione si applichi a In Active Directory. Con 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

Sophos Firewall Mail Protection è uguale a Sophos Email?

No. Firewall Mail Protection elabora SMTP direttamente sul firewall; Sophos Email è un cloud email gateway. Entrambi possono svolgere compiti di protezione simili, ma non vanno messi in sequenza senza un design deliberato.

Perché i messaggi rimangono nel Mail spool?

Spesso sono coinvolti server di destinazione, DNS, TLS o routing. Controllare anche se una regola con priorità superiore esegue il match SMTP prima della regola MTA automatica.

Sophos Firewall supporta SMTP AUTH per i client relay interni?

Non nella SMTP route and scan Policy. Per i dispositivi usare Host-based relay. Secondo Sophos, l’Authenticated relay separato non è conforme alle RFC e va testato con il client; l’autenticazione del firewall verso uno smarthost upstream supporta PLAIN e LOGIN.