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 Central 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.

Occorre distinguere tre funzioni di Sophos Firewall:

• MTA mode: il firewall accetta, analizza e instrada le email.
• Legacy mode: precedente elaborazione proxy trasparente per ambienti esistenti.
• 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.

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.
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. Inoltre il firewall convalida SMTP TLS tramite l’IP del dominio, non il nome. Più domini sullo stesso IP possono quindi causare errori di certificato.

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.

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 a 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.
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.

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.

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.

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. 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

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.

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.

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.

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.

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;
• 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.

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.

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. Gli indirizzi alias vanno verificati separatamente nel design; i messaggi agli alias non compaiono in User Portal.

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.

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.

SFOS 22.0 MR2 corregge inoltre NC-177930, che lasciava messaggi nello spool dopo un crash di mailpoller. Se il problema compare su una versione precedente, includere il firmware nella diagnosi.

Central mostra Invalid API request

Su SFOS 22.0 MR1, Release e Delete potevano fallire quando il firewall veniva aperto tramite Sophos Central. Il workaround sicuro è accedere direttamente al WebAdmin locale ed eseguire l’azione in Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 ha corretto il problema. Se persiste, controllare separatamente profilo amministratore, accesso Central e permessi locali.

Impossibile attivare Reject based on RBL

Sophos elenca in 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. L’attuale Known Issues List non indica 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.

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