Postfix 3.10 : mises à jour, TLSRPT et la transition vers la version 3.11

Situer correctement Postfix 3.10 dans le temps

À la date de cette recherche, le 20 octobre 2026, Postfix 3.10 n'est pas la branche de développement stable actuelle : ce rôle revient à Postfix 3.11. L'éditeur classe la version 3.10 comme Branche « Legacy », mais continue de lui fournir des correctifs de bogues et de sécurité. Dans les annonces officielles, Postfix 3.10.14, daté du 7 septembre 2026, est mentionné comme étant la dernière version disponible de cette branche.

Cette distinction permet de séparer deux types de décisions. Une mise à jour de maintenance, par exemple de la version 3.10.8 vers un correctif 3.10 plus récent, conserve la branche fonctionnelle choisie et intègre ses corrections. Une mise à niveau vers la version 3.11, en revanche, change de branche de développement et doit donc faire l'objet de tests pour vérifier la compatibilité des fonctions modifiées, la compatibilité de configuration, les extensions et les processus opérationnels. Le passage à une version majeure ou mineure supérieure n'est pas automatiquement la mesure appropriée pour chaque système en production.

Pour les paquets Linux, vérifiez, en plus de la version visible de Postfix, les métadonnées du paquet, le journal des modifications et les consignes de sécurité fournies par l'éditeur du système d'exploitation. Vérifiez-y quelles corrections ce paquet spécifique contient et si l'éditeur documente les rétroportages. L'annonce en amont décrit en revanche la version de Postfix et ne témoigne pas d'une politique générale de rétroportage d'une distribution.

En termes de planification de la maintenance, cela signifie qu’il faut d’abord documenter la version du paquet installé, le canal du référentiel et les adaptations locales. Il faut ensuite comparer les correctifs indiqués par l’éditeur du système d’exploitation pour ce paquet. Ce n’est qu’après cette comparaison qu’il est possible de déterminer s’il existe une mise à jour en attente Mise à jour de Postfix s'il est nécessaire de passer à la version 3.10 ou si une mise à niveau prévue vers la version 3.11 présenterait un intérêt technique supplémentaire. Le point 3.10.14 constitue à cet égard un point de référence en amont, et non une procédure d'installation pour un système Linux spécifique.

Rôle MTA, ports SMTP et limites du système

Postfix est un Agent de transfert de courrier (MTA). Il reçoit les e-mails via SMTP, décide de la suite du traitement en fonction de sa configuration de routage et de ses règles, puis transfère les messages vers d'autres serveurs de messagerie ou vers des chemins de distribution locaux. Postfix constitue ainsi la couche de transport d'un serveur de messagerie sous Linux. Sa configuration ne détermine toutefois pas automatiquement la manière dont les utilisateurs consultent leurs boîtes mail ni la façon dont les contenus suspects sont évalués.

Un serveur IMAP ou POP3 met des boîtes aux lettres à la disposition des clients de messagerie et constitue un composant distinct du transport SMTP. De même, les fonctions de Postfix ne remplacent pas une solution complète de filtrage anti-spam ou antivirus : de tels systèmes doivent, si nécessaire, être correctement intégrés, entretenus et surveillés. Cette distinction est importante d'un point de vue pratique, car un test SMTP réussi ne prouve ni la possibilité de consulter une boîte aux lettres, ni la qualité d'une vérification du contenu.

Le port 25 est généralement utilisé pour le trafic SMTP entre les serveurs de messagerie et, par conséquent, pour le fonctionnement public des serveurs MX. Les ports 587 et 465 sont en revanche destinés à la transmission par les clients de messagerie, généralement avec authentification et une définition de service spécifique. Postfix ne traite pas seulement ces rôles différemment sur le plan organisationnel : certains paramètres ne doivent ou ne devraient justement pas s'appliquer de manière générale à tous les services SMTP.

Avant d'effectuer des modifications, vous devez disposer de droits d'administrateur, d'une sauvegarde restaurable de la configuration de Postfix et d'une fenêtre de maintenance adaptée à la file d'attente, aux délais de distribution et aux applications connectées. Notez également si le serveur envoie des e-mails sortants, reçoit en tant que MX public ou propose un service de remise par client. Ces séparation des fonctions empêche qu'une décision relative à la protection des données, pertinente dans le cadre de la soumission, ne modifie par inadvertance le port 25 accessible au public.

TLSRPT complète la livraison sécurisée des e-mails

Postfix 3.10 offre une prise en charge optionnelle de TLSRPT dans le client SMTP. Les domaines peuvent publier, via le DNS, un destinataire pour les rapports TLS agrégés ; la norme RFC 8460 autorise les adresses e-mail et les points de terminaison HTTPS. Postfix signale uniquement la réussite ou l'échec des poignées de main TLS, avec au maximum un statut final par connexion SMTP. Les échecs d'établissement de connexion et les interruptions avant ou après la poignée de main TLS ne sont pas enregistrés.

Le numéro de version 3.10 ne suffit toutefois pas à lui seul à prouver qu'un paquet Postfix installé peut effectivement utiliser TLSRPT. Cette fonctionnalité nécessite que Postfix soit compilé avec une bibliothèque cliente TLSRPT compatible et l'option de compilation USE_TLSRPT a été créé. Avant de planifier la configuration, tu dois donc vérifier, à l'aide de la documentation du paquet, des caractéristiques de compilation indiquées et des paquets supplémentaires disponibles, si ta distribution intègre cette prise en charge.

TLSRPT complète les procédures qui ont une incidence réelle sur la protection TLS d'une transmission. STARTTLS permet la négociation d'un chiffrement de transport. DANE utilise des enregistrements TLSA et repose sur DNSSEC pour ses hypothèses de sécurité ; MTA-STS publie une politique définissant les propriétés TLS attendues. Si une exigence DANE ou MTA-STS contraignante échoue, TLSRPT peut fournir des informations en aval concernant ces erreurs. Il n’active toutefois ni le chiffrement ni la vérification des certificats lui-même.

Il convient ici de distinguer deux rôles. Le domaine destinataire publie un point de terminaison rua et assure ou confie à un tiers la réception surveillée ainsi que l'analyse des rapports entrants. Un MTA déclarant, en revanche, a besoin d’un Postfix correctement configuré et activé, ainsi que d’une infrastructure distincte qui collecte, récupère, agrège les événements et envoie les rapports. Ces deux aspects peuvent être séparés sur le plan organisationnel ; un titulaire de domaine émetteur n’est pas tenu de générer lui-même les rapports TLSRPT sur le même système.

Un plugin de politique TLS ne fait donc pas systématiquement partie de chaque chaîne de rapports TLSRPT. Postfix prend lui-même en charge DANE. Un plugin adapté devient particulièrement pertinent lorsque le MTA émetteur fournit des informations de politique MTA-STS via smtp_tls_policy_maps . Postfix 3.10 enrichit les réponses d'un tel plugin d'attributs liés à TLSRPT ; cela ne signifie toutefois pas que chaque installation nécessite un plugin, ni que TLSRPT soit intégré dans chaque paquet 3.10.

De plus, TLSRPT n'est pas un outil de surveillance en temps réel. La documentation de Postfix indique qu'il faut compter en moyenne environ douze heures avant la réception d'un message d'erreur et distingue donc expressément ces rapports de la surveillance des incidents urgents. Pour les problèmes de livraison en cours, la vérification des files d'attente, l'analyse des journaux et la mise en place d'alertes restent nécessaires. TLSRPT aide avant tout à mettre en évidence les schémas récurrents et les problèmes liés aux politiques de distribution sur un grand nombre de tentatives de livraison.

Préparer la mise à jour de Postfix dans la branche 3.10

Une mise à jour au sein de Postfix 3.10 est une tâche de maintenance dont le contexte est clair : vous mettez à jour une branche héritée existante vers la version corrigée fournie par votre distribution. Avant d'intervenir, sauvegardez la configuration de Postfix et prévoyez une fenêtre de maintenance. Vérifiez également si le serveur gère les envois sortants, le trafic MX ou la fonction « Submission », car le contrôle et le plan de secours en dépendent.

Commencez par déterminer la version de Postfix installée ou celle détectée par le programme lancé, puis consignez-la explicitement dans main.cf paramètres définis. Les deux premières commandes servent à dresser un état des lieux. postfix check Il s'agit en revanche d'une commande d'administration : elle vérifie notamment les droits de propriété et d'accès aux fichiers et répertoires, et peut créer les répertoires manquants. Il convient donc de l'exécuter avec les droits d'administration prévus à cet effet, et non en partant du principe que le système de fichiers est garanti inchangé.

postconf mail_version
postconf -n
postfix check

L'édition de postconf mail_version indique la version du noyau Postfix utilisé. postconf -n affiche les paramètres avec des valeurs explicites name=value-entrées dans main.cf. Cela peut également inclure des paramètres dont la valeur correspond à la valeur par défaut actuellement installée ; le résultat affiché ne constitue donc pas une preuve certaine d'un écart réel par rapport à la valeur par défaut. De plus, après un changement de version, les valeurs par défaut peuvent changer, tandis qu'une entrée définie précédemment reste inchangée.

Voir aussi postfix check ne constitue pas une validation complète de la configuration du serveur de messagerie. Cette commande peut signaler des problèmes liés aux droits d'accès aux répertoires ou aux fichiers et générer des répertoires manquants, mais elle n'évalue pas de manière exhaustive l'exactitude technique de tous les paramètres. Les chaînes de certificats, les mappages externes, les dépendances DNS, les filtres, l'authentification et l'intégration des services connectés doivent être vérifiés séparément.

Pour mettre à jour le paquet, utilisez la méthode de mise à jour prise en charge par votre distribution. Vérifiez dans les métadonnées du paquet, le journal des modifications et les avis de sécurité quels correctifs et éventuels backports ce paquet spécifique contient. Compare ces informations avec les annonces en amont. Ne conclus pas à l'absence d'un correctif sur la seule base d'une chaîne de version tronquée.

L'obligation particulière de mise à jour du processus, documentée par Postfix, concerne la mise à niveau depuis une ancienne branche de développement vers Postfix 3.10.0. En raison d'une modification du protocole interne de l'agent de distribution, il faut alors au moins postfix reload ou un arrêt suivi d'un redémarrage est nécessaire ; sinon, les agents de livraison risquent de se retrouver face à une situation inattendue smtputf8- Avertissement concernant l'attribut. Ce raisonnement ne peut pas s'appliquer de manière générale à toutes les mises à jour ultérieures de la version 3.10.

Pour les mises à jour de maintenance au sein de la branche 3.10, vérifie plutôt si l'outil de gestion des paquets a déjà rechargé ou redémarré le service conformément à la distribution, et si les processus en cours correspondent à la version mise à jour. Si ce n'est pas le cas, utilise la commande de rechargement ou de redémarrage prévue par la distribution et le paquet. Vérifie ensuite la file d'attente et les journaux dans la fenêtre de maintenance, au lieu de supposer l'exécution d'une commande d'activation spécifique indépendamment du comportement du paquet.

Planifier TLSRPT avec le DNS et l'infrastructure de rapports

Avec TLSRPT, le rôle du domaine destinataire des rapports et celui d'un MTA émetteur doivent être configurés séparément. Un domaine souhaitant recevoir des rapports sur les livraisons vers sa propre infrastructure publie un point de terminaison rua dans le DNS et garantit que leur réception, leur protection, leur stockage et leur analyse sont gérés de manière contraignante. L'enregistrement TXT indique ainsi à quelle adresse les autres MTA émetteurs doivent envoyer leurs rapports agrégés.

Un MTA censé générer lui-même des rapports TLSRPT a besoin, indépendamment de cela, d'un paquet Postfix comprenant une bibliothèque cliente TLSRPT et USE_TLSRPT a été compilé. La mention « Postfix 3.10 » indique uniquement à partir de quelle branche l'intégration est disponible ; elle ne précise pas la version de compilation d'un paquet binaire spécifique. Vérifie donc la documentation du paquet, les informations de compilation et les paquets supplémentaires disponibles dans ta distribution avant de prévoir l'utilisation de cette fonctionnalité.

Sur chaque système Postfix concerné, un fichier local Collector les événements transmis par la bibliothèque TLSRPT intégrée via un socket de domaine Unix local. Le « Fetcher », l'agrégation centrale et le générateur de rapports peuvent fonctionner indépendamment de ce processus : ils récupèrent les données collectées, établissent les synthèses prévues et envoient les rapports vers les destinations publiées par les domaines destinataires. Ces composants en aval peuvent être centralisés sur d’autres systèmes ; cela ne remplace toutefois pas le collecteur local sur le système Postfix concerné.

A Plugin de stratégie n'est nécessaire que dans certains cas spécifiques du côté de l'expéditeur. Si le MTA utilise les informations de politique MTA-STS via smtp_tls_policy_maps, le plugin utilisé à cet effet doit prendre en charge les attributs liés à TLSRPT. DANE est pris en charge par Postfix lui-même. Ni l'enregistrement DNS d'un domaine destinataire, ni le traitement des rapports par un MTA correctement configuré ne nécessitent donc systématiquement un plugin MTA-STS.

L'entrée suivante explique exclusivement la syntaxe DNS pour un destinataire de rapport. example.invalid n'est délibérément pas un domaine productif et ne doit pas être repris tel quel. La balise v=TLSRPTv1 caractérise la procédure ; rua Spécifie ici une destination pour les rapports. La RFC 8460 autorise non seulement les adresses e-mail, mais aussi les points de terminaison HTTPS.

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.invalid"

Pour les rapports TLSRPT, Postfix 3.10 définit l'en-tête TLS-Required: no, afin que le rapport puisse passer au niveau de sécurité TLS „ may “ lors de sa transmission. Cette exception strictement limitée permet d’éviter qu’un rapport d’erreur ne soit rejeté en raison d’une exigence TLS trop stricte. Elle ne constitue en aucun cas une instruction visant à assouplir les exigences TLS pour les e-mails professionnels ou personnels courants.

Protéger les soumissions, évaluer de manière ciblée les options TLS

Le réglage smtpd_hide_client_session s'applique à la transmission authentifiée par un client de messagerie. Lorsqu'elle est activée, le serveur SMTP génère des en-têtes « Received: » sans inclure les informations issues de la session du client. Selon la session, cela permet ainsi de masquer de l'en-tête, par exemple, le nom d'hôte et l'adresse IP du client, les données de session TLS, les informations de connexion SASL ainsi que les détails du journal SMTP.

Classe-les fonction de protection des données à une définition de service de soumission dédiée pour le port 587 ou 465, au lieu de les définir globalement de manière générale dans main.cf à activer. Le MTA public sur le port 25 joue un rôle différent dans le transport de serveur à serveur. La documentation Postfix recommande d'utiliser la valeur par défaut dans ce cas, afin de respecter les exigences de la RFC 5321.

Cette décision concerne donc non seulement la vie privée, mais aussi la traçabilité et les limites du service. Pour les clients authentifiés, la réduction des métadonnées superflues peut être justifiée. Sur un serveur MX public, ce même paramètre enfreindrait toutefois les attentes documentées concernant les informations « Received: ». Il convient donc d’envisager des services distincts, des écouteurs et leurs paramètres respectifs plutôt qu’une règle globale unique.

Postfix 3.10.0 inclut également une adaptation à OpenSSL 3.5 et à sa syntaxe de groupes pour la cryptographie post-quantique. Si l'on souhaite déléguer entièrement la sélection des groupes à la configuration OpenSSL gérée de manière centralisée, il faut tls_eecdh_auto_curves et tls_ffdhe_auto_groups les deux doivent être laissés vides. Ce n'est qu'avec ce paramètre commun qu'OpenSSL se charge du choix ; Postfix ne reproduit pas lui-même la nouvelle syntaxe d'OpenSSL.

La suppression des deux paramètres automatiques est une Cas particulier pour les paramètres de cryptage gérés de manière centralisée ; il ne s'agit pas d'une recommandation générale de renforcement de la sécurité. Cette approche n’est appropriée que si la configuration OpenSSL effective est connue, versionnée et testée. En l’absence de ce contrôle, le transfert de la sélection peut masquer des erreurs de configuration ou générer des comportements TLS inattendus ; dans ce cas, les paramètres explicites de Postfix restent plus faciles à retracer.

Vérifier l'état des correctifs et les problèmes connus

La mention de version 3.10 ne décrit pas à elle seule un état technique uniforme. Ce qui est déterminant, ce sont la version concrète du correctif, les informations du journal des modifications (changelog) du paquet de distribution et, le cas échéant, les corrections rétroportées. Postfix 3.10.14 a été annoncé le 7 septembre 2026 en tant que version héritée, parallèlement à d'autres branches maintenues. Cela ne signifie pas pour autant que chaque paquet Linux intègre déjà cette version en amont.

Prenons l'exemple concret de Postfix 3.10.6 : cette version a corrigé un problème lié à TLS requis : non et le mode „ wrapper “ TLS côté client. L'implémentation précédente pouvait affecter ce type de connexions ; le correctif les traite avec le niveau de sécurité « encrypt ». Les utilisateurs du mode wrapper SMTPS doivent donc vérifier les versions des correctifs et le chemin de transmission effectivement utilisé, plutôt que de supposer un comportement identique à celui de la version « 3.10 ».

L'annonce du 3 octobre 2014 mentionne notamment des corrections et des renforcements de sécurité concernant une faille de type « SMTP smuggling » impliquant smtpd_proxy_filter. Il ne s'agit pas d'une affirmation générale selon laquelle tous les serveurs de messagerie sont concernés : ce paramètre est désactivé par défaut, et la pertinence de cette mise à jour dépend de la configuration locale ainsi que de l'architecture de filtrage en amont ou intégrée. Vérifie donc d'abord si cette fonctionnalité est effectivement utilisée.

En cas de problèmes de livraison, il convient de suivre un ordre logique pour le dépannage : commence par vérifier les écarts significatifs et la validation de la configuration, puis assure-toi que le rechargement s'est bien effectué après une mise à niveau. Ensuite, tu examines la file d'attente et les journaux à la recherche de messages récurrents liés au protocole TLS, à la connexion ou aux messages différés. Un guide systématique pour Analyse des journaux Postfix permet d'associer des événements individuels à un identifiant de file d'attente et à leur tentative de livraison.

Avertissement : Un changement de version ne remplace pas une analyse des causes. Une réinitialisation ne résout ni les chaînes de certificats non valides, ni les erreurs DNS, ni les règles de routage inappropriées. À l'inverse, l'absence de réinitialisation après une mise à niveau peut masquer des processus ou des configurations modifiés en production. Il convient donc de documenter conjointement l'état des correctifs, la source du paquet, la date d'activation et les messages de journalisation observés.

Évaluer correctement les rapports TLSRPT en conditions réelles d'exploitation

Les rapports TLSRPT sont différés et ne remplacent pas la surveillance en temps réel. La documentation de Postfix indique qu'il faut compter en moyenne environ douze heures avant la réception d'un rapport d'erreur. Avec Postfix, les résultats enregistrés concernent les handshakes TLS ; les erreurs d'établissement de connexion et les interruptions avant ou après le handshake ne sont pas pris en compte. Pour les incidents urgents, la surveillance des files d'attente, l'analyse des journaux et la mise en alerte restent nécessaires.

La réutilisation limite également le comptage : une connexion SMTP réutilisée ne génère pas de nouvelle poignée de main TLS. Pour les sessions TLS reprises, Postfix 3.10 ignore par défaut l'enregistrement ; le paramètre smtp_tlsrpt_skip_reused_handshakes est déterminant à cet égard. Les agrégats de rapports ne constituent donc ni un décompte exhaustif de toutes les connexions SMTP, ni un taux de messages ou de délivrables. Évaluez les types d'erreurs, les domaines destinataires, les périodes et les schémas récurrents en conjonction avec les journaux du serveur.

La transmission technique d'un rapport n'apporte encore aucun bénéfice. Déterminez au préalable qui est en charge du destinataire RUA, qui réceptionne et enregistre les rapports, et pendant combien de temps les données sont conservées. Étant donné que les rapports peuvent contenir des informations sur les sessions TLS, le concept d'exploitation doit inclure des droits d'accès, des règles de protection des données et une procédure de suppression. Une règle d'escalade en cas d'erreurs répétées doit également être mise en place.

L'analyse combine donc deux niveaux : TLSRPT présente des tendances agrégées sur une période donnée, tandis que les journaux du serveur de messagerie fournissent le déroulement concret de chaque tentative de livraison. Pour la surveillance en continu, le Guide pratique sur la surveillance des journaux Postfix les rapports concernant les méthodes de classification des messages d'erreur et des files d'attente. Les alertes automatiques devraient réagir aux données d'exploitation en temps réel, et non pas attendre la réception des agrégats TLSRPT.

En l'absence de destinataire responsable, d'espace de stockage sécurisé et d'analyse régulière, la publication TLSRPT devrait d'abord être planifiée plutôt que mise en place à la hâte. Responsabilité en matière de rapports Cela fait partie de la fonction de sécurité : ce n'est qu'en attribuant une erreur à un service compétent qu'il est possible d'apporter une réponse traçable, par exemple en cas d'expiration d'une politique MTA-STS ou de problèmes liés aux données TLSA.

Maintenir la version 3.10 ou passer à la version 3.11

Le choix entre la maintenance par correctifs et le changement de branche dépend de la situation initiale et des objectifs de l'entreprise. Au moment de la rédaction de cet article, Postfix 3.10 reste une branche héritée toujours prise en charge, tandis que la 3.11 est la branche de développement stable. Des correctifs réguliers au sein de la version 3.10 sont donc utiles pour les installations existantes ; ils ne doivent toutefois pas être assimilés à une mise à niveau fonctionnelle vers la version 3.11.

Le passage à la version 3.11 se justifie objectivement surtout lorsque ses fonctionnalités ou ses objectifs à long terme sont nécessaires. Les sorties REQUIRETLS et JSON de certains outils d'administration sont documentées comme des fonctionnalités de la branche la plus récente et ne doivent pas être prises en compte comme des fonctionnalités de Postfix 3.10. Avant de changer de branche, il convient de vérifier la compatibilité des paramètres de configuration, des filtres connectés, de l'authentification et de l'automatisation.

Pour un système 3.10 stable ne nécessitant pas de nouvelles fonctionnalités, il faut mise à jour continue des correctifs la mesure la plus appropriée dans l'immédiat. Elle nécessite toutefois un déroulement contrôlé comprenant une sauvegarde, une vérification des paquets, une validation, un contrôle de l'activation du processus et une surveillance. Un changement de branche, en revanche, doit être motivé par une raison technique et s'inscrire dans une fenêtre de maintenance planifiée ; le simple fait d'avoir un numéro de version plus élevé ne constitue pas un critère de décision suffisant.