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 :

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

2. Activer Reject based on IP reputation pour rejeter les connexions d’expéditeurs de mauvaise réputation.

3. Sous SMTP TLS configuration, sélectionner un certificat publiquement approuvé et n’autoriser Allow invalid certificate que pour des exceptions documentées.

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

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

3. Ajouter le domaine comme Address Group

1. Ouvrir Email > Address group > Add.
2. Définir Group type sur Email address/domain et Type sur Manual.
3. Ajouter le domaine protégé, par exemple example.com.
4. 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 :

1. Saisir un nom clair, par exemple Inbound example.com to Exchange.
2. Sous Protected domain, sélectionner l’Address Group.
3. 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.
4. Pour Static host, sélectionner le serveur sous Host list. Créer son IP host sous Hosts and services > IP host si nécessaire.
5. 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.
6. Activer Spam protection et Malware protection conformément au concept d’exploitation.
7. 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.
8. 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.

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.

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

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.

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. Avec recipient verification activé, le destinataire non valide doit être refusé ; si 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