Configurare Sophos Firewall Mail Protection in modalità MTA

Sophos Firewall può non solo consentire il traffico email come normale connessione firewall, ma anche lavorare in modalità MTA come Mail Transfer Agent tra Internet e il server di posta interno. Il firewall accetta connessioni SMTP, controlla i messaggi con Mail Protection e li consegna poi al server di posta definito.

Oggi consigliamo Mail Protection sul firewall solo per casi speciali pianificati consapevolmente, per esempio quando un Exchange locale o un altro server di posta interno deve essere protetto direttamente tramite il firewall. Per Microsoft 365, Google Workspace e la maggior parte degli ambienti di posta cloud moderni, Sophos Central Email è in genere la soluzione migliore. Central Email è più vicino al servizio di posta effettivo, si integra in modo più pulito con le mailbox cloud, riduce la complessità nel set di regole del firewall ed evita molti temi MTA classici come modifiche MX, spool locali, domande sul relay e analisi degli errori sul firewall.

Un altro punto pratico: rispetto a Sophos Central Email, Email Protection sul firewall appare da tempo come una funzione per ambienti esistenti, che resta rilevante soprattutto per server di posta on-premises già presenti. Chi pianifica oggi un nuovo progetto dovrebbe quindi verificare prima se un cloud mail gateway sia l’architettura più pulita.

La soluzione è tecnicamente potente, ma anche soggetta a errori se DNS, record MX, TLS, relay, verifica utenti, policy e log non sono pianificati con cura. Un MTA configurato in modo errato può bloccare email legittime, ritardare il mailflow o, nel peggiore dei casi, essere interpretato come relay.

Questo articolo spiega la configurazione pratica di Sophos Firewall Mail Protection in modalità MTA. Non sostituisce una pianificazione di Sophos Central Email. Per molti ambienti Microsoft 365 o Google Workspace, un cloud mail gateway è spesso più adatto. Se però viene gestito un Exchange locale, un server di posta ibrido o un percorso SMTP volutamente basato sul firewall, serve un piano operativo chiaro.

Quando Mail Protection sul firewall ha senso

Mail Protection su Sophos Firewall ha senso soprattutto quando il traffico SMTP deve passare intenzionalmente dal firewall e il firewall deve fare più che inoltrare semplicemente la porta 25.

Scenari tipici:

Le email in ingresso devono essere prima accettate e controllate sul firewall.
Un server di posta interno non deve essere raggiungibile direttamente da Internet.
Il controllo di spam, malware, tipi di file o contenuti deve avvenire prima della consegna.
Le email in uscita devono essere inviate in modo controllato tramite il firewall o uno smarthost.
Quarantena, mail spool e log SMTP devono essere tracciabili sul firewall.

Non ogni configurazione mail dovrebbe passare dal firewall. Se Sophos Central Email, Microsoft Defender for Office 365 o un altro cloud mail gateway gestisce già l’intero mailflow, Mail Protection sul firewall non dovrebbe essere inserita in aggiunta senza documentare precisamente il flusso mail. Gateway doppi portano rapidamente a responsabilità poco chiare per quarantena, header, SPF/DKIM/DMARC, TLS e troubleshooting.

Distinguere modalità MTA, Legacy mode e SMTP Relay

Con Sophos Firewall bisogna separare chiaramente tre aspetti:

Funzione	Scopo	Uso tipico
MTA mode	Il firewall accetta email, le controlla e le consegna	Mailflow SMTP in ingresso o in uscita con policy
Legacy mode	vecchia elaborazione mail basata su proxy	Ambienti esistenti che vengono migrati o mantenuti volutamente
SMTP Relay come servizio locale	sistemi interni inviano tramite il firewall	Stampanti, scanner, applicazioni o sistemi di monitoring

Il MTA mode è la modalità di destinazione normale per scenari moderni di Mail Protection sul firewall. Il servizio locale SMTP Relay, invece, è un tema di Device Access. Dovrebbe essere raggiungibile solo da reti interne definite. Un’apertura troppo ampia può favorire l’abuso del relay. L’hardening dei servizi locali è descritto in Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Requisiti

Prima della configurazione, questi punti devono essere chiariti:

Sophos Firewall con Email Protection valida o bundle adeguato.
Non tutti i modelli supportano il MTA mode. XGS 87 e XGS 88 sono appliance senza supporto MTA mode.
Zona DNS pubblica e record MX sono noti.
Server di posta interno, porta di destinazione e percorso di consegna sono documentati.
Indirizzo IP pubblico o indirizzo WAN per il traffico SMTP in ingresso è definito.
Il firewall può instradare e raggiungere il server di posta interno.
L’accesso DNS in uscita del firewall funziona.
La strategia TLS e certificati desiderata è chiarita.
Il processo di quarantena e rilascio è definito a livello organizzativo.

Prima di modificare il mailflow dovrebbe essere pianificata una finestra di manutenzione. Un test su record MX produttivi senza piano di fallback è rischioso, perché le email in ingresso possono essere rapidamente ritardate o rifiutate a seconda del mittente.

Definire l’architettura target

Per prima cosa va deciso quale direzione deve elaborare il firewall.

Mailflow in ingresso

Nel mailflow in ingresso, i record MX esterni puntano all’indirizzo pubblico su cui Sophos Firewall accetta SMTP. Il firewall controlla il messaggio e lo inoltra al server di posta interno.

Flusso tipico:

Il mittente esterno si connette via SMTP all’indirizzo MX pubblico.
Sophos Firewall accetta la connessione in MTA mode.
Mail Protection controlla mittente, destinatario, spam, malware, allegati e policy.
Il firewall consegna l’email al server di posta interno.
Il server di posta interno consegna nella mailbox o elabora ulteriormente il messaggio.

È importante che il server di posta interno non resti raggiungibile anche in modo non filtrato da Internet. Se in parallelo una regola DNAT punta ancora direttamente al server di posta, una parte del traffico può aggirare Mail Protection. Per pubblicazioni server normali, Pubblicare un server tramite DNAT è la base adatta, ma in MTA mode il firewall stesso è il punto di accettazione SMTP.

Mailflow in uscita

Nel mailflow in uscita, il server di posta interno invia tramite Sophos Firewall. Il firewall può controllare i messaggi, inoltrarli a uno smarthost o consegnarli direttamente, a seconda della configurazione.

Chiarire prima:

L’IP pubblico del firewall può inviare email direttamente?
SPF, DKIM e DMARC sono corretti per il percorso di invio scelto?
Serve uno smarthost del provider?
Il traffico SMTP in uscita deve essere limitato a sistemi interni specifici?
Dove vengono monitorati i messaggi rifiutati o ritardati?

Per il traffico mail in uscita dovrebbe essere usata una struttura di regole e policy propria e tracciabile. Una regola generale LAN to WAN senza restrizioni chiare è di solito troppo ampia per server di posta. Le basi su ordine delle regole e profili di sicurezza sono in Capire e costruire correttamente le regole Sophos Firewall.

Preparare cambio MX e test esterni

Una modifica di Mail Protection diventa critica solo quando i mittenti esterni usano davvero il nuovo percorso. Per questo record MX, DNS TTL, raggiungibilità esterna e rollback devono essere verificati prima del cambio produttivo.

Prima del cambio:

Documentare record MX attuale, priorità e TTL.
Ridurre per tempo il DNS TTL se potrebbe servire un fallback rapido.
Distinguere chiaramente vecchio percorso mail e nuovo indirizzo Sophos Firewall.
Identificare vecchie regole DNAT dirette al server di posta.
Definire destinatari e mittenti di test.
Definire il piano di fallback: vecchio MX, vecchia regola DNAT o smarthost temporaneo.
Preparare monitoring per spool, quarantena e queue del server di posta.

Controlli esterni utili da un sistema fuori dalla propria rete:

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

I comandi non sostituiscono un test completo del mailflow, ma mostrano rapidamente se DNS, porta 25 e STARTTLS sono fondamentalmente raggiungibili. example.com e mail.example.com devono essere sostituiti con il dominio reale e l’host mail reale.

Dopo il cambio, inviare subito una mail di test in ingresso e documentare l’intero percorso:

Connessione visibile in Log Viewer?
Voce presente in smtpd_main.log?
Verifica destinatario riuscita?
Consegna al server di posta interno avvenuta?
Messaggio arrivato nella mailbox?
Nessuna consegna diretta parallela che aggira il MTA?

Se il firewall accetta email ma non le consegna, non bisogna riportare subito indietro l’MX. Prima va chiarito se si tratta di un problema interno di routing, DNS, TLS o server di posta. Se però i mittenti esterni non riescono a connettersi al firewall o email legittime vengono rifiutate in modo ampio, un fallback rapido al percorso mail precedente è spesso più sensato di esperimenti prolungati nel percorso MX produttivo.

Attivare MTA mode

Le impostazioni di base si trovano in Sophos Firewall sotto:

Email > General settings

Qui viene definita la modalità email. Per questa guida è rilevante MTA mode. Dopo il cambio, verificare se policy, oggetti host e domini mail esistenti corrispondono ancora all’operatività desiderata.

In ambienti esistenti non cambiare semplicemente tra Legacy mode e MTA mode senza testare il mailflow. Elaborazione, log e logica delle policy sono diversi. Prima di una migrazione vanno documentati configurazione firewall attuale, record MX, connettori del server di posta e impostazioni relay.

Configurare routing SMTP e domini

Per le email in ingresso, il firewall deve sapere quali domini accettare e dove consegnarli.

Flusso tipico:

Sotto Email > Policies and exceptions o nelle aree Mail Protection, pianificare domini e server di destinazione interessati.
Inserire il dominio mail, per esempio example.com.
Definire server di posta interno o oggetto host come destinazione di consegna.
Verificare se il firewall raggiunge il server di posta sulla porta di destinazione.
Verificare requisiti TLS e certificati.
Inviare email di test dall’esterno a un destinatario noto.

Per server di posta interni, DNS è particolarmente importante. Il firewall deve poter risolvere correttamente le destinazioni interne, e i mittenti esterni devono raggiungere il record MX pubblico. Se la risoluzione DNS interna ha un ruolo, aiuta Configurare DNS Request Routes su Sophos Firewall.

Pianificare policy per spam, malware e allegati

Mail Protection è valida solo quanto le policy che si applicano davvero. Una policy non va solo creata, ma nominata con uno scopo chiaro.

Domande importanti sulle policy:

Quali domini o gruppi di destinatari sono interessati?
Viene elaborato traffico mail in ingresso, in uscita o in entrambe le direzioni?
Cosa succede con spam, malware, allegati sospetti o tipi di file indesiderati?
Le email vengono bloccate, messe in quarantena, consegnate o marcate con header?
Chi può controllare la quarantena e rilasciare email?
Quali processi per false positive esistono?

Se viene usata Zero-Day Protection, gli allegati email sospetti possono essere analizzati in aggiunta. Limiti, report e decisione di rilascio sono spiegati in Capire e gestire Sophos Firewall Zero-Day Protection.

Mettere in sicurezza relay e Device Access

Un errore frequente è confondere mailflow MTA e SMTP Relay aperto. Il firewall non deve poter essere usato come relay da reti qualsiasi.

Verificare:

Sotto Administration > Device access, SMTP Relay è raggiungibile solo dalle zone interne necessarie.
Se vengono usate ACL Exception Rules, le sorgenti sono definite in modo stretto.
Solo server di posta interni, scanner o server applicativi definiti possono relayare tramite il firewall.
Da WAN, reti guest e zone untrusted, SMTP Relay non è abilitato in modo generico.
Il logging è attivo, così abusi o configurazioni errate sono visibili.

Se stampanti, scanner o applicazioni devono inviare email, va documentato un percorso relay interno dedicato. Tali sistemi non dovrebbero comunicare direttamente con destinazioni SMTP esterne arbitrarie se l’ambiente può evitarlo.

Testare il mailflow

Dopo la configurazione, un singolo invio riuscito non basta. Vanno eseguiti più test e documentati i risultati.

Test in ingresso

Verificare almeno:

Il record MX esterno punta all’indirizzo atteso.
La porta 25 è raggiungibile dall’esterno.
Il firewall accetta la connessione in MTA mode.
L’email viene inoltrata al server di posta interno.
Il destinatario esiste e riceve il messaggio.
Il test spam o malware viene trattato come previsto.
La voce di quarantena o log è tracciabile.

Test in uscita

Verificare almeno:

Il server di posta interno invia tramite la route attesa.
La regola firewall e la mail policy si applicano.
SPF, DKIM e DMARC corrispondono al percorso di invio.
Il server di destinazione accetta il messaggio.
Bounces o messaggi Deferred vengono monitorati.
Nessun altro sistema interno invia direttamente verso l’esterno in modo non pianificato.

Controllare i log

Per un controllo visivo rapido aiuta Log Viewer. Per un’analisi più profonda sono importanti i file di log mail. La corrispondenza è in Troubleshooting Sophos Firewall: servizi e log.

File di log rilevanti:

Area	File di log tipico
SMTP MTA	`smtpd_main.log`
Errori SMTP	`smtpd_error.log`, `smtpd_panic.log`, `smtpd_reject.log`
Anti-Spam	`sasi.log`
Legacy SMTP/MTA	`awarrensmtp.log`, `awarrenmta.log`, `awarrenmta_debug.log`
POP/IMAP Proxy	`warren.log`

In caso di troubleshooting urgente, annotare l’orario del test, raccogliere mittente, destinatario, oggetto, IP sorgente e Message-ID, quindi correlare temporalmente Log Viewer e file di log.

Quarantena, spool e storage

Mail Protection genera dati locali. A seconda del volume, i messaggi finiscono in quarantena, spool o aree temporanee. Per questo spazio di storage, stato SSD e piano di recovery diventano più rilevanti che con una semplice regola firewall.

Domande operative pratiche:

Chi controlla la quarantena e con quale frequenza?
Come vengono rilasciati i false positive?
Quando un messaggio viene eliminato invece che rilasciato?
Come viene rilevato un mail spool in crescita?
Esiste monitoring per spazio di storage e System Health?
Dopo firmware update è previsto un breve test del mailflow?

Per temi di storage e reporting sono adatti Pulire storage e report di Sophos Firewall e Controllare Sophos Firewall SSD Health. In ambienti HA va inoltre considerato che quarantena mail e dati mail elaborati possono essere dati operativi legati al nodo. Le basi HA sono in Varianti di cluster HA Sophos Firewall.

Troubleshooting

Le email esterne non arrivano

Controllare prima DNS e raggiungibilità: record MX, IP pubblico, porta 25, vecchie configurazioni NAT, MTA mode e dominio mail responsabile. Poi verificare in Log Viewer e in smtpd_main.log se la connessione raggiunge il firewall. Se non è visibile alcuna connessione, il problema è probabilmente prima di Mail Protection.

Il firewall accetta email, ma non le consegna

Allora sono più probabili server di posta interno, routing, DNS, porta di destinazione, TLS, verifica destinatario o policy. Verificare se il firewall può raggiungere il server di posta e se il server accetta la connessione. Reject log e log del server di posta devono essere valutati insieme nel tempo.

Molte email restano nello spool

Uno spool in crescita indica spesso problemi di consegna: server di posta interno non raggiungibile, requisito TLS non adatto, risoluzione DNS fallita o server di destinazione che rifiuta il messaggio. In questo caso non limitarsi a riconsegnare singoli messaggi, ma cercare la causa nel percorso di routing e SMTP.

Un caso importante di ordine delle regole viene facilmente trascurato: se una regola firewall creata automaticamente o manualmente si trova sopra la regola MTA e matcha traffico SMTP, la vera regola MTA non viene più valutata. Le email possono quindi rimanere nel mail spool anche se DNS, porta 25 e server di posta sembrano fondamentalmente corretti.

Verificare:

Aprire Rules and policies > Firewall rules.
Controllare le regole sopra la regola MTA o SMTP.
Controllare nuove regole generate automaticamente, regole IPsec, regole hotspot o regole impostate manualmente su Top.
Eseguire di nuovo il test SMTP e confrontare Log Viewer, mail spool e smtpd_main.log.

La regola non deve essere spostata alla cieca verso il basso se svolge altri scopi produttivi. Il punto decisivo è se intercetta in modo inatteso traffico SMTP prima della regola MTA.

Digest di quarantena assente per indirizzi alias

Se gli utenti usano indirizzi alias, non bisogna controllare le impostazioni di quarantena solo per l’indirizzo mail primario. Secondo Sophos, le impostazioni di quarantena non vengono applicate automaticamente agli indirizzi alias per impostazione predefinita. Se mancano digest mail o rilasci per destinatari alias, gli indirizzi alias devono essere considerati insieme all’indirizzo primario nel contesto di quarantena o utente.

Un mittente legittimo viene riconosciuto come spam

I false positive non dovrebbero essere risolti subito con eccezioni ampie. Prima controllare dominio mittente, SPF/DKIM/DMARC, header, reputazione, policy match e destinatari interessati. Se serve un’eccezione, deve essere strettamente limitata e documentata con una data di revisione.

I sistemi interni non possono relayare

Verificare se SMTP Relay sotto Administration > Device access è consentito dalla zona corretta e se la sorgente corrisponde all’ACL. Poi controllare i log mail. Se uno scanner o un’applicazione deve relayare, la sorgente dovrebbe essere documentata come oggetto host e non va abilitata inutilmente un’intera rete.

Dopo firmware update la posta funziona diversamente

Dopo firmware update vanno controllati MTA mode, policy, certificati, mail spool, quarantena e log rilevanti. Per update più grandi è adatto anche Controllare Sophos Firewall prima dell’upgrade a SFOS 22.

Checklist operativa

Licenza Mail Protection e supporto appliance verificati.
MTA mode scelto consapevolmente e documentato.
Record MX, IP pubblico e server interno di destinazione corretti.
Cambio MX, test esterni e rollback preparati.
Nessuna regola DNAT parallela non filtrata aggira il MTA.
Policy in ingresso e in uscita nominate in modo comprensibile.
L’ordine delle regole firewall non impedisce alla regola MTA di applicarsi.
SMTP Relay consentito solo da sorgenti interne definite.
Processo di quarantena e false positive definito.
Indirizzi alias considerati nel processo di quarantena e digest.
Mail spool, spazio di storage e System Health monitorati.
Log conservati localmente, in Sophos Central o via Syslog abbastanza a lungo.
Dopo firmware update viene eseguito un test del mailflow.

Per conservazione più lunga e correlazione con altri eventi di sicurezza, verificare Central Firewall Reporting o Inviare Sophos Firewall Syslog a SIEM.

FAQ

Che cos'è il MTA mode su Sophos Firewall?

In MTA mode, Sophos Firewall lavora come Mail Transfer Agent. Accetta messaggi SMTP, li controlla con Mail Protection e poi li consegna al server di posta interno o al mailhop successivo.

Serve una licenza propria per Mail Protection?

Sì. Per Mail Protection serve un’autorizzazione Email Protection adeguata o un bundle che include questa funzione. Senza licenza, la protezione mail MTA non deve essere pianificata come percorso di protezione produttivo.

Sophos Firewall Mail Protection è uguale a Sophos Central Email?

No. Sophos Firewall Mail Protection gira sul firewall nel mailflow. Sophos Central Email è un cloud mail gateway. Entrambi gli approcci possono avere obiettivi simili, ma sono architettonicamente diversi e non dovrebbero essere combinati senza pianificazione.

Sophos Firewall può essere abusato come SMTP Relay?

Il rischio nasce quando SMTP Relay viene abilitato in modo troppo ampio. Per questo SMTP Relay sotto Administration > Device access dovrebbe essere consentito solo da sorgenti interne chiaramente definite.

Perché le email restano bloccate nel mail spool?

Spesso sono coinvolti server di posta interno, DNS, TLS o routing. Inoltre bisogna verificare se una regola firewall con priorità superiore matcha traffico SMTP prima della regola MTA. In quel caso la vera regola MTA non viene valutata.

Dove si vedono problemi con MTA e SMTP?

Prima in Log Viewer e poi nei log mail sotto /log, soprattutto smtpd_main.log, smtpd_error.log, smtpd_reject.log e sasi.log. In caso di problemi di consegna vanno controllati anche i log del server di posta interno.