Configurer Sophos Firewall Mail Protection en mode MTA

En MTA mode, Sophos Firewall accepte lui-même les e-mails, les inspecte et les remet au serveur de messagerie interne ou au relais suivant. Le flux ne fonctionne que si l’enregistrement MX, la règle MTA automatique, la SMTP route and scan Policy, le relais, TLS et la vérification des destinataires sont cohérents.

La configuration comporte six étapes : définir le flux et le chemin de repli, activer MTA mode, ajouter le domaine, créer la route and scan Policy, sécuriser le relais et modifier l’enregistrement MX. Il faut ensuite valider les flux entrant et sortant à l’aide de commandes externes, de la quarantaine, du spool et des logs.

Quand utiliser MTA mode

Mail Protection sur le pare-feu convient surtout aux environnements on-premises et hybrides conçus à cet effet, dans lesquels un serveur Exchange local ou un autre serveur de messagerie doit être protégé. Pour Microsoft 365, Google Workspace et de nombreux environnements entièrement cloud, Sophos Email ou une autre passerelle de messagerie cloud constitue généralement une architecture plus claire. L’enchaînement de deux passerelles complique la quarantaine, les headers, TLS, SPF/DKIM/DMARC et le dépannage.

Si Exchange Online doit utiliser volontairement le MTA du pare-feu, Configurer Sophos Firewall MTA avec Microsoft 365 décrit le chemin complet EOP, relais, connecteur, MX et SPF.

Il faut distinguer trois fonctions de Sophos Firewall :

MTA mode : le pare-feu accepte, inspecte et route les e-mails.
Legacy mode : traitement proxy transparent d’un chemin SMTP existant. Configurer Mail Protection en Legacy mode explique le NAT, les règles, les politiques d’analyse et la validation.
SMTP Relay dans Device Access : contrôle les zones depuis lesquelles le MTA est joignable. Les e-mails entrants d’Internet nécessitent WAN ; le relais sortant est en outre limité à des serveurs internes précis.

La relève de messages existants via POP3 ou IMAP est une tâche distincte. Analyser et tester POP3 et IMAP sur Sophos Firewall couvre la confiance TLS, la stratégie facultative, la règle firewall et la validation.

Les prérequis comprennent une licence Email Protection valide, un routage et un DNS opérationnels, une adresse IP publique connue, le serveur interne et son port cible, ainsi que des stratégies TLS, de quarantaine et de repli définies. Selon la présentation actuelle de Sophos, MTA mode n’est pas disponible sur les XGS 87/87w et XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation et SXL2 Live Protection nécessitent un accès Internet. Le routage des e-mails, l’analyse antimalware, le filtrage MIME et SPX peuvent continuer à fonctionner avec la licence appropriée dans un environnement airgap, mais un MTA actif ne signifie pas que tous les contrôles de protection y sont disponibles.

Configurer MTA mode de bout en bout

1. Définir le flux et le chemin de repli

Pour le flux entrant, l’enregistrement MX public pointe vers l’adresse sur laquelle Sophos Firewall accepte TCP 25. Le pare-feu inspecte le message et le remet au serveur interne. Une ancienne règle DNAT ne doit pas laisser ce serveur directement accessible depuis Internet sans inspection, sous peine de contourner le MTA. Publier un serveur avec DNAT explique la logique DNAT générale.

Pour le flux sortant, seul le serveur prévu envoie via le pare-feu. Le chemin d’envoi, le smarthost, PTR/rDNS, HELO, SPF, DKIM et DMARC doivent correspondre à l’identité publique de l’expéditeur. Une règle générale LAN to WAN est trop large ; la base de règles doit identifier clairement l’expéditeur SMTP autorisé. Comprendre les règles Sophos Firewall explique leur ordre.

Avant la migration, documenter :

l’enregistrement MX actuel, sa priorité et son TTL ;
la nouvelle adresse publique du pare-feu et le serveur cible interne ;
les règles DNAT et SMTP existantes et les connecteurs du serveur ;
les expéditeurs de test entrants et sortants ;
l’ancien MX ou chemin de messagerie comme repli ;
la supervision de la file du serveur, du spool du pare-feu et de la quarantaine.

Réduire le TTL suffisamment tôt si un retour rapide peut être nécessaire. Toute modification du MX de production doit intervenir dans une fenêtre de maintenance.

2. Configurer MTA mode et les paramètres SMTP de base

Sous Email > General settings, sélectionner Switch to MTA mode si nécessaire. Sophos Firewall crée alors la règle Any-to-Any Auto added firewall policy for MTA pour SMTP et SMTPS. Cette règle ne doit pas être modifiée et doit rester en tête de la liste. Le passage à Legacy mode la supprime ; le retour à MTA mode la recrée.

Configurer ensuite les paramètres de base :

Sous SMTP hostname, saisir le nom de domaine, par exemple example.com, et non le hostname du serveur interne. Cette valeur apparaît dans HELO et dans la bannière SMTP des notifications générées par le système.
Vérifier la réponse de l’API XML : La documentation de SFOS 23 répertorie le statut 506 avec Message.AVGeneralConfInvalidSmtpNtfyHostname pour l’opération Email Configuration de l’API XML. Il s’agit d’un statut de l’opération, pas d’un code de statut HTTP. La clé n’est pas résolue et ne constitue pas un message d’erreur en anglais ; elle ne permet pas de déduire des règles de validation précises. Si cette réponse apparaît, vérifier la valeur du nom d’hôte transmise pour les notifications, la réponse réelle de l’opération et la configuration enregistrée avant de considérer la modification comme réussie. La ligne supplémentaire dans la documentation ne prouve pas que ce comportement à l’exécution a été introduit pour la première fois dans SFOS 23.
Activer Reject based on IP reputation pour rejeter les connexions d’expéditeurs de mauvaise réputation.
Sous SMTP TLS configuration, sélectionner un certificat publiquement approuvé et n’autoriser Allow invalid certificate que pour des exceptions documentées.
Activer Disable legacy TLS protocols, sauf si des systèmes anciens documentés l’empêchent. Cette option désactive les protocoles antérieurs à TLS 1.1 ; elle n’impose pas automatiquement uniquement les versions TLS actuelles.
Activer Scan outgoing mails si les messages sortants doivent également être inspectés.

Utiliser Require TLS negotiation avec prudence : si SFOS ne peut pas établir la connexion TLS requise, il supprime les e-mails vers la destination concernée ou provenant du domaine expéditeur configuré. L’aide SFOS 22/23 avertit que la connexion et la validation SMTP TLS utilisent l’adresse IP du domaine plutôt que son nom ; plusieurs domaines sur une même IP peuvent donc provoquer des erreurs de certificat. Il s’agit d’un avertissement documentaire, pas d’une preuve de l’algorithme de correspondance des certificats sur le build déployé.

Skip TLS negotiation sélectionne des hôtes de messagerie distants ou des réseaux pour des connexions SMTP non chiffrées ; la limite documentée est de 512 entrées d’hôtes. Ce n’est pas une solution à un certificat défectueux. Allow invalid certificate est une exception à la validation du pair TLS, pas un passage en clair. Ne pas présumer de priorité si les listes Require et Skip se chevauchent, ni de repli en clair après l’échec d’un TLS obligatoire. Limiter et documenter les exceptions, puis vérifier le résultat réel de la connexion et du certificat sur le build déployé avant de les modifier.

Définir les limites SMTP globales avant les stratégies

Les paramètres sous Email > General settings s’appliquent à tous les e-mails et sont traités avant les stratégies SMTP et POP-IMAP. Reject based on IP reputation n’est donc pas une action de stratégie individuelle : SFOS contrôle l’adresse IP de l’expéditeur avant les contrôles antispam de la stratégie SMTP. Blocked senders est également global, mais bloque uniquement les e-mails entrants.

Sous SMTP settings, Don’t scan emails greater than définit la taille maximale des messages pour l’analyse SMTP globale. 0 signifie 51,200 KB, et non illimité. Pour les messages plus volumineux, Accept, Reject et Drop sont disponibles. Accept remet sans analyser, Reject refuse et informe l’expéditeur, tandis que Drop supprime sans notification. Ce choix est documenté comme une lacune d’analyse ou une décision de remise délibérée et testé avec un message juste au-dessus et juste en dessous de la limite.

Les SMTP DoS settings limitent les connexions simultanées, les e-mails par connexion, les destinataires par e-mail ainsi que les taux d’e-mails et de connexions. SFOS définit le nombre maximal de connexions selon la RAM et le processeur. Les valeurs par défaut documentées sont 1000 e-mails par connexion et 100 destinataires par message. Les valeurs personnalisées sont dérivées du volume réel de messagerie ; une limite trop basse peut assimiler des listes de distribution ou des scanners légitimes à une attaque.

Sous Advanced SMTP settings, SFOS peut rejeter un HELO non valide ou l’absence de RDNS et, avec Do strict RDNS checks, un nom d’hôte qui ne se résout pas vers l’adresse IP source. Ces contrôles ne sont pas introduits en même temps qu’une exception étendue. Les chemins réels des partenaires, newsletters et applications sont d’abord consignés dans le journal, puis testés individuellement.

Une bannière sortante peut utiliser Inline, no conversion, l’option MIME part ou Off. L’analyse SMTP ou SMTPS doit être active dans la règle de pare-feu correspondante. Comme une bannière modifie le body et peut invalider une signature DKIM existante, il faut soit signer après cette modification, soit vérifier explicitement chez le destinataire que la signature prévue reste valide.

Avant une mise à niveau, consigner aussi les limites de débit SMTP. Les plages documentées sont 1–1000 e-mails par connexion, 1–512 destinataires par e-mail, 1–1000 e-mails par hôte et par minute et 1–100 connexions par hôte et par seconde. Les débits par défaut sont respectivement 1000 et 100. Lors de la migration, SFOS conserve les débits d’e-mails et de connexions admis, mais rétablit la valeur par défaut lorsque le maximum est dépassé. Comparer les valeurs enregistrées après la mise à niveau, pas seulement l’ancien export de configuration.

3. Ajouter le domaine comme Address Group

Ouvrir Email > Address group > Add.
Définir Group type sur Email address/domain et Type sur Manual.
Ajouter le domaine protégé, par exemple example.com.
Enregistrer le groupe.

Lors de la création, renseigner aussi un Name clair avant d’enregistrer. Pour un groupe existant, utiliser Edit sous Email > Address group ; lancer l’importation d’un fichier avec Import. RBL (IPv4) reçoit des adresses IPv4 et RBL (IPv6) des adresses IPv6. Email address/domain accepte une saisie manuelle ou un import CSV/texte. La correspondance RBL utilise l’adresse IP de connexion et l’action définie dans la policy SMTP ; le comportement de rejet SPF/RBL documenté séparément reste applicable. Conserver les noms par défaut Premium RBL services et Standard RBL services, sauf changement explicitement planifié.

Les Address Groups ne se limitent pas aux domaines de messagerie. Group type peut être Email address/domain, RBL IPv4 ou RBL IPv6. Une même adresse peut appartenir à plusieurs groupes, ce qui permet de créer des cibles de policy distinctes sans copier ni renommer l’entrée.

Pour les listes plus longues, SFOS peut importer un fichier CSV ou texte contenant jusqu’à 400 adresses ou domaines. Les entrées invalides et en double sont ignorées. Après l’importation, contrôler le nombre d’entrées et quelques exemples avant d’affecter le groupe à une policy de production.

Les nouvelles SMTP route and scan Policies sont conçues autour des domaines, et non d’adresses de destinataires individuelles. Les adresses individuelles migrées peuvent rester actives, mais elles ne peuvent plus être ajoutées ni modifiées dans les policies actuelles.

4. Créer une SMTP route and scan Policy

Ouvrir Email > Policies and exceptions > Add policy > SMTP route and scan :

Saisir un nom clair, par exemple Inbound example.com to Exchange.
Sous Protected domain, sélectionner l’Address Group.
Choisir Route by :
- Static host : adresse IP fixe du serveur interne ; en cas de panne, le pare-feu essaie l’hôte suivant de la liste.
- DNS host : nom DNS tel que mailserver.example.com ; plusieurs enregistrements A sont répartis entre les remises et les serveurs défaillants sont ignorés.
- MX : remise basée sur un enregistrement MX.
Pour Static host, sélectionner le serveur sous Host list. Créer son IP host sous Hosts and services > IP host si nécessaire.
Définir Global action sur Accept pour les domaines que l’on protège délibérément. Reject refuserait tous les messages entrants et sortants associés à ces domaines et en informerait l’expéditeur.
Activer Spam protection et Malware protection conformément au concept d’exploitation.
N’activer File protection et Data protection qu’après avoir compris leurs effets sur les pièces jointes, les messages volumineux, SPX et DKIM.
Enregistrer la policy.

Pour modifier une policy SMTP route and scan existante, ouvrir Email > Policies and exceptions, sélectionner Edit pour la policy concernée, modifier les paramètres nécessaires et enregistrer la policy. Vérifier ensuite à nouveau la correspondance de la policy et la remise à l’aide d’un message contrôlé.

Avec Route by MX, le MX résolu par le pare-feu ne doit pas repointer vers ce même pare-feu, sinon une boucle de routage se produit. Le pare-feu doit résoudre correctement les destinations internes ; les DNS Request Routes sont utiles avec le split DNS.

L’option Route inbound mail through gateway n’est nécessaire que pour des conceptions particulières, par exemple des serveurs cibles dans la zone WAN, l’application de la règle d’origine aux destinations LAN/DMZ ou le choix d’une passerelle précise avec plusieurs accès Internet. Ne pas l’activer sans besoin concret de routage.

5. Sécuriser l’accès entrant et le relais sortant

Sous Administration > Device access, autoriser SMTP Relay depuis toutes les zones qui doivent joindre le MTA. Les e-mails entrants d’Internet nécessitent WAN ; les e-mails sortants nécessitent également la zone du serveur interne, généralement LAN ou DMZ. Sous Email > Relay settings > Host-based relay, limiter ensuite l’accès aux serveurs, scanners ou applications précis.

Des autorisations larges pour les hôtes ou les réseaux créent un risque d’open relay. Si des imprimantes ou applications doivent envoyer des e-mails, les documenter comme objets hôtes précis. Sécuriser l’accès à Sophos Firewall explique les bases de Device Access.

Les listes Allow et Block ne suivent pas le principe selon lequel Block est toujours prioritaire. Si le même hôte ou le même réseau figure dans les deux listes de Host-based relay ou Upstream host, SFOS autorise le relay. Ces chevauchements sont supprimés avant l’activation, puis un test négatif est effectué depuis une source non autorisée.

Un hôte autorisé ne contourne pas non plus l’analyse des e-mails. Si SFOS ne peut pas analyser une adresse IP source autorisée pour host-based relay, il la rejette. Une autorisation de relay ne prouve donc ni la réussite de l’analyse du contenu ni la remise ; les deux sont vérifiées avec un message réel et les logs MTA.

La SMTP route and scan Policy ne prend pas en charge SMTP AUTH. Pour les appareils, Host-based relay constitue donc la méthode fiable. Il existe aussi des Authenticated relay settings séparés pour les utilisateurs et groupes ; Sophos indique cependant qu’ils ne prennent pas en charge une norme SMTP Authentication conforme aux RFC, ce qui impose de tester la compatibilité du client. Cette situation est différente de l’authentification du pare-feu auprès d’un smarthost en amont, pour laquelle SFOS prend en charge PLAIN et LOGIN. Ne jamais utiliser une adresse d’interface du même pare-feu comme smarthost, car cela créerait une boucle de routage.

Si le courrier sortant utilise un smarthost, configurer Email > General settings > Smarthost settings : sélectionner Hostname, définir Port (valeur par défaut 25) et, uniquement si ce serveur l’exige, activer Authenticate device with smarthost et saisir ses identifiants de manière sécurisée. Cela achemine le courrier sortant via un MTA intermédiaire ; cela n’autorise pas les clients à utiliser le relais du pare-feu. Adapter les exigences TLS et l’identité publique finale de l’expéditeur à ce saut supplémentaire et consigner les paramètres précédents pour le retour arrière.

Relais upstream et serveurs hébergés dans le cloud

Upstream host, sous Email > Relay settings, contrôle les sources SMTP en amont autorisées à remettre des e-mails entrants ; Host-based relay contrôle les hôtes autorisés à utiliser le relais sortant. Configurer ces périmètres séparément. Si une autre passerelle reçoit d’abord le courrier public, inscrire ses véritables réseaux sources dans la liste upstream, et non l’adresse du serveur de destination. Dans les deux sections, une entrée d’autorisation correspondante prime sur une entrée de blocage qui la recouvre.

Pour un serveur hébergé dans le cloud, activer SMTP Relay pour sa zone source, généralement WAN, et limiter le relais sortant par hôte aux adresses sources réelles du serveur. Le serveur cloud doit également autoriser la connexion de relais prévue avec le pare-feu. Séparer le MX public pointant vers le pare-feu de la cible de remise résolue par SFOS : la procédure cloud mentionne les deux cibles MX sans expliquer la séparation DNS. Utiliser un hôte DNS distinct, une cible statique ou un DNS scindé maintenu délibérément ; Route by MX ne doit jamais renvoyer les messages au pare-feu.

La procédure cloud recommande aussi de passer en Legacy puis de revenir si la règle automatique manque. Cela supprime et recrée la règle et modifie le traitement du courrier en cours. Ne pas en faire une réparation improvisée : consigner d’abord les stratégies, les files et le chemin de repli, puis examiner la règle manquante avec le support. Tout changement de mode approuvé doit se faire dans une fenêtre de maintenance, avec de nouveaux tests entrants, sortants et de refus de relais.

Les anciens exemples cloud et données financières demandent le nom du serveur sortant comme SMTP hostname, alors que la configuration MTA plus récente demande le domaine, pas le hostname du serveur. Suivre cette indication plus récente pour les notifications système ; ce paramètre ne définit pas l’identité de tous les messages relayés. De même, la vérification DKIM entrante utilise la clé publique DNS de l’expéditeur et n’exige pas de créer une clé de signature sortante simplement parce que la présentation MTA mentionne signature et vérification ensemble.

Plusieurs interfaces WAN ou adresses IP d’alias

Le MTA crée lui-même la connexion SMTP sortante. Lorsque plusieurs adresses publiques peuvent servir d’adresse source, une règle client normale ne suffit donc pas. Sophos distingue trois cas : avec une interface WAN et plusieurs adresses IP d’alias, créer une règle SNAT avec la Translated source publique souhaitée. Avec plusieurs interfaces WAN sans alias, créer une route SD-WAN pour SMTP, SMTP(S) et SMTPS_465. Si plusieurs interfaces WAN et des adresses d’alias sont présentes, combiner SNAT et la route SD-WAN.

La règle SNAT conserve la destination et le service, utilise la liaison WAN prévue comme interface sortante et traduit vers MASQ ou l’adresse IP d’alias souhaitée. La route SD-WAN utilise le groupe Internet comme destination, les trois services SMTP, la passerelle primaire prévue et, si nécessaire, une passerelle de secours. Cette dernière n’est utile que si TCP 25 sortant y est réellement autorisé et si cette adresse publique figure également dans l’enregistrement SPF du domaine de messagerie.

Pour ce processus multi-WAN officiel, Sophos exige la priorité static, vpn, sdwan_policyroute et active SD-WAN pour le trafic généré par le système. Exécuter ces commandes dans la Device Console (option 4 du menu CLI), et non dans l’Advanced Shell. Lire d’abord les deux valeurs initiales, effectuer les modifications, puis les vérifier à nouveau :

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

La priorité des routes est globale et ne constitue pas un simple réglage de messagerie. Avant la modification, documenter tous les chemins statiques, VPN et SD-WAN qui se chevauchent ainsi que les deux valeurs relevées. Pour le retour arrière, restaurer l’ordre précédent complet avec system route_precedence set ... et remettre system-generate-traffic dans son état initial, enable ou disable. Vérifier ensuite non seulement les compteurs SMTP, mais aussi l’adresse IP source réellement utilisée, la remise, le résultat SPF et la panne de la passerelle primaire. Vérifier le routage SD-WAN du trafic généré par le système explique le processus général de sécurité et de retour arrière.

Dans la route SD-WAN, Route only through specified gateways empêche volontairement le repli vers d’autres passerelles : si les passerelles sélectionnées sont injoignables, le pare-feu abandonne le trafic. Décider si cela est préférable à une adresse IP d’expédition imprévue et tester ce cas de panne. Choisir les objets IPv4 ou IPv6 adaptés au chemin de messagerie effectivement publié ; ne pas copier un groupe Internet IPv4 dans une architecture IPv6.

6. Modifier l’enregistrement MX

Ne modifier le MX public vers l’adresse du pare-feu qu’une fois la règle MTA, le domaine, la policy, le relais et le chemin de remise interne prêts. Envoyer immédiatement un message externe de test et vérifier qu’il apparaît dans Log Viewer ou Mail logs, qu’il est remis au serveur interne et qu’il arrive dans la boîte aux lettres.

Si les expéditeurs externes ne peuvent pas atteindre le pare-feu ou si les messages légitimes sont largement rejetés, restaurer l’ancien chemin documenté. Les caches DNS empêchent ce retour arrière d’être immédiatement effectif partout. Conserver donc l’ancien et le nouveau chemin opérationnels en parallèle et les surveiller au moins jusqu’à l’expiration du TTL antérieur le plus long. Si le pare-feu accepte les messages mais ne les remet pas, contrôler d’abord le routage, le DNS, TLS, recipient verification et les logs du serveur.

Choisir consciemment les protections

Actions pour le spam, les malwares et les données sensibles

Pour le spam entrant, le spam probable et les envois en masse, choisir explicitement l’action : None remet sans modification, Warn ajoute le préfixe d’objet configuré, Quarantine retient le message et Drop le supprime sans prévenir l’expéditeur. Définir les préfixes d’objet pour le spam et les envois en masse selon les besoins. Ces choix ne remplacent pas le rejet distinct SPF/RBL.

Pour les malwares, Selected antivirus action propose None, Drop et Quarantine ; configurer Notify sender séparément. Quarantine unscannable content couvre les contenus impossibles à inspecter, notamment les fichiers corrompus, chiffrés ou compressés, les messages trop volumineux et les erreurs internes d’analyse. Une remise réussie ne prouve pas que toutes les pièces jointes ont été analysées. Zero-Day Protection possède sa propre taille maximale d’analyse : les fichiers plus volumineux ne sont pas analysés par ce service. Tester cette limite séparément de la taille SMTP globale et des limites de suppression de File protection.

Sous Data protection, sélectionner la Data control list exacte, son action et, le cas échéant, le SPX template : Accept remet le message, Accept with SPX le chiffre et le remet, et Drop le supprime sans notification. Notify sender est un choix distinct. Une attribution SPX au niveau du domaine chiffre tout le courrier sortant correspondant ; utiliser un déclencheur Data Control si seuls les résultats correspondant aux données financières doivent être chiffrés. L’exemple de mot de passe du destinataire utilise Specified by recipient et retient le message jusqu’à l’enregistrement du mot de passe. Configurer ensemble le modèle, le Reply Portal et l’enregistrement dans le runbook SPX lié, puis tester un message correspondant et un autre non correspondant, plutôt que d’activer uniquement Data protection.

Utiliser des types de fichiers personnalisés et des Data Control Lists

En MTA mode, un type de fichier personnalisé est créé sous Email > Policies and exceptions > File type > Add à partir d’un modèle, d’extensions ou de types MIME. Les extensions sont saisies sans point initial. Seuls les types personnalisés sont modifiables. Un nouveau type n’est pas ajouté automatiquement aux policies existantes : il faut ouvrir la SMTP route and scan Policy concernée, l’ajouter sous File protection, puis enregistrer à nouveau la policy. Un test positif avec une pièce jointe et un test négatif similaire confirment la correspondance plus sûrement que le seul nom de l’objet.

Sous File protection > Block file types, All bloque les e-mails avec pièces jointes ; cela ne signifie pas analyser toutes les pièces jointes. None autorise les pièces jointes pour ce filtre de fichiers, sans contourner les contrôles antimalware, antispam, Data Protection ou autres. L’aide des policies indique que les en-têtes MIME sélectionnés remplissent la MIME whitelist, autorisant ces types et bloquant les autres. Les en-têtes MIME et extensions ne prouvent pas que le contenu est inoffensif. Vérifier les pièces jointes autorisées et bloquées sur le build déployé avant d’appliquer une recette précise de liste blanche.

Une Data Control List se compose de Content Control Lists, ou CCL, pour des types de contenu définis comme des données financières ou personnelles. Lors de sa création sous Email > Data control list > Add, filtrer les CCL par Type et Region et ne sélectionner que les entrées réellement nécessaires. L’action est définie uniquement dans la policy associée. Un contenu correspondant contrôlé et un contenu similaire sans correspondance permettent de vérifier ensemble le match et l’action, sans faux positifs inutiles.

Spam protection ne se limite pas à l’action appliquée au spam. Les échecs SPF et RBL sont rejetés directement et ne suivent pas les actions normales pour spam ou probable spam. Greylisting rejette volontairement un message de façon temporaire et oblige le serveur expéditeur à réessayer.

Pour Reject based on BATV, un BATV secret commun doit d’abord être configuré sous Email > General settings > Advanced SMTP settings. Le même secret est utilisé sur plusieurs systèmes MX appartenant à l’organisation. SFOS le combine à l’horodatage et à l’adresse de l’expéditeur pour créer la signature Return-Path, qui expire après sept jours. Une erreur BATV est donc comparée au secret, à l’heure système, au chemin de l’expéditeur et à l’âge de la signature, et non masquée par une exception étendue sans échéance.

Recipient verification empêche les messages destinés à des utilisateurs inconnus :

With callout : interroge le serveur cible. S’il est temporairement indisponible, SFOS accepte les destinataires après une durée définie au lieu de bloquer durablement tout le flux.
In Active Directory : effectue la vérification via Simple, SSL ou STARTTLS avec un timeout de 30 secondes. Indiquer le serveur AD, Bind DN et Base DN. Bind DN est le nom distinctif complet, incluant le CN de l’identité de liaison configurée ; Base DN est le point de départ des recherches dans l’annuaire. Utiliser les valeurs propres à votre annuaire. L’exemple d’administrateur de l’aide n’établit pas une obligation de privilèges Domain Admin. Choisir un transport conforme à la politique de confiance et de sécurité déployée ; la seule étiquette SSL ou STARTTLS ne prouve pas une validation réussie du certificat.

Malware Protection peut utiliser une ou deux analyses antivirus. Pour utiliser Zero-Day Protection avec une seule analyse, Sophos doit être le moteur principal. Sophos Firewall Zero-Day Protection explique les limites et les décisions de libération.

Selon l’aide des policies SFOS 22/23, Single antivirus sélectionne le moteur principal uniquement pour les messages entrants ; les messages sortants utilisent les deux moteurs. Dual antivirus analyse d’abord avec le moteur principal, puis avec le moteur secondaire. Le moteur principal, Sophos ou Avira, se sélectionne globalement sous Email > General settings. Le choix d’Avira désactive Zero-day protection dans les policies SMTP à analyse antivirus unique ; Sophos doit être principal pour utiliser Zero-Day Protection avec une seule analyse. L’aide des paramètres généraux décrit l’analyse unique comme utilisant seulement le moteur principal, sans la distinction de direction du tableau des policies. Cette différence documentaire ne prouve pas les moteurs réellement utilisés : vérifier le build, la policy, la direction du courrier et l’état de protection avant et après un changement. Consigner les paramètres précédents ; restaurer le choix du moteur ne démontre pas la réactivation de Zero-day protection.

La limite de stratégie Drop message greater than sous File protection n’est pas identique au comportement global pour les messages trop volumineux : les messages plus grands sont supprimés à ce stade. SFOS contrôle également le contenu visible et celui de formats groupés tels que docx, xlsx, pptx, odt, ods, odp et odg. Un test positif avec un simple fichier texte non empaqueté ne prouve donc pas comment les mêmes informations sont traitées dans un document Office.

Lorsque l’option DKIM verification est activée, SFOS distingue une différence de hash, une signature non valide ou une clé publique indisponible et l’absence de signature DKIM. Accept, Quarantine ou Reject peuvent être sélectionnés pour chaque résultat. Selon Sophos, les messages signés DKIM qui utilisent RSA-SHA1 ou une clé hors de la plage 1024 à 4096 bits sont placés en quarantaine. Cette vérification entrante est testée séparément de la signature sortante.

Pour les messages sortants, l’ordre de traitement est important. Le chiffrement SPX, les préfixes d’objet, File ou Data Protection et les bannières sortantes peuvent modifier le header ou le body après l’ajout d’une signature DKIM. La validation DKIM échoue alors chez le destinataire. Il faut décider si le serveur interne, Sophos Firewall ou une passerelle ultérieure signe les messages.

Signer les messages sortants avec DKIM sur le pare-feu

Si Sophos Firewall doit signer lui-même les messages, ajouter une signature pour chaque domaine expéditeur sous Email > General settings > DKIM signing > Add. Domain correspond au FQDN du domaine de messagerie ; Key selector est exactement le sélecteur qui sera ensuite publié dans le DNS public. Un nom comme fw01 ou zurich facilite les futures rotations de clés, mais ne constitue pas une fonction de sécurité.

SFOS attend une clé RSA privée de 1024 à 2048 bits entre -----BEGIN RSA PRIVATE KEY----- et -----END RSA PRIVATE KEY-----. Pour une nouvelle configuration, 2048 bits est le choix approprié. RSA-SHA1 ne doit pas être utilisé. D’après Sophos, le pare-feu n’accepte pas une clé de 1024 bits générée avec PuTTYgen ; il faut donc également y choisir 2048 bits. La clé privée reste exclusivement sur le pare-feu et ne doit jamais figurer dans le DNS, un ticket ou une documentation publique.

Après l’enregistrement, publier chez le fournisseur DNS autoritatif l’enregistrement TXT DKIM du sélecteur avec la clé publique. Envoyer un nouveau message de test par le chemin MTA sortant prévu uniquement lorsque cet enregistrement est résolu depuis l’extérieur. L’en-tête reçu doit contenir le sélecteur et le domaine attendus, et la vérification DKIM chez le destinataire doit réussir. Si la signature manque, contrôler le domaine expéditeur, la correspondance de la policy et Scan outgoing mails. Si la vérification échoue, comparer d’abord l’enregistrement DNS, le sélecteur, la clé utilisée et les modifications ultérieures dues à SPX, aux bannières, à File Protection ou Data Protection.

Configurer et tester le chiffrement des e-mails SPX explique comment le modèle, la priorité des déclencheurs, le modèle de mot de passe et le Reply Portal fonctionnent ensemble.

Automatiser les paramètres MTA en toute sécurité via l’API XML

Pour les automatisations, les paramètres globaux, les Address Groups et les policies SMTP restent des cibles distinctes. Lire d’abord le build, le mode de messagerie actif, les valeurs enregistrées et les policies dépendantes ; préparer une sauvegarde et un retour arrière ciblé. Envoyer la requête confirmée avec une opération explicite uniquement pour la cible nécessaire. Comparer ensuite la réponse de l’opération, l’état relu et le test de flux de messagerie approprié. Même après une erreur ou un timeout, relire d’abord l’état pour déterminer si des données ont déjà été enregistrées, au lieu de répéter aveuglément la requête d’écriture. Sécuriser l’accès à l’API XML explique l’accès, le stockage des secrets et l’interprétation des réponses.

Les références d’objets SFOS 22/23 ne sont pas des payloads prêts pour la production. Les exemples XML, les tableaux de paramètres et l’aide WebAdmin peuvent indiquer des syntaxes, des valeurs ou des valeurs par défaut différentes. Des cellules de valeur par défaut vides ou Any ne confirment ni qu’une valeur vide est sûre, ni le comportement des champs omis. Les constantes non résolues $EMAILPROTECTION{…} ne sont pas des valeurs littérales d’API confirmées. Si la syntaxe, l’opération ou l’effet reste incertain, arrêter avant toute écriture et consulter API help du build installé ou obtenir une clarification officielle. Les différences documentaires seules ne prouvent pas un changement du produit.

Distinguer les paramètres globaux SMTP, TLS et de relais

Dans EmailConfiguration, la limite d’analyse SMTP et les valeurs DoS relèvent de SMTPSSettings, tandis que les valeurs POP/IMAP distinctes relèvent de POPIMAPSettings. Le champ homonyme DontScanEmailsGreaterThan ne doit pas être associé au mauvais protocole. RecipientHeaders avec des éléments Header répétés concerne l’identification des destinataires POP/IMAP, et non le routage SMTP. Les bannières se trouvent sous GeneralSettings. De même, SMTPTLSConfiguration et POPSIMAPTLSConfiguration sont des contextes distincts : TLSCertificate, AllowInvalidCertificate et DisableTLS1 ne peuvent pas être adressés sans ambiguïté par un seul nom de champ non qualifié. Une exception SMTP ne doit pas assouplir aussi POP/IMAP à l’insu de l’administrateur. Après l’enregistrement, relire séparément les deux contextes et tester uniquement le chemin de messagerie prévu.

Selon le tableau de l’API, BypassSpamCheck sous SMTPSSettings décrit le contournement de l’analyse antispam pour le trafic authentifié. Le tableau indique la valeur par défaut Disable, tandis que l’exemple XML définit Enable. Ne pas reprendre cet exemple comme configuration sûre par défaut : avant toute modification, clarifier quel trafic est considéré comme authentifié dans le build concerné et quel contrôle antispam est contourné. Limiter strictement le périmètre d’une exception voulue et vérifier son effet sur les messages correspondants et non correspondants ; ne pas considérer les autres périmètres d’analyse comme automatiquement exemptés.

La provenance des valeurs SMTP est importante : le tableau de l’API indique pour DontScanEmailsGreaterThan la valeur 1024 KB, pour MaximumConnections la valeur 5000 dans la plage 1–20000 et pour MaximumConnectionsHost la valeur 100 dans la plage 1–10000. Pour MaximumEmailsConnection, il indique la valeur par défaut 100, contre 1000 dans l’exemple XML ; l’aide WebAdmin indique également 1000. MaximumRecepientsEmail est l’orthographe de la source, avec la valeur par défaut 100 et la plage 1–512. Pour EmailsRate et ConnectionsRate, le tableau de l’API indique les valeurs par défaut 1000 et 100, chacune dans la plage 1–20000 ; l’aide WebAdmin limite en revanche les débits à 1–1000 par minute et à 1–100 par seconde, respectivement, et détermine les maxima de connexions selon le matériel. Ne reprendre donc ni les maxima du tableau comme limites actuelles de l’interface, ni les valeurs des exemples comme valeurs par défaut. Les limites WebAdmin décrites ci-dessus et le contrôle de mise à niveau restent déterminants pour cette procédure ; les automatisations doivent comparer les valeurs réellement enregistrées sur le build.

D’autres conflits de syntaxe empêchent d’importer aveuglément les exemples : VerifySendersIPReputation affiche Enable dans l’exemple XML, mais on/off dans le tableau de l’API, avec la valeur par défaut Disable ; SMTPSDosSettings y est décrit comme un entier avec la valeur par défaut Disable, mais figure comme Enable dans l’exemple. Pour la bannière, les textes de l’exemple contrastent avec les valeurs du tableau inline_plain, mimepart, off. Ne pas « corriger » soi-même ces indications : confirmer la syntaxe et les valeurs valides avant toute requête. Tenir compte séparément de l’avertissement existant concernant Email Configuration, statut 506.

AdvancedSMTPSetting est également global. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks et ScanOutboundEmails pilotent les contrôles HELO/RDNS et sortants expliqués ci-dessus. FirewallRelateInboundMails concerne le chemin distinct via la passerelle et les règles de pare-feu ; l’exemple indique Disable, le tableau Turn on/Turn off. Pour le secret BATV, l’exemple affiche BATVSecret, tandis que le tableau indique BATVsecret. Confirmer la casse et les valeurs valides avant l’écriture ; ne présenter aucune de ces variantes comme un payload testé. Utiliser le secret commun depuis un stockage protégé ; ne copier ni le secret d’exemple ni le secret utilisé dans un ticket, un dépôt ou un journal de requêtes. Planifier le changement de secret sur tous les systèmes MX concernés, puis vérifier BATV et l’envoi normal.

Dans RelaySettings, HostBased et UpstreamHost possèdent chacun leurs propres listes AllowRelay et BlockRelay. Sous celles-ci se trouvent HostsOrNetworks et des entrées HostsOrNetwork répétées. Un même nom de champ terminal ne signifie donc pas un même périmètre de relais. AuthenticatedRelaySettings contient séparément AuthenticatedRelay ainsi que UsersOrGroups avec UsersOrGroup. Les groupes ouverts ou invités présentés dans l’exemple du fabricant ne constituent pas une sélection sûre. Utiliser uniquement les identités et les objets hôtes prévus, supprimer les chevauchements entre listes, puis vérifier l’envoi autorisé et le refus du relais non autorisé depuis une source distincte.

Dans SmarthostSettings, UseSmarthost active le saut intermédiaire sortant ; SmarthostList avec des éléments Hostname répétés sélectionne les cibles, et Port le port cible. Le tableau de l’API indique 1–65535, mais aucune valeur de port par défaut ; 25 figure dans l’exemple et comme valeur par défaut dans l’aide WebAdmin. AuthenticateDevicewithSmarthost est distinct : fournir Username et Password de manière sécurisée uniquement si une authentification est nécessaire. Le tableau de l’API indique Disable par défaut pour les deux commutateurs d’activation, tandis que l’exemple les active tous les deux. passwordform="encrypt" est la syntaxe de mot de passe de l’exemple, pas une autorisation de réutiliser les valeurs chiffrées d’un autre pare-feu. Si la provenance ou les exigences d’importation restent incertaines, arrêter la requête. Vérifier ensuite la cible, TLS, l’authentification et la remise via ce saut, et pas seulement l’autorisation de relais.

Modifier de manière ciblée les Address Groups et les policies SMTP

Pour le MTA, l’objet d’exemple prévu est MTAAddressGroup, et non AVASAddressGroup, au nom similaire, qui appartient à l’autre contexte de messagerie. Name identifie le groupe. GroupType détermine la liste appropriée : le tableau de l’API distingue RBLIPv4, RBLIPv6, IPAddress et EmailAddressOrDomain, ainsi que les champs d’entrée RBLName, IPAddressNetwork et EmailAddressDomain. L’exemple de domaine de messagerie utilise EmailAddressList avec des éléments EmailAddressDomain répétés et EmailImportType défini sur Manual. Pour Import et EmailAddressFile, clarifier la méthode de téléversement de fichier adaptée au build : le texte descriptif associe de manière contradictoire le champ de fichier à l’importation manuelle. Une réponse HTTP réussie ne confirme ni toutes les entrées importées ni la composition finale du groupe. Relire le nombre d’entrées, les entrées omises et les valeurs exactes des domaines avant qu’une policy n’utilise le groupe.

Pour Delete Address Group, les pages SFOS 22/23 fournissent des lignes de statut, mais aucune définition de paramètres ni exemple de suppression. Elles ne permettent donc de déduire ni l’identité exacte de l’objet pour l’opération Remove ni une requête fonctionnelle. Ne pas simplement insérer Name ou l’objet de création dans un payload Remove. Vérifier d’abord les utilisations dans les configurations de messagerie, d’antispam et d’archivage ; obtenir l’opération exacte et sa requête complète auprès de API help installé ou par une clarification officielle. Jusqu’à cette clarification, n’exécuter aucune suppression automatique. Après une suppression approuvée, vérifier à nouveau que seul le groupe prévu a été supprimé et que les références nécessaires ainsi que le flux de messagerie restent intacts.

Dans SMTPPolicy, Name constitue l’identité de la policy ; DomainList avec DomainName associe les domaines protégés. RouteBy, DNSHostName et RouteList avec HostName, routingid et routingorder décrivent différents chemins de remise, et non des noms de domaine supplémentaires. Le tableau de l’API indique MX comme valeur de routage par défaut, mais l’exemple contient des textes de routage alternatifs plutôt qu’une valeur unique. Vérifier le routage au préalable par rapport à la résolution DNS réelle afin d’éviter une boucle vers le pare-feu.

Les sections imbriquées SpamProtection, MalwareProtection, FiletypeFilter et DataProtection possèdent des champs de statut indépendants. Le tableau de l’API les indique par défaut sur OFF, bien que l’exemple les définisse sur ON. Une action globale Accept n’active donc pas automatiquement tous les contrôles. De même, le champ SPX de domaine SPXEncryption et le champ lié aux correspondances DataProtectionSPXTemplate ne sont pas interchangeables ; DataProtectionPolicy doit référencer une Data Control List existante et appropriée. Vérifier au préalable les prérequis des moteurs, de Zero-Day et de BATV ainsi que le modèle de mot de passe SPX. Le tableau décrit la vérification des destinataires comme sortante, l’aide WebAdmin comme entrante ; ne pas en déduire une nouvelle direction de contrôle. Les tests positifs et négatifs propres à chaque direction et les valeurs de policy enregistrées déterminent si le dispositif de protection prévu est effectivement mis en œuvre.

Pour la Data Control List, l’exemple XML présente MTADataControlList, contenant Name et Signatures avec des éléments Signature répétés. Les libellés de tableau name et signaturename ne constituent pas une instruction confirmée de les sérialiser en minuscules comme balises XML. Confirmer au préalable le mode MTA, lire les signatures disponibles et choisir uniquement les CCL appropriées. La liste seule ne produit aucune action de protection : seules l’association via DataProtectionPolicy et l’action dans la policy SMTP mettent le dispositif en œuvre. Relire ensuite la liste et son association, puis vérifier une correspondance contrôlée et un contenu similaire sans correspondance.

Ne pas assimiler DKIM et les exceptions au routage

Dans DKIMVerification, VerifactionStatus, effectivement écrit ainsi dans l’exemple, contrôle l’activation. ActionForVerifactionFail est un sélecteur différent de ActionForSignatureInvalid ou de ActionForSignatureNotFound : le premier concerne les erreurs de vérification du hash ou de la signature, le deuxième une clé publique DNS absente ou syntaxiquement non valide, et le troisième une signature absente. Ne pas corriger silencieusement les fautes d’orthographe des deux premières balises. L’exemple XML indique Pass, tandis que le tableau des paramètres et l’aide WebAdmin indiquent Accept aux côtés de Quarantine et Reject. Cela ne confirme pas que ces valeurs d’API sont interchangeables ; clarifier le contrat d’API du build avant toute requête et tester séparément les trois cas entrants.

Dans DKIMSigning, Domain identifie le domaine de signature, et non Name ; la référence de suppression exige également Domain. Lors de la création et de la modification, KeySelector et PrivateRSAKey sont des champs obligatoires. Selon l’aide WebAdmin, un domaine peut avoir plusieurs signatures, tandis que la référence de suppression ne mentionne que le domaine : en présence de plusieurs sélecteurs, clarifier au préalable le périmètre exact de suppression, sans en déduire une suppression propre à un sélecteur. Stocker les clés privées et les identifiants d’accès à l’API de manière protégée et les retirer des réponses et des logs ; vérifier ensuite le DNS et la nouvelle signature reçue comme décrit ci-dessus.

La liste globale entrante utilise MtaBlockedSenders avec BlockedEmailAddresses et des éléments EmailAddress répétés ; le tableau de l’API autorise des adresses individuelles ou des domaines avec caractère générique tels que *@example.com. Cette liste ne remplace pas une policy antispam complète et ne s’applique, dans le contexte MTA décrit ici, qu’aux messages entrants. Avant toute modification, lire le périmètre et les entrées existantes ; tester ensuite un expéditeur correspondant et un expéditeur non correspondant.

Séparément, l’API décrit AntiSpamTrustedDomain avec DomainList et des éléments DomainName répétés comme une exception permettant de contourner l’analyse des e-mails pour les domaines de confiance. Cette source ne précise pas quels analyseurs sont exactement contournés. Ne pas inventer de chemin dans l’interface graphique, garantir que « toutes les analyses sont désactivées » ou confondre les domaines de confiance avec les domaines protégés utilisés pour le routage. Avant toute création ou suppression, clarifier la liste exacte des domaines, l’exception nécessaire et l’effet sur l’analyse sur le build installé ; limiter strictement le périmètre et vérifier l’exception avec une date de révision et des messages correspondants et non correspondants.

Pour Delete Trusted Domain, le tableau des paramètres indique que DomainName est un tableau obligatoire pouvant contenir plusieurs valeurs, mais ne fournit aucun exemple de suppression. Ne pas reprendre sans vérification l’imbrication de l’exemple Add comme requête de suppression ; confirmer au préalable les valeurs cibles et la structure complète de la requête dans API help du build installé ou par une clarification officielle.

Le sélecteur global de moteur est MalwareProtection avec PrimaryAntiVirusEngine, défini par défaut sur Sophos dans le tableau de l’API. Ce n’est pas l’élément imbriqué homonyme de la policy et il n’active pas lui-même les périmètres d’analyse. Contrôler les effets sur l’analyse simple ou double et sur Zero-Day Protection, comme décrit ci-dessus, avant et après une modification des policies concernées.

Utiliser les réponses propres aux objets comme aide au diagnostic

Les correspondances suivantes proviennent des lignes de statut SFOS 22/23. Les nombres sont des codes d’opération XML, pas des codes HTTP ; Message.* désigne des clés de source non résolues, et non des textes de message confirmés ou des causes d’erreur univoques. Les règles générales de sécurité de l’API décrites ci-dessus s’appliquent aussi ici : comparer la réponse réelle et l’état enregistré avant chaque nouvelle tentative, ne pas supprimer des dépendances sur la base d’une supposition et arrêter si l’état partiel reste incertain.

Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. Les trois dernières lignes rendent la vérification de l’importation particulièrement importante ; ne pas supposer que le fichier entier a été rejeté ou accepté. Edit Address Group ne répertorie dans ces sources que 200 → Message.AddrGrpUpdateSuccess et 500 → Message.AddrGrpUpdateFail ; ne pas présenter les codes Add comme des réponses Edit documentées.
Delete Address Group: 504, 505 et 506 renvoient chacun à Message.AddrGrpForeignKeyExists ; 507 à Message.AddrGrpEmailArcKeyExists. Une même correspondance symbolique ne détermine pas quelle référence est concernée. Vérifier les utilisations et les groupes réellement présents ; ces réponses ne remplacent pas le contrat de suppression manquant.
Add Data Control List et Update Data Control List: chacun indique 502 → Message.DLPAddSameName et 545 → Message.MTAModeDisableCheck. La clé Update contient elle aussi « Add » ; ne pas la renommer. Vérifier les noms, le mode et la liste enregistrée, sans déterminer une cause à partir de la seule clé.
Add SMTP Policy et Edit SMTP Policy: chacun indique 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck et 545 → Message.MTAModeDisableCheck. Seul Add SMTP Policy répertorie 502 → Message.SMTPProfileduplicateName. Pour 543, la source distingue Message.SMTPProfileSenderGenSPXAdd pour Add et Message.SMTPProfileSenderGenSPXEdit pour Edit. Comparer les associations de domaines, les noms, le mode et les dépendances SPX à l’état réel ; ne déclencher aucun renommage automatique ni assouplissement de la protection.
Email Configuration: 505 → Message.ASConfigSubOperationFail figure dans les deux versions. Avant toute nouvelle tentative, relire toutes les sous-sections SMTP, POP/IMAP et TLS concernées, sans présumer d’une réussite complète ni d’un rollback complet. La ligne supplémentaire de SFOS 23, 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname, reste soumise aux réserves indiquées ci-dessus.

Valider le flux de messagerie

Exécuter les commandes suivantes depuis un système extérieur au réseau :

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

Remplacer example.com et mail.example.com par les valeurs réelles. Ces commandes testent le DNS, TCP 25 et STARTTLS, mais ni l’autorisation de relais ni la remise complète. openssl s_client reste interactif après le handshake ; l’arrêter avec Ctrl+C.

Tester au minimum les cas suivants :

message externe vers un destinataire valide ;
avec Recipient verification activé, message externe vers un destinataire non valide ;
message sortant via le serveur prévu ;
test spam ou malware adapté à la policy ;
STARTTLS et chaîne de certificats présentée ;
action de quarantaine et remise après libération ;
tentative de relais bloquée depuis une source non autorisée ;
absence de remise directe contournant le MTA via une ancienne règle DNAT.

Ne consigner que les résultats d’acceptation réellement observés : le message de test valide doit apparaître comme Delivered dans Mail logs et pouvoir être suivi par son Message-ID jusqu’à la boîte cible. Ne s’attendre au refus du destinataire non valide que si la vérification des destinataires est activée, si la méthode de vérification sélectionnée fonctionne via un chemin de vérification accessible faisant autorité et si le refus est configuré. Pour With callout, distinguer ce test négatif de l’exception documentée : SFOS accepte les destinataires lorsque le serveur de messagerie cible est inaccessible pendant une durée déterminée. La documentation ne précise pas cette durée ; ne pas supposer que la même exception s’applique à In Active Directory. Lorsque la vérification est désactivée, un refus n’est pas le résultat attendu de ce test négatif. La tentative de relais non autorisée ne doit créer aucun message, et la libération de quarantaine doit montrer la remise ultérieure du même Message-ID.

Pour la première vérification, utiliser Email > Mail logs, Email > Mail spool, Email > SMTP quarantine et Log Viewer. Pour une analyse approfondie, noter l’heure du test, l’expéditeur, le destinataire, l’objet, l’IP source et le Message-ID, puis les corréler avec ces fichiers :

MTA : smtpd_main.log
rejets : smtpd_reject.log
erreurs d’analyse : smtpd_error.log
erreurs MTA internes : smtpd_panic.log
anti-spam : sasi.log
proxy SMTP legacy : awarrensmtp.log
proxy POP/IMAP : warren.log

Services et logs Sophos Firewall explique la correspondance et l’accès via Advanced Shell.

Dans Mail logs, Result indique l’état de remise, tandis que Reason décrit le motif d’analyse ou de policy. Rejected signifie que SFOS a supprimé le message et informé l’expéditeur. Dropped le supprime sans notification ; Bounced apparaît après plusieurs tentatives de remise infructueuses. Ces états ne sont pas équivalents, car ils produisent des retours et des chemins de diagnostic différents. Les autres résultats comprennent Delivered, Quarantined et Deleted manuellement ; les motifs peuvent notamment être filtrés par Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM et BATV.

Exploiter la quarantaine et le Mail spool

Sous Email > SMTP quarantine, filtrer par période, expéditeur, destinataire, objet et motif de quarantaine :

Release : remettre le message.
Delete : supprimer le message.
Release and report : libérer et signaler à SophosLabs uniquement les faux positifs classés Spam ou Probable spam.

Les messages infectés par un virus ou classés malveillants par Zero-Day Protection ne peuvent pas être libérés. La suppression d’entrées Zero-Day Protection nécessite un droit d’écriture pour cette fonction dans le profil administrateur. Lorsque la quarantaine est pleine, les anciens messages sont purgés.

Seuls les utilisateurs qui se sont authentifiés au moins une fois auprès du pare-feu reçoivent les résumés de quarantaine. Par défaut, SFOS n’applique pas les paramètres de résumé aux alias ; les attribuer avec l’adresse principale sous Email > Quarantine settings > Change user’s quarantine digest settings ou dans l’objet utilisateur. Le résumé peut alors inclure le spam destiné aux adresses principale et alias. Les messages destinés aux alias n’apparaissent toujours pas dans User Portal lui-même.

Configurer et tester le rapport de quarantaine Sophos Firewall explique la configuration, l’affectation des utilisateurs, le lien de libération et le test fonctionnel complet.

Email > Mail spool contient les messages non encore remis ou en échec. SFOS retente la remise pendant trois jours et supprime les messages après quatre jours supplémentaires ; les messages supprimés restent visibles dans Mail logs. Un spool croissant signale donc un problème de routage, DNS, TLS, policy ou serveur de messagerie et ne justifie pas des clics répétés sur Retry sans diagnostic.

Le filtre d’état distingue Queued, Failed, SPX blocked, Zero-day protection et Error. SPX blocked attend que le destinataire crée un mot de passe ; Zero-day protection attend l’analyse. Seuls les messages de l’error queue peuvent être téléchargés ou supprimés. La suppression ou le nouvel envoi de messages Zero-Day Protection nécessite des droits en lecture et écriture sur Zero-Day Protection Activity. Si un bouton manque, contrôler d’abord l’état et le profil administrateur au lieu de contourner la limite par un redémarrage de service.

La quarantaine et le spool consomment du stockage local. Surveiller l’espace libre, l’état du SSD et System Health ; voir Nettoyer le stockage et les reports et Contrôler SSD Health. En HA, les logs et reports sont séparés pour chaque node et ne sont pas synchronisés ; il faut donc contrôler les deux. Clusters HA Sophos Firewall présente les bases.

Dépannage

Les e-mails externes n’arrivent pas

Contrôler MX, A/AAAA, l’IP publique, TCP 25 et SMTP Relay depuis WAN. Vérifier ensuite que MTA mode est actif, que le domaine protégé correspond à la policy et qu’aucune ancienne règle DNAT ou règle de priorité supérieure ne modifie le chemin attendu. Si smtpd_main.log ne montre aucune connexion, le problème se situe probablement avant Mail Protection.

Le pare-feu accepte mais ne remet pas le message

Contrôler le serveur interne, la route, le DNS, le port cible, TLS et recipient verification. Static host, DNS host et MX utilisent des chemins de résolution et de failover différents. Corréler les logs de rejet et d’erreur du pare-feu avec ceux du serveur.

De nombreux messages restent dans le spool

Contrôler d’abord Email > Mail spool et les logs MTA. Une cause fréquente est une règle placée au-dessus de la règle MTA automatique qui matche déjà SMTP. Sous Rules and policies > Firewall rules, vérifier les nouvelles règles en position Top, les règles IPsec ou hotspot générées automatiquement et les autres chevauchements. Ne déplacer aucune règle à l’aveugle ; son match SMTP réel est déterminant.

Uniquement après confirmation que la nouvelle règle qui chevauche la règle SMTP est à l’origine du problème, la déplacer suffisamment bas sous Rules and policies > Firewall rules pour que la règle SMTP prévue soit à nouveau évaluée. Vérifier ensuite à nouveau la remise et le spool à l’aide d’un message contrôlé ; les autres connexions nécessaires doivent continuer à passer par les règles prévues.

NC-177930 a été corrigé dans SFOS 22.0 MR2 : des messages restaient dans le spool après un crash de mailpoller. Si le problème apparaît sur une version antérieure, inclure la version du firmware dans le diagnostic. Utiliser le contrôle de mise à niveau vers SFOS 22 pour choisir le build cible, préparer le changement et retester ensuite le flux de messagerie.

Sophos Fusion affiche `Invalid API request`

Sous SFOS 22.0 MR1, Release et Delete pouvaient échouer lorsque le pare-feu était ouvert via Sophos Fusion (anciennement Sophos Central). Le symptôme Invalid API request est suivi sous NC-182056 ; NC-181904 désigne le correctif de l’échec de libération depuis Sophos Fusion. Le workaround sûr consiste à se connecter directement au WebAdmin local et à effectuer l’action sous Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 corrige le problème. S’il persiste, contrôler séparément le profil administrateur, l’accès à Sophos Fusion et les permissions locales. Pour une mise à jour, suivre le processus complet d’approbation, de préparation, de validation et de dépannage dans Mise à jour du firmware Sophos Firewall : préparation et bonnes pratiques.

Impossible d’activer `Reject based on RBL`

NC-144563 est un cas propre à SFOS 20.0.2 MR2 Build 378 : si les groupes RBL par défaut ont été renommés sous Email > Address group, il est impossible d’activer Reject based on RBL lors de la création d’une policy SMTP route and scan. Dans une policy existante, l’option ne peut plus être réactivée après sa désactivation. Aucune version corrigée n’est documentée.

Les groupes par défaut s’appellent Premium RBL services et Standard RBL services. Documenter d’abord le build exact et les noms actuels des groupes. Si ces deux conditions sont remplies, rétablir les noms d’origine des RBL par défaut, rouvrir la policy et vérifier l’option. Ne pas confondre les RBL personnalisées avec ces deux groupes système.

Sur d’autres builds, ou si les noms par défaut n’ont pas changé, une option grisée ne suffit pas à confirmer NC-144563. Vérifier séparément le type de policy, Spam protection, la licence Email Protection et le reste de la configuration.

Un expéditeur légitime est classé comme spam

Contrôler le domaine expéditeur, SPF/DKIM/DMARC, les headers, la réputation, le policy match et les destinataires concernés. Créer seulement ensuite une exception étroite avec une date de révision. Créer et tester en toute sécurité des exceptions de messagerie décrit l’ensemble du processus de portée, de test et de retour arrière.

Les systèmes internes ne peuvent pas relayer

Contrôler la zone source sous Administration > Device access, l’objet hôte sous Email > Relay settings > Host-based relay et les logs MTA. Si un scanner attend SMTP AUTH standard, Host-based relay est généralement plus fiable. Le relais authentifié séparé, non conforme aux RFC, doit être testé avec le client concerné.

Checklist d’exploitation

Licence, prise en charge du modèle, DNS et services Internet requis vérifiés.
MX, TTL, chemins public et interne ainsi que repli documentés.
Règle MTA automatique inchangée et maintenue en tête.
Aucune ancienne règle DNAT ne contourne Mail Protection.
Address Group, destination de routage et policy match testés.
SMTP Relay entrant depuis WAN et autorisations d’hôtes sortantes correctement séparés.
Effets de SPF/RBL, recipient verification, TLS, DKIM, SPX et des bannières compris.
Tests externes positifs et négatifs effectués.
Quarantaine, spool, stockage et logs surveillés.
Flux de messagerie retesté après les mises à jour du firmware.

Pour une conservation et une corrélation plus longues, utiliser Central Firewall Reporting ou envoyer les logs Sophos Firewall à un SIEM.

FAQ

Sophos Firewall Mail Protection est-il identique à Sophos Email ?

Non. Firewall Mail Protection traite SMTP directement sur le pare-feu ; Sophos Email est une passerelle de messagerie cloud. Les deux peuvent assurer des fonctions de protection similaires, mais ne doivent pas être enchaînés sans conception délibérée.

Pourquoi des messages restent-ils dans le Mail spool ?

Le serveur cible, le DNS, TLS ou le routage sont souvent en cause. Il faut également vérifier si une règle de priorité supérieure matche SMTP avant la règle MTA automatique.

Sophos Firewall prend-il en charge SMTP AUTH pour les clients de relais internes ?

Pas dans la SMTP route and scan Policy. Pour les appareils, utiliser Host-based relay. Selon Sophos, le relais authentifié séparé n’est pas conforme aux RFC et doit être testé avec le client ; l’authentification du pare-feu auprès d’un smarthost en amont prend en charge PLAIN et LOGIN.