MTA-STS

Ce guide fait partie de notre guide sur l’authentification des e-mails. Voir aussi : MTA-STS et DKIM vs DMARC.

MTA-STS (SMTP MTA Strict Transport Security) est une norme qui permet à un domaine d’exiger que le courrier entrant soit remis via un TLS chiffré et authentifié, empêchant les attaques par rétrogradation et de type man-in-the-middle. TLS-RPT est sa norme de reporting compagnon, qui collecte des rapports quotidiens sur les échecs TLS de remise. MTA-STS protège la couche de transport, complétant SPF, DKIM et DMARC, qui authentifient l’expéditeur plutôt que la connexion.

Le problème que MTA-STS résout

Lorsque deux serveurs de messagerie échangent des messages via SMTP, ils négocient normalement le chiffrement à l’aide de STARTTLS. Le hic, c’est que STARTTLS est opportuniste : le serveur expéditeur demande si le destinataire prend en charge TLS, et si la réponse est non, il retombe discrètement en texte clair. Cette question et cette réponse se déroulent en clair, ce qui signifie qu’un attaquant positionné entre les deux serveurs peut supprimer la commande STARTTLS de la conversation. Le serveur expéditeur croit alors que le destinataire ne prend pas en charge TLS et remet le message non chiffré, ou se connecte à un serveur imposteur présentant un certificat falsifié.

Ce sont ce qu’on appelle des attaques par rétrogradation et de type man-in-the-middle. Comme SMTP a été conçu d’abord pour l’interopérabilité et pour la sécurité seulement ensuite, il n’existait historiquement aucun moyen pour un domaine destinataire de dire « chiffre toujours le courrier qui m’est destiné, et refuse de le remettre si tu ne peux pas ». MTA-STS comble exactement cette faille. Il permet à un domaine de publier une politique déclarant que le courrier entrant doit être remis via TLS, en utilisant un certificat valide qui correspond à l’un de ses hôtes MX publiés. Les serveurs expéditeurs qui prennent en charge MTA-STS respectent la politique et diffèreront ou renverront un message plutôt que de l’envoyer en clair.

Comment fonctionne MTA-STS

MTA-STS repose sur deux éléments fonctionnant ensemble : un enregistrement DNS TXT qui annonce la politique, et un fichier de politique hébergé en HTTPS qui la définit.

D’abord, publiez un enregistrement TXT à _mta-sts.yourdomain.com. Cet enregistrement signale qu’une politique existe et porte un identifiant qui change chaque fois que vous mettez à jour la politique, afin que les serveurs expéditeurs sachent quand la récupérer à nouveau.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

Ensuite, servez le fichier de politique via HTTPS à un emplacement fixe et bien connu : https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. L’exigence HTTPS est importante, car le certificat sur cet hôte prouve que la politique est authentique et n’a pas été altérée en transit.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

Les lignes mx listent chaque nom d’hôte autorisé à recevoir votre courrier, correspondant à vos enregistrements MX. max_age indique aux serveurs expéditeurs combien de temps mettre la politique en cache, en secondes (604800 correspond à une semaine). Un cache plus long résiste mieux à un attaquant capable de manipuler brièvement le DNS, une valeur d’au moins quelques jours est donc recommandée une fois que vous êtes sûr de votre configuration.

Mode enforce vs mode de test

Le champ mode dans le fichier de politique contrôle la rigueur avec laquelle la politique est appliquée, et c’est le bouton le plus important lors du déploiement de MTA-STS.

Commencez avec mode: testing. En mode de test, les serveurs expéditeurs évaluent votre politique mais ne bloquent jamais la remise en cas d’échec. Au lieu de cela, combinés avec TLS-RPT ci-dessous, ils vous signalent les échecs. Cela vous permet de découvrir des hôtes MX mal configurés, des certificats expirés ou des incohérences de nom d’hôte sans jamais perdre un message légitime.

Une fois que vos rapports reviennent propres pendant une semaine ou deux, passez à mode: enforce. Désormais, les serveurs expéditeurs refuseront de remettre le courrier qui ne peut pas être envoyé via un TLS authentifié vers un hôte MX listé. Une troisième valeur, mode: none, désactive de fait la politique et sert à retirer MTA-STS de manière élégante. Passez toujours de testing à enforce délibérément, jamais l’inverse dans la précipitation.

TLS-RPT : le reporting

MTA-STS à lui seul ne vous dit rien sur la façon dont la remise se déroule. TLS-RPT (SMTP TLS Reporting) est le canal de retour. Vous publiez un second enregistrement TXT à _smtp._tls.yourdomain.com nommant une adresse qui doit recevoir des rapports agrégés.

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Les serveurs expéditeurs participants vous envoient un rapport JSON quotidien résumant les sessions TLS réussies et échouées vers votre domaine, y compris la raison de chaque échec, comme un certificat qui n’a pas été validé ou une négociation STARTTLS qui a été supprimée. Ces rapports sont ce qui rend le mode de test utile, et ils restent précieux en mode enforce comme système d’alerte précoce en cas d’expiration de certificat ou de changement de MX. De nombreuses équipes acheminent l’adresse rua vers un tableau de bord de surveillance plutôt que vers une boîte de réception humaine.

Où il s’insère aux côtés de SPF, DKIM et DMARC

Il est facile d’assimiler MTA-STS aux autres acronymes, mais il résout un problème différent. SPF, DKIM et DMARC authentifient l’expéditeur, répondant à « ce message provient-il vraiment du domaine qu’il prétend ? ». MTA-STS sécurise la connexion, répondant à « ce message est-il remis de manière privée et vers le bon serveur ? ». Vous voulez les deux. Un message peut être parfaitement authentifié tout en étant intercepté en transit, et une connexion parfaitement chiffrée peut toujours transporter un message usurpé.

Pour une vue d’ensemble de l’authentification de l’expéditeur, consultez notre guide sur l’authentification des e-mails. MTA-STS se marie naturellement avec ces normes en tant qu’ajout à la couche de transport, et une fois que vous les avez en place, BIMI est une autre couche avancée à considérer, vous permettant d’afficher un logo de marque vérifié dans les boîtes de réception compatibles.

Foire aux questions

Qu’est-ce que MTA-STS ?

MTA-STS (SMTP MTA Strict Transport Security) est une norme qui permet à un domaine d’exiger que le courrier entrant soit remis via un TLS chiffré et authentifié. Il publie un enregistrement DNS et un fichier de politique hébergé en HTTPS afin que les serveurs expéditeurs imposent le chiffrement et refusent de retomber en texte clair, bloquant les attaques par rétrogradation et de type man-in-the-middle contre SMTP.

Quelle est la différence entre MTA-STS et TLS-RPT ?

MTA-STS est la norme d’application : elle définit la politique qui exige la remise en TLS. TLS-RPT est la norme de reporting : elle définit un enregistrement DNS et un format de rapport JSON afin que les serveurs expéditeurs vous envoient des résumés quotidiens des succès et échecs de remise TLS. Vous les déployez ensemble, en utilisant TLS-RPT pour valider en toute sécurité une politique MTA-STS avant de l’appliquer.

MTA-STS est-il obligatoire ?

Non, MTA-STS n’est pas obligatoire, et le courrier fonctionne sans lui. Cependant, il est fortement recommandé pour tout domaine qui gère du courrier sensible, car il comble une faille réelle que SPF, DKIM et DMARC ne traitent pas. Le déployer d’abord en mode de test ne comporte aucun risque de remise, il y a donc peu de raisons de ne pas l’adopter.

MTA-STS remplace-t-il SPF, DKIM ou DMARC ?

Non. MTA-STS opère à une couche différente. SPF, DKIM et DMARC authentifient l’expéditeur et détectent l’usurpation, tandis que MTA-STS sécurise la connexion de transport afin que le courrier soit remis de manière privée vers le bon serveur. Ce sont des contrôles complémentaires, et un domaine bien protégé les déploie tous ensemble plutôt que d’en choisir un plutôt qu’un autre.