Configurer Sophos Firewall Mail Protection en mode MTA

Sophos Firewall peut non seulement autoriser le trafic email comme une connexion de pare-feu normale, mais aussi fonctionner en mode MTA comme Mail Transfer Agent entre Internet et le serveur de messagerie interne. Le pare-feu accepte les connexions SMTP, contrôle les messages avec Mail Protection, puis les remet au serveur de messagerie défini.

Aujourd’hui, nous recommandons Mail Protection sur le pare-feu uniquement pour des cas particuliers planifiés consciemment, par exemple lorsqu’un serveur Exchange local ou un autre serveur de messagerie interne doit être protégé directement par le pare-feu. Pour Microsoft 365, Google Workspace et la plupart des environnements de messagerie cloud modernes, Sophos Central Email est généralement la meilleure solution. Central Email est plus proche du service de messagerie réel, s’intègre plus proprement aux boîtes aux lettres cloud, réduit la complexité dans le jeu de règles du pare-feu et évite de nombreux sujets MTA classiques comme les changements MX, les spools locaux, les questions de relais et l’analyse des erreurs sur le pare-feu.

Autre point pratique : par rapport à Sophos Central Email, Email Protection sur le pare-feu ressemble depuis un certain temps à une fonction de parc existant, surtout pertinente pour les serveurs de messagerie on-premises déjà en place. Pour une nouvelle planification aujourd’hui, il faut donc d’abord vérifier si une passerelle de messagerie cloud constitue l’architecture la plus propre.

La solution est techniquement puissante, mais aussi sensible aux erreurs si DNS, enregistrement MX, TLS, relais, vérification des utilisateurs, policies et logs ne sont pas planifiés proprement. Un MTA mal configuré peut bloquer des emails légitimes, retarder le mailflow ou, dans le pire des cas, être compris comme un relais.

Cet article explique la mise en place pratique de Sophos Firewall Mail Protection en mode MTA. Il ne remplace pas une planification Sophos Central Email. Pour de nombreux environnements Microsoft 365 ou Google Workspace, une passerelle de messagerie cloud est souvent plus adaptée. Mais lorsqu’un Exchange local, un serveur de messagerie hybride ou un chemin SMTP volontairement basé sur le pare-feu est exploité, un plan d’exploitation clair est nécessaire.

Quand Mail Protection sur le pare-feu est pertinente

Mail Protection sur Sophos Firewall est surtout pertinente lorsque le trafic SMTP doit volontairement passer par le pare-feu et que celui-ci doit faire plus que simplement transférer le port 25.

Scénarios typiques :

Les emails entrants doivent d’abord être acceptés et contrôlés sur le pare-feu.
Un serveur de messagerie interne ne doit pas être joignable directement depuis Internet.
Le contrôle du spam, des malwares, des types de fichiers ou du contenu doit s’appliquer avant la remise.
Les emails sortants doivent être envoyés de manière contrôlée via le pare-feu ou un smarthost.
La quarantaine, le mail spool et les logs SMTP doivent être traçables sur le pare-feu.

Toutes les configurations de messagerie ne doivent pas passer par le pare-feu. Si Sophos Central Email, Microsoft Defender for Office 365 ou une autre passerelle de messagerie cloud prend déjà en charge tout le mailflow, il ne faut pas intercaler Mail Protection sur le pare-feu en plus sans documenter précisément le flux de messagerie. Les passerelles doublées entraînent rapidement des responsabilités peu claires pour la quarantaine, les en-têtes, SPF/DKIM/DMARC, TLS et le dépannage.

Distinguer mode MTA, Legacy mode et SMTP Relay

Avec Sophos Firewall, trois éléments doivent être clairement séparés :

Fonction	Objectif	Utilisation typique
MTA mode	Le pare-feu accepte les emails, les contrôle et les remet ensuite	Mailflow SMTP entrant ou sortant avec policies
Legacy mode	ancien traitement mail basé sur proxy	Environnements existants migrés ou volontairement maintenus
SMTP Relay comme service local	des systèmes internes envoient via le pare-feu	Imprimantes, scanners, applications ou systèmes de monitoring

Le MTA mode est le mode cible normal pour les scénarios modernes de Mail Protection sur pare-feu. Le service local SMTP Relay, en revanche, relève de Device Access. Il ne doit être joignable que depuis des réseaux internes définis. Une autorisation trop large peut favoriser l’abus de relais. Le durcissement des services locaux est décrit dans Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.

Prérequis

Avant la configuration, ces points doivent être clarifiés :

Sophos Firewall avec Email Protection valide ou bundle adapté.
Tous les modèles ne prennent pas en charge le MTA mode. Les XGS 87 et XGS 88 sont des appliances sans prise en charge du MTA mode.
La zone DNS publique et l’enregistrement MX sont connus.
Le serveur de messagerie interne, le port cible et le chemin de remise sont documentés.
L’adresse IP publique ou l’adresse WAN pour le trafic SMTP entrant est définie.
Le pare-feu peut router vers le serveur de messagerie interne et l’atteindre.
L’accès DNS sortant du pare-feu fonctionne.
La stratégie TLS et certificats souhaitée est clarifiée.
Le processus de quarantaine et de libération est défini au niveau organisationnel.

Avant de modifier le mailflow, une fenêtre de maintenance doit être planifiée. Un test sur des enregistrements MX productifs sans plan de retour arrière est risqué, car les emails entrants peuvent être rapidement retardés ou refusés selon l’expéditeur.

Définir l’architecture cible

Il faut d’abord décider quelle direction le pare-feu doit traiter.

Mailflow entrant

Pour le mailflow entrant, les enregistrements MX externes pointent vers l’adresse publique sur laquelle Sophos Firewall accepte SMTP. Le pare-feu contrôle le message et le transmet au serveur de messagerie interne.

Déroulement typique :

L’expéditeur externe se connecte par SMTP à l’adresse MX publique.
Sophos Firewall accepte la connexion en MTA mode.
Mail Protection contrôle l’expéditeur, le destinataire, le spam, les malwares, les pièces jointes et la policy.
Le pare-feu remet l’email au serveur de messagerie interne.
Le serveur de messagerie interne livre dans la boîte aux lettres ou traite le message.

Il est important que le serveur de messagerie interne ne reste pas également joignable sans filtrage depuis Internet. Si une règle DNAT pointe encore directement vers le serveur de messagerie en parallèle, une partie du trafic peut contourner Mail Protection. Pour les publications de serveurs normales, Publier un serveur avec DNAT constitue la base adaptée, mais en MTA mode le pare-feu lui-même est le point d’acceptation SMTP.

Mailflow sortant

Pour le mailflow sortant, le serveur de messagerie interne envoie via Sophos Firewall. Selon la configuration, le pare-feu peut contrôler les messages, les transférer à un smarthost ou les remettre directement.

Clarifier au préalable :

L’adresse IP publique du pare-feu est-elle autorisée à envoyer des emails directement ?
SPF, DKIM et DMARC correspondent-ils au chemin d’envoi choisi ?
Un smarthost de fournisseur est-il nécessaire ?
Le trafic SMTP sortant doit-il être limité à certains systèmes internes ?
Où les messages refusés ou retardés sont-ils surveillés ?

Pour le trafic mail sortant, il faut utiliser une structure de règles et de policies dédiée et traçable. Une règle générale LAN to WAN sans restriction claire est généralement trop large pour des serveurs de messagerie. Les bases de l’ordre des règles et des profils de sécurité sont décrites dans Comprendre et construire proprement les règles Sophos Firewall.

Préparer le changement MX et les tests externes

Un changement Mail Protection devient critique uniquement lorsque les expéditeurs externes utilisent réellement le nouveau chemin. Il faut donc vérifier l’enregistrement MX, le DNS TTL, la joignabilité externe et le rollback avant le passage en production.

Avant le changement :

Documenter l’enregistrement MX actuel, la priorité et le TTL.
Réduire le DNS TTL suffisamment tôt si un retour rapide peut être nécessaire.
Distinguer clairement l’ancien chemin mail et la nouvelle adresse Sophos Firewall.
Identifier les anciennes règles DNAT directes vers le serveur de messagerie.
Définir les destinataires et expéditeurs de test.
Définir le plan de retour arrière : ancien MX, ancienne règle DNAT ou smarthost temporaire.
Préparer le monitoring du spool, de la quarantaine et de la queue du serveur de messagerie.

Contrôles externes utiles depuis un système hors du réseau propre :

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Ces commandes ne remplacent pas un test complet du mailflow, mais montrent rapidement si DNS, port 25 et STARTTLS sont globalement joignables. example.com et mail.example.com doivent être remplacés par le domaine réel et l’hôte mail réel.

Après le basculement, il faut envoyer immédiatement un email de test entrant et documenter tout le chemin :

Connexion visible dans Log Viewer ?
Entrée présente dans smtpd_main.log ?
Vérification du destinataire réussie ?
Remise au serveur de messagerie interne effectuée ?
Message arrivé dans la boîte aux lettres ?
Pas de remise directe parallèle contournant le MTA ?

Si le pare-feu accepte les emails mais ne les remet pas, il ne faut pas remettre immédiatement le MX en arrière. Il faut d’abord clarifier s’il s’agit d’un problème interne de routage, DNS, TLS ou serveur de messagerie. Mais si les expéditeurs externes ne peuvent pas établir de connexion au pare-feu ou si des emails légitimes sont largement refusés, un retour rapide au chemin mail précédent est souvent plus judicieux que de longues expérimentations dans le chemin MX productif.

Activer le MTA mode

Les paramètres de base se trouvent dans Sophos Firewall sous :

Email > General settings

C’est là que le mode email est défini. Pour ce guide, MTA mode est pertinent. Après le changement, il faut vérifier si les policies, objets hôtes et domaines mail existants correspondent encore au fonctionnement souhaité.

Dans les environnements existants, ne pas basculer simplement entre Legacy mode et MTA mode sans tester le mailflow. Le traitement, les logs et la logique de policy diffèrent. Avant une migration, la configuration actuelle du pare-feu, les enregistrements MX, les connecteurs du serveur de messagerie et les paramètres de relais doivent être documentés.

Configurer le routage SMTP et les domaines

Pour les emails entrants, le pare-feu doit savoir quels domaines il doit accepter et où il doit les remettre.

Déroulement typique :

Sous Email > Policies and exceptions ou dans les zones Mail Protection, planifier les domaines et serveurs cibles concernés.
Saisir le domaine mail, par exemple example.com.
Définir le serveur de messagerie interne ou l’objet hôte comme cible de remise.
Vérifier si le pare-feu atteint le serveur de messagerie sur le port cible.
Vérifier les exigences TLS et les certificats.
Envoyer un email de test depuis l’externe à un destinataire connu.

Le DNS est particulièrement important pour les serveurs de messagerie internes. Le pare-feu doit pouvoir résoudre correctement les cibles internes, et les expéditeurs externes doivent atteindre l’entrée MX publique. Si la résolution DNS interne joue un rôle, Configurer DNS Request Routes sur Sophos Firewall aide.

Planifier les policies pour le spam, les malwares et les pièces jointes

Mail Protection n’est aussi efficace que les policies qui s’appliquent réellement. Une policy ne doit pas seulement être créée, mais nommée avec un objectif clair.

Questions importantes sur les policies :

Quels domaines ou groupes de destinataires sont concernés ?
Le trafic mail entrant, sortant ou bidirectionnel est-il traité ?
Que se passe-t-il en cas de spam, malware, pièces jointes suspectes ou types de fichiers indésirables ?
Les emails sont-ils bloqués, mis en quarantaine, remis ou marqués avec des en-têtes ?
Qui peut vérifier la quarantaine et libérer des emails ?
Quels processus de faux positifs existent ?

Si Zero-Day Protection est utilisé, les pièces jointes suspectes peuvent être analysées en plus. Les limites, rapports et décisions de libération sont expliqués dans Comprendre et exploiter Sophos Firewall Zero-Day Protection.

Sécuriser le relais et Device Access

Une erreur fréquente consiste à confondre mailflow MTA et relais SMTP ouvert. Le pare-feu ne doit pas pouvoir être utilisé comme relais depuis des réseaux arbitraires.

Vérifier :

Sous Administration > Device access, SMTP Relay est joignable uniquement depuis les zones internes nécessaires.
Si des ACL Exception Rules sont utilisées, les sources sont définies de manière stricte.
Seuls les serveurs de messagerie internes, scanners ou serveurs applicatifs définis peuvent relayer via le pare-feu.
Depuis WAN, les réseaux invités et les zones untrusted, SMTP Relay n’est pas autorisé globalement.
La journalisation est active afin que les abus ou mauvaises configurations soient visibles.

Si des imprimantes, scanners ou applications doivent envoyer des emails, il faut documenter pour cela un chemin de relais interne dédié. Ces systèmes ne doivent pas communiquer directement avec n’importe quelles destinations SMTP externes si l’environnement peut l’éviter.

Tester le mailflow

Après la configuration, un seul envoi réussi ne suffit pas. Plusieurs tests doivent être effectués et les résultats documentés.

Tester l’entrant

Vérifier au minimum :

L’enregistrement MX externe pointe vers l’adresse attendue.
Le port 25 est joignable depuis l’extérieur.
Le pare-feu accepte la connexion en MTA mode.
L’email est transféré au serveur de messagerie interne.
Le destinataire existe et reçoit le message.
Le test spam ou malware est traité comme attendu.
L’entrée de quarantaine ou de log est traçable.

Tester le sortant

Vérifier au minimum :

Le serveur de messagerie interne envoie par la route attendue.
La règle de pare-feu et la mail policy s’appliquent.
SPF, DKIM et DMARC correspondent au chemin d’envoi.
Le serveur cible accepte le message.
Les bounces ou messages Deferred sont surveillés.
Aucun autre système interne n’envoie directement vers l’extérieur de façon non planifiée.

Vérifier les logs

Pour un contrôle visuel rapide, Log Viewer aide. Pour une analyse plus profonde, les fichiers de logs mail sont importants. La correspondance est indiquée dans Dépannage Sophos Firewall : services et logs.

Fichiers de logs pertinents :

Domaine	Fichier de log typique
SMTP MTA	`smtpd_main.log`
Erreurs SMTP	`smtpd_error.log`, `smtpd_panic.log`, `smtpd_reject.log`
Anti-Spam	`sasi.log`
Legacy SMTP/MTA	`awarrensmtp.log`, `awarrenmta.log`, `awarrenmta_debug.log`
POP/IMAP Proxy	`warren.log`

En dépannage urgent, il faut noter l’heure du test, collecter expéditeur, destinataire, objet, IP source et Message-ID, puis corréler Log Viewer et fichiers de logs dans le temps.

Quarantaine, spool et stockage

Mail Protection génère des données locales. Selon le volume, les messages arrivent dans la quarantaine, le spool ou des zones temporaires. L’espace de stockage, l’état du SSD et le plan de recovery deviennent donc plus importants qu’avec une simple règle de pare-feu.

Questions pratiques d’exploitation :

Qui vérifie la quarantaine et à quelle fréquence ?
Comment les faux positifs sont-ils libérés ?
Quand un message est-il supprimé plutôt que libéré ?
Comment un mail spool en croissance est-il détecté ?
Existe-t-il un monitoring de l’espace de stockage et du System Health ?
Un bref test du mailflow est-il prévu après les mises à jour de firmware ?

Pour les sujets de stockage et de reporting, Nettoyer le stockage et les rapports Sophos Firewall et Vérifier le SSD Health de Sophos Firewall conviennent. Dans les environnements HA, il faut aussi noter que la quarantaine mail et les données mail traitées peuvent être des données d’exploitation liées au noeud. Les bases HA sont décrites dans Variantes de cluster HA Sophos Firewall.

Dépannage

Les emails externes n’arrivent pas

Vérifier d’abord DNS et joignabilité : enregistrement MX, IP publique, port 25, anciens éléments NAT, MTA mode et domaine mail responsable. Vérifier ensuite dans Log Viewer et dans smtpd_main.log si la connexion atteint le pare-feu. Si aucune connexion n’est visible, le problème se situe probablement avant Mail Protection.

Le pare-feu accepte les emails, mais ne les remet pas

Le serveur de messagerie interne, le routage, DNS, le port cible, TLS, la vérification du destinataire ou la policy sont alors plus probables. Il faut vérifier si le pare-feu peut atteindre le serveur de messagerie et si celui-ci accepte la connexion. Les reject logs et les logs du serveur de messagerie doivent être évalués ensemble dans le temps.

Beaucoup d’emails restent dans le spool

Un spool qui grossit indique souvent des problèmes de remise : serveur de messagerie interne non joignable, exigence TLS inadéquate, échec de résolution DNS ou refus du message par le serveur cible. Dans ce cas, il ne faut pas seulement remettre des messages isolés, mais chercher la cause dans le chemin de routage et SMTP.

Un cas important d’ordre des règles est facile à manquer : si une règle de pare-feu créée automatiquement ou manuellement se trouve au-dessus de la règle MTA et matche le trafic SMTP, la règle MTA réelle n’est plus évaluée. Des emails peuvent alors rester bloqués dans le mail spool même si DNS, le port 25 et le serveur de messagerie semblent globalement corrects.

Vérifier :

Ouvrir Rules and policies > Firewall rules.
Vérifier les règles au-dessus de la règle MTA ou SMTP.
Contrôler les nouvelles règles automatiques, règles IPsec, règles hotspot ou règles placées manuellement sur Top.
Réaliser à nouveau le test SMTP et comparer Log Viewer, mail spool et smtpd_main.log.

La règle ne doit pas être déplacée aveuglément vers le bas si elle remplit d’autres objectifs productifs. Le point décisif est de savoir si elle intercepte de manière inattendue le trafic SMTP avant la règle MTA.

Digest de quarantaine manquant pour les adresses alias

Si les utilisateurs emploient des adresses alias, il ne faut pas vérifier les paramètres de quarantaine uniquement pour l’adresse email primaire. Selon Sophos, les paramètres de quarantaine ne sont pas appliqués automatiquement par défaut aux adresses alias. Si des emails digest ou des libérations manquent pour des destinataires alias, les adresses alias doivent être prises en compte avec l’adresse primaire dans le contexte de quarantaine ou d’utilisateur.

Un expéditeur légitime est reconnu comme spam

Les faux positifs ne doivent pas être traités immédiatement par de larges exceptions. Vérifier d’abord le domaine expéditeur, SPF/DKIM/DMARC, les en-têtes, la réputation, le match de policy et les destinataires concernés. Si une exception est nécessaire, elle doit être strictement limitée et documentée avec une date de revue.

Les systèmes internes ne peuvent pas relayer

Vérifier si SMTP Relay sous Administration > Device access est autorisé depuis la bonne zone et si la source correspond à l’ACL. Vérifier ensuite les logs mail. Si un scanner ou une application doit relayer, la source doit être documentée comme objet hôte, et il ne faut pas autoriser inutilement tout un réseau.

Le comportement mail change après une mise à jour de firmware

Après les mises à jour de firmware, MTA mode, policies, certificats, mail spool, quarantaine et logs pertinents doivent être vérifiés. Pour les mises à jour plus importantes, Vérifier Sophos Firewall avant la mise à niveau SFOS 22 convient également.

Checklist d’exploitation

Licence Mail Protection et prise en charge appliance vérifiées.
MTA mode choisi consciemment et documenté.
Enregistrement MX, IP publique et serveur cible interne corrects.
Changement MX, tests externes et rollback préparés.
Aucune règle DNAT parallèle non filtrée ne contourne le MTA.
Policies entrantes et sortantes nommées de manière compréhensible.
L’ordre des règles de pare-feu n’empêche pas la règle MTA de s’appliquer.
SMTP Relay autorisé uniquement depuis des sources internes définies.
Processus de quarantaine et de faux positifs défini.
Adresses alias prises en compte dans le processus de quarantaine et de digest.
Mail spool, espace de stockage et System Health surveillés.
Logs conservés assez longtemps localement, dans Sophos Central ou via Syslog.
Un test du mailflow est effectué après les mises à jour de firmware.

Pour une conservation plus longue et une corrélation avec d’autres événements de sécurité, il faut vérifier Central Firewall Reporting ou Envoyer le Syslog Sophos Firewall vers un SIEM.

FAQ

Qu'est-ce que le MTA mode sur Sophos Firewall ?

En MTA mode, Sophos Firewall fonctionne comme Mail Transfer Agent. Il accepte les messages SMTP, les contrôle avec Mail Protection, puis les remet au serveur de messagerie interne ou au prochain mailhop.

Faut-il une licence dédiée pour Mail Protection ?

Oui. Mail Protection nécessite une autorisation Email Protection adaptée ou un bundle qui contient cette fonction. Sans licence, la protection mail MTA ne doit pas être planifiée comme chemin de protection productif.

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

Non. Sophos Firewall Mail Protection s’exécute sur le pare-feu dans le mailflow. Sophos Central Email est une passerelle de messagerie cloud. Les deux approches peuvent viser des objectifs similaires, mais elles sont différentes sur le plan architectural et ne doivent pas être combinées sans planification.

Sophos Firewall peut-il être utilisé abusivement comme SMTP Relay ?

Le risque apparaît lorsque SMTP Relay est autorisé trop largement. C’est pourquoi SMTP Relay sous Administration > Device access ne doit être autorisé que depuis des sources internes clairement définies.

Pourquoi des emails restent-ils bloqués dans le mail spool ?

Le serveur de messagerie interne, DNS, TLS ou le routage sont souvent impliqués. Il faut aussi vérifier si une règle de pare-feu de priorité supérieure matche le trafic SMTP avant la règle MTA. Dans ce cas, la règle MTA réelle n’est pas évaluée.

Où voit-on les problèmes avec MTA et SMTP ?

D’abord dans Log Viewer, puis dans les logs mail sous /log, surtout smtpd_main.log, smtpd_error.log, smtpd_reject.log et sasi.log. En cas de problèmes de remise, les logs du serveur de messagerie interne doivent aussi être vérifiés.