MTA-STS et TLS-RPT : imposer TLS en réception et en être informé

Le chiffrement SMTP par STARTTLS est opportuniste : un serveur émetteur tente TLS et, si la négociation échoue ou si le serveur en face ne le propose pas, il envoie en clair. Un attaquant placé sur le chemin peut donc supprimer l'annonce STARTTLS ou rediriger le trafic vers un autre serveur via de fausses réponses MX. MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) permet au domaine destinataire de déclarer que ses MX exigent TLS avec un certificat valide ; TLS-RPT (SMTP TLS Reporting, RFC 8460) permet de recevoir des rapports quand des émetteurs n'y parviennent pas.

Ces deux mécanismes concernent le domaine en réception : ils protègent le courrier qui vous est destiné, pas celui que vous envoyez.

Comment fonctionne MTA-STS#

Le mécanisme repose sur deux éléments :

1. Un enregistrement TXT sous _mta-sts.<domaine> qui signale l'existence d'une politique et porte un identifiant id= ;
2. Un fichier de politique servi en HTTPS à l'adresse https://mta-sts.<domaine>/.well-known/mta-sts.txt, avec un certificat valide pour le nom mta-sts.<domaine>.

Un serveur émetteur qui prend en charge MTA-STS interroge le TXT, télécharge la politique, la met en cache pour la durée max_age, puis n'accepte de livrer qu'à des MX dont le nom correspond à la liste mx: de la politique et dont le certificat TLS est valide pour ce nom. À chaque envoi ultérieur, il compare l'id= du DNS à celui en cache pour savoir s'il doit recharger la politique. Le passage par HTTPS rend la politique indépendante de l'intégrité du DNS, contrairement à DANE qui exige DNSSEC.

Les enregistrements#

_mta-sts.example.com.   IN TXT  "v=STSv1; id=20261001T090000"
_smtp._tls.example.com. IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Et le fichier de politique :

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
mx: *.backup-mx.example.net
max_age: 604800

• mode: vaut testing (les échecs sont seulement rapportés), enforce (les échecs bloquent la livraison, le message reste en file chez l'émetteur) ou none (retrait de la politique) ;
• mx: liste les noms d'hôtes autorisés, avec un joker possible uniquement sur le label le plus à gauche ;
• max_age: est la durée de cache en secondes, souvent entre une et quatre semaines.

Pour TLS-RPT, l'étiquette rua= accepte une adresse mailto: ou une URL https:. Les rapports sont des fichiers JSON envoyés une fois par jour par les émetteurs qui le prennent en charge, listant les sessions réussies et les échecs par cause : certificat invalide, STARTTLS absent, nom de MX non autorisé, politique introuvable.

Déployer MTA-STS et TLS-RPT#

1. Commencer par TLS-RPT seul : publier _smtp._tls et observer pendant quelques semaines quels émetteurs échouent déjà à établir TLS vers vos MX.
2. Vérifier chaque MX : STARTTLS annoncé, certificat délivré par une autorité reconnue, couvrant exactement le nom du MX (pas seulement le domaine), chaîne complète, protocoles TLS 1.2 ou 1.3.
3. Mettre en ligne le fichier de politique en mode: testing sur mta-sts.<domaine> avec un certificat HTTPS valide, puis publier le TXT _mta-sts.
4. Lire les rapports TLS-RPT : tant qu'ils signalent des échecs liés à votre configuration, rester en testing.
5. Passer en mode: enforce et augmenter max_age.
6. À chaque changement de MX ou de certificat, mettre à jour le fichier puis l'id= du TXT, dans cet ordre.

Erreurs fréquentes#

• Certificat du MX non conforme au nom : le MX s'appelle mx1.example.com mais le certificat couvre mail.example.com. En enforce, le courrier reste bloqué chez l'émetteur.
• id= jamais mis à jour après modification de la politique : les émetteurs gardent l'ancienne version en cache jusqu'à expiration.
• Liste mx: incomplète : un MX de secours oublié devient inutilisable pour les émetteurs qui appliquent la politique.
• Hôte mta-sts.<domaine> inaccessible ou redirection HTTP vers un autre nom : la politique n'est pas récupérée et, si elle était en cache, elle expire sans remplacement.
• Fichier servi avec un mauvais type MIME : il doit être text/plain.
• max_age trop court en enforce : si le site HTTPS tombe, la protection disparaît rapidement ; trop long, un changement de MX devient délicat à opérer.
• Confondre MTA-STS et DANE : les deux peuvent coexister ; DANE (RFC 7672) repose sur des enregistrements TLSA signés par DNSSEC, MTA-STS sur HTTPS.

Ce que SenderRadar en montre#

SenderRadar indique pour chaque domaine la présence d'un enregistrement MTA-STS, le mode et la durée de cache de la politique, la cohérence entre la liste mx: et les MX réellement publiés, la présence d'un enregistrement TLS-RPT et sa destination, ainsi que l'état des certificats présentés par les MX. SenderRadar s'appuie sur sa propre base d'analyse pour signaler les incohérences entre ces éléments.

Références#

• RFC 8461 – SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 – SMTP TLS Reporting
• RFC 7672 – SMTP Security via Opportunistic DANE TLS
• RFC 3207 – SMTP Service Extension for Secure SMTP over TLS