Creare e testare in sicurezza le eccezioni email di Sophos Firewall

Un’eccezione email su Sophos Firewall non si limita ad autorizzare un mittente. Ignora controlli di sicurezza selezionati per un percorso SMTP definito. Proprio per questo può risolvere in modo preciso un falso positivo confermato, ma può anche disattivare silenziosamente SPF, la scansione antimalware, Zero-Day Protection o i controlli DKIM.

⚠️ Un’eccezione viene creata solo dopo aver riprodotto un falso positivo. Si ignora esclusivamente il controllo interessato. Scegliere la condizione affidabile più ristretta, perché host sorgente, mittente e destinatario sono alternative e non una condizione AND comune. All checks e wildcard estese non sono una soluzione rapida standard.

Creare l’eccezione in sette passaggi

1. Registrare l’ora del test, l’IP sorgente SMTP, il mittente della busta, il destinatario, l’oggetto, il Message-ID e il motivo esatto del rifiuto.
2. Verificare se il problema è causato da DNS, routing, relay, TLS o dalla policy email vera e propria anziché da un controllo di sicurezza.
3. In Email > Policies and exceptions > Add an exception, selezionare solo il controllo dimostrato come interessato.
4. Attivare solo la condizione più ristretta adatta in Sources or hosts, Sender addresses o Recipient addresses.
5. Testare positivamente un messaggio equivalente e negativamente almeno una variante fuori dall’ambito.
6. In Email > Mail logs, confrontare risultato e Reason prima e dopo; verificare separatamente le altre protezioni con casi innocui.
7. Documentare il responsabile, la motivazione e la data di revisione; rimuovere l’eccezione dopo aver corretto la causa.

Cosa ignora realmente un’eccezione

SFOS raggruppa i controlli ignorabili in base al loro effetto. Spam protection contiene RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF e BATV. Malware protection contiene Malware e Zero-day protection. Other contiene Data protection, File protection, Encryption, Banner addition, DKIM signing e DKIM verification.

Questa selezione non è un elenco di comodità. Un’eccezione per SPF, ad esempio, lascia in funzione il resto del percorso antispam e antimalware. Un’eccezione per Malware o Zero-day protection, invece, rimuove un controllo centrale dei contenuti per tutti i messaggi che corrispondono all’ambito. Encryption, DKIM signing o DKIM verification modificano inoltre la riservatezza e la convalida dell’integrità del flusso email in uscita o in entrata.

Questa eccezione appartiene alla modalità MTA. Una policy SMTP route and scan riunisce routing e azioni antispam, antimalware, file e dati. In modalità legacy, SFOS opera come proxy trasparente e usa policy SMTP malware scan e SMTP spam scan separate; l’oggetto eccezione MTA non è il controllo adatto. Vedere Configurare Mail Protection di Sophos Firewall in modalità MTA e Configurare Mail Protection in modalità legacy.

Encryption indica qui la crittografia email della policy MTA, ad esempio SPX Email Encryption, non la crittografia di trasporto SMTP. Require TLS negotiation, convalida del certificato e Skip TLS negotiation si gestiscono separatamente in Email > General settings > SMTP TLS configuration. Un’eccezione email non corregge quindi handshake TLS, routing, relay o regole firewall.

Comprendere la corrispondenza prima di salvare

I tre gruppi non formano una condizione AND. L’API ufficiale SFOS 22.0 li denomina ForTheseSourceHost, ORTheseSenderAddresses e ORTheseRecipientAddresses. Con più gruppi attivi basta la corrispondenza dell’host sorgente o del mittente o del destinatario. IP, dominio partner e casella pilota creano quindi tre percorsi di corrispondenza, non una combinazione più ristretta.

Questo oggetto non offre un AND tra i gruppi; anche due eccezioni allargherebbero l’ambito. Se servono due criteri simultanei, correggere la causa o separare il flusso con una policy o un percorso gateway appropriato.

Sources or hosts

SFOS accetta come sorgenti indirizzi IP, intervalli IP, liste IP, reti o FQDN. I FQDN con wildcard non sono supportati per le eccezioni host email. *.example.net non è quindi un sostituto valido dell’indirizzo sorgente SMTP osservato. Per localhost non serve un’eccezione, poiché SFOS non esegue la scansione delle email locali per impostazione predefinita.

Per i servizi email cloud o i gateway distribuiti, un singolo IP può essere troppo restrittivo, mentre un’intera rete del provider può essere eccessivamente ampia. Si utilizza solo un oggetto sorgente pubblicato e realmente osservato nel proprio flusso email. Se altri tenant condividono gli IP del provider, anche tale oggetto può essere troppo ampio. Non escludere un controllo di sicurezza basandosi soltanto su quella rete.

Mittente e destinatario

Per Sender addresses e Recipient addresses è consentito un indirizzo come sender@example.net o una wildcard come *@example.net. Un secondo gruppo non è un ancoraggio più restrittivo perché è collegato con OR. Un mittente non è una prova di fiducia indipendente quando si esclude SPF o DKIM; un’eccezione destinatario vale per i messaggi corrispondenti di tutti i mittenti.

BATV presenta una regola speciale insolita: per ignorare il controllo BATV delle email di un mittente, il suo indirizzo deve essere inserito sia in Sender addresses sia in Recipient addresses. Se manca uno dei due campi, l’eccezione è incompleta per questo caso BATV.

Creare un’eccezione ristretta

L’esempio riguarda un falso positivo SPF confermato da un gateway dedicato del partner. 203.0.113.25 è un indirizzo di documentazione da sostituire con l’IP pubblico osservato in Mail logs. È adatto solo se l’IP appartiene esclusivamente al gateway fidato; per un relay cloud condiviso il bypass sarebbe troppo ampio.

1. Aprire Email > Policies and exceptions > Add an exception.
2. Inserire un nome tracciabile come FP-SPF-partner-example-review-2026-09-30.
3. Tra i controlli da ignorare, selezionare esclusivamente SPF.
4. In Sources or hosts, inserire l’host 203.0.113.25.
5. Lasciare Sender addresses e Recipient addresses disattivati o vuoti: aggiungerebbero corrispondenze OR.
6. Salvare senza aggiungere altri host o controlli.

Il nome contiene intenzionalmente la causa e la data di revisione. Non sostituisce però la documentazione nella modifica o nel ticket. Il nome non impone tecnicamente una data di scadenza; il responsabile deve effettuare realmente la revisione.

Eseguire test positivi e negativi

Il partner reinvia lo stesso messaggio controllato, che non deve più fallire per il Reason SPF confermato. In Email > Mail logs filtrare per intervallo, mittente, destinatario o oggetto e per Result e Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification e BATV hanno filtri Reason dedicati. Per approfondire usare smtpd_main.log e, per i rifiuti, smtpd_reject.log; Servizi e log di Sophos Firewall ne spiega il ruolo.

Eseguire poi un test negativo su un percorso SMTP controllato non escluso. Non deve bypassare il controllo documentato a causa di questa eccezione. Con un’eccezione solo per host sorgente, altri mittenti o destinatari sullo stesso IP non sono test negativi: corrispondono allo stesso ramo OR. Un file innocuo può verificare separatamente Malware e File Protection; non usare malware reale.

La sola consegna non dimostra l’ambito. La documentazione ufficiale di Mail logs descrive Reason e stato di consegna, ma non un campo “matched exception” né l’elenco dei controlli ignorati. Valutare insieme Reason prima/dopo, configurazione e casi positivi e negativi separati. Non presentare la consegna come prova che tutte le altre protezioni siano state eseguite.

Riconoscere le eccezioni rischiose

Anche una sola wildcard di dominio ampia o una grande rete sorgente può rimuovere la protezione per una parte considerevole del flusso email. Inserirle entrambe non restringe l’ambito, ma aggiunge corrispondenze OR. In particolare, le eccezioni per Malware, Zero-Day Protection, Data protection e File protection richiedono una decisione di rischio documentata e un ambito molto ridotto e affidabile di per sé. In presenza di un errore di scansione ancora sconosciuto, non si disattiva preventivamente l’intero gruppo.

Anche le opzioni apparentemente funzionali sono rilevanti per la sicurezza. Ignorare Encryption può inviare contenuti riservati senza protezione. Senza DKIM signing manca la firma in uscita pianificata; senza DKIM verification non viene valutata una prova d’identità in entrata. Un’eccezione Banner può rimuovere testi o contrassegni obbligatori. Tali modifiche vengono concordate con i responsabili della posta e della conformità.

Circoscrivere gli errori in base al sintomo

Il messaggio viene ancora rifiutato

Valutare prima la nuova voce di log anziché il vecchio messaggio di test. L’IP sorgente effettivo, il mittente della busta, il destinatario e il Reason devono corrispondere all’ambito e al controllo selezionato. Un FQDN con wildcard in Sources or hosts non funziona. Se il messaggio viene rifiutato a causa di RBL, IP reputation, RDNS/HELO o un altro controllo, un’eccezione esclusivamente SPF non risolve questo motivo separato.

L’eccezione corrisponde a troppi messaggi

Confrontare separatamente i tre gruppi con il flusso reale. Ogni gruppo OR attivo aumenta le corrispondenze. Ridurre l’eccezione a un gruppo affidabile con il minor numero di valori e ripetere il test negativo.

L’email supera il controllo, ma non viene consegnata

Un’eccezione controlla le verifiche di sicurezza, non MX, il percorso interno, il relay, TLS SMTP o il server email di destinazione. Mail logs e lo spool mostrano se il messaggio fallisce dopo la scansione per DNS, routing, policy o consegna. Per un errore TLS, controllare il certificato, Require TLS negotiation e il peer; Encryption nell’eccezione e un ambito più ampio non lo risolvono.

L’eccezione BATV non viene applicata

Verificare che lo stesso indirizzo del mittente sia presente in Sender addresses e Recipient addresses. Quindi confrontare nuovamente il Reason BATV specifico e gli altri campi dell’ambito. Una seconda eccezione più ampia non sostituisce il campo BATV mancante.

Gestione e rollback

Ogni eccezione ha un responsabile, un motivo dimostrato di falso positivo e una data di revisione. Le modifiche vengono confrontate con l’audit trail; Tracciare le modifiche di configurazione su Sophos Firewall descrive la prova appropriata. Il flusso email effettivo rimane inoltre visibile separatamente in Mail logs e nei file MTA.

Prima della modifica registrare nome, controlli, valori dell’ambito e Reason precedente. Per preservare lo stato, eliminare soltanto la nuova eccezione lasciando intatte policy e altre eccezioni. Ritestare l’errore originale e un messaggio di controllo; se la causa non è risolta, pianificare prima una finestra di manutenzione o una correzione più ristretta.

Inquadrare le eccezioni e-mail tramite XML API

Nell’automazione, l’oggetto delle eccezioni MTA si chiama ExceptionPolicy. Prima di una modifica, salvare il nome esistente, i controlli saltati e tutti i valori di ambito. L’accesso, l’operazione di scrittura esplicita, l’analisi della risposta XML e i tentativi successivi sicuri sono spiegati in Proteggere l’accesso alla XML API di Sophos Firewall. L’inquadramento seguente descrive il contratto documentato per SFOS 22/23, non una richiesta di scrittura testata.

Trattare separatamente gli interruttori di esclusione e gli elenchi di corrispondenza

I campi di controllo all’interno di MalwareProtection, SpamProtection e Other selezionano quali controlli vengono saltati; non attivano la protezione generale della posta. Ad esempio, nell’oggetto dell’eccezione Malware è una selezione di esclusione, non un’attivazione dello scanner antimalware. Il riferimento indica Enable/Disable per la maggior parte di questi campi. Separatamente, gli interruttori anch’essi scalari ForTheseSourceHost, ORTheseSenderAddresses e ORTheseRecipientAddresses attivano quali gruppi di ambito vengono utilizzati. Anche i loro valori sono Enable/Disable, non elenchi di IP o indirizzi.

Nell’esempio di oggetto documentato, i valori corrispondenti si trovano separatamente e in strutture annidate:

• SourceHostList/SourceHost: più valori stringa per gli host di origine; il testo del parametro indica IP/FQDN.
• SenderAddressesList/Address: più indirizzi mittente, con supporto per i caratteri jolly negli indirizzi e-mail.
• RecipientAddresses/Address: più indirizzi destinatario, anch’essi con supporto per i caratteri jolly negli indirizzi e-mail.

I due campi Address hanno lo stesso nome, ma non sono intercambiabili: è il contenitore padre a determinare se si tratta del mittente o del destinatario. Un contenitore popolato non sostituisce la verifica dell’interruttore di ambito corrispondente. Ulteriori voci negli elenchi non costituiscono una condizione AND aggiuntiva; ogni ulteriore gruppo attivato crea il percorso di corrispondenza OR descritto sopra. In particolare, un elenco aggiuntivo di destinatari estenderebbe il bypass dell’host di origine anche ai messaggi provenienti da altre origini. Confrontare quindi sempre gli interruttori e gli elenchi salvati insieme con l’ambito approvato. La regola speciale BATV e la limitazione per gli FQDN con caratteri jolly continuano ad applicarsi.

Secondo il riferimento, Name è obbligatorio e può contenere al massimo 100 caratteri. I campi opzionali e le colonne dei valori predefiniti vuote, invece, non dimostrano che i valori omessi durante un aggiornamento vengano mantenuti o impostati su Disable. Non copiare l’ampio esempio del produttore per creare un’eccezione in produzione: attiva contemporaneamente più campi di esclusione e tutti e tre i gruppi di ambito.

Prima di una richiesta di scrittura, verificare la API help locale: l’esempio mostra CheckForSPF con Disable, mentre la tabella dei parametri riporta CheckforSPF con i valori non risolti $EMAILPROTECTION{SMTP_CHECK_SPF_ENABLE} e $EMAILPROTECTION{SMTP_CHECK_SPF_DISABLE}. RBL e RDNSAndHelo compaiono nella tabella, ma mancano nell’esempio di oggetto; in quest’ultimo, la selezione del banner è scritta come BanerAddition. Non correggere autonomamente queste grafie, non indovinare i valori dei token e non dedurre la collocazione XML dai campi mancanti. Se i tag esatti, i valori consentiti o l’operazione concreta per la build installata restano da chiarire, interrompere la scrittura e rivolgersi al supporto; per questo motivo, questa sezione non contiene un modello eseguibile di scrittura XML.

Distinguere le risposte e controllare lo stato salvato

La corrispondenza riportata nel riferimento deve essere letta insieme all’operazione. I valori sono codici di stato XML, non codici di stato HTTP; Message.* sono simboli della documentazione non risolti, non testi di runtime comprovati né cause di errore deducibili dal solo nome.

Add e Update indicano qui rispettivamente Exception Policy Add e Exception Policy Update. Sebbene la pagina menzioni anche Exception Policy Delete nel titolo, la sua tabella degli stati non contiene alcuna corrispondenza per Delete. Non applicare a Delete un codice di successo di Add/Update e non inventare una regola di validazione concreta a partire dal nome di un simbolo.

Dopo ogni tentativo di scrittura, anche in caso di 200, riaprire l’eccezione in Email > Policies and exceptions e confrontare con lo stato previsto il nome effettivamente salvato, tutte le selezioni di esclusione, tutti e tre gli interruttori di ambito e ogni elenco di host/indirizzi. In caso di eliminazione, verificare l’assenza dell’esatto oggetto previsto e che lo stato delle altre eccezioni sia rimasto invariato. Salvare l’Audit Trail e la risposta API completa, depurata dai dati sensibili. Solo dopo, i test positivi/negativi descritti sopra confermano l’effetto sul flusso di posta.

In caso di 502, errore, timeout o risposta poco chiara, rileggere lo stato effettivo prima di ogni nuovo tentativo: un nome esistente potrebbe già identificare un’altra eccezione oppure derivare dal primo tentativo. Non duplicare l’oggetto con un nuovo nome, non aggiungere ulteriori gruppi OR e non saltare altri controlli solo per aggirare l’errore. Per 541–545, verificare insieme operazione, codice, testo effettivo della risposta e configurazione salvata; una denominazione simbolica non risolta non giustifica una richiesta di correzione basata su supposizioni.

Checklist

• Sono disponibili un falso positivo riproducibile e il Reason esatto.
• IP sorgente, mittente della busta, destinatario e Message-ID sono documentati.
• Viene ignorato solo il controllo interessato.
• Preferire un solo gruppo di ambito adatto; gruppi aggiuntivi ampliano la corrispondenza tramite OR.
• I FQDN con wildcard non vengono usati come eccezioni host.
• Un’eccezione BATV contiene l’indirizzo del mittente in entrambi i campi degli indirizzi.
• I test positivi e negativi, insieme ai Reason precedenti e successivi, confermano l’effetto previsto.
• Gli altri controlli di spam, malware, file, dati e DKIM restano attivi.
• Responsabile, motivazione, data di revisione e rollback sono documentati.

FAQ