Configurer le chiffrement des e-mails SPX sur Sophos Firewall

Avec Secure PDF Exchange, ou SPX, Sophos Firewall convertit un e-mail sortant et ses pièces jointes en fichier PDF protégé par mot de passe. Le destinataire n’a pas besoin de son propre client de chiffrement. Selon le modèle choisi, il reçoit un mot de passe à usage unique, utilise un mot de passe enregistré ou en définit un lui-même.

Quatre éléments doivent fonctionner ensemble : un modèle SPX, un déclencheur sans ambiguïté, un canal sécurisé pour le mot de passe et, si nécessaire, le SPX Reply Portal. Un flux positif et un flux négatif sont ensuite testés. La seule réception d’un PDF ne prouve ni que la bonne stratégie s’est déclenchée, ni que l’enregistrement du mot de passe et la réponse sécurisée fonctionnent.

SPX en huit étapes

1. Vérifier la licence Email Protection, le flux de messagerie MTA, la compatibilité du modèle, le certificat du portail et le chemin SMTP TLS distinct.
2. Décider si le chiffrement est déclenché par un domaine protégé, une correspondance Data Control ou l’expéditeur.
3. Créer un modèle personnalisé sous Email > Encryption > SPX templates > Add.
4. Choisir consciemment le type de mot de passe, le chiffrement PDF, la notification et le Reply Portal.
5. Sécuriser le FQDN, les réseaux autorisés et le port sous Email > Encryption > SPX portal settings.
6. En MTA mode, configurer la stratégie SMTP route and scan et affecter le modèle ; un Default SPX template ne remplace pas cette stratégie.
7. Tester le PDF, le canal du mot de passe, l’enregistrement et la réponse avec un destinataire externe.
8. Effectuer un test négatif sans déclencheur SPX et documenter Mail logs, les journaux MTA et le retour arrière.

⚠️ Un champ Allowed networks vide pour le SPX Portal ne signifie pas « aucun accès » : il revient à Any. Sophos recommande également un port dédié pour le Reply Portal. Le FQDN du portail, le certificat, les sources autorisées et le canal du mot de passe doivent donc être définis avant le test en production.

Quand SPX convient

SPX convient lorsque des destinataires externes doivent recevoir des contenus confidentiels sous forme de PDF protégé sans installer de client de chiffrement. Il est disponible en MTA mode comme en Legacy mode. Cette procédure utilise MTA mode, car le domaine, Data Control et le routage peuvent ainsi être reliés de façon compréhensible dans la stratégie SMTP. Configurer Mail Protection en Legacy mode explique l’alternative transparente.

SPX n’est ni un chiffrement de transport entre serveurs de messagerie ni un chiffrement de bout en bout entre deux clients de messagerie. Le pare-feu traite le texte en clair, génère le PDF et gère le mot de passe ou l’enregistrement. Le PDF peut ensuite subsister hors du pare-feu dans des boîtes aux lettres, des archives ou des téléchargements. Le périmètre des destinataires, la conservation et la transmission du mot de passe font donc partie de la conception de sécurité.

Le chiffrement du transport SMTP se règle séparément sous Email > General settings > SMTP TLS configuration. Require TLS negotiation impose TLS aux hôtes distants ou réseaux sélectionnés ; si SFOS ne peut pas établir la connexion TLS, il supprime l’e-mail destiné à cette cible. À l’inverse, Skip TLS negotiation force une connexion SMTP non chiffrée. Le TLS certificate sélectionné à cet endroit protège le chemin SMTP et n’est pas le certificat des portails SPX. Il faut donc planifier SPX et SMTP TLS séparément, puis les valider ensemble dans le flux externe.

Les prérequis sont les suivants :

• une licence Email Protection valide ;
• un flux de messagerie sortant déjà testé via Sophos Firewall ;
• un destinataire externe de test documenté ;
• un FQDN de confiance et un certificat correspondant pour les portails SPX utilisés ;
• un canal sécurisé distinct pour les mots de passe lorsqu’ils ne sont pas enregistrés par le destinataire ;
• une voie de récupération permettant de retirer les affectations de modèle et de stratégie.

Selon l’aide Sophos actuelle, SPX n’est pas disponible sur XGS 87/87w. Le MTA mode complet n’est en outre pas disponible sur XGS 88/88w. Configurer Mail Protection en MTA mode explique le flux de messagerie, la licence, le relais et les limites de modèle.

Définir le déclencheur et la priorité

SPX peut être déclenché de trois façons. Lorsque plusieurs méthodes sont configurées, Sophos Firewall applique cet ordre en MTA mode :

1. Domaine protégé : Le modèle SPX sélectionné sous Domains and routing target s’applique aux messages sortants du domaine protégé correspondant.
2. Data control list : Seulement si aucun modèle SPX n’est défini au niveau du domaine, une correspondance Data Control peut appliquer le modèle sélectionné pour la liste.
3. Déclencheur de l’expéditeur : Seulement lorsque ni le domaine ni Data Control ne fournissent de modèle, la méthode de l’expéditeur configurée sous Default SPX template s’applique.

Une affectation au niveau du domaine est large et ne convient que si tous les messages sortants correspondants doivent réellement être chiffrés. Data Control est adapté à des types de contenu définis, mais doit être testé avec de vrais exemples positifs et négatifs afin de détecter les faux positifs. Le déclencheur de l’expéditeur lui laisse la décision, mais exige une procédure de client de messagerie clairement documentée.

Avant la configuration, un seul déclencheur principal est défini pour chaque flux. Une deuxième méthode ne doit pas en supplanter une autre sans que cela soit remarqué.

Créer le modèle SPX

L’exemple utilise le modèle Finance-SPX-Recipient. Ce nom est une valeur de documentation à adapter au but et à l’organisation.

Des modèles distincts avec des textes adaptés et des logos d’entreprise peuvent être utilisés pour différents domaines clients. Ce n’est pas seulement une question de présentation : les instructions destinées au destinataire doivent correspondre au modèle de mot de passe et au domaine réellement affecté.

1. Ouvrir Email > Encryption > SPX templates.
2. Sélectionner Add.
3. Saisir un nom tel que Finance-SPX-Recipient. SFOS n’autorise pas les apostrophes, barres obliques, virgules, barres obliques inverses ni guillemets dans ce nom.
4. Définir le nom de l’organisation pour les notifications.
5. Choisir Encryption standard et PDF page size selon les exigences internes.
6. Sous Password type, sélectionner le modèle de mot de passe prévu.
7. Vérifier l’objet, le corps du message et les instructions destinées au destinataire, puis les adapter si nécessaire.
8. Pour cette procédure MTA, activer Enable SPX reply portal, comme l’exige l’aide du modèle. Sécuriser l’accès au portail comme décrit ci-dessous avant le test.
9. Activer Include original body into reply uniquement si le message original peut figurer dans la réponse.
10. Enregistrer le modèle.

Choisir consciemment le modèle de mot de passe

Sophos Firewall propose quatre modèles :

• Specified by sender : L’expéditeur définit le mot de passe. Le pare-feu le retire avant l’envoi et ne le conserve pas. Le mot de passe doit parvenir au destinataire par un canal sécurisé distinct.
• Generate one-time password for every email : Le pare-feu génère un nouveau mot de passe pour chaque message et l’envoie à l’expéditeur. Celui-ci le transmet séparément au destinataire. Le mot de passe n’est pas conservé.
• Generated and stored for recipient : Le pare-feu génère un mot de passe propre au destinataire, l’envoie à l’expéditeur et le réutilise jusqu’à son expiration.
• Specified by recipient : Un destinataire qui n’est pas encore enregistré reçoit un lien d’enregistrement, définit son mot de passe et l’utilise jusqu’à son expiration pour les futurs messages SPX de l’organisation.

Avec Specified by recipient, le premier message chiffré n’est envoyé qu’après l’enregistrement du mot de passe ; la réception du lien d’enregistrement ne signifie donc pas que le PDF SPX a été distribué.

Pour une relation régulière avec un partenaire, Specified by recipient est souvent la procédure la plus simple à comprendre. Un mot de passe à usage unique peut mieux convenir à un envoi ponctuel particulièrement sensible. Il faut éviter de mélanger sans planification plusieurs modèles de mots de passe enregistrés pour un même destinataire, car celui-ci devrait alors identifier le mot de passe correspondant à chaque message.

Avec Specified by sender, le mot de passe est saisi dans l’objet selon le modèle [secure:<password>]<subject text>. L’expéditeur doit ensuite transmettre le mot de passe séparément. Pour Microsoft Outlook, Sophos fournit un Outlook Add-in sous Authentication > Client downloads.

Après avoir vérifié l’installation, sélectionner Encrypt dans Outlook pour le message à chiffrer. La seule installation du complément ne déclenche pas le chiffrement.

Installer l’Outlook Add-in de manière contrôlée

Les utilisateurs sans accès à WebAdmin ouvrent Download client dans le User Portal, puis sélectionnent Download Sophos Outlook Add-in. Extraire l’archive téléchargée dans un dossier temporaire ; pour une installation interactive, y exécuter setup.exe. Le téléchargement administratif sous Authentication > Client downloads constitue un autre mode d’accès et doit être distingué de ce parcours.

Vérifier le nom du fichier MSI avant le déploiement : l’aide du User Portal pour SFOS 22 et 23 indique SophosOutlookAddInSetup.msi ; la procédure d’installation SPX indique en revanche SophosOutlookAddInSetupUTM.msi, comme dans l’exemple existant ci-dessous. Il n’est pas confirmé que ces noms soient interchangeables. Vérifier le nom réel du fichier MSI dans le paquet extrait. L’exemple suivant s’applique uniquement si le fichier s’appelle réellement SophosOutlookAddInSetupUTM.msi. Pour un paquet contenant SophosOutlookAddInSetup.msi, utiliser exactement ce nom de fichier existant comme argument de /i ; les options documentées /qr /i et T=1 EC=3 C=1 I=1 restent inchangées. Si le MSI attendu est absent ou si le paquet ne peut pas être identifié sans ambiguïté, arrêter le déploiement et clarifier le paquet concerné, plutôt que de renommer un fichier ou de supposer la prise en charge d’une plateforme moderne.

Pour une installation interactive, exécuter setup.exe depuis le paquet téléchargé sur le firewall actif. Sophos documente cette commande pour un déploiement sans assistance :

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

La liste publique de compatibilité est particulièrement ancienne : L’aide SFOS documente les prérequis historiques suivants pour l’installation sans assistance du SPX Outlook Add-in : Windows XP, Windows Vista, Windows 7 ou Windows 8, chacun en versions 32 bits et 64 bits ; Microsoft Outlook 2007 SP3, 2010 ou 2013, également chacun en versions 32 bits et 64 bits ; Microsoft .NET Framework 4 Client Profile ainsi que Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. Ces indications ne permettent pas de conclure à la prise en charge des applications Microsoft 365 actuelles ni des versions modernes de Windows. Avant un déploiement étendu, il convient donc de vérifier sur un appareil pilote le paquet réellement téléchargé, les versions de Windows et d’Outlook ainsi que leur architecture respective, un déclencheur SPX positif et un déclencheur SPX négatif, ainsi que la désinstallation. Les paramètres MSI non expliqués ne doivent pas être modifiés au hasard.

L’aide Sophos actuelle utilise deux orthographes différentes de l’en-tête pour les autres clients de messagerie : X-Sophos-SPXEncrypt: yes sur la page du modèle et X-Sophos-SPX-Encrypt: yes sur la page générale Encryption. Cette divergence n’est pas traitée comme une recette à copier-coller. Avant un déploiement en production, il faut vérifier l’orthographe qui fonctionne sur le build SFOS utilisé. Lorsque c’est possible, une stratégie, Data Control ou le Sophos Outlook Add-in constitue un déclencheur plus facile à tracer.

Concevoir la notification sans créer une nouvelle fuite de données

Les variables de notification disponibles comprennent notamment :

• %ENVELOPE_TO%: destinataire du mot de passe.
• %PASSWORD%: mot de passe pour ouvrir le PDF SPX.
• %ORGANIZATION_NAME%: nom de l’organisation saisi dans le modèle.
• %SENDER%: expéditeur de l’e-mail.
• %REG_LINK%: lien d’enregistrement du mot de passe.

Une mise en forme HTML simple et des liens sont autorisés. Le texte doit expliquer qui a envoyé le message, comment obtenir le mot de passe de façon sécurisée et pendant combien de temps l’enregistrement ou la réponse restent possibles. Les identifiants ou le contenu confidentiel du message ne doivent pas être recopiés dans une notification non protégée.

Reset rétablit la notification par défaut. Sauvegarder les textes personnalisés au préalable ; après la réinitialisation, vérifier à nouveau l’objet, le corps du message et les instructions destinées au destinataire.

Définir les durées de validité et les notifications d’erreur

Les durées et les destinataires des erreurs se définissent sous Email > Encryption > SPX configuration, et non sous SPX portal settings :

• Keep unused password for: Durée de validité d’un mot de passe conservé lorsqu’aucun message SPX n’est envoyé à ce destinataire. Avec trois jours, par exemple, l’aide indique une expiration à minuit à la fin du troisième jour. Il s’agit d’une durée d’inactivité, pas d’une durée de vie universelle pour chaque PDF.
• Allow secure reply for: Nombre de jours pendant lesquels le destinataire peut répondre via le SPX Reply Portal ; ce réglage appartient à la procédure MTA.
• Allow password registration for: Durée après laquelle le lien d’enregistrement expire. Elle est distincte de la durée des mots de passe conservés.
• Send error notification to: Destinataires responsables des notifications d’erreur SPX. Les erreurs figurent également dans le journal SMTP.

Choisir les durées selon les besoins de réponse et les règles de sécurité de l’organisation. Dans le pilote, tester séparément l’enregistrement, l’inactivité du mot de passe et le délai de réponse. Une expiration sur le pare-feu ne prouve pas qu’un PDF déjà distribué a été supprimé ou ne peut plus être ouvert.

Sécuriser les portails SPX

L’enregistrement des mots de passe et l’accès au portail sont définis sous Email > Encryption > SPX portal settings :

1. Sous Hostname, saisir le FQDN réellement utilisé par les destinataires externes pour atteindre le portail.
2. Sous Allowed networks, définir uniquement les réseaux sources requis. Any ne convient que si des destinataires externes quelconques doivent accéder au portail et si le risque est accepté consciemment.
3. Documenter le port. Le Password Registration Portal utilise par défaut le port TCP 8094.
4. Utiliser un port dédié pour le SPX Reply Portal.

Si Allowed networks reste vide, SFOS utilise Any, car le SPX Reply Portal est activé par défaut dans la zone WAN. Si le Reply Portal n’est pas nécessaire, Sophos indique d’utiliser une adresse privée de confiance inutilisée, par exemple 169.254.0.1, comme seul réseau autorisé afin de le désactiver. Cette valeur de documentation ne doit correspondre à aucune adresse utilisée en production.

Le CAPTCHA est toujours actif sur le SPX Portal et ne peut pas être désactivé. Gérer le CAPTCHA de Sophos Firewall de manière réfléchie explique les limites des réglages CAPTCHA des autres portails.

WebAdmin, User Portal, VPN Portal, Captive Portal et les deux portails SPX utilisent la même sélection centrale de certificat. Une modification peut donc affecter plusieurs services à la fois. Le certificat, les SAN, la voie de récupération et l’URL réelle du portail doivent être planifiés avec Gérer les certificats sur Sophos Firewall. Un certificat Let’s Encrypt sur Sophos Firewall peut convenir à un nom public.

La sélection se trouve sous Administration > Admin and user settings > Admin console and end-user interaction > Certificate. L’identité du certificat dans le SAN ou le CN doit correspondre au FQDN du portail saisi sous Hostname, et la chaîne de CA complète doit être présente sur le firewall. Un remplacement de certificat n’est donc pas une modification limitée à SPX : WebAdmin et les autres portails doivent aussi être vérifiés après l’opération.

Relier le modèle à la stratégie SMTP

En MTA mode, le modèle SPX est sélectionné dans la stratégie SMTP route and scan correspondante sous Email > Policies and exceptions.

Utiliser un domaine comme déclencheur

Sous Domains and routing target, le modèle est affecté au domaine protégé. Il s’applique ensuite aux messages sortants correspondants. Une affectation large au niveau du domaine est d’abord testée avec un expéditeur pilote et un destinataire externe de test.

Utiliser Data Control comme déclencheur

Une Data Control List n’est pas une règle de contenu rédigée librement. Elle est constituée de Sophos Content Control Lists, ou CCL, pour des modèles de données définis. Lors de sa création, filtrer les CCL par Type et Region. Le pilote ne contient que les modèles réellement nécessaires, afin qu’une sélection trop large ne déclenche pas inutilement l’envoi SPX.

1. Créer une liste clairement nommée sous Email > Data control list ou vérifier la liste existante.
2. Activer Data protection dans la stratégie SMTP route and scan et sélectionner précisément cette liste sous Data control list.
3. Définir Data control list action sur Accept with SPX, puis sélectionner le SPX template prévu. Accept distribue sans SPX ; Drop supprime le message sans avertir l’expéditeur.
4. Effectuer un test de contenu positif et un test négatif similaire.

Si un modèle SPX est déjà défini sous Domains and routing target, il est prioritaire sur le modèle Data Control. Une correspondance de la Data Control List prouve uniquement que le contenu a correspondu au critère configuré. Le flux de messagerie réel doit confirmer que le bon message a été chiffré.

Utiliser un déclencheur de l’expéditeur

Sous Email > Encryption > SPX configuration, sélectionner un Default SPX template. Il s’applique au chiffrement SPX déclenché par l’expéditeur uniquement si la stratégie SMTP ne fournit pas déjà un modèle au niveau du domaine ou de Data Control. None désactive cette voie par défaut.

Pour MTA mode, l’aide exige explicitement une stratégie SMTP route and scan configurée et la sélection du modèle sous Domains and routing target ou Data control list. Elle cite example.com comme domaine fictif si aucun domaine protégé ne doit être indiqué. C’est un exemple de documentation, pas un domaine de messagerie de production ni une autorisation générale de relais ou de routage. L’affectation de la stratégie et les deux cas de test doivent également être corrects dans ce cas particulier. La description générale du modèle par défaut ne démontre pas que MTA peut fonctionner sans stratégie SMTP. None désactive uniquement la voie par défaut, pas une affectation SPX dans une stratégie.

Automatiser SPX via l’API XML

Pour les modifications récurrentes, commencer par inventorier le mode de messagerie, les modèles existants et leurs affectations aux stratégies ou comme modèles par défaut. Les références XML pour SFOS 22 et 23 distinguent les objets Legacy et MTA ; des noms de champs identiques ne rendent pas leurs charges utiles interchangeables. Les indications suivantes expliquent le contrat documenté, mais ne constituent ni une requête d’écriture exécutable ni la preuve d’un test en laboratoire. L’autorisation des sources, le compte de service aux privilèges minimaux, la vérification TLS, l’opération explicite, la sauvegarde et l’analyse du statut XML plutôt que HTTP sont décrits dans Limiter de manière sûre l’accès à l’API XML et vérifier les réponses. Avant toute écriture, confirmer le contrat complet de l’objet dans API help du build installé ; les contradictions non résolues ne doivent pas être contournées par une charge utile supposée.

Configuration globale : distinguer Legacy et MTA

Legacy : L’exemple documenté imbrique SPXConfiguration sur deux niveaux : un élément externe SPXConfiguration contenant à nouveau SPXConfiguration. L’élément interne contient SPXGlobalTemplate avec DefaultSPXTemplate ; à côté figurent HostName, AllowedNetworks avec des entrées Network répétables, Port, KeepUnusedPassFor, AllowPassRegistrationFor et SendNotifcationErrorTo. Ne pas supprimer ce double niveau en le prenant pour une faute de frappe, ni utiliser cet exemple comme schéma MTA général.

MTA : L’objet distinct s’appelle MTASPXConfiguration. Son exemple contient directement SPXGlobalTemplate avec DefaultSPXTemplate, ainsi que le nom d’hôte, le port, les délais des mots de passe et la notification d’erreur, sans la double imbrication Legacy. Pour les deux contrats, le tableau des paramètres indique Network, DefaultSPXTemplate et HostName comme tableaux facultatifs de chaînes ; cela ne valide pas une structure de tableau construite arbitrairement. Le FQDN du portail et les sources autorisées sont vérifiés au regard des contrôles du portail et du certificat décrits ci-dessus. La valeur d’exemple MTA None pour HostName ne démontre pas un état de désactivation sûr.

Les paramètres obligatoires sont KeepUnusedPassFor (nombre de jours documenté comme chaîne, valeur par défaut 30), AllowPassRegistrationFor (nombre entier de jours, valeur par défaut 10), Port (entier, valeur par défaut 8094, plage de 1025 à 65535) et SendNotifcationErrorTo. L’orthographe SendNotifcationErrorTo reste inchangée malgré la lettre manquante. Les jetons autorisés sont SenderOnly et Nobody ; l’exemple Legacy et l’affichage de la valeur par défaut indiquent en revanche Sender Only. Ne pas normaliser silencieusement cette divergence, ni déduire du seul affichage que l’une de ces deux valeurs est une valeur XML testée. Si le contrat reste incertain pour le build utilisé, arrêter la tâche d’écriture.

Seul le tableau MTA indique en plus AllowSecureReplyfor comme champ obligatoire pour le délai de réponse (nombre de jours sous forme de chaîne, valeur par défaut 30). Ce champ précis est absent de l’exemple MTA. L’exemple ne constitue donc pas une preuve complète d’une requête prête pour la production ; ne pas omettre le délai de réponse sans vérification ni inventer une orthographe avec une casse différente. Le modèle global, l’inactivité du mot de passe, l’enregistrement et le délai de réponse restent des décisions distinctes ; aucune ne remplace l’affectation dans la stratégie SMTP.

Pour Update SPX Configuration dans le contrat Legacy, les correspondances de statut XML suivantes sont documentées :

Le contrat MTA de la même opération indique en revanche 200 avec Operation Successful. et 500 avec Operation Fail.. Ne pas présenter le code Legacy 541 comme une réponse MTA documentée dans ce contrat. Pour la correspondance Legacy 541, vérifier d’abord l’occupation réelle des ports et le port du portail enregistré, plutôt que de relancer la tâche sans modification ou de modifier SMTP TLS.

Modèles : protéger l’identité, les valeurs et les notifications

L’objet documenté est SPXTemplates pour Legacy et MTASPXTemplates pour MTA. Name est l’identifiant unique obligatoire du modèle, limité à 255 caractères ; avant une mise à jour ou une suppression, il est comparé exactement à celui de l’objet existant. Description et OrganizationName sont des chaînes facultatives ; OrganizationName est également limité à 255 caractères. Un nouveau texte descriptif ne justifie pas de recréer aveuglément un objet portant le même nom.

Les deux contrats exigent PDFEncryption, PageSize et PasswordType. Les valeurs de sélection exactes sont les suivantes :

• PDFEncryption : AES/128 ou AES/256.
• PageSize : A/4, Letter ou Legal. La valeur par défaut affichée A4 n’est pas le jeton de sélection documenté A/4.
• PasswordType : SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient ou SpecifiedByRecipient. La valeur par défaut affichée Specified by sender ne constitue pas une recommandation de jeton XML.

NotificationSubject, NotificationBody et InstructionsForRecipient sont des chaînes facultatives. Selon le contrat, les deux champs de notification ne s’appliquent qu’aux modèles de mots de passe générés ou enregistrés par le destinataire, et non à SpecifiedBySender. Seul le modèle MTA ajoute SPXReplyPortal et IncludeOriginalBodyIntoReply : chacun est facultatif, avec la valeur par défaut Disabled et les valeurs autorisées Disabled ou Enable. L’exemple Enable/Disabled est une notation de choix, pas une valeur unique à envoyer. Ne pas confondre l’obligation d’utiliser le Reply Portal dans la procédure MTA via l’interface graphique décrite ci-dessus avec le champ API facultatif et sa valeur par défaut.

Les textes de notification sont localisés, tandis que les espaces réservés techniques restent inchangés. Les exemples API montrent également %CURRENT_RECIPIENT% ainsi que, dans l’objet, %%ENVELOPE_TO%% ou %%ORGANIZATION_NAME%% ; ne pas les convertir automatiquement en variables encadrées de simples signes de pourcentage comme celles indiquées ci-dessus. Avant toute modification, sauvegarder le modèle réellement enregistré et vérifier la résolution des variables avec un nouveau message de test. Le HTML standard, les anciennes recommandations concernant les lecteurs PDF et les exemples de mots de passe de la référence ne constituent pas un modèle obligatoire pour les notifications personnalisées. Le HTML, les guillemets et les sauts de ligne doivent être sérialisés de manière contrôlée et vérifiés après l’enregistrement. Ne pas non plus adopter le |n visible dans l’exemple MTA comme mécanisme universel d’échappement sans confirmation propre au build.

Les correspondances documentées sont identiques pour les modèles Legacy et MTA :

Les identifiants Message.* restent des clés de message non résolues de la référence, et non des textes attestés à l’exécution. En cas de 502, vérifier l’identité exacte et le contenu existant, sans passer automatiquement de Add à Update. En cas de 541 lors d’un Update, examiner les affectations réelles Spam/Data Control et SPX, sans déduire du symbole un mécanisme universel de conflit. En cas de 504 lors d’un Delete, clarifier d’abord les références dans les stratégies et la configuration globale ; l’ordre de retour arrière décrit ci-dessous reste impératif. Avant chaque nouvelle tentative, comparer la réponse à l’état réellement enregistré ; contrôler également l’objet cible après 200. Seuls de nouveaux e-mails de test positif et négatif, accompagnés de tests du mot de passe et de la réponse, permettent de valider l’effet opérationnel.

Valider le flux de messagerie chiffré

Noter l’heure du test, l’expéditeur, le destinataire, l’objet et le déclencheur attendu. Tester ensuite au minimum les cas suivants :

1. Test positif : Un message sortant déclenche exactement le modèle SPX prévu.
2. Test du mot de passe : Le destinataire reçoit le mot de passe ou le lien d’enregistrement par le canal prévu et peut ouvrir le PDF.
3. Test du contenu : L’objet, le corps et les pièces jointes figurent dans le PDF comme prévu et sont lisibles.
4. Test de réponse : Si cette fonction est activée, le lien de réponse mène au FQDN attendu et une réponse de test parvient à l’expéditeur initial.
5. Test négatif : Un message similaire sans déclencheur n’est pas envoyé sous forme de PDF SPX.
6. Test d’expiration : L’enregistrement, le mot de passe conservé et la période de réponse se comportent de façon prévisible après la durée définie.
7. Test du certificat : Le navigateur et le destinataire externe reçoivent une chaîne de certificats complète et de confiance pour le FQDN du portail utilisé.

Commencer la corrélation sous Email > Mail logs. Dans Reason, SPX encryption identifie les messages chiffrés par SPX et SPX failure les messages SPX non distribués ; dans Result, filtrer ensuite par exemple sur Delivered, Dropped ou Quarantined. Faire correspondre l’expéditeur, le destinataire, l’objet et la plage horaire à la note de test. Pour les erreurs détaillées, poursuivre dans Log Viewer et les fichiers MTA smtpd_main.log, smtpd_error.log et smtpd_panic.log. Services et journaux de Sophos Firewall explique l’accès et les autres fichiers journaux.

SPX failure n’est pas un autre nom pour la quarantaine SMTP. Un message n’apparaît sous Email > SMTP quarantine que lorsqu’une action Spam, Malware, Unscannable, DKIM ou une autre action de stratégie l’a réellement mis en quarantaine. Pendant le test, ne pas le libérer avant d’avoir consigné le motif et la stratégie déclenchée, sous peine de confondre une erreur d’analyse ou de stratégie avec une erreur SPX.

En HA, les journaux résident sur le nœud qui a traité le trafic. Après un basculement contrôlé, tester séparément un nouvel e-mail SPX, l’enregistrement du mot de passe et la réponse. Ne pas supposer qu’une session de portail existante ou un enregistrement en cours se poursuit sans interruption. Les principes HA sont décrits dans Clusters HA Sophos Firewall.

Isoler les erreurs de manière systématique

Le message n’est pas chiffré

Vérifier la direction, le domaine protégé, la stratégie SMTP route and scan réellement appliquée et la priorité des déclencheurs. Pour Data Control, vérifier aussi Data protection, la Data control list sélectionnée, Data control list action: Accept with SPX et le SPX template associé. Pour un déclencheur d’expéditeur, un modèle par défaut doit être défini et ne doit pas être supplanté par un modèle de domaine ou Data Control. Les deux orthographes documentées de l’en-tête ne justifient pas de les déployer toutes les deux sans test en production.

Mail logs affiche SPX failure

Sous Email > Mail logs, isoler la ligne concernée par l’heure, l’expéditeur, le destinataire et l’objet, puis confirmer Reason: SPX failure. Corréler l’erreur affichée avec smtpd_main.log, smtpd_error.log et, pour une erreur de processus grave, smtpd_panic.log au même instant. Ne modifier qu’ensuite le modèle de mot de passe, le template, la distribution ou le chemin du portail. Si Result vaut plutôt Quarantined, examiner sous Email > SMTP quarantine l’analyse ou l’action de stratégie déclenchée.

Le lien d’enregistrement ou le portail est inaccessible

Vérifier le FQDN, la résolution DNS publique, le port, le certificat, Allowed networks et la validité du lien. Une valeur Allowed Networks vide est traitée comme Any et ne constitue donc pas un état désactivé sûr. Si le client atteint un autre hôte ou portail, l’URL, le NAT ou l’affectation du certificat ne correspond pas au chemin prévu.

Le PDF ne s’ouvre pas

Commencer par faire correspondre le type de mot de passe au message concerné. Un mot de passe à usage unique ne s’applique qu’à cet e-mail. Pour les mots de passe conservés ou enregistrés, l’expiration ou plusieurs modèles de mot de passe peuvent être en cause. Après un SPX Password Reset, l’expéditeur doit de nouveau transmettre le nouveau mot de passe au destinataire de façon sécurisée.

Pour une réinitialisation ciblée, saisir l’adresse e-mail du destinataire concerné sous Email > Encryption > SPX password reset et la vérifier avant de lancer l’opération. Coordonner la réinitialisation et la transmission sécurisée du nouveau mot de passe avec l’expéditeur et le destinataire, puis ouvrir un nouveau message SPX de test. Cela ne garantit pas que les anciens PDF puissent être ouverts avec le nouveau mot de passe.

La réponse sécurisée n’arrive pas

Vérifier Enable SPX reply portal dans le modèle, la période de réponse, le FQDN du portail, le port, le certificat et les sources autorisées. Examiner ensuite Mail logs et les journaux MTA pour la réponse concernée. L’ouverture réussie du PDF ne prouve pas que le canal de retour fonctionne.

La validation DKIM échoue après SPX

SPX modifie le corps et les pièces jointes. Si un message est signé avant cette modification, la signature peut devenir invalide chez le destinataire. Définir si le serveur de messagerie interne, Sophos Firewall ou une passerelle ultérieure signe après toutes les modifications prévues. La chaîne de traitement et un test externe doivent être validés ensemble.

Revenir en arrière en toute sécurité

1. Retirer d’abord l’affectation SPX concernée de Domains and routing target. Pour un déclencheur Data Control, rétablir Data control list action dans la stratégie SMTP de Accept with SPX à l’action précédente consignée.
2. Si elle est utilisée, définir Default SPX template sur None.
3. Effectuer un test négatif sortant et confirmer qu’aucun nouveau PDF SPX n’est généré.
4. Ne retirer les Reply et Registration Portal que si aucune autre stratégie SPX active n’en dépend.
5. Rétablir les accès temporaires publics de port, DNS ou portail à l’état antérieur documenté. Ne restaurer les exigences SMTP TLS modifiées séparément qu’en fonction de leur propre état antérieur consigné.
6. Supprimer le modèle seulement lorsqu’aucune stratégie ni procédure opérationnelle active ne le référence.
7. Conserver Mail logs et les journaux MTA du dernier test chiffré et du premier test non chiffré.

Créer une sauvegarde Sophos Firewall récente avant toute modification des chemins de messagerie et de portail en production. SPX peut continuer à fonctionner dans un environnement air gap, mais les dépendances externes DNS, certificats et portail doivent rester accessibles séparément. Les limites du produit sont décrites dans Fonctions SFOS sans accès Internet.

Liste de contrôle opérationnelle

• La licence, le modèle, le flux de messagerie MTA et le destinataire externe sont vérifiés.
• Le déclencheur et sa priorité sont documentés.
• Le type de mot de passe et son canal de transmission sécurisé correspondent au cas d’usage.
• Le FQDN du portail, le certificat central des portails, le port et Allowed Networks sont strictement limités ; SMTP TLS est documenté séparément.
• L’affectation par domaine, Data Control ou par défaut est sans ambiguïté.
• Les tests positif, négatif, du mot de passe, du PDF et de réponse ont réussi.
• Les filtres SPX encryption et SPX failure de Mail logs ainsi que les journaux MTA peuvent être corrélés avec le message de test ; les actions de quarantaine en sont distinguées.
• Le basculement HA et les journaux locaux aux nœuds font partie de la procédure opérationnelle.
• Le responsable, les délais d’expiration, la date de révision et le retour arrière sont documentés.

FAQ