TLS-RPT pour les e-mails : obtenez de la visibilité sur les échecs TLS (et corrigez-les)

Ce qu’est réellement TLS‑RPT (et ce que ce n’est pas)

TLS‑RPT (Transport Layer Security Reporting) est une norme qui permet aux expéditeurs d’e-mails de signaler au propriétaire d’un domaine lorsqu’ils ont eu des difficultés à livrer du courrier à ce domaine via TLS.
L’expression clé est « lorsqu’ils ont eu des difficultés » : il s’agit de rapports d’échec, pas d’une fonctionnalité de sécurité à elle seule.

Vous publiez un enregistrement DNS indiquant au monde où envoyer les rapports. Ensuite, les gros expéditeurs (et tout expéditeur qui le supporte) vous enverront des rapports JSON périodiques (généralement quotidiens).
Ces rapports décrivent les tentatives de livraison vers vos hôtes MX et pourquoi TLS n’a pas fonctionné comme prévu.

Ce que ce n’est pas

• Ce n’est pas une application de chiffrement forcé. TLS‑RPT ne force personne à utiliser TLS. Pour cela, il existe MTA‑STS (basé sur une politique) ou DANE (basé sur DNSSEC).
• Ce n’est pas la sécurité du contenu du message. Il s’agit du saut de transport SMTP, pas du chiffrement de bout en bout comme S/MIME ou PGP.
• Ce n’est pas instantané. La plupart des rapports sont livrés par lots. Vous obtenez un signal, mais pas une alerte en temps réel.

Pensez à TLS‑RPT comme à des détecteurs de fumée : ils n’empêchent pas les incendies, mais ils vous indiquent où il y a de la fumée.

Pourquoi vous devriez vous en soucier (même si vous « avez déjà TLS »)

« Nous utilisons STARTTLS » est l’équivalent e‑mail de « nous avons des sauvegardes ». Très bien. Maintenant, montrez‑moi un test de restauration.
STARTTLS est opportuniste par défaut : si TLS échoue, de nombreux expéditeurs retomberont sur du texte clair à moins qu’une politique ne dise le contraire.
Sans télémétrie, vous pouvez être rétrogradé sans le savoir. Ou vous pouvez casser la livraison entrante pour un sous‑ensemble d’expéditeurs et ne le découvrir que lorsqu’un contrat important n’est pas renouvelé.

TLS‑RPT vous apporte :

• Visibilité sur les échecs réels dans l’écosystème : problèmes de certificat, incohérences de nom, versions de protocole, suites de chiffrement, bizarreries de bannière SMTP, délais réseau et violations de politique.
• Des preuves pour le débogage avec des tiers : « Vos rapports montrent que vous échouez la validation contre mx2 ; voici le type d’échec et la période. »
• Alerte précoce lorsqu’un changement survient : un nouveau load balancer, une nouvelle chaîne de certificats, un intermédiaire cassé, un changement DNS, une règle de pare‑feu.
• Détection de sécurité pour les schémas de rétrogradation ou d’interception : si beaucoup d’expéditeurs signalent soudainement des échecs auparavant inexistants, quelque chose se trouve sur le chemin.

Blague n°1 : L’e‑mail est le système distribué le plus ancien que beaucoup d’entreprises exploitent. Il mûrit comme du vin — si le vin prend parfois feu.

Faits et petite histoire utiles en production

Points de contexte courts et concrets qui changent la façon d’opérer :

1. Le SMTP précède le chiffrement généralisé de plusieurs décennies. STARTTLS a été greffé ensuite, d’où la norme culturelle du « TLS opportuniste ».
2. TLS‑RPT a été standardisé en 2018 (RFC 8460), principalement pour rendre MTA‑STS opérationnel à l’échelle d’Internet.
3. MTA‑STS est arrivé parce que la rétrogradation STARTTLS était réelle en pratique : des attaquants pouvaient supprimer l’annonce STARTTLS ou provoquer des échecs pour forcer le basculement en clair.
4. DANE existait déjà (records TLSA avec DNSSEC), mais l’adoption est inégale car le déploiement de DNSSEC et le confort opérationnel varient fortement.
5. Les grands fournisseurs de boîtes mail ont poussé l’adoption des formats de rapport parce qu’ils avaient besoin de signaux à fort volume et de faible friction, pas de tickets faits à la main.
6. Les rapports parlent des tentatives de livraison, pas de vos logs MTA. Cela signifie qu’ils captent des échecs qui n’atteignent jamais votre infrastructure (par ex. blocages réseau ou erreurs de négociation TLS avant DATA SMTP).
7. Les rapports sont agrégés : vous verrez des totaux et des types d’échecs, pas un détail forensique par message. C’est une fonctionnalité, pas un bug.
8. Les rapports peuvent révéler une dérive de l’écosystème : de vieilles versions TLS et des suites héritées apparaissent encore dans la longue traîne, surtout avec des appliances et des MTA anciens.

Comment TLS‑RPT fonctionne de bout en bout

Les éléments en jeu

• Votre domaine : publie un enregistrement TLS‑RPT DNS à _smtp._tls.
• Les expéditeurs : MTAs tentant de livrer vers vos hôtes MX. S’ils supportent TLS‑RPT, ils collectent la télémétrie d’échec.
• Votre récepteur de rapports : une adresse e‑mail (ou un endpoint HTTPS) qui reçoit des rapports JSON, souvent compressés et attachés.
• Politique d’application optionnelle : politique MTA‑STS (_mta-sts + fichier de politique HTTPS) ou enregistrements DANE TLSA. TLS‑RPT devient beaucoup plus utile lorsqu’il y a une politique appliquée.

Le cycle de vie

1. Vous publiez _smtp._tls.example.com TXT avec un enregistrement v=TLSRPTv1 pointant vers l’endroit où envoyer les rapports.
2. Un expéditeur tente de livrer vers example.com, négocie STARTTLS, et vérifie les politiques qu’il respecte (MTA‑STS, DANE, règles locales).
3. Si l’expéditeur ne peut pas établir TLS quand c’est attendu, ou si une validation de politique échoue (par ex. mismatch de certificat vs attentes MTA‑STS), il enregistre l’événement.
4. Périodiquement, l’expéditeur vous envoie un rapport décrivant le nombre de succès/échecs et les raisons, regroupés par destination et types de résultats.
5. Vous l’ingérez dans quelque chose de consultable (même si c’est « une boîte mail + un script »). Ensuite vous décidez : corriger la config, corriger le DNS, réparer la chaîne de certificats, ou ouvrir un ticket auprès d’une équipe réseau/sécurité.

Pourquoi c’est de l’or opérationnel

Les échecs SMTP sont souvent asymétriques. Vos logs peuvent ne rien montrer parce que la connexion ne vous a jamais atteint, ou qu’elle est morte avant que votre MTA n’écrive une entrée significative.
TLS‑RPT vous donne la perspective de l’expéditeur. Dans les systèmes distribués, c’est la moitié de la vérité qui vous manque habituellement.

Citation (idée paraphrasée) : Werner Vogels, sur les opérations, insiste souvent sur la construction de systèmes qui « acceptent l’échec » et le rendent observable.
TLS‑RPT applique cette philosophie au transport du courrier.

Enregistrements DNS à publier (avec valeurs par défaut raisonnables)

Principes de base de l’enregistrement TXT TLS‑RPT

L’enregistrement se trouve à _smtp._tls.<domain>. C’est un enregistrement TXT dont la valeur commence par v=TLSRPTv1 et inclut une ou plusieurs URI de rapport via rua=.
On utilise généralement mailto: car c’est simple et interopérable.

Exemples d’enregistrements

Minimal mailto :

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Plusieurs destinataires (utile pendant le déploiement) :

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com,mailto:mailops@example.net"

Endpoint HTTPS (plus difficile à maintenir correctement, mais automatisable) :

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=https://tlsrpt-api.example.com/v1/report"

Opinions acquises sur le terrain

• Commencez par mailto sauf raison forte de ne pas le faire. Les endpoints HTTPS nécessitent des choix d’authentification, limitation de débit, stockage et revue de sécurité. Mailto demande une boîte aux lettres et une hygiène.
• Utilisez un alias dédié comme tlsrpt@ qui envoie vers un système de tickets ou une boîte surveillée, pas la boîte personnelle de quelqu’un.
• Ne publiez pas TLS‑RPT sans au moins une hygiène TLS de base. Vous recevrez des rapports, mais ce sera du bruit tant que vous n’aurez pas corrigé les problèmes évidents (chaînes mauvaises, noms erronés, protocoles anciens).

Ce que contiennent les rapports et comment les lire

Les rapports TLS‑RPT sont des documents JSON décrivant :

• Méta‑données du rapport : nom de l’organisation qui rapporte, plage de dates du rapport.
• Politiques évaluées : des états comme « no-policy-found » ou « sts » avec des détails.
• Résultats : comptes de succès et d’échecs, plus les types d’échec tels que échec de négociation TLS, échec de validation de certificat, ou incongruence de politique.
• Points de terminaison : hôtes MX de destination et IP sur lesquelles l’expéditeur a tenté.

Ce que vous devez regarder en premier

1. Détection de pics : les échecs ont‑ils augmenté par rapport au jour précédent ?
2. Concentration : est‑ce un seul hôte MX, une seule IP, une seule région, un seul expéditeur ?
3. Classe d’échec : échec de poignée de main/protocole vs certificat/PKI vs politique.
4. Consistance : plusieurs reporters sont‑ils d’accord ? Un expéditeur défaillant peut être un bug de leur côté. Beaucoup d’expéditeurs en échec, c’est généralement vous (ou le réseau entre).

Interpréter les thèmes d’échec courants

• Mismatch de nom de certificat : votre nom d’hôte MX ne correspond pas au certificat, ou vous présentez le mauvais certificat sur un nœud.
• CA inconnue / chaîne non fiable : intermédiaires manquants ou chaîne d’entreprise présentée par accident.
• Alerte de version TLS : certains expéditeurs n’utiliseront pas de vieilles versions TLS ; d’autres ne peuvent pas utiliser une configuration ultra‑moderne uniquement.
• Incohérences de politique : MTA‑STS dit « enforce », mais votre serveur ne répond pas aux exigences.
• Échecs de connexion : pare‑feu, routage, pannes grises, ou vérifications de santé du load balancer mensongères.

Blague n°2 : Le débogage TLS, c’est comme l’archéologie. Vous brossez des couches jusqu’à trouver une erreur parfaitement préservée d’il y a trois ans.

Mode opératoire pour un diagnostic rapide

Lorsque vous voyez des échecs TLS‑RPT, résistez à l’envie de changer les suites de chiffrement comme si vous secouiez un distributeur automatique.
Trier d’abord. Corriger ensuite.

Première étape : délimiter le périmètre

• S’agit‑il d’un seul MX de destination ou de tous ?
• S’agit‑il d’une seule organisation expéditrice ou de plusieurs ?
• S’agit‑il d’une seule IP derrière un load balancer ?
• Est‑ce que cela a commencé après un déploiement, une rotation de certificat, un changement DNS ou une modification de pare‑feu ?

Deuxième étape : classer l’échec

• Échecs de poignée de main : version de protocole, incompatibilité de suite, STARTTLS supprimé, délais d’attente.
• Échecs PKI : chaîne, expiration, mismatch de nom d’hôte, comportement de révocation.
• Échecs de politique : MTA‑STS mismatch, DANE mismatch, « no policy » alors que vous en attendiez une.
• Échecs réseau : accessibilité TCP/25, routage asymétrique, NAT hairpin, interférence d’IDS.

Troisième étape : reproduire depuis l’extérieur

• Testez STARTTLS avec openssl s_client contre chaque hôte MX et chaque IP.
• Vérifiez la résolution DNS et l’ordre des MX depuis plusieurs résolveurs.
• Contrôlez quel certificat est effectivement présenté par nœud (les load balancers aiment les déploiements partiels).
• Si MTA‑STS est impliqué, confirmez l’accessibilité et la validité du fichier de politique.

Quatrième étape : décider quoi changer

• Si vous ne pouvez pas reproduire depuis l’extérieur, suspectez une différence de politique ou de validation côté expéditeur.
• Si ce n’est qu’une seule IP, évacuez‑la (drain) et corrigez la dérive de configuration.
• Si c’est lié à la chaîne, corrigez la chaîne servie avant de rotater à nouveau le certificat leaf (rotater le leaf ne réparera pas un intermédiaire manquant).
• Si ce sont des délais, inspectez les timers d’inactivité/poignée de main du pare‑feu et du load balancer.

Tâches pratiques : commandes, sorties et décisions

Ce sont les tâches que j’exécute réellement quand TLS‑RPT se met à crier. Chaque élément inclut : la commande, ce que signifie la sortie, et la décision à prendre.
Supposez des outils Linux et un monde Postfix‑ish ; adaptez selon vos besoins.

Task 1: Confirm the TLS-RPT record exists and is exactly what you think

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Ce que cela signifie : Les expéditeurs savent où envoyer les rapports, et votre enregistrement est analysable.

Décision : S’il est manquant ou mal formé, corrigez d’abord le DNS. Pas d’enregistrement, pas de rapports, pas de visibilité.

Task 2: Check MX records and spot split-horizon or stale changes

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Ce que cela signifie : Les cibles de livraison sont prévisibles et ordonnées.

Décision : Si un MX inattendu apparaît, ou si les priorités ont changé, réconciliez‑les avec votre conception prévue et vos hypothèses de politique TLS.

Task 3: Resolve each MX to all A/AAAA records (multi-IP drift is common)

cr0x@server:~$ dig +short A mx1.example.com
203.0.113.10
203.0.113.11

Ce que cela signifie : Vous avez plusieurs frontends derrière un nom MX.

Décision : Testez TLS contre chaque IP. Un nœud défaillant peut empoisonner votre réputation et votre livraison.

Task 4: Validate TCP/25 reachability from where you are

cr0x@server:~$ nc -vz mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!

Ce que cela signifie : La connectivité de base existe depuis ce point de vue.

Décision : Si cela échoue, cessez d’incriminer TLS. Vous avez un problème de routage/pare‑feu/fournisseur ou vous testez depuis un réseau qui bloque le port 25 sortant.

Task 5: Speak SMTP and verify STARTTLS is advertised

cr0x@server:~$ printf "EHLO test.example\r\nQUIT\r\n" | nc -w 3 mx1.example.com 25
220 mx1.example.com ESMTP
250-mx1.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
221 Bye

Ce que cela signifie : Le serveur propose STARTTLS, donc le TLS opportuniste est possible.

Décision : Si STARTTLS manque de façon inattendue, vérifiez la config MTA, les réglages de délestage TLS, et les proxies SMTP en amont.

Task 6: Do a STARTTLS handshake and inspect the presented certificate

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 

CONNECTED(00000003)
depth=2 C=US, O=Example Root CA, CN=Example Root CA G2
verify return:1
depth=1 C=US, O=Example Issuing CA, CN=Example Issuing CA R3
verify return:1
depth=0 CN=mx1.example.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
---
250 2.0.0 Ready to start TLS

Ce que cela signifie : TLS se négocie, la chaîne est vérifiée, SNI fonctionne, et votre point de terminaison sert le certificat attendu.

Décision : Si la vérification échoue (CA inconnue, émetteur local introuvable, mismatch de hostname), corrigez la chaîne servie et la sélection de certificat sur ce nœud spécifique ou sur le load balancer.

Task 7: Check certificate validity dates (avoid “surprise” expiry)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 2>/dev/null | openssl x509 -noout -dates -subject
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT
subject=CN = mx1.example.com

Ce que cela signifie : Le certificat est actuellement valide et a une date d’expiration claire.

Décision : Si l’expiration est proche, planifiez la rotation tôt. TLS‑RPT vous informera des ruptures après coup ; vous voulez l’éviter.

Task 8: Confirm the full certificate chain served (missing intermediate is classic)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++} {print > ("cert" i ".pem")}'

cr0x@server:~$ for f in cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer < "$f"; done
== cert1.pem ==
subject=CN = mx1.example.com
issuer=C=US, O=Example Issuing CA, CN=Example Issuing CA R3
== cert2.pem ==
subject=C=US, O=Example Issuing CA, CN=Example Issuing CA R3
issuer=C=US, O=Example Root CA, CN=Example Root CA G2

Ce que cela signifie : Vous servez au moins le leaf + l’intermédiaire. Bon.

Décision : Si vous ne voyez que le leaf, corrigez le MTA ou le terminateur TLS pour servir la chaîne. Beaucoup d’expéditeurs ne récupéreront pas les intermédiaires de manière fiable.

Task 9: Verify what ciphers/protocols your SMTP endpoint supports (and if you cut off legacy senders)

cr0x@server:~$ nmap --script ssl-enum-ciphers -p 25 mx1.example.com
Starting Nmap 7.94 ( https://nmap.org ) at 2026-01-03 10:11 UTC
Nmap scan report for mx1.example.com (203.0.113.10)
PORT   STATE SERVICE
25/tcp open  smtp
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLSv1.3:
|     ciphers:
|       TLS_AES_256_GCM_SHA384 - A
|_  least strength: A

Ce que cela signifie : Vous supportez TLS moderne. Bonne posture de sécurité.

Décision : Si votre entreprise nécessite une interopérabilité héritée, réfléchissez si la suppression de TLSv1.2 a causé de réelles ruptures de livraison. Utilisez TLS‑RPT pour quantifier avant de relâcher les exigences.

Task 10: On Postfix, confirm the runtime TLS settings are what you intended

cr0x@server:~$ postconf -n | egrep '(^smtpd_tls_|^smtp_tls_|^smtpd_tls_security_level|^smtp_tls_security_level)'
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_loglevel = 1

Ce que cela signifie : Le TLS entrant est proposé (may), les chemins de certificats sont définis, et les anciens protocoles sont désactivés.

Décision : Si smtpd_tls_cert_file pointe vers le mauvais fichier sur un hôte, vous aurez des échecs TLS‑RPT concentrés sur cette IP. Corrigez la dérive ; ne discutez pas avec les mathématiques.

Task 11: Check mail logs for TLS handshake errors on the server side

cr0x@server:~$ sudo grep -E 'TLS|STARTTLS|SSL_accept|handshake' /var/log/maillog | tail -n 10
Jan 03 10:01:44 mx1 postfix/smtpd[22131]: Anonymous TLS connection established from mail-oi1-f180.google.com[209.85.167.180]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
Jan 03 10:02:09 mx1 postfix/smtpd[22155]: warning: TLS library problem: error:0A000126:SSL routines::unexpected eof while reading

Ce que cela signifie : Vous avez au moins une anomalie de poignée de main. « Unexpected EOF » indique souvent des middleboxes ou des clients qui abandonnent.

Décision : Si TLS‑RPT montre beaucoup d’échecs provenant de plusieurs expéditeurs et que vous voyez des erreurs de poignée de main côté serveur, investigatez les dispositifs réseau (pare‑feu/IDS) et les limites de débit.

Task 12: Confirm which certificate file your TLS terminator is actually using (Nginx/HAProxy style)

cr0x@server:~$ sudo haproxy -c -f /etc/haproxy/haproxy.cfg
Configuration file is valid

Ce que cela signifie : Au moins la configuration est analysable. C’est le plancher, pas le plafond.

Décision : Si TLS‑RPT pointe vers un mismatch de certificat, vérifiez les chemins de fichier crt par frontend et le comportement de reload. Les reloads partiels créent un chaos où « certains clients échouent ».

Task 13: Validate MTA-STS DNS presence (if you claim to enforce TLS)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T001"

Ce que cela signifie : Vous avez un identifiant de version de politique MTA‑STS publié.

Décision : Si TLS‑RPT indique « no policy found » mais que vous attendez une enforcement, votre enregistrement DNS est manquant, erroné, ou pas visible publiquement.

Task 14: Check the MTA-STS policy file is reachable and correct

cr0x@server:~$ curl -sS -D- https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,25p'
HTTP/2 200
content-type: text/plain
content-length: 128

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

Ce que cela signifie : La politique est accessible en HTTPS et elle liste vos hôtes MX.

Décision : Si cela renvoie 404, redirige étrangement, ou liste les mauvais noms MX, corrigez‑le immédiatement. Sinon, les expéditeurs qui appliquent MTA‑STS vous considéreront comme « TLS requis mais non satisfaisable ».

Task 15: Check for DNSSEC/DANE posture (if you use it) and avoid half-configurations

cr0x@server:~$ dig +short TLSA _25._tcp.mx1.example.com
3 1 1 aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899

Ce que cela signifie : Un enregistrement TLSA existe pour SMTP sur le port 25 vers mx1.

Décision : Si vous publiez TLSA sans DNSSEC fiable, vous pouvez créer des échecs déroutants pour les expéditeurs qui valident. Soit faites‑le correctement, soit ne le faites pas du tout.

Task 16: Decompress and inspect a TLS-RPT JSON report attachment you received

cr0x@server:~$ ls -1
tlsrpt-report-2026-01-02.json.gz

cr0x@server:~$ gzip -dc tlsrpt-report-2026-01-02.json.gz | head -n 30
{
  "organization-name": "Example Sender",
  "date-range": {
    "start-datetime": "2026-01-02T00:00:00Z",
    "end-datetime": "2026-01-03T00:00:00Z"
  },
  "report-id": "abc123",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce"
        ],
        "mx-host": [
          "mx1.example.com",
          "mx2.example.com"
        ]
      },
      "summary": {
        "total-successful-session-count": 984,
        "total-failure-session-count": 27
      }
    }
  ]
}

Ce que cela signifie : Le rapport confirme qu’il a évalué la politique STS et compté les succès vs échecs.

Décision : Creusez les détails d’échec. Si des échecs non nuls apparaissent en mode enforce, considérez‑le comme un incident : certains mails peuvent être différés ou rejetés.

Trois mini‑histoires d’entreprise issues du terrain

1) Incident causé par une mauvaise hypothèse : « Le load balancer présente le même certificat partout »

Une société SaaS de taille moyenne exploitait deux hôtes MX derrière un load balancer régional. L’équipe avait un processus de rotation propre pour les certificats web et a supposé que le mail était « la même chose ».
Dans leur modèle mental, SMTP n’était qu’un autre service TCP avec TLS et un certificat. On déploie le bundle de certificats centralement, on recharge le balancer, terminé.

Puis des rapports TLS‑RPT ont commencé à arriver : plusieurs gros expéditeurs ont signalé une « erreur de validation du certificat » pour un hôte MX, mais pas pour l’autre.
L’astreinte a regardé la région primaire, testé STARTTLS depuis son laptop, et cela fonctionnait. Ils ont clôturé le ticket comme « incident côté expéditeur ».

Le lendemain, le nombre d’échecs a doublé. Le schéma était étrange : certains expéditeurs réussissaient, d’autres échouaient, et ce n’était pas corrélé à l’heure.
TLS‑RPT apportait la réponse en évidence : les échecs étaient liés à une IP de destination, pas au nom MX. Le load balancer avait un backend obsolète servant une ancienne chaîne sans intermédiaire.

L’hypothèse erronée était subtile : ils croyaient « le balancer termine le TLS, donc les nœuds backend n’ont pas d’importance ». En réalité, ils avaient un pass‑through TLS pour SMTP afin de préserver les IP clients.
Le balancer était un routeur sophistiqué, pas un endpoint TLS. Un backend avait un fullchain.pem obsolète.

La correction fut ennuyeuse : unifier le déploiement des certificats, appliquer une gestion de configuration sur les nœuds mail, et ajouter un contrôle STARTTLS externe par IP.
TLS‑RPT n’a pas seulement rapporté un échec ; il a fourni l’indice topologique que les logs serveur ne donnaient pas, car la plupart des connexions en échec n’atteignaient jamais le nœud où on regardait les logs.

2) Optimisation qui s’est retournée contre eux : « Désactiver TLSv1.2 pour réduire la CPU et simplifier la politique »

Un groupe IT d’entreprise a décidé de « moderniser » leur périmètre mail. Ils voyaient l’usage de TLSv1.3 augmenter et voulaient simplifier les configurations, réduire la prolifération des suites et aligner sur des standards internes.
Quelqu’un a proposé : désactiver TLSv1.2 entièrement sur le SMTP entrant. Moins de négociations, moins de complexité, moins de surface d’attaque.

Sur le papier, c’était propre. En laboratoire, les MTA modernes négociaient TLSv1.3 instantanément. Les graphes CPU s’amélioraient légèrement. L’équipe sécurité a donné son accord.
Le changement est passé en production un vendredi après‑midi, parce que bien sûr.

Lundi matin : une poignée de partenaires business ne pouvaient plus leur envoyer d’e‑mails. Pas tous. Juste suffisamment pour provoquer l’agacement des dirigeants.
Leurs propres logs mail montraient moins de connexions entrantes que la normale, mais pas d’indice flagrant. Les MTA qui ne pouvaient pas négocier n’ont simplement pas livré.

Des rapports TLS‑RPT sont arrivés le lendemain avec une classe d’échec cohérente : échecs de négociation, regroupés par un ensemble d’organisations partenaires et de MTA anciens.
Ces partenaires n’étaient pas « non sécurisés » au sens malveillant ; ils étaient juste derrière des appliances qui n’avaient pas encore appris TLSv1.3.

L’équipe a réactivé TLSv1.2, gardé les suites faibles désactivées, et mis en place un plan avec échéance : suivre qui a encore besoin de TLSv1.2, les notifier, et mesurer le recul de la traîne.
L’optimisation n’était pas mauvaise en soi. Elle était mal séquencée. TLS‑RPT a transformé un débat politique en migration mesurable.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Tester STARTTLS sur chaque IP, chaque jour »

Une entreprise financière traitait le mail comme un système régulé. Pas glamour, mais cohérent. Ils avaient MTA‑STS en mode enforce et une boîte TLS‑RPT alimentant un petit parseur.
Le parseur ne faisait pas de machine learning. Il comptait les échecs et alertait quand ils franchissaient un seuil.

Une nuit, l’équipe pare‑feu a poussé une mise à jour de règles. Ce n’était pas ciblé sur le mail. C’était ciblé sur les « services entrants inconnus ».
TCP/25 est resté ouvert, mais le nouveau profil d’inspection a commencé à terminer les connexions qui négociaient TLSv1.3 avec certaines extensions.

Leurs contrôles externes quotidiens l’ont détecté immédiatement : STARTTLS fonctionnait sur une IP, échouait sur une autre, et l’échec corrélait exactement avec la frontière du cluster pare‑feu.
Les rapports TLS‑RPT du lendemain l’ont confirmé depuis plusieurs expéditeurs : échecs de poignée de main concentrés sur la même plage d’IP.

Parce qu’ils avaient une pratique ennuyeuse et correcte — contrôles synthétiques par IP plus alertes de tendance TLS‑RPT — ils ont eu un récit d’incident clair et une demande de rollback rapide.
L’équipe pare‑feu a reverté le profil, le mail a repris, et personne n’a eu à deviner si c’était « un problème Google ».

La morale n’est pas « les pare‑feu sont mauvais ». C’est « supposez que votre réseau peut changer de comportement silencieusement, puis instrumentez en conséquence ».
TLS‑RPT est l’instrumentation que vous recevez du monde extérieur, précisément là où vos utilisateurs vivent.

Erreurs courantes : symptôme → cause → correction

1) Les rapports indiquent « certificate validation failure » pour un seul hôte MX

Symptôme : Les échecs sont concentrés sur mx2 ou une IP unique derrière lui.

Cause racine : Dérive de déploiement de certificat, mapping SNI erroné, ou un nœud qui sert une chaîne incomplète.

Correction : Testez chaque cible A/AAAA avec openssl s_client, puis standardisez les chemins de certificats et le comportement de reload sur tous les nœuds.

2) Les rapports indiquent « no policy found » alors que vous pensez que MTA‑STS est activé

Symptôme : Les reporters disent ne pas avoir trouvé STS ; vous attendiez une évaluation « sts ».

Cause racine : Enregistrement TXT _mta-sts manquant, mauvais sous‑domaine, ou DNS non visible publiquement à cause d’un split‑horizon.

Correction : Vérifiez dig TXT _mta-sts.example.com depuis un résolveur public et assurez‑vous qu’il correspond au domaine utilisé par les expéditeurs.

3) Les rapports indiquent « policy validation failure » après un changement DNS bénin

Symptôme : Le mode enforce de STS commence à échouer juste après des changements MX.

Cause racine : Le fichier de politique MTA‑STS liste encore d’anciens noms MX, ou vous avez changé la priorité/hostname MX sans mettre à jour la politique.

Correction : Mettez à jour le fichier de politique (lignes mx:), augmentez l’id de politique dans _mta-sts, et validez la récupération HTTPS.

4) Pic soudain de « TLS negotiation failure » chez de nombreux expéditeurs

Symptôme : Beaucoup de reporters, beaucoup d’échecs, débutant dans la même fenêtre temporelle.

Cause racine : Modifications de pare‑feu/IDS, bug du load balancer, ou vous avez désactivé TLSv1.2 et coupé des expéditeurs anciens.

Correction : Reproduisez depuis l’extérieur, comparez le comportement par IP, consultez les logs de changements réseau. Si vous avez durci les protocoles, revenez en arrière et migrez progressivement.

5) Vous ne recevez aucun rapport

Symptôme : La boîte TLS‑RPT reste vide pendant des semaines.

Cause racine : Pas d’enregistrement TLS‑RPT, enregistrement mal formé, la boîte rejette les grosses pièces jointes, ou vous attendez que tous les expéditeurs du monde le supportent.

Correction : Confirmez l’enregistrement DNS, assurez‑vous que la boîte accepte le format/tailles des rapports, et vérifiez qu’au moins un expéditeur majeur est dans votre mix entrant.

6) Les rapports arrivent mais sont du « bruit » inutile

Symptôme : Beaucoup de types d’échec avec de petits comptes ; vous ne savez pas quoi prioriser.

Cause racine : Vous regardez des rapports bruts sans agrégation, sans baseline, ni regroupement par destination.

Correction : Construisez un pipeline minimal : décompressez le JSON, regroupez par MX/IP/type d’échec, alertez sur les deltas plutôt que sur les absolus.

7) Activer MTA‑STS en enforce provoque des délais de livraison

Symptôme : Certains expéditeurs différent/rejettent parce que la politique exige TLS et qu’ils ne peuvent pas la valider.

Cause racine : Votre posture TLS n’est pas réellement cohérente : mismatch de nom, chaîne incorrecte, échecs intermittents, politique listant de mauvais MX, ou endpoint HTTPS instable.

Correction : Exécutez d’abord en mode: testing, corrigez les échecs avec TLS‑RPT, puis passez en enforce une fois stable.

Listes de contrôle / plan étape par étape

Phase 1 : Faire circuler les rapports (1–2 jours)

1. Créez une boîte dédiée : tlsrpt@yourdomain. Orientez‑la vers une file surveillée (système de tickets ou boîte partagée).
2. Publiez le TXT TLS‑RPT : _smtp._tls.yourdomain avec v=TLSRPTv1; rua=mailto:....
3. Confirmez le DNS depuis l’extérieur de votre réseau (plusieurs résolveurs, pas seulement le vôtre).
4. Vérifiez que la boîte accepte les pièces jointes et ne supprime pas silencieusement les e‑mails automatisés.

Phase 2 : Établir une baseline (première semaine)

1. Collectez les rapports pendant 7 jours sans rien changer. Vous construisez une baseline, pas un concours d’apparence.
2. Agrégerez par nom MX de destination, IP de destination, et type d’échec.
3. Identifiez les 1–3 catégories d’échec principales. Ignorez la longue traîne jusqu’à ce que le haut soit corrigé.
4. Exécutez des contrôles externes STARTTLS contre chaque IP MX quotidiennement.

Phase 3 : Corriger systématiquement (en continu)

1. Corrigez d’abord la chaîne de certificats et les mismatchs de nom. Ce sont des problèmes à fort impact et déterministes.
2. Corrigez ensuite l’alignement des politiques : assurez‑vous que la politique MTA‑STS correspond à l’inventaire MX actuel et que l’endpoint HTTPS est stable.
3. Ajustez les protocoles/suites avec soin. Utilisez TLS‑RPT pour mesurer l’impact de compatibilité avant et après.
4. Lorsque c’est stable, envisagez MTA‑STS en mode: enforce si votre modèle de menace et vos impératifs business le justifient.

Phase 4 : Rendre cela opérationnel (pour survivre aux rotations du personnel)

1. Créez un runbook d’astreinte basé sur le « Mode opératoire pour un diagnostic rapide » ci‑dessus.
2. Ajoutez des alertes : delta du taux d’échec par MX/IP, et « nouveau type d’échec apparu ».
3. Suivez l’expiration des certificats des points de terminaison mail comme pour les endpoints web.
4. Reviewez TLS‑RPT chaque semaine dans les réunions de gestion des changements. L’objectif est d’attraper les régressions, pas d’admirer des graphiques.

FAQ

1) Ai‑je besoin de MTA‑STS pour utiliser TLS‑RPT ?

Non. TLS‑RPT fonctionne seul. Mais il est plus utile si vous publiez aussi une politique d’application (MTA‑STS ou DANE), car les échecs deviennent alors exploitables et pertinents pour la sécurité.

2) TLS‑RPT me dira‑t‑il si un message a été livré en clair ?

Il rend compte des échecs de négociation TLS ou du non‑respect des attentes de politique. Il ne fournit pas de garantie par message et n’énumérera pas les livraisons en clair à moins que la politique n’exigeait TLS et que cela ait échoué.

3) Pourquoi je vois des échecs provenant d’un seul expéditeur ?

Les expéditeurs valident différemment. Certains sont stricts sur les chaînes, d’autres mettent en cache les politiques STS différemment, certains ont des chemins réseau qui atteignent votre nœud défaillant. Faites des tests par IP pour écarter votre côté en premier.

4) Les rapports TLS‑RPT sont‑ils sûrs à recevoir par e‑mail ?

Pour la plupart, oui, mais traitez‑les comme des entrées non fiables. Ce sont des pièces jointes générées par des machines et elles peuvent être volumineuses. Stockez‑les en sécurité, limitez l’exposition de la boîte, et nettoyez‑les avant de les parser.

5) Dois‑je utiliser un endpoint HTTPS plutôt que mailto ?

Si vous disposez déjà d’une infrastructure d’ingestion fiable et souhaitez l’automatiser, HTTPS peut être excellent. Sinon, mailto est le choix pragmatique. N’imaginez pas un webhook fragile pour un système que vous consultez rarement.

6) Combien de temps avant de commencer à recevoir des rapports après la publication DNS ?

Généralement un à deux jours, selon le rythme des expéditeurs et les TTL DNS. Ce n’est pas de la télémétrie en temps réel ; ce sont des rapports programmés.

7) TLS‑RPT aide‑t‑il à détecter les attaques de rétrogradation ?

Il peut aider. Si vous avez MTA‑STS en enforce (ou DANE) et que vous observez soudainement des échecs de négociation TLS à grande échelle, ce schéma peut indiquer une interférence. Ce n’est pas une preuve, mais c’est un signal fort.

8) Quelle est la cause racine la plus fréquente derrière les échecs TLS‑RPT ?

Les problèmes de certificats — en particulier les chaînes incomplètes et les mismatchs sur un nœud derrière un nom MX. La dérive d’infrastructure est difficile à vaincre.

9) TLS‑RPT peut‑il casser mon flux de mail ?

Non. Publier un enregistrement TLS‑RPT se contente de demander des rapports. Les décisions d’application viennent de MTA‑STS ou DANE, pas de TLS‑RPT.

10) Comment prioriser les corrections quand les rapports montrent de nombreux types d’échec ?

Triez par impact : commencez par les échecs qui affectent de nombreux expéditeurs ou un expéditeur à fort volume, puis les échecs liés à un MX/IP (gains rapides), ensuite l’ajustement des politiques, puis le durcissement des protocoles.

Conclusion : prochaines étapes qui réduisent réellement le risque

TLS‑RPT est l’une de ces rares normes e‑mail qui donne l’impression d’avoir été conçue par des gens qui ont été alertés à 2 h du matin.
Il ne sécurisera pas magiquement le SMTP, mais il vous empêchera d’opérer à l’aveugle.

1. Publiez _smtp._tls avec une boîte dédiée tlsrpt@.
2. En une semaine, agrégez les rapports par MX/IP/type d’échec et établissez une baseline.
3. Corrigez d’abord les problèmes déterministes : chaîne, mismatch de nom, dérive par nœud.
4. Si vous utilisez MTA‑STS, validez le chemin HTTPS de la politique et maintenez‑le synchronisé avec les changements MX.
5. Automatisez deux choses : contrôles synthétiques STARTTLS par IP et alertes sur les deltas d’échec dans TLS‑RPT.

Vous n’avez pas besoin de perfection. Vous avez besoin de boucles de rétroaction. TLS‑RPT vous en fournit une venue du monde extérieur — le monde que votre mail doit réellement traverser.