Configurer Mail Protection sur Sophos Firewall en mode Legacy

En Legacy mode, Sophos Firewall fonctionne comme un proxy de messagerie transparent. Le serveur de messagerie interne reste l’endpoint SMTP réel ; le firewall transmet le trafic au moyen des règles firewall et NAT existantes tout en recherchant le spam, les malwares, les types de fichiers ou les correspondances Data Control.

Ce fonctionnement est fondamentalement différent du MTA mode. Le firewall ne devient pas un Mail Transfer Agent, ne prend pas en charge la distribution des messages pour les domaines protégés et ne fournit pas de MTA mail spool pour ce chemin. Un test de port SMTP réussi ne prouve donc ni l’analyse par le proxy ni l’application de la bonne politique.

⚠️ La modification du SMTP Deployment Mode est un changement global du chemin de protection de la messagerie. Avant la commutation, il faut documenter le backup, les politiques existantes, les règles firewall et NAT ainsi qu’un chemin de secours testé. Un problème MTA ne justifie pas de passer au Legacy mode sans planification.

Legacy mode en neuf étapes

1. Documenter le chemin SMTP entrant et sortant existant avec les adresses IP, les ports, le NAT et les Firewall Rule IDs.
2. Vérifier si le fonctionnement en proxy transparent convient réellement mieux que le MTA mode.
3. Garantir un backup de configuration et un accès d’administration indépendant.
4. Sous Email > General settings, sélectionner Switch to legacy mode.
5. Définir le SMTP hostname, les limites de taille, l’action pour les messages surdimensionnés, IP Reputation, les limites DoS, les ports et le comportement TLS.
6. Créer uniquement les politiques SMTP malware et SMTP spam nécessaires, ou vérifier leur ordre.
7. Limiter les chemins DNAT entrants et SNAT sortants au serveur de messagerie réel.
8. Activer Scan SMTP ou Scan SMTPS dans les règles firewall qui correspondent réellement.
9. Valider les messages de test entrants et sortants avec la Rule ID, le résultat de la politique, le certificat et les logs du proxy Legacy.

Choisir entre Legacy mode et MTA mode

Legacy mode convient principalement aux environnements existants dans lesquels le serveur de messagerie interne est déjà publié directement par NAT et où ce chemin doit être conservé. SFOS se place de manière transparente entre le peer distant et le serveur. La cible MX, l’acceptation SMTP et la logique de distribution restent intégrées à la conception existante du serveur de messagerie.

MTA mode constitue le meilleur choix lorsque le firewall doit accepter lui-même les messages, les router par domaine protégé, les relayer et les conserver dans un spool en cas d’échec temporaire de distribution. Mail logs et mail spool appartiennent explicitement à ce modèle d’exploitation. La configuration complète est décrite dans Configurer Mail Protection en MTA mode.

Selon l’aide SFOS 22, MTA mode n’est pas disponible sur les XGS 87/87w et XGS 88/88w. Cela ne fait toutefois pas automatiquement de Legacy mode une bonne architecture de messagerie cloud. Microsoft 365, Google Workspace et les services hébergés modernes imposent leurs propres exigences en matière de TLS, d’authentification et de protection contre les abus. Leur compatibilité avec un proxy transparent doit être vérifiée au préalable.

En bref : MTA mode possède son propre flux de messagerie. Legacy mode protège un chemin SMTP qui fonctionne déjà. Mélanger ces deux modèles conduit à chercher dans le mauvais log, sur la mauvaise destination NAT ou dans un spool inexistant.

Topologie d’exemple et chemin de secours

L’exemple suivant utilise des valeurs de documentation et doit être adapté à l’environnement réel avant sa mise en œuvre :

• serveur de messagerie interne 10.20.30.25 dans la zone DMZ
• adresse SMTP publique 192.0.2.25 sur le chemin WAN
• service SMTP entrant TCP 25
• SMTPS facultatif sur TCP 465, uniquement si les peers et le serveur utilisent réellement cette variante
• règles firewall SMTP_In_Legacy et SMTP_Out_Legacy

192.0.2.25 appartient à la plage TEST-NET et n’est pas une valeur de production. Avant le changement, effectuer un test entrant externe et un test sortant avec horodatage. Conserver les Rule IDs actuellement utilisées, l’adresse source publique employée par le serveur sortant et la chaîne de certificats.

Le chemin de secours ne se limite pas à rétablir le mode précédent. Il faut également pouvoir restaurer l’état documenté des nouvelles options d’analyse, de l’ordre des politiques, du DNAT, des règles SNAT réflexives ou manuelles et des tests temporaires.

Définir les paramètres de messagerie globaux

Lorsque MTA mode est disponible, l’aide le présente comme mode par défaut. Sous Email > General settings, sélectionner délibérément Switch to legacy mode après avoir sécurisé le chemin de secours documenté. Le changement de mode seul ne crée pas un chemin de messagerie Legacy validé.

Sous Email > General settings, SMTP hostname s’applique uniquement aux notifications générées par le système dans les chaînes HELO et de bannière SMTP ; sa valeur par défaut est SMTP. Il ne remplace ni le FQDN du serveur de messagerie de production ni son DNS public. S’il est modifié, il faut valider une notification SFOS et pas seulement un message normal généré par le serveur.

Vérification de l’API XML : La documentation SFOS 23 répertorie le statut d’opération 506 pour Email Configuration, associé à Message.AVGeneralConfInvalidSmtpNtfyHostname. Il s’agit d’une clé de message non résolue, et non d’un message d’erreur en anglais ou d’un code de statut HTTP. Si ce statut apparaît dans la réponse réelle de l’API XML, vérifier le nom d’hôte envoyé pour les notifications, la réponse de l’opération et la configuration enregistrée avant de considérer la modification comme réussie. La clé ne permet pas de déduire des règles de validation précises. L’entrée supplémentaire dans la documentation ne prouve ni que ce comportement a été introduit avec SFOS 23 ni qu’il s’applique à REST.

Limite de taille, action sur les messages surdimensionnés et protection DoS

Sous Email > General settings > SMTP settings, Don’t scan emails greater than définit la taille maximale des messages à analyser. Sur le chemin SMTP, la valeur 0 signifie 51,200 KB selon l’aide SFOS 22, et non une taille illimitée. Les options disponibles pour les messages plus volumineux sont Accept, Reject et Drop.

Accept distribue un message surdimensionné sans l’analyser. Reject le refuse et informe l’expéditeur, tandis que Drop le rejette sans notification. Ce choix est une décision délibérée en matière de risque et d’exploitation. Un Drop non testé complique le diagnostic ; un Accept non évalué crée une lacune d’analyse qui doit être documentée.

Verify sender’s IP reputation vérifie l’adresse IP de l’expéditeur avant les critères antispam de la politique SMTP et rejette les messages provenant d’adresses IP de mauvaise réputation. Les six champs SMTP DoS acceptent les plages suivantes dans SFOS 22 :

• Maximum connections : 1 à 20000 connexions au serveur de messagerie
• Maximum connections/host : 1 à 10000 connexions d’un hôte
• Maximum emails/connection : 1 à 1000 messages par connexion
• Maximum recipients/email : 1 à 256 destinataires par message
• Emails rate : 1 à 20000 messages d’un hôte par minute
• Connections rate : 1 à 20000 connexions d’un hôte par seconde

Une valeur admise n’est pas automatiquement appropriée. Les limites de production sont déduites du volume réel et d’une baseline afin que les pics d’envoi légitimes ne soient pas traités comme un DoS.

Bypass spam check for SMTP/S authenticated connections ignore globalement le contrôle antispam pour les connexions que le serveur de messagerie signale comme authentifiées. Ce choix n’est acceptable qu’après vérification de l’authentification, des sources autorisées et de la protection contre les abus de ce chemin. Une authentification réussie ne remplace ni l’analyse antimalware ni un test négatif avec une connexion non authentifiée. Les domaines sous Spam check exceptions constituent également un contournement global et ne servent pas de remplacement rapide à une exception étroitement limitée.

La bannière globale propose Inline, no conversion, MIME part et Off. Inline, no conversion ajoute le texte directement aux messages sortants ; MIME part l’ajoute sous forme de partie MIME distincte. Off n’ajoute aucune bannière. Saisir uniquement du texte dans Email banner, par exemple un bref avis de confidentialité. La bannière exige l’analyse SMTP ou SMTPS dans la règle correspondante. Vérifier un message en texte brut et un message HTML chez le destinataire pour contrôler le contenu, la structure MIME et la présentation. Comme modifier le corps peut invalider une signature DKIM existante, vérifier également les en-têtes du chemin sortant réel.

Planifier séparément POP/IMAP et les ports

POP/IMAP dispose de sa propre sélection de CA TLS certificate sous POP and IMAP TLS configuration. Laisser Allow invalid certificate désactivé pour rejeter les certificats serveur non valides ; ici aussi, Disable legacy TLS protocols bloque uniquement les protocoles antérieurs à TLS 1.1. Les paramètres SMTP ne remplacent pas cette configuration. Le parcours de récupération est décrit dans Analyse des e-mails POP/IMAP, et l’administration des CA et certificats dans Gestion des certificats.

Le Legacy mode couvre également l’analyse transparente POP3/S et IMAP/S. Sous POP/S and IMAP/S settings, 0 pour Don’t scan emails greater than signifie 10,240 KB. Recipient headers détermine dans quels headers SFOS recherche les destinataires utilisés par les politiques POP/IMAP ; les valeurs par défaut sont Delivered-To, Received et X-RCPT-TO. Elles ne sont modifiées que si un header capturé du serveur utilisé le justifie.

Les ports standard documentés sont SMTP 25, SMTPS 465, POP3 avec STARTTLS 110, POP3S 995, IMAP avec STARTTLS 143 et IMAPS 993. SFOS peut également analyser les e-mails sur d’autres ports ; l’aide mentionne explicitement le port 587. Un port alternatif doit figurer comme service dans la règle firewall correspondante et être associé au protocole d’analyse réellement activé. Changer seulement le port ne transforme pas TLS implicite en STARTTLS, ni l’inverse.

Une politique POP-IMAP scan peut associer des groupes d’expéditeurs et de destinataires à des critères tels que la classification entrante, l’adresse IP source, la taille du message ou un en-tête. Les seules actions disponibles sont Accept et Prefix subject. La politique n’active pas elle-même le proxy : dans Scan email content de la règle firewall correspondante, il faut également sélectionner le protocole POP3, POP3S, IMAP ou IMAPS réellement utilisé.

Ne pas surestimer TLS à cause d’une case à cocher

Sous SMTP TLS configuration, sélectionner le certificat CA ou serveur destiné à l’analyse. Allow invalid certificate reste désactivé. Selon l’aide, Disable legacy TLS protocols désactive uniquement les protocoles antérieurs à TLS 1.1 et ne prouve pas l’établissement d’une session TLS 1.2 ou TLS 1.3 précise.

Sophos signale également une limite importante du mode Legacy : le firewall établit la connexion TLS à partir de l’adresse IP du domaine plutôt que de son nom. Si plusieurs domaines partagent une même adresse IP, la validation du certificat peut échouer. Dans ce cas, Sophos recommande un autre chemin de protection, comme Sophos Email Security. Il ne faut pas contourner la vérification avec Allow invalid certificate.

Require TLS negotiation impose TLS pour les Remote Hosts ou réseaux sélectionnés ; Require sender email domains l’impose pour les domaines expéditeurs. Si la connexion TLS ne peut pas être établie, SFOS élimine les messages concernés. Skip TLS negotiation autorise intentionnellement des connexions SMTP non chiffrées avec les peers sélectionnés et doit être réservé à des exceptions documentées. Selon l’aide, chaque champ accepte jusqu’à 512 entrées d’hôte ; il faut exclure tout chevauchement entre les listes d’obligation et de contournement avant d’utiliser de larges sélections.

Utiliser les politiques d’analyse de manière ciblée

Sans abonnement Email Protection valide, le trafic de messagerie peut rester autorisé, mais ne bénéficie pas d’Email Protection. L’accessibilité ne prouve donc ni la licence ni l’analyse. Les paramètres globaux sont traités avant les politiques SMTP et POP-IMAP. Sous Email > General settings > SMTP settings, activer la réputation IP en Legacy mode avec Verify sender’s IP reputation, puis enregistrer avec Apply ; le contrôle MTA s’appelle Reject based on IP reputation. La bannière globale des e-mails sortants ne prend en charge que du texte.

Après l’activation de l’abonnement Email Protection, Sophos Firewall applique automatiquement la politique par défaut default-smtp-av au trafic SMTP en Legacy mode. Les politiques personnalisées sont créées sous Email > Policies et traitées dans l’ordre de la liste. Il faut donc commencer par vérifier quelle politique existante correspond à l’expéditeur et au destinataire concernés.

Créer les nouvelles politiques SMTP en mode Legacy sous Email > Policies > Add policy, en choisissant SMTP malware scan ou SMTP spam scan. Pour modifier une politique existante, ouvrir Email > Policies, sélectionner Edit pour la politique concernée, modifier les paramètres nécessaires et enregistrer la politique. Vérifier ensuite à nouveau l’ordre des politiques et répéter le test positif ainsi que le test négatif.

Sous Email > General settings > Malware protection, le moteur antivirus principal est sélectionné globalement entre Sophos et Avira. Si Avira est choisi, SFOS désactive Zero-day Protection dans les politiques SMTP utilisant Single antivirus. Il faut inventorier toutes les politiques concernées avant de changer de moteur, puis les valider à nouveau.

SMTP malware scan

Modifier l’ordre par glisser-déposer dans la liste des politiques. Noter la position précédente et répéter ensuite les deux tests : une politique pilote limitée ne doit pas être masquée par une politique plus large qui correspond déjà.

Lors de la création, définir un nom clair et les groupes d’adresses e-mail ou de domaines des expéditeurs et destinataires. Sous Block file types, sélectionner les pièces jointes à bloquer ; Ctrl+Shift permet de choisir plusieurs types. MIME whitelist autorise les en-têtes MIME sélectionnés, tandis que les autres types sont bloqués selon l’aide. Cette autorisation de types de fichiers ne contourne pas l’antivirus. Disable, en revanche, signifie explicitement que les e-mails ne sont pas analysés.

Delivery option for recipient s’applique aux pièces jointes infectées, protégées et suspectes :

• Don’t deliver : ni le message ni une notification ne sont envoyés au destinataire.
• Deliver original : envoie le message original au destinataire, sans le nettoyer.
• Remove and deliver : supprime la pièce jointe infectée, notifie sa suppression et livre le message. Cette action ne s’applique pas aux types définis sous Block file types ; cela ne permet pas de déduire une autre action de livraison pour les types bloqués.

Les pièces jointes protégées ne sont pas analysées ; une notification au destinataire est prévue par défaut, sauf configuration contraire. Enregistrer avec Save et vérifier les résultats réels de livraison et de notification avec des cas positifs et négatifs inoffensifs.

Une politique SMTP malware scan contrôle les types de fichiers bloqués, les exceptions MIME, l’analyse antivirus et les actions de distribution. Avec Single antivirus, le moteur sélectionné ne s’applique selon l’aide qu’aux messages entrants ; les messages sortants sont analysés par les deux moteurs. Dual antivirus exécute successivement le moteur principal et le moteur secondaire.

L’action Quarantine est combinée aux actions destinées au destinataire et à l’administrateur. Don’t deliver, Deliver original et Remove and deliver produisent des résultats très différents. Une pièce jointe protégée ou non analysable ne doit pas être assimilée automatiquement à un malware. Chaque action nécessite donc un message de test, un état attendu pour le destinataire et un chemin de libération documenté.

Quarantine ne signifie pas automatiquement que le destinataire ne reçoit aucun message ; la Delivery option for recipient reste déterminante. Selon Sophos, Notify sender fonctionne uniquement avec Don’t deliver. Les pièces jointes protégées ne sont pas analysées, mais peuvent déclencher une notification. Sous Delivery option for administrator, Don’t deliver ne notifie pas les administrateurs ; Send original leur envoie le message original. Celui-ci peut contenir des pièces jointes dangereuses ou non analysées et ne remplace pas une notification sûre. Vérifier séparément les résultats pour l’expéditeur, le destinataire, l’administrateur et la quarantaine.

⚠️ Remove attachment sous Delivery option for administrator est exclu de ce guide : le nom du champ suggère une action administrateur, mais sa description mentionne un message sans pièce jointe au destinataire et une notification de suppression aux administrateurs. Cela ne définit pas une affectation de livraison sûre. Ne pas activer cette option pour la première fois en production. Pour un pilote isolé de pièces jointes infectées, utiliser Don’t deliver pour les destinataires et les administrateurs, surveiller séparément la quarantaine et vérifier avec des motifs de test inoffensifs. Ne modifier un réglage existant Remove attachment qu’après clarification documentée avec Sophos Support et vérification contrôlée ; ne présumer ni innocuité ni nettoyage automatique.

Un pilote limité plutôt qu’une politique d’exemple non vérifiée

Pour le serveur 10.20.30.25, limiter d’abord une politique clairement nommée à un groupe de destinataires de test du domaine d’exemple example.net ; remplacer domaine et groupe par des valeurs propres contrôlées. Si le domaine manque dans le carnet d’adresses, l’ajouter avec Create new. Sous Block file types, choisir par exemple Executable files, sélectionner Dual antivirus et Quarantine, puis prévoir séparément les actions destinataire et administrateur indiquées ci-dessus. N’ajouter une autorisation MIME que si elle est justifiée. Une pièce jointe protégée reste non analysée ; ne pas copier aveuglément Send original pour ces pièces depuis une politique d’exemple.

La limite d’exemple 2048 KB relève de Don’t scan emails greater than dans les paramètres SMTP globaux, et non de la politique pilote ou d’une valeur par défaut fixe. Elle limite l’analyse aux petits messages. Avant de l’adopter, prévoir l’action sur les messages surdimensionnés et un test juste au-dessus de la limite selon le volume réel ; sinon Accept crée une lacune d’analyse, ou Reject et Drop causent des problèmes de livraison. Les politiques SMTP spam et POP/IMAP personnalisées sont des compléments facultatifs selon les besoins, pas des prérequis pour simplement créer le chemin NAT.

SMTP spam scan

Définir un nom et les groupes d’adresses e-mail ou de domaines des expéditeurs et destinataires. Choisir délibérément une correspondance exacte ou par mot-clé pour ces groupes : la recherche par mot-clé ne doit pas élargir involontairement le périmètre. Ne pas supposer de syntaxe regex, de caractères génériques ou de règles AND/OR non documentées.

• Inbound email is et Outbound email is : choisir séparément le sens ; les critères sont spam, probable spam, virus outbreak ou probable virus outbreak.
• Source IP/network address et Destination IP/network address : indiquer l’IP ou le réseau requis de l’expéditeur ou du destinataire.
• Sender remote blacklist : sélectionner le groupe RBL approprié pour l’expéditeur.
• Message size : définir une limite supérieure ou inférieure ; ne pas la confondre avec la limite globale des messages surdimensionnés.
• Message header : sélectionner l’en-tête ; pour Other, saisir les détails, choisir la correspondance exacte ou par mot-clé et préciser la valeur du mot-clé.

Reject refuse le message et informe l’expéditeur. Accept le livre. Prefix subject ajoute un préfixe à l’objet et livre également le message ; par exemple, Probable spam identifie un test contrôlé. Drop supprime sans avertir l’expéditeur ; Quarantine conserve le message en quarantaine. Le choix d’un modèle SPX est documenté pour Accept et Prefix subject, exclusivement pour les e-mails sortants. Cela ne prouve ni la prise en charge SPX des autres actions ni le chiffrement automatique de chaque message accepté. Enregistrer avec Save et vérifier séparément correspondance et action.

Une politique SMTP spam scan peut correspondre à la classification du spam, à la source ou à la destination, à une RBL, à la taille du message, aux headers ou à une Data Control List. Selon le chemin, les actions disponibles sont Reject, Accept, Change recipient, Prefix subject, Drop et Quarantine.

Le critère Data control list et l’affectation SPX de cette politique s’appliquent uniquement aux messages sortants. None applique en revanche l’action sélectionnée à tous les messages entre les groupes d’expéditeurs et de destinataires définis. Change recipient remplace le destinataire d’origine par la destination configurée ; le message n’est pas également remis au destinataire d’origine. Ces trois portées sont testées avec un cas destinataire positif et un cas négatif avant le classement de la politique en production.

Préparer des types de fichiers personnalisés et Data Control

Les catégories de fichiers prédéfinies pour la messagerie sont Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files et Web files. Elles classent les fichiers par extension ou en-tête MIME, sans garantir leur innocuité. Par exemple, Executable files contient exe, cmd, bat et com ; pdf figure dans Document files et Page layout files, et application/octet-stream apparaît dans plusieurs catégories. Ne pas considérer ces catégories comme mutuellement exclusives ni autoriser largement un en-tête MIME générique pour résoudre le cas d’une seule pièce jointe. La référence interne détaillée se trouve dans Web Protection ; vérifier les valeurs sur l’installation cible avant de choisir un modèle ou de définir un type personnalisé restreint.

Les CCL peuvent détecter des motifs tels que numéros de carte bancaire ou de sécurité sociale, adresses postales et adresses e-mail. Utiliser des données synthétiques pour le pilote, jamais de véritables données personnelles. Inclure uniquement les motifs adaptés à la finalité et à la région ; une correspondance ne prouve ni l’authenticité des données ni leur classification juridique.

Nommer le type de fichier personnalisé et enregistrer l’objet avec Save avant de modifier la politique. Le chemin de création MTA distinct est Email > Policies and exceptions > File type > Add ; il ne remplace pas celui de Legacy. Les types de fichiers servent aussi aux politiques web ; leur configuration relève de Web Protection. Donner également un nom clair à la Data Control List et sélectionner Save après le choix des CCL.

En Legacy mode, les types de fichiers personnalisés sont créés sous Email > Policies > File type > Add à partir d’un modèle, d’extensions ou de types MIME. Les extensions sont saisies sans point initial et seuls les types personnalisés sont modifiables. Un nouveau type n’est pas ajouté automatiquement aux policies existantes. Il faut ouvrir la scan policy concernée, y ajouter le type, puis l’enregistrer à nouveau. Un test positif avec une pièce jointe et un test négatif similaire montrent si l’action prévue s’applique réellement.

Une Data Control List est créée sous Email > Data control list > Add à partir des Content Control Lists nécessaires. Les filtres Type et Region aident à ne sélectionner que les modèles pertinents de données financières, d’identité ou d’autres données sensibles. La correspondance de la liste ne définit pas encore l’action ; celle-ci est configurée dans la scan policy associée. Une petite liste pilote avec un test de contenu positif et un test négatif est plus sûre qu’une vaste collection de CCL non vérifiées.

En Legacy mode, SPX peut être sélectionné dans cette politique pour les messages sortants. Le modèle de mot de passe, le portail et la validation constituent toutefois un processus de sécurité distinct ; voir Configurer le chiffrement des e-mails SPX. Aucune Data Control List ni affectation SPX n’est ajoutée au premier test élémentaire du proxy.

Une classification erronée confirmée ne se corrige pas en désactivant une politique de portée étendue. En mode Legacy, adapter de manière ciblée la politique SMTP malware scan ou SMTP spam scan appropriée ; un test positif et un test négatif en dehors du périmètre prévu doivent confirmer l’effet de la modification. Créer et tester en toute sécurité des exceptions de messagerie décrit en revanche exclusivement l’objet d’exception du mode MTA : la source, l’expéditeur ou le destinataire sont des déclencheurs alternatifs (OR), et non une condition AND combinant exactement les trois critères. Cet objet d’exception MTA n’est pas un élément de contrôle du mode Legacy.

Correspondances documentées des types de fichiers

Cette référence conserve les correspondances des catégories de messagerie ; ce n’est ni une liste d’autorisation ni une preuve de malware. Vérifier les valeurs sur l’installation cible avant modification. Les tokens MIME techniques restent inchangés, y compris les graphies documentées inhabituelles comme text/x-script.phyton ; cela ne prouve ni leur conformité aux standards ni une nouvelle règle MIME personnalisée.

Audio files

• Extensions: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
• En-têtes MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv.

Backup files

• Extensions: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• En-têtes MIME: application/octet-stream.

Compressed files

• Extensions: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• En-têtes MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Extensions: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• En-têtes MIME: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

• Extensions: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
• En-têtes MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensions: as, asc, c, cbl, cc, class, cp, cpp, cs, csproj, dev, dtd, f, fs, fsproj, fsx, ftl, gem, h, hpp, ise, ism, java, m, ocx, pas, pod, pro, py, r, rb, sh, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj.
• En-têtes MIME: text/plain, text/x-c, application/java, application/java-byte-code, application/x-java-class, text/xml, text/x-fortran, text/x-h, text/x-java-source, text/x-m, application/octet-stream, text/pascal, text/x-script.phyton, application/x-bsh, application/x-sh, application/x-shar, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl.

Disk image files

• Extensions: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• En-têtes MIME: application/x-cdlink.

Document files

• Extensions: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, thmx, aw, bld, blg, bvp, cdd, cdf, contact, csv, dat, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, mw, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vcf, vdb, vxml, windowslivecontact, wlmp, xfd, xml, xsl, xslt, lit, log, lst, odt, opml, pages, rtf, sig, tex, txt, wpd, wps, pdf.
• En-têtes MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/octet-stream, application/vnd.ms-project, application/x-project, application/vnd.ms-officetheme, application/cdf, application/x-cdf, application/x-netcdf, text/comma-separated-values, text/csv, application/csv, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/tab-separated-values, text/x-vcard, application/xml, text/xml, application/x-ms-reader, text/plain, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf.

Dynamic files

• Extensions: pl, jsp, asp, php, cgi, shtml.
• En-têtes MIME: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

• Extensions: bin, enc, hex, hqx, mim, mime, uue.
• En-têtes MIME: application/mac-binary, application/macbinary, application/octet-stream, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Extensions: exe, cmd, bat, com.
• En-têtes MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

• Extensions: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
• En-têtes MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

• Extensions: idml, indd, inx, isd, mdi, pct, pdf, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• En-têtes MIME: image/x-pict, application/pdf, application/x-mspublisher, application/octet-stream, application/vnd.ms-xpsdocument.

Plugin files

• Extensions: 8bi, arx, crx, plugin, vst, xll.
• En-têtes MIME: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

• Extensions: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, ico, key, lnk, msp, prf, profile, scf, scr, sys.
• En-têtes MIME: application/vnd.ms-cab-compressed, application/octet-stream, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp, image/x-icon.

Video files

• Extensions: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
• En-têtes MIME: application/octet-stream, application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash.

Web files

• Extensions: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• En-têtes MIME: application/atom+xml.

Utiliser la journalisation facultative des e-mails en respectant la protection des données

Donner un nom clair à l’entrée de journalisation et enregistrer la sélection des destinataires ainsi que la destination du journal avec Save avant les tests suivants.

Sous Email > General settings > Email journaling > Add, SFOS peut envoyer les copies des messages SMTP/S entrants de destinataires ou de groupes d’adresses sélectionnés vers une adresse de journalisation distincte. La sélection Any couvre tous les messages entrants. La fonction s’applique uniquement à SMTP/S et ne journalise pas le trafic POP ou IMAP.

La journalisation crée une copie supplémentaire de l’e-mail. Elle ne constitue pas automatiquement une archive inviolable et ne prouve pas le respect des obligations légales de conservation. Avant de l’activer, il faut définir sa finalité, les destinataires autorisés, l’accès à la boîte de journalisation, le chiffrement, la durée de conservation, le stockage nécessaire et le responsable.

Pour le premier test, une seule boîte de test est sélectionnée à la place de Any. Un message entrant destiné à cette boîte doit apparaître dans la destination normale et dans la boîte de journalisation ; un message adressé à un destinataire non sélectionné ne doit pas produire de copie. L’adresse de journalisation ne doit pas déclencher un flux qui renvoie la copie vers SFOS et crée une boucle.

La sélection des destinataires n’est étendue qu’après les tests positif et négatif. Pour le rollback, l’entrée de journalisation est supprimée ou l’état antérieur documenté est restauré. Les copies déjà distribuées restent dans la boîte de journalisation et doivent être traitées selon ses propres règles de conservation.

Associer les objets de messagerie Legacy de manière sûre via l’API XML

Les références de l’API XML pour SFOS 22 et 23 décrivent des objets de messagerie Legacy distincts. Un chemin de menu de MTA Mode, un tableau de paramètres à plat ou un exemple présentant des alternatives séparées par des barres obliques ne constitue pas une requête prête à copier. L’accès à l’API, le transport, le statut des opérations, les clés de message non résolues et le contrôle après écriture sont expliqués dans Sécuriser l’accès à l’API XML. Les correspondances suivantes facilitent la lecture d’une configuration existante ; elles n’affirment pas qu’un appel d’écriture a été testé et ne s’appliquent pas automatiquement à REST ou à la Central API.

Avant toute modification, conserver une sauvegarde, le contenu actuel des objets, les policies qui les référencent et leur ordre. Clarifier la requête précise et les valeurs de champs contradictoires à l’aide de l’aide API du build installé ou auprès de Sophos Support. Vérifier ensuite séparément les objets enregistrés et l’effet réel sur la messagerie. Un champ indiqué comme obligatoire dans le tableau ne permet pas de conclure que l’omission d’autres champs conserve leur valeur antérieure. Cela ne démontre pas non plus le comportement de vidage, de remplacement ou de fusion des listes, ni le caractère atomique des modifications.

EmailConfiguration : le protocole et le contexte TLS font partie du champ

Sous EmailConfiguration, les champs de même nom se distinguent par leurs parents :

• GeneralSettings/EmailSignature et GeneralSettings/EmailBannerMode concernent la bannière sortante. Le tableau API indique les valeurs de mode inline_plain, mimepart et off ; l’exemple contient en revanche des alternatives proches de l’interface utilisateur. Ne pas considérer ces textes comme des valeurs API identiques sans vérification. EmailSignature est une chaîne limitée à 2000 caractères selon le tableau API.
• SMTPSSettings/DontScanEmailsGreaterThan est la limite d’analyse SMTP en KB ; SMTPSSettings/ActionForOversizeEmails est l’action distincte correspondante, Accept, Reject ou Drop. BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings et les six seuils DoS se trouvent également dans SMTPSSettings.
• POPIMAPSettings/DontScanEmailsGreaterThan est une autre limite entière en KB. POPIMAPSettings/RecipientHeaders/Header est une liste de chaînes d’en-tête permettant d’identifier les destinataires, et non une liste de destinataires SMTP.
• SMTPTLSConfiguration et POPSIMAPTLSConfiguration contiennent chacun leurs propres champs TLSCertificate, AllowInvalidCertificate et DisableTLS1. Le certificat SMTP ne remplace pas le certificat POP/IMAP. RequireTLSWithHost, RequireTLSWithSenderDomain et SkipTLSHosts appartiennent au contexte TLS SMTP ; ce sont des listes de chaînes distinctes, et non une exception commune d’activation/désactivation. Ne pas confondre la limite de 512 entrées d’hôtes de l’interface utilisateur avec le maximum de 512 caractères indiqué dans le tableau API.

Distinguer le tableau API, l’exemple et la référence de l’interface utilisateur : le tableau API indique 1024 comme valeur par défaut pour les deux limites d’analyse. Pour MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate et ConnectionsRate, il indique respectivement 5000, 100, 100, 100, 1000 et 100. L’exemple utilise toutefois 1000 pour MaximumEmailsConnection ; l’exemple d’interface utilisateur 2048 KB expliqué plus haut n’est pas non plus une valeur par défaut. La signification de 0 reste celle de la référence d’interface utilisateur propre au protocole décrite plus haut, et non un réglage illimité déduit de l’exemple API.

Le tableau API autorise 1 à 512 pour MaximumRecepientsEmail, tandis que la référence de l’interface utilisateur indique 1 à 256 pour Maximum recipients/email. L’orthographe API MaximumRecepientsEmail reste inchangée ; ne pas en déduire un nom de champ corrigé ni la validité certaine de 512 dans l’interface utilisateur. Les cinq autres plages DoS correspondent aux plages de l’interface utilisateur mentionnées plus haut. L’état enregistré et l’aide du build cible restent déterminants.

D’autres contradictions empêchent de reprendre aveuglément l’exemple : pour VerifySendersIPReputation, le tableau indique on/off et donne Disable comme valeur par défaut, tandis que l’exemple montre Enable. Pour SMTPSDosSettings, le type de données INTEGER côtoie la valeur par défaut Disable du tableau et la valeur Enable de l’exemple. Selon le tableau, BypassSpamCheck a pour valeur par défaut Disable, mais l’exemple l’active. Les deux contextes TLS autorisent les certificats non valides dans l’exemple. Ne pas reprendre ces réglages non sûrs de l’exemple ni construire une charge utile supposée valide à partir des indications contradictoires ; la décision de sécurité relative à TLS et au contournement décrite plus haut reste applicable.

Pour l’opération Email Configuration, les correspondances documentées sont 200 avec Message.AVGeneralConfUpdateSuccess, 500 avec Message.AVGeneralConfUpdateFail et 505 avec Message.ASConfigSubOperationFail. SFOS 23 ajoute la correspondance déjà expliquée plus haut, 506 avec Message.AVGeneralConfInvalidSmtpNtfyHostname. Il s’agit de statuts d’opération et de clés non résolues, et non de codes HTTP ou de textes d’exécution confirmés. En particulier après 505, relire d’abord les paramètres SMTP, POP/IMAP et TLS ; ne présumer ni un retour arrière complet ni un enregistrement complet, et ne pas répéter aveuglément l’opération.

Malware SMTP : traiter indépendamment les destinataires et les administrateurs

L’objet s’appelle AntiVirusMailSMTPScanningRules. Name désigne la policy, et After/Name la référence au prédécesseur présentée dans l’exemple. SenderList/Sender et ReceiverList/Receiver sont des listes distinctes ; BlockFileTypes/FileType est la liste des types de fichiers bloqués. Le tableau API mentionne également WhiteList comme liste MIME, mais l’exemple ne montre pas d’imbrication correspondante. Ne pas en déduire un nœud parent XML supplémentaire.

Pour Scanning, le tableau API indique Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) et Disable, avec Disable comme valeur par défaut. L’exemple Disable/Disable n’est ni une énumération complète ni une valeur utilisable pour l’analyse antivirus souhaitée. Quarantine et NotifySender sont des commutateurs indépendants avec Enable/Disable ; selon le tableau API, leur valeur par défaut est dans les deux cas Disable. Ces valeurs du tableau ne remplacent ni la policy par défaut existante ni une preuve de l’état actuel de l’analyse.

Les pièces jointes infectées, suspectes et protégées disposent chacune de deux actions choisies indépendamment :

• Destinataires : ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment avec Don'tDeliver, DeliverOriginal ou RemoveAndDeliver.
• Administrateurs : NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment avec Don'tDeliver, SendOriginal ou RemoveAttachment.

Le tableau API indique Don'tDeliver comme valeur par défaut pour les six champs d’action. Cela ne doit pas être assimilé à la description, dans l’interface utilisateur, d’une notification par défaut pour les pièces jointes protégées et ne démontre aucun état actuel de remise. Les effets et les limites expliqués plus haut restent déterminants : DeliverOriginal ou SendOriginal peut transmettre des pièces jointes non analysées ou dangereuses ; la mise en quarantaine ne prouve pas que la remise au destinataire a été empêchée. L’option administrateur non clarifiée RemoveAttachment reste exclue, même si l’API la mentionne comme valeur. Contrôler séparément les résultats concernant l’expéditeur, le destinataire, l’administrateur et la quarantaine.

AntiSpamRules : ne pas confondre correspondance, ordre et action

Dans AntiSpamRules, Name identifie la règle. After/Name est la référence présentée dans l’exemple pour positionner cette règle après une autre. Avant Add, Edit ou Order, conserver l’ordre réel et le nom de la règle référencée ; cette documentation ne décrit pas automatiquement une syntaxe pour la première position ou pour des prédécesseurs inexistants.

RecipientList/Action avec RecipientEmail et SenderEmailList/Action avec SenderEmail commandent séparément la correspondance du destinataire et celle de l’expéditeur. Le tableau API indique Equals ou Contains pour les deux actions de correspondance, avec Contains comme valeur par défaut du tableau. Il ne s’agit pas de l’action de remise. MarkSpamIf contient en revanche Condition et les champs correspondants OtherHeader, Operator et MatchIs. Une taille de message nécessite une comparaison de taille ; un en-tête, une correspondance textuelle ; une classification, une valeur de classification. La ligne du tableau à plat décrit MatchIs comme une taille de message entière, mais l’exemple utilise Spam. Ne pas en conclure que tous les types de conditions sont numériques. La valeur 4 du tableau et les différents identifiants de condition de l’exemple ne permettent pas d’inventer une correspondance d’en-tête ou d’énumération.

SMTPAction/Action et SMTPAction/ActionParameter déterminent l’action SMTP et sa valeur complémentaire ; SMTPAction/Quarantine est distinct. POPIMAPAction/Action et POPIMAPAction/ActionParameter appartiennent au chemin de récupération, dont l’exemple ne montre que Accept et Prefix Subject. Ne pas transposer une action SMTP à POP/IMAP. Pour Change recipient, le paramètre est la destination de remise de remplacement, et non une adresse de journalisation supplémentaire. Les restrictions décrites plus haut pour Data Control sortant et SPX restent applicables.

Ici aussi, l’exemple et le tableau se contredisent : pour Quarantine, l’exemple montre Enable/Disable, tandis que le tableau autorise 0 et Enable. Le tableau des actions SMTP mentionne également Accept With SPX ; ne pas déduire cette graphie API du libellé de l’interface utilisateur ou d’un simple Accept. Avant un appel d’écriture, clarifier la valeur précise dépendant de la condition, plutôt que d’envoyer les alternatives de l’exemple séparées par des barres obliques.

Pour Order SMTP Scanning Policy, les correspondances sont 200 avec Message.SpamRuleUpdateRuleOrderSuccess, ainsi que 500 et 505 avec Message.SpamRuleUpdateRuleOrderFail. La même clé désigne donc deux lignes de statut ; elle n’en explique pas la cause. Pour Add SMTP Scanning Policy, 502 avec Message.SpamRuleRecordExists est documenté. Avant un nouvel Add ou Order, vérifier le nom existant, le contenu et l’ordre enregistré ; le contrôle central de sécurité de l’API et les tests positif et négatif de la policy s’appliquent également ici.

DataControlList : les signatures ne constituent pas encore une action de remise

L’objet Legacy DataControlList contient Name et Signatures/Signature, une liste de noms de signatures CCL. Le tableau à plat utilise pour cela les désignations name et signaturename ; ce n’est pas une raison pour renommer silencieusement les balises XML présentées dans l’exemple. Le tableau décrit le nom comme une chaîne obligatoire limitée à 255 caractères et les signatures comme une liste facultative de chaînes. Utiliser le nom réel de la signature provenant de votre propre sélection CCL disponible, sans le copier depuis l’exemple de pays. L’action reste déterminée uniquement par la policy liée. Ne pas utiliser l’autre objet MTADataControlList à la place de cet objet Legacy.

Pour Add Data Control List et Update Data Control List, les deux références mentionnent 502 avec Message.DLPAddSameName ainsi que 545 avec Message.MTAModeDisableCheck. 545 est une correspondance statut/clé documentée, et non une affirmation vérifiée selon laquelle Legacy Mode interdit cette fonction ou qu’un changement de mode serait nécessaire. Ne pas changer de mode pour résoudre l’erreur. Vérifier la liste enregistrée et ses références avant un nouvel Add ou Update, et clarifier la réponse réelle à l’aide de l’aide du build installé ou auprès de Sophos Support.

AVASAddressGroup : exactement une branche dépendant du type

AVASAddressGroup est le groupe d’adresses Legacy pour ces règles de messagerie, et non un objet dont l’équivalence serait démontrée par un chemin de menu MTA. Name identifie le groupe ; le tableau API indique un maximum de 50 caractères, et de 255 pour le champ facultatif Description. Le tableau de GroupType indique RBLIPv4, RBLIPv6, IPAddress et EmailAddressOrDomain, tandis que l’exemple utilise globalement RBL. Ne pas normaliser silencieusement ces graphies.

Le commentaire de l’exemple exige exactement une branche adaptée au type : RBLList/RBLName ou RBLFile, IPAddressList/IPAddressNetwork ou IPAddressFile, ou encore EmailAddressList/EmailAddressDomain ou EmailAddressFile. Les entrées des listes sont des chaînes ; le tableau mentionne plusieurs valeurs et des doublons ignorés. L’exemple présente les alternatives ensemble, mais ne demande pas d’envoyer toutes les listes et tous les fichiers. Pour les groupes d’adresses e-mail/domaines, EmailImportType distingue les valeurs Manual et Import. Le tableau indique les formats csv et txt pour EmailAddressFile, mais décrit de manière contradictoire le champ comme une saisie manuelle ; l’exemple renvoie au nom de fichier d’une requête multipart. Ni l’un ni l’autre ne démontre une association multipart complète ou un appel d’importation sûr. Clarifier ces détails en fonction du build avant toute importation.

Pour Add Address Group, les correspondances documentées sont 502 avec Message.AddrGrpRecordExists, 541 avec Message.AddrGrpImportFailed, 542 avec Message.AddrGrpEmptyFile1 et 543 avec Message.AddrGrpSomeEmailNotImported. Ne déduire des clés non résolues ni les entrées réellement importées ni un retour arrière complet. Comparer les membres enregistrés à la liste prévue avant l’importation suivante.

Pour Delete Address Group, 504, 505 et 506 ont la même clé Message.AddrGrpForeignKeyExists ; 507 est associé à Message.AddrGrpEmailArcKeyExists. Ces clés ne permettent pas de distinguer avec certitude les différents objets qui référencent le groupe. Inventorier les policies et les références de journalisation avant la suppression, examiner la réponse exacte de l’opération et vérifier ensuite la présence du groupe. Ne pas supprimer aveuglément une policy de protection liée pour forcer un appel de suppression.

TrustedDomain, journalisation et sélection du moteur ont des portées différentes

AntiSpamTrustedDomain/DomainList/DomainName est une liste de chaînes de domaines. Add et Delete utilisent DomainName comme identité dans la liste. La description API évoque un contournement de l’analyse pour les messages provenant de domaines de confiance, sans préciser quels moteurs d’analyse sont contournés. L’interface utilisateur décrit Spam check exceptions comme un contournement du contrôle antispam. Ne pas étendre ces deux affirmations à une garantie concernant toutes les analyses ni à une équivalence exacte démontrée entre API et interface utilisateur. Gérer les domaines uniquement dans un but documenté et avec un périmètre restreint ; avant et après Add ou Delete, vérifier la liste et l’effet de protection attendu. Ne pas inventer une requête XML complète absente de la page Delete.

AntiSpamEmailArchiver produit en revanche des copies : Name nomme l’entrée, RecipientList/Recipient limite les destinataires d’origine et SendCopyOfEmailTo est l’adresse de copie distincte. Selon le tableau API, le nom, les destinataires et l’adresse de copie sont obligatoires ; le nom et l’adresse de copie sont limités à 50 caractères. La ligne relative aux destinataires est décrite comme une chaîne scalaire, tandis que l’exemple la présente dans le nœud parent d’une liste. Ne pas résoudre cet écart par une charge utile attrape-tout inventée. Le pilote sur une seule boîte aux lettres décrit plus haut, avec protection des données, prévention des boucles et test négatif, s’applique également à l’automatisation ; une modification du destinataire n’est pas une modification de l’adresse de copie.

MalwareProtection/PrimaryAntiVirusEngine est quant à lui un sélecteur global scalaire de moteur, et non un filtre de destinataires ou une policy d’analyse individuelle. Le tableau API indique Sophos comme valeur par défaut ; l’exemple Sophos/Avira présente des alternatives, et non une valeur combinée à envoyer. L’incidence de Avira sur Zero-day Protection dans les policies SMTP à antivirus unique, expliquée plus haut, reste à vérifier. Contrôler la valeur globale enregistrée et toutes les policies concernées après un changement ; des parcours documentaires distincts n’en font pas des configurations de moteur indépendantes.

Associer NAT et règles firewall

Publier le chemin SMTP entrant

Sous Rules and policies > NAT rules, choisir la famille IP adaptée et ouvrir Add NAT rule. Un objet IP host du serveur interne doit exister sous Hosts and services > IP host pour le sélectionner dans Translated destination (DNAT). Dans l’exemple entrant simple, Translated source (SNAT) et Translated service (PAT) restent Original ; sous Original service, sélectionner uniquement les services SMTP utilisés, par exemple SMTP et SMTP[S]. Vérifier tous les champs avant Save. La traduction de destination NAT ne correspond pas au champ firewall Destination networks, traité séparément ci-dessous.

Pour les messages entrants, une règle DNAT traduit l’adresse WAN publique vers le serveur de messagerie interne. Original Source est limité autant que la conception de messagerie le permet ; Original Destination est l’adresse publique prévue ; Translated Destination est 10.20.30.25 ou le serveur de messagerie réel. Original service et translated service restent limités aux ports SMTP réellement proposés.

Une règle réflexive crée également un SNAT pour le sens inverse. Elle n’est sélectionnée que si cette identité source publique précise est prévue pour le chemin sortant. Plusieurs liaisons WAN, smarthosts ou chemins opérateur différents nécessitent une conception propre du routing et du SNAT. L’ordre général et la zone de destination après NAT sont expliqués dans Publier un serveur avec DNAT.

Utiliser deux règles firewall précises

Pour créer une règle sous Rules and policies > Firewall rules, choisir la famille de protocole réelle IPv4 ou IPv6, puis ouvrir Add firewall rule > New firewall rule. Définir le nom et les champs requis, puis enregistrer avec Save. Ne pas reprendre les adresses IPv4 d’exemple de cet article dans une règle IPv6.

⚠️ Les descriptions de Destination networks se contredisent : l’exemple de messagerie Legacy nomme le serveur interne, alors que le parcours général DNAT fonde la correspondance firewall sur la destination publique d’origine. Ce guide ne tranche pas le cas particulier du proxy par supposition. Documenter la correspondance entrante dont le fonctionnement est déjà prouvé et la conserver pour le pilote. Ne créer aucune nouvelle règle entrante de production à partir de l’une des deux affectations et ne pas changer la destination au hasard. Pour un nouveau chemin, clarifier avec Sophos Support ou une vérification contrôlée adaptée avant validation, avec Rule ID, hit DNAT et captures avant et après traduction. La variante SNAT sortante ne résout pas ce conflit.

Pour la validation, deux règles séparées sont plus compréhensibles qu’une règle bidirectionnelle contenant plusieurs zones et des objets Any :

• Entrant : WAN vers la zone du serveur interne, endpoint SMTP 10.20.30.25, uniquement les services SMTP requis, logging activé. L’endpoint n’est pas une valeur prescrite pour le champ non résolu Destination networks.
• Sortant : zone et hôte du serveur de messagerie interne vers WAN ou le smarthost précis, uniquement les services SMTP requis, logging activé

Sous Scan email content, activer Scan SMTP dans les deux sens nécessaires et Scan SMTPS uniquement lorsque SMTPS est réellement utilisé. Si le port standard du protocole sélectionné manque dans Services, SFOS propose Add ports. Pour un port non standard, il faut définir volontairement le service correspondant. Le service, le NAT, le listener du serveur et l’option d’analyse doivent décrire le même chemin de port ; Add ports ne remplace pas ce contrôle.

Placer les règles au-dessus des règles plus générales qui correspondent déjà au même trafic. Après l’enregistrement, la Firewall Rule ID consignée fait foi. La structure des règles, la zone NAT et l’ordre sont décrits dans Configurer les règles Sophos Firewall en toute sécurité.

Facultatif : utiliser une autre adresse source publique en sortie

Dans la règle firewall sortante, During scheduled time définit quand cette règle s’applique. Choisir volontairement All the time pour un serveur disponible en permanence. Un horaire limité peut modifier la règle correspondante hors de sa plage ; vérifier aussi Rule ID et flux de messagerie à ce moment-là. Ce n’est pas un horaire de la règle SNAT. La règle créée automatiquement à l’activation du MTA mode relève d’un autre flux et ne remplace pas cette règle serveur Legacy ; utiliser le guide MTA pour ce chemin.

Cette configuration concerne le trafic SMTP transféré du serveur interne, pas les messages MTA générés par le système. Elle sert lorsqu’une autre identité publique attribuée est nécessaire à la place de l’adresse MASQ WAN. Attribution par l’opérateur, routage, SPF, RDNS et autorisations de l’opérateur doivent correspondre à cette identité ; SNAT ne modifie pas ces prérequis.

1. Sous Network > Interfaces > Add interface > Add alias, choisir l’interface WAN physique réelle, IP version IPv4 et l’adresse attribuée avec le bon IPv4/Netmask ; Save. Le chemin opérateur, Device Access et les vérifications d’alias sont décrits dans Configurer une IP alias.
2. Sous Hosts and services > IP host > Add, créer un hôte nommé pour cette même adresse publique : IP family IPv4, Type IP, IP address l’adresse attribuée ; Save. Un objet hôte seul ne lie pas l’adresse à l’interface.
3. Sous Rules and policies > NAT rules > New NAT rule, limiter Original source au serveur interne réel et définir Translated source (SNAT) sur l’hôte IP public. Limiter Original destination aux destinations nécessaires ou au smarthost et Original service aux services SMTP requis. Translated destination (DNAT) et Translated service (PAT) restent Original. Inbound interface et Outbound interface doivent correspondre au chemin réel serveur-WAN. Enregistrer avec Save et placer la règle au-dessus des autres SNAT qui correspondent aussi ; vérifier séparément les ordres NAT et firewall. Principes de NAT explique la première règle correspondante. Any, Top, Port1 et Port2 sont des exemples, pas des valeurs obligatoires.
4. Sous Rules and policies > Firewall rules > Add firewall rule > New firewall rule, créer une règle IPv4 sortante adaptée ou vérifier la règle restreinte existante : Action Accept, zone et hôte réels du serveur comme source, WAN et destinations requises, uniquement les services SMTP nécessaires, Log firewall traffic activé. Choisir Scan SMTP et, si nécessaire, Scan SMTPS comme ci-dessus ; Save et vérifier l’ordre firewall indépendamment de NAT.
5. Établir une nouvelle connexion SMTP vers un destinataire externe contrôlé. Vérifier ensemble Firewall Rule ID, NAT Rule ID, IP source traduite dans la capture ou chez le destinataire externe et livraison réelle. Une session existante ou un test de port SMTP ne suffit pas. Tester aussi un cas négatif avec une source hors périmètre ou un service non autorisé.

Pour revenir en arrière, restaurer d’abord les règles documentées et leur ordre, puis vérifier l’ancienne IP source et la livraison avec une nouvelle connexion. Supprimer l’alias et l’hôte IP uniquement si aucun autre service n’en dépend.

Valider le flux de messagerie et l’analyse du proxy

Envoyer d’abord un petit message externe vers une boîte de test. Faire ensuite envoyer par le serveur de messagerie interne un second message vers un destinataire externe contrôlé. Les deux tests reçoivent des objets uniques et des horodatages UTC.

Pour STARTTLS sur le port 25 et une connexion TLS directe sur le port 465, les contrôles en lecture seule suivants peuvent aider depuis un système de test autorisé :

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Remplacer mail.example.net par le FQDN réel et tester uniquement les ports effectivement proposés. Ces commandes OpenSSL affichent la chaîne de certificats présentée et les paramètres TLS négociés ; examiner toute erreur de vérification des certificats. Elles ne vérifient pas explicitement le nom d’hôte attendu et peuvent continuer malgré des erreurs de vérification : une connexion ne prouve donc pas la réussite de l’authentification du certificat. Elles ne prouvent ni la distribution réussie du message ni l’analyse des malwares, du spam ou de Data Control.

Dans Log Viewer, la source, la destination, le service, l’action et la Firewall Rule ID doivent correspondre aux nouvelles règles. Pour le proxy SMTP/S Legacy, corréler awarrensmtp.log et awarrenmta.log avec le même horodatage. Les fichiers de log sont décrits dans Services et logs Sophos Firewall.

Effectuer ensuite des tests négatifs distincts pour le périmètre de la règle de pare-feu et la correspondance avec la politique de messages. Une source ou un service hors du périmètre du pilote ne doit pas correspondre à la règle de pare-feu du pilote et doit suivre le résultat documenté d’autorisation ou de blocage ; une autre règle autorisée peut néanmoins assurer une protection. Un message de test ne satisfaisant pas au critère de la politique du pilote ne doit pas correspondre à cette politique ni recevoir son action spécifique, tout en restant soumis à toute analyse par défaut ou autre analyse applicable. Pour chaque cas, consigner la Firewall Rule ID, la politique et le résultat de distribution attendus, puis les comparer au résultat observé. Ne pas utiliser de malware réel dans les tests de production ; utiliser des modèles de test inoffensifs reconnus et une boîte aux lettres contrôlée pour valider l’analyse.

Isoler les erreurs selon le symptôme

SMTP fonctionne, mais la politique ne s’applique pas

Commencer par vérifier la Firewall Rule ID. Si une autre règle correspond, corriger l’ordre, la source, la destination, la cible NAT et le service. Si la règle attendue correspond, Scan SMTP ou Scan SMTPS, l’ordre des politiques et les groupes d’expéditeurs et de destinataires doivent convenir au test. Une politique seule n’active pas le proxy transparent.

Le courrier entrant n’atteint pas le serveur

Contrôler séparément l’adresse de destination publique, le hit DNAT, la translated destination, la zone de destination, le listener du serveur et le chemin retour. Une connexion TCP ouverte jusqu’au firewall ne prouve pas que le DNAT et la règle firewall atteignent le serveur interne. Packet Capture et Rule ID doivent montrer l’entrée et le transfert.

Le courrier sortant utilise la mauvaise adresse IP publique

Contrôler le SNAT, la règle réflexive, le gateway WAN, la route SD-WAN et le comportement des reply packets. Le proxy Legacy ne sélectionne pas automatiquement l’adresse source publique requise pour SPF, RDNS ou l’autorisation du fournisseur. Prouver le chemin concret avant toute modification globale de Route Precedence.

TLS échoue après l’activation de l’analyse

Relever le FQDN, l’adresse IP de destination, le certificat, l’émetteur, la chaîne et la version négociée. Si plusieurs domaines partagent une adresse IP, le contrôle de certificat fondé sur l’adresse IP documenté peut être en cause. Allow invalid certificate ne doit pas être activé comme solution rapide.

Un message manque et rien n’apparaît dans le MTA mail spool

Ce n’est pas un critère de réussite pertinent en Legacy mode, car mail spool et les mail logs spécifiques au MTA appartiennent au MTA mode. La chaîne pertinente comprend ici la règle firewall, le NAT, les logs du serveur SMTP, Log Viewer, awarrensmtp.log et awarrenmta.log. Contrôler séparément les messages mis en quarantaine sous Email > SMTP quarantine.

Effectuer un rollback sûr

Pour le rollback, restaurer d’abord les règles pilotes et les options d’analyse dans leur état antérieur documenté. Supprimer ensuite les nouvelles affectations de politiques ou rétablir leur ordre. Les modifications temporaires du DNAT, du SNAT ou des certificats ne sont supprimées que si aucun autre service n’en dépend.

Ce n’est qu’ensuite que le SMTP Deployment Mode est rétabli si la modification incluait cette commutation. Le flux de messagerie entrant et sortant d’origine doit à nouveau fonctionner avec les Rule IDs, les adresses publiques et les logs serveur attendus. Les messages, le contenu de la quarantaine et les logs du proxy ne sont pas supprimés dans le cadre d’un rollback standard.

Checklist d’exploitation

• Le proxy transparent est un choix délibéré et les exigences MTA ont été exclues.
• Le backup, l’accès d’administration et les Rule IDs d’origine sont documentés.
• Le SMTP hostname, les limites de taille SMTP et POP/IMAP, l’action sur les messages surdimensionnés, IP Reputation et les limites DoS sont justifiés.
• Les ports standard ou alternatifs utilisés et les POP/IMAP recipient headers correspondent au chemin réel du serveur.
• Le moteur antivirus principal et son effet sur Zero-day Protection dans les politiques Single antivirus ont été contrôlés.
• Le certificat, les exceptions TLS et les domaines concernés ont été contrôlés.
• Le DNAT, le SNAT, la zone de destination et les ports réels du serveur correspondent.
• Les règles firewall entrante et sortante sont précises, journalisées et leur correspondance est prouvée.
• Les politiques par défaut et personnalisées possèdent un ordre traçable.
• La journalisation facultative est limitée aux destinataires nécessaires et répond à un objectif documenté de protection et de conservation des données.
• Les tests positif, négatif, TLS et de distribution ont réussi.
• Les logs du proxy Legacy et du serveur de messagerie peuvent être corrélés dans le temps.
• Le responsable, la date de révision et le chemin de secours complet sont consignés.

FAQ