Configurare la crittografia email SPX su Sophos Firewall

Con Secure PDF Exchange, o SPX, Sophos Firewall converte un’email in uscita e i relativi allegati in un file PDF protetto da password. Il destinatario non ha bisogno di un proprio client di crittografia. A seconda del modello scelto, riceve una password monouso, utilizza una password memorizzata oppure ne registra una autonomamente.

Per un funzionamento affidabile devono cooperare quattro elementi: un template SPX, un trigger inequivocabile, un canale sicuro per la password e, se necessario, lo SPX Reply Portal. In seguito si testano un flusso positivo e uno negativo. La sola consegna di un PDF non dimostra né che sia scattata la policy corretta né che la registrazione della password e la risposta sicura funzionino.

SPX in otto passaggi

1. Verificare la licenza Email Protection, il flusso di posta MTA, il supporto del modello, il certificato del portale e il percorso SMTP TLS separato.
2. Decidere se la crittografia viene attivata da un dominio protetto, una corrispondenza Data Control o dal mittente.
3. Creare un template personalizzato in Email > Encryption > SPX templates > Add.
4. Scegliere consapevolmente il tipo di password, la crittografia PDF, la notifica e il Reply Portal.
5. Proteggere FQDN, reti consentite e porta in Email > Encryption > SPX portal settings.
6. In MTA mode, configurare la policy SMTP route and scan e assegnare il template; un Default SPX template non sostituisce questa policy.
7. Testare PDF, canale della password, registrazione e risposta con un destinatario esterno.
8. Eseguire un test negativo senza trigger SPX e documentare Mail logs, log MTA e rollback.

⚠️ Un campo Allowed networks vuoto nello SPX Portal non significa «nessun accesso», ma torna a Any. Sophos consiglia inoltre una porta dedicata per il Reply Portal. FQDN del portale, certificato, origini consentite e canale della password devono quindi essere definiti prima del test in produzione.

Quando SPX è adatto

SPX è utile quando destinatari esterni devono ricevere contenuti riservati come PDF protetti senza installare un client di crittografia. Può essere utilizzato sia in MTA mode sia in Legacy mode. Questa procedura usa MTA mode perché consente di collegare in modo chiaro dominio, Data Control e routing nella policy SMTP. Configurare Mail Protection in Legacy mode spiega l’alternativa trasparente.

SPX non è una crittografia del trasporto tra server di posta e non è una crittografia end-to-end tra due client email. Il firewall elabora il testo in chiaro, genera il PDF e controlla la password o la registrazione. Il PDF può poi continuare a esistere fuori dal firewall in caselle di posta, archivi o download. Ambito dei destinatari, conservazione e trasmissione della password fanno quindi parte del progetto di sicurezza.

La crittografia del trasporto SMTP si gestisce separatamente in Email > General settings > SMTP TLS configuration. Require TLS negotiation impone TLS agli host remoti o alle reti selezionate; se SFOS non riesce a stabilire la connessione TLS, scarta l’email destinata a tale destinazione. Skip TLS negotiation, invece, forza una connessione SMTP non cifrata. Il TLS certificate selezionato in questa sezione protegge il percorso SMTP e non è il certificato dei portali SPX. SPX e SMTP TLS vanno quindi pianificati separatamente e poi verificati insieme nel flusso esterno.

I prerequisiti sono:

• una licenza Email Protection valida;
• un flusso di posta in uscita già testato attraverso Sophos Firewall;
• un destinatario esterno di test documentato;
• un FQDN attendibile e un certificato corrispondente per i portali SPX utilizzati;
• un canale sicuro separato per le password quando non vengono registrate dal destinatario;
• una via di ripristino con cui rimuovere nuovamente le assegnazioni di template e policy.

Secondo l’attuale documentazione Sophos, SPX non è disponibile su XGS 87/87w. Inoltre, MTA mode completo non è disponibile su XGS 88/88w. Configurare Mail Protection in MTA mode spiega flusso di posta, licenza, relay e limiti dei modelli.

Definire trigger e priorità

SPX può essere attivato in tre modi. Se sono configurati più metodi, Sophos Firewall applica questo ordine in MTA mode:

1. Dominio protetto: Il template SPX selezionato in Domains and routing target si applica ai messaggi in uscita del dominio protetto corrispondente.
2. Data control list: Solo se non è impostato alcun template SPX a livello di dominio, una corrispondenza Data Control può applicare il template selezionato per la lista.
3. Trigger del mittente: Solo quando né il dominio né Data Control forniscono un template, si applica il metodo del mittente configurato in Default SPX template.

Un’assegnazione per dominio è ampia ed è adatta solo quando ogni messaggio in uscita corrispondente deve effettivamente essere cifrato. Data Control è adatto a tipi di contenuto definiti, ma deve essere testato con esempi positivi e negativi reali per individuare falsi positivi. Il trigger del mittente lascia a quest’ultimo la decisione, ma richiede una procedura del client di posta chiaramente documentata.

Prima della configurazione si definisce un solo trigger primario per ogni flusso di posta. Un secondo metodo non deve prevalere silenziosamente su un altro.

Creare il template SPX

L’esempio utilizza il template Finance-SPX-Recipient. Il nome è un valore di documentazione da adattare allo scopo e all’organizzazione.

Per diversi domini dei clienti si possono utilizzare template separati con testi adeguati e loghi aziendali. Non è solo una scelta grafica: le istruzioni per il destinatario devono corrispondere al modello di password e al dominio effettivamente assegnato.

1. Aprire Email > Encryption > SPX templates.
2. Selezionare Add.
3. Immettere un nome, ad esempio Finance-SPX-Recipient. SFOS non consente apostrofi, barre, virgole, barre rovesciate o virgolette nel nome.
4. Impostare il nome dell’organizzazione per le notifiche.
5. Selezionare Encryption standard e PDF page size secondo i requisiti interni.
6. In Password type, selezionare il modello di password previsto.
7. Controllare oggetto, corpo del messaggio e istruzioni per il destinatario e adattarli se necessario.
8. Per questa procedura MTA, attivare Enable SPX reply portal, come richiesto dalla guida del template. Prima del test, proteggere l’accesso al portale come descritto di seguito.
9. Attivare Include original body into reply solo se il messaggio originale può essere incluso nella risposta.
10. Salvare il template.

Scegliere consapevolmente il modello di password

Sophos Firewall offre quattro modelli:

• Specified by sender: Il mittente imposta la password. Il firewall la rimuove prima dell’invio e non la memorizza. La password deve raggiungere il destinatario tramite un canale sicuro separato.
• Generate one-time password for every email: Il firewall genera una nuova password per ogni messaggio e la invia al mittente. Quest’ultimo la comunica separatamente al destinatario. La password non viene memorizzata.
• Generated and stored for recipient: Il firewall genera una password specifica per il destinatario, la invia al mittente e la riutilizza fino alla scadenza.
• Specified by recipient: Un destinatario non ancora registrato riceve un link di registrazione, imposta la propria password e la utilizza fino alla scadenza per ulteriori messaggi SPX dell’organizzazione.

Con Specified by recipient, il primo messaggio cifrato viene inviato solo dopo la registrazione della password; la ricezione del link di registrazione non significa quindi che il PDF SPX sia stato consegnato.

Per un rapporto continuativo con un partner, Specified by recipient è spesso il processo più facile da comprendere. Una password monouso può essere più adatta per un singolo invio particolarmente sensibile. Non è opportuno mescolare senza pianificazione diversi modelli di password memorizzate per lo stesso destinatario, perché dovrebbe identificare la password corrispondente a ogni messaggio.

Con Specified by sender, la password viene inserita nell’oggetto nel formato [secure:<password>]<subject text>. Il mittente deve poi comunicare la password separatamente. Per Microsoft Outlook, Sophos fornisce un Outlook Add-in in Authentication > Client downloads.

Dopo aver verificato l’installazione, selezionare Encrypt in Outlook per il messaggio da cifrare. La sola installazione del componente aggiuntivo non attiva la crittografia.

Installare Outlook Add-in in modo controllato

Gli utenti senza accesso a WebAdmin aprono Download client nello User Portal e selezionano Download Sophos Outlook Add-in. L’archivio scaricato viene estratto in una cartella temporanea; per l’installazione interattiva si avvia setup.exe da quella cartella. Il download amministrativo in Authentication > Client downloads va distinto da questo percorso di accesso.

Verificare il nome del file MSI prima della distribuzione: La guida dello User Portal per SFOS 22 e 23 indica SophosOutlookAddInSetup.msi; la descrizione dell’installazione SPX indica invece SophosOutlookAddInSetupUTM.msi, come nell’esempio esistente riportato sotto. Non è confermato che questi nomi siano intercambiabili. Occorre verificare il nome effettivo del file MSI nel pacchetto estratto. L’esempio seguente è valido solo se il file si chiama effettivamente SophosOutlookAddInSetupUTM.msi. Se il pacchetto contiene SophosOutlookAddInSetup.msi, si utilizza esattamente questo nome presente nel pacchetto come argomento di /i; le opzioni documentate /qr /i e T=1 EC=3 C=1 I=1 rimangono invariate. Se manca il file MSI previsto o non è possibile identificare inequivocabilmente il pacchetto, interrompere la distribuzione e chiarire quale pacchetto si sta utilizzando, anziché rinominare un file o presumere il supporto delle piattaforme moderne.

Per un’installazione interattiva, eseguire setup.exe dal pacchetto scaricato dal firewall attivo. Sophos documenta questo comando per una distribuzione automatica:

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

L’elenco pubblico di compatibilità è sorprendentemente datato: La guida di SFOS documenta i seguenti prerequisiti storici per l’installazione non presidiata del componente aggiuntivo SPX per Outlook: Windows XP, Windows Vista, Windows 7 o Windows 8, ciascuno nelle versioni a 32 bit e a 64 bit; Microsoft Outlook 2007 SP3, 2010 o 2013, anch’essi ciascuno nelle versioni a 32 bit e a 64 bit; Microsoft .NET Framework 4 Client Profile e Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. Da questo elenco non si può dedurre il supporto delle attuali Microsoft 365 Apps o delle versioni moderne di Windows. Prima di una distribuzione estesa, occorre quindi verificare su un dispositivo pilota il pacchetto effettivamente scaricato, le versioni di Windows e Outlook e le rispettive architetture, un trigger SPX positivo e uno negativo, nonché la disinstallazione. I parametri MSI non spiegati non devono essere modificati per tentativi.

L’attuale documentazione Sophos utilizza due grafie diverse dell’header per altri client di posta: X-Sophos-SPXEncrypt: yes nella pagina del template e X-Sophos-SPX-Encrypt: yes nella pagina generale Encryption. Questa discrepanza non viene trattata come una ricetta da copiare e incollare. Prima di un rollout in produzione va verificata la grafia funzionante sul build SFOS utilizzato. Dove possibile, una policy, Data Control o il Sophos Outlook Add-in rappresentano un trigger più tracciabile.

Progettare la notifica senza creare un’altra fuga di dati

Le variabili disponibili per le notifiche includono:

• %ENVELOPE_TO%: destinatario della password.
• %PASSWORD%: password per aprire il PDF SPX.
• %ORGANIZATION_NAME%: nome dell’organizzazione inserito nel template.
• %SENDER%: mittente dell’email.
• %REG_LINK%: link per registrare la password.

Sono supportati formattazione HTML semplice e link. Il testo deve spiegare chi ha inviato il messaggio, come ottenere la password in modo sicuro e per quanto tempo sono possibili registrazione o risposta. Credenziali o contenuti email riservati non devono essere ripetuti in una notifica non protetta.

Reset ripristina la notifica predefinita. Salvare prima i testi personalizzati; dopo il ripristino, verificare nuovamente oggetto, corpo del messaggio e istruzioni per il destinatario.

Impostare validità e notifiche di errore

I periodi e i destinatari degli errori si impostano in Email > Encryption > SPX configuration, non in SPX portal settings:

• Keep unused password for: Validità di una password memorizzata quando non viene inviata alcuna email SPX a quel destinatario. Con tre giorni, ad esempio, la guida indica che la password scade a mezzanotte alla fine del terzo giorno. È un periodo di inattività, non una durata universale per ogni PDF.
• Allow secure reply for: Numero di giorni entro i quali il destinatario può rispondere tramite SPX Reply Portal; questa impostazione appartiene alla procedura MTA.
• Allow password registration for: Periodo dopo il quale scade il link di registrazione. È distinto dal periodo delle password memorizzate.
• Send error notification to: Destinatari responsabili delle notifiche di errore SPX. Gli errori compaiono anche nel log SMTP.

Scegliere i periodi in base alle esigenze di risposta e alle regole di sicurezza dell’organizzazione. Nel test pilota verificare separatamente registrazione, inattività della password e termine per le risposte. La scadenza sul firewall non dimostra che un PDF già consegnato sia stato eliminato o non possa più essere aperto.

Proteggere i portali SPX

La registrazione delle password e l’accesso al portale sono definiti in Email > Encryption > SPX portal settings:

1. In Hostname, inserire il FQDN con cui i destinatari esterni raggiungono effettivamente il portale.
2. In Allowed networks, impostare solo le reti di origine necessarie. Any è appropriato solo quando destinatari esterni arbitrari devono raggiungere il portale e il rischio viene accettato consapevolmente.
3. Documentare la porta. Il Password Registration Portal usa per impostazione predefinita TCP 8094.
4. Utilizzare una porta dedicata per lo SPX Reply Portal.

Se Allowed networks rimane vuoto, SFOS usa Any, perché lo SPX Reply Portal è attivo per impostazione predefinita nella zona WAN. Se il Reply Portal non è necessario, Sophos documenta l’uso di un indirizzo privato attendibile non utilizzato, ad esempio 169.254.0.1, come unica rete consentita per disattivarlo. Questo valore di documentazione non deve corrispondere a un indirizzo usato in produzione.

CAPTCHA è sempre attivo sullo SPX Portal e non può essere disattivato. Gestire consapevolmente CAPTCHA su Sophos Firewall spiega i limiti delle impostazioni CAPTCHA degli altri portali.

WebAdmin, User Portal, VPN Portal, Captive Portal e i due portali SPX utilizzano la stessa selezione centrale del certificato. Una modifica può quindi influire contemporaneamente su più servizi. Certificato, SAN, via di ripristino e URL reale del portale vanno pianificati con Gestire i certificati su Sophos Firewall. Un certificato Let’s Encrypt su Sophos Firewall può essere adatto a un nome pubblico.

La selezione si trova in Administration > Admin and user settings > Admin console and end-user interaction > Certificate. L’identità del certificato nel SAN o nel CN deve corrispondere al FQDN del portale inserito in Hostname e sul firewall deve essere presente l’intera catena CA. La sostituzione del certificato non è quindi una modifica limitata a SPX: dopo il cambio verificare anche WebAdmin e gli altri portali.

Collegare il template alla policy SMTP

Per MTA mode, il template SPX viene selezionato nella policy SMTP route and scan corrispondente in Email > Policies and exceptions.

Utilizzare un dominio come trigger

In Domains and routing target, il template viene assegnato al dominio protetto. Si applica quindi ai messaggi in uscita corrispondenti. Un’assegnazione ampia per dominio viene prima testata con un mittente pilota e un destinatario esterno di test.

Utilizzare Data Control come trigger

Una Data Control List non è una regola di contenuto scritta liberamente. È composta da Sophos Content Control List, o CCL, per modelli di dati definiti. Durante la creazione, filtrare le CCL per Type e Region. Nel test pilota vanno inclusi solo i modelli realmente necessari, affinché una selezione troppo ampia non attivi inutilmente l’invio SPX.

1. Creare una lista con un nome chiaro in Email > Data control list oppure controllare quella esistente.
2. Attivare Data protection nella policy SMTP route and scan e selezionare esattamente questa lista in Data control list.
3. Impostare Data control list action su Accept with SPX e selezionare lo SPX template previsto. Accept consegna senza SPX; Drop scarta il messaggio senza avvisare il mittente.
4. Eseguire un test positivo del contenuto e un test negativo simile.

Se è già impostato un template SPX in Domains and routing target, questo ha priorità sul template Data Control. Inoltre, una corrispondenza della Data Control List dimostra solo il match del contenuto configurato. Il flusso di posta reale deve confermare che sia stato cifrato il messaggio corretto.

Utilizzare un trigger del mittente

In Email > Encryption > SPX configuration, selezionare un Default SPX template. Si applica alla crittografia SPX attivata dal mittente solo quando la policy SMTP non fornisce già un template a livello di dominio o Data Control. None disattiva questo percorso predefinito.

Per MTA mode, la guida richiede esplicitamente una policy SMTP route and scan configurata e la selezione del template in Domains and routing target oppure Data control list. Indica example.com come dominio fittizio se non si vuole specificare un dominio protetto. È un esempio di documentazione, non un dominio di posta di produzione né un’autorizzazione generale per relay o routing. Anche in questo caso particolare devono essere corrette l’assegnazione della policy e le due prove. La descrizione generale del template predefinito non dimostra che MTA possa funzionare senza una policy SMTP. None disattiva solo il percorso predefinito, non un’assegnazione SPX in una policy.

Automatizzare SPX tramite XML API

Per le modifiche ricorrenti, rilevare prima la modalità di posta, i template esistenti e le relative assegnazioni alle policy o come predefiniti. I riferimenti XML per SFOS 22 e 23 distinguono gli oggetti Legacy da quelli MTA; nomi di campo identici non rendono intercambiabili i rispettivi payload. Le indicazioni seguenti spiegano il contratto documentato, ma non costituiscono una richiesta di scrittura eseguibile né la prova di un test di laboratorio. Autorizzazione delle origini, account di servizio con privilegi minimi, verifica TLS, operazione esplicita, backup e valutazione dello stato XML anziché HTTP sono descritti in Limitare in modo sicuro l’accesso XML API e verificare le risposte. Prima della scrittura, confermare il contratto completo dell’oggetto in API help del build installato; le contraddizioni non chiarite non devono essere aggirate con un payload ipotizzato.

Configurazione globale: distinguere Legacy e MTA

Legacy: L’esempio documentato annida SPXConfiguration due volte: un elemento esterno SPXConfiguration contiene un altro SPXConfiguration. Nell’elemento interno si trova SPXGlobalTemplate con DefaultSPXTemplate; accanto sono presenti HostName, AllowedNetworks con voci Network ripetibili, Port, KeepUnusedPassFor, AllowPassRegistrationFor e SendNotifcationErrorTo. Non eliminare il doppio livello considerandolo un presunto refuso e non utilizzare l’esempio come schema MTA generale.

MTA: L’oggetto separato si chiama MTASPXConfiguration. Il relativo esempio contiene direttamente SPXGlobalTemplate con DefaultSPXTemplate, oltre a nome host, porta, periodi di validità delle password e notifica di errore, senza il doppio annidamento Legacy. Per entrambi i contratti, la tabella dei parametri indica Network, DefaultSPXTemplate e HostName come array di stringhe opzionali; ciò non conferma la validità di una struttura di array costruita arbitrariamente. Confrontare il FQDN del portale e le origini consentite con i controlli del portale e del certificato descritti sopra. Il valore di esempio MTA None per HostName non dimostra uno stato di disattivazione sicuro.

I parametri obbligatori sono KeepUnusedPassFor (numero di giorni documentato come stringa, valore predefinito 30), AllowPassRegistrationFor (numero di giorni intero, valore predefinito 10), Port (intero, valore predefinito 8094, intervallo da 1025 a 65535) e SendNotifcationErrorTo. La grafia SendNotifcationErrorTo rimane invariata nonostante la lettera mancante. I token consentiti sono SenderOnly e Nobody; l’esempio Legacy e la visualizzazione del valore predefinito riportano invece Sender Only. Non normalizzare silenziosamente questa discrepanza e non dedurre dalla sola visualizzazione che uno dei due valori sia un valore XML testato. Se il contratto per il build utilizzato non è chiarito, interrompere il job di scrittura.

Solo la tabella MTA elenca inoltre AllowSecureReplyfor come campo obbligatorio per il periodo di risposta (numero di giorni espresso come stringa, valore predefinito 30). Proprio questo campo manca nell’esempio MTA. L’esempio non costituisce quindi una prova completa di una richiesta pronta per la produzione; non omettere il periodo di risposta senza verificarlo e non inventare una grafia con maiuscole e minuscole diverse. Template globale, inattività della password, registrazione e periodo di risposta restano decisioni separate; nessuna sostituisce l’assegnazione alla policy SMTP.

Per Update SPX Configuration nel contratto Legacy sono documentate le seguenti associazioni degli stati XML:

Il contratto MTA della stessa operazione indica invece 200 con Operation Successful. e 500 con Operation Fail.. Non presentare il codice Legacy 541 come una risposta MTA documentata in tale contratto. In caso di associazione Legacy 541, verificare prima l’effettivo utilizzo delle porte e la porta del portale memorizzata, anziché ripetere il job senza modifiche o cambiare SMTP TLS.

Template: proteggere identità, valori e notifiche

Per Legacy è documentato SPXTemplates, per MTA MTASPXTemplates. Name è l’identità univoca obbligatoria del template, con un massimo di 255 caratteri, e prima di un aggiornamento o di un’eliminazione deve essere confrontato esattamente con l’oggetto esistente. Description e OrganizationName sono stringhe opzionali; anche per OrganizationName vale il limite massimo di 255. Un nuovo testo descrittivo non giustifica la creazione alla cieca di un nuovo oggetto con lo stesso nome.

Entrambi i contratti richiedono PDFEncryption, PageSize e PasswordType. I valori di selezione esatti sono:

• PDFEncryption: AES/128 oppure AES/256.
• PageSize: A/4, Letter oppure Legal. Il valore predefinito visualizzato A4 non è il token di selezione documentato A/4.
• PasswordType: SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient oppure SpecifiedByRecipient. Il valore predefinito visualizzato Specified by sender non è una raccomandazione per un token XML.

NotificationSubject, NotificationBody e InstructionsForRecipient sono stringhe opzionali. Secondo il contratto, i due campi di notifica sono applicabili solo ai modelli con password generate o registrate dal destinatario, non a SpecifiedBySender. Solo il template MTA aggiunge SPXReplyPortal e IncludeOriginalBodyIntoReply: entrambi opzionali, con valore predefinito Disabled e valori consentiti Disabled oppure Enable. L’esempio Enable/Disabled è una notazione di scelta, non un singolo valore da inviare. Non confondere l’obbligo del Reply Portal nella procedura GUI MTA descritta sopra con il campo API opzionale e il relativo valore predefinito.

I testi delle notifiche vengono localizzati, mentre i segnaposto tecnici rimangono invariati. Gli esempi API mostrano inoltre %CURRENT_RECIPIENT% e, nell’oggetto, %%ENVELOPE_TO%% oppure %%ORGANIZATION_NAME%%; non convertirli automaticamente nelle variabili delimitate da singoli segni di percentuale elencate sopra. Prima di una modifica, salvare il template effettivamente memorizzato e verificare la risoluzione delle variabili con un nuovo messaggio di test. L’HTML standard, le indicazioni storiche sui lettori PDF e le password di esempio presenti nel riferimento non costituiscono un modello obbligatorio per le proprie notifiche. HTML, virgolette e interruzioni di riga devono essere serializzati in modo controllato e verificati dopo il salvataggio. Anche |n, visibile nell’esempio MTA, non deve essere adottato come metodo di escape universale senza una conferma specifica per il build.

Per i template Legacy e MTA, le associazioni documentate coincidono:

Gli identificatori Message.* restano chiavi di messaggio non risolte del riferimento, non testi verificati in fase di esecuzione. In caso di 502, verificare l’identità esatta e il contenuto esistente, senza passare automaticamente da Add a Update. In caso di Update-541, esaminare le effettive assegnazioni Spam/Data Control e SPX, senza dedurre dal simbolo un meccanismo universale di conflitto. In caso di Delete-504, chiarire prima i riferimenti nelle policy e nella configurazione globale; l’ordine di rollback descritto sotto resta vincolante. Prima di ogni nuovo tentativo, confrontare la risposta con lo stato effettivamente memorizzato e controllare l’oggetto di destinazione anche dopo 200. Solo nuovi messaggi di test positivo e negativo, insieme ai test della password e della risposta, consentono di convalidare l’effetto operativo.

Verificare il flusso di posta cifrato

Annotare ora del test, mittente, destinatario, oggetto e trigger atteso. Poi testare almeno questi casi:

1. Test positivo: Un messaggio in uscita attiva esattamente il template SPX previsto.
2. Test della password: Il destinatario riceve la password o il link di registrazione tramite il canale previsto e può aprire il PDF.
3. Test del contenuto: Oggetto, corpo e allegati compaiono nel PDF come previsto e sono leggibili.
4. Test della risposta: Se attivato, il link di risposta conduce al FQDN previsto e una risposta di test raggiunge il mittente originale.
5. Test negativo: Un messaggio simile senza trigger non viene inviato come PDF SPX.
6. Test della scadenza: Registrazione, password memorizzata e periodo di risposta si comportano in modo prevedibile dopo la validità definita.
7. Test del certificato: Browser e destinatario esterno ricevono una catena di certificati completa e attendibile per il FQDN del portale utilizzato.

Iniziare la correlazione in Email > Mail logs. In Reason, SPX encryption identifica i messaggi cifrati con SPX e SPX failure i messaggi SPX non consegnati; in Result filtrare ulteriormente, ad esempio per Delivered, Dropped o Quarantined. Confrontare mittente, destinatario, oggetto e intervallo temporale con la nota di test. Per gli errori dettagliati proseguire con Log Viewer e i file MTA smtpd_main.log, smtpd_error.log e smtpd_panic.log. Servizi e log di Sophos Firewall spiega l’accesso e gli altri file di log.

SPX failure non è un altro nome per la quarantena SMTP. Un messaggio compare in Email > SMTP quarantine solo quando un’azione Spam, Malware, Unscannable, DKIM o un’altra azione di policy lo mette effettivamente in quarantena. Durante il test non rilasciare semplicemente il messaggio prima di aver documentato motivo e policy che l’ha attivata, altrimenti si rischia di confondere un errore di scansione o policy con un errore SPX.

In HA, i log risiedono sul nodo che ha elaborato il traffico. Dopo un failover controllato, testare separatamente una nuova email SPX, la registrazione della password e la risposta. Non si presume che una sessione del portale esistente o una registrazione in corso continuino senza interruzioni. I concetti di base sono descritti in Cluster HA Sophos Firewall.

Circoscrivere gli errori in modo sistematico

Il messaggio non viene cifrato

Controllare direzione, dominio protetto, policy SMTP route and scan effettiva e priorità dei trigger. Per Data Control verificare anche Data protection, la Data control list selezionata, Data control list action: Accept with SPX e il relativo SPX template. Per un trigger del mittente deve essere impostato un template predefinito e non deve essere sovrascritto da un template di dominio o Data Control. Le due grafie documentate dell’header non sono un motivo per distribuire entrambe senza test in produzione.

Mail logs mostra SPX failure

In Email > Mail logs, circoscrivere la riga interessata tramite ora, mittente, destinatario e oggetto, quindi confermare Reason: SPX failure. Correlare l’errore visualizzato con smtpd_main.log, smtpd_error.log e, per errori gravi di processo, smtpd_panic.log allo stesso orario. Solo dopo modificare modello di password, template, consegna o percorso del portale. Se Result è invece Quarantined, esaminare in Email > SMTP quarantine la scansione o l’azione di policy che l’ha attivata.

Il link di registrazione o il portale non è raggiungibile

Controllare FQDN, risoluzione DNS pubblica, porta, certificato, Allowed networks e validità del link. Un valore Allowed Networks vuoto viene trattato come Any e quindi non è uno stato di disattivazione sicuro. Se il client raggiunge un altro host o portale, URL, NAT o assegnazione del certificato non corrispondono al percorso pianificato.

Il PDF non si apre

Per prima cosa confrontare il tipo di password con il messaggio specifico. Una password monouso vale solo per quella email. Con password memorizzate o registrate, la causa può essere la scadenza o l’uso di più modelli. Dopo uno SPX Password Reset, il mittente deve comunicare nuovamente la nuova password al destinatario in modo sicuro.

Per un reset mirato, inserire in Email > Encryption > SPX password reset l’indirizzo email del destinatario interessato e verificarlo prima di avviare l’operazione. Coordinare con mittente e destinatario il reset e la consegna sicura della nuova password, quindi aprire una nuova email SPX di test. Questo non garantisce che i PDF precedenti possano essere aperti con la nuova password.

La risposta sicura non arriva

Controllare Enable SPX reply portal nel template, periodo di risposta, FQDN del portale, porta, certificato e origini consentite. Poi esaminare Mail logs e i log MTA per la risposta specifica. L’apertura corretta del PDF non dimostra che il canale di ritorno funzioni.

La verifica DKIM fallisce dopo SPX

SPX modifica corpo e allegati. Se un messaggio viene firmato prima di questa modifica, la firma può risultare non valida al destinatario. Definire se il server di posta interno, Sophos Firewall o un gateway successivo firma dopo tutte le modifiche previste. La catena di elaborazione e un test esterno devono essere verificati insieme.

Eseguire un rollback sicuro

1. Rimuovere per prima cosa l’assegnazione SPX specifica da Domains and routing target. Per un trigger Data Control, ripristinare Data control list action nella policy SMTP da Accept with SPX all’azione precedente documentata.
2. Se utilizzato, impostare Default SPX template su None.
3. Eseguire un test negativo in uscita e confermare che non venga generato alcun nuovo PDF SPX.
4. Ritirare Reply e Registration Portal solo se nessun’altra policy SPX attiva ne dipende.
5. Ripristinare gli accessi pubblici temporanei di porta, DNS o portale allo stato precedente documentato. Ripristinare requisiti SMTP TLS modificati separatamente solo rispetto al relativo stato precedente registrato.
6. Eliminare il template solo quando nessuna policy o procedura operativa attiva vi fa più riferimento.
7. Conservare Mail logs e i log MTA dell’ultimo test cifrato e del primo non cifrato.

Creare un backup aggiornato di Sophos Firewall prima di modificare percorsi di posta e portali di produzione. SPX può continuare a funzionare in ambienti air gap, ma le dipendenze esterne DNS, certificati e portale devono restare raggiungibili separatamente. I limiti del prodotto sono descritti in Funzioni SFOS senza accesso a Internet.

Checklist operativa

• Licenza, modello, flusso di posta MTA e destinatario esterno sono stati verificati.
• Il trigger e la sua priorità sono documentati.
• Tipo di password e canale di consegna sicuro sono adatti al caso d’uso.
• FQDN del portale, certificato centrale dei portali, porta e Allowed Networks hanno un ambito ristretto; SMTP TLS è documentato separatamente.
• L’assegnazione per dominio, Data Control o predefinita è inequivocabile.
• I test positivo, negativo, password, PDF e risposta sono riusciti.
• I filtri SPX encryption e SPX failure di Mail logs e i log MTA possono essere correlati con il messaggio di test; le azioni di quarantena sono distinte.
• Il failover HA e i log locali dei nodi sono inclusi nella procedura operativa.
• Responsabile, scadenze, data di revisione e rollback sono documentati.

FAQ