Lisez l’enregistrement MTA-STS que publie un domaine, collez ensuite le fichier de politique vers lequel il pointe et voyez ce qu’il fait vraiment : appliqué ou seulement en test, combien de temps les expéditeurs le gardent en cache, et s’il couvre tous les serveurs de messagerie que le domaine utilise réellement. Cela tourne gratuitement dans votre navigateur, sans inscription et sans rien conserver.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
MTA-STS est la façon dont un domaine annonce au reste d’internet que le courrier qui lui arrive doit être chiffré et remis à un serveur dont le certificat correspond. Sans lui, le chiffrement SMTP est opportuniste : l’expéditeur propose STARTTLS et, si quelque chose se passe mal, un certificat expiré, une capacité retirée en chemin, un attaquant placé sur le trajet, il retombe en clair plutôt que de ne pas remettre. C’est ce repli qui constitue tout le problème, car il signifie que le chiffrement peut être coupé par quiconque est capable d’interférer avec la connexion. MTA-STS le referme en nommant les serveurs autorisés à recevoir le courrier du domaine et en demandant aux expéditeurs de refuser tout le reste. Il est délibérément en deux pièces : un court enregistrement DNS sous _mta-sts qui indique qu’une politique existe et porte un id de version, et la politique elle-même, un fichier texte servi en HTTPS depuis mta-sts.example.com derrière un certificat qui doit être valide. La moitié DNS est la partie qu’un attaquant peut altérer, et c’est celle qui ne contient rien qui vaille la peine d’être altéré. La moitié politique est celle qui décide de quelque chose, et elle est récupérée par un canal qui prouve qui l’a servie.
La moitié DNS, et les deux balises sont obligatoires. La version doit être écrite exactement ainsi, avec cette casse, et un expéditeur qui ne la trouve pas traite le domaine comme s’il n’avait aucune politique plutôt que de réparer l’enregistrement. L’id est ce qui permet à un expéditeur de voir que la politique a changé : il le compare à celui qu’il a en cache, donc modifier le fichier sans changer l’id laisse tout le monde sur l’ancienne politique jusqu’à son expiration.
La seule ligne qui décide si MTA-STS fait quoi que ce soit. Enforce veut dire qu’un expéditeur refuse de remettre par une connexion qu’il ne peut pas authentifier. Testing veut dire qu’il signale l’échec et remet quand même, ce qui donne exactement le même résultat qu’aucune politique. None veut dire que le domaine se retire, ce qui est une vraie configuration et la façon documentée de mettre fin à un déploiement.
Combien de secondes un expéditeur peut garder la politique en cache, et la spécification attend une valeur en semaines, pas en heures. La longue durée est la propriété de sécurité : une fois qu’un expéditeur a la politique, un attaquant qui bloque toutes les récupérations suivantes ne peut toujours pas faire rétrograder le domaine. Une durée courte lui offre une occasion neuve chaque jour.
Une ligne par serveur de messagerie couvert par la politique, et la liste est exhaustive : en mode enforce, un expéditeur refuse de remettre à tout hôte que la liste ne couvre pas. Un joker peut remplacer le label le plus à gauche en entier et rien d’autre, donc *.example.com couvre mx1.example.com et ne couvre ni example.com lui-même ni a.b.example.com.
Testing a été conçu comme une première étape et est devenu un lieu de séjour. Une politique en mode test remet exactement le courrier qu’une politique absente remettrait : rien n’est donc protégé, et le domaine paraît configuré à qui ne regarde que le DNS. Il faut savoir qu’une large part des domaines qui publient MTA-STS aujourd’hui sont en test, et c’est pourquoi ce vérificateur n’affiche jamais un résultat conforme avant d’avoir lu la politique.
Un enregistrement DNS sans fichier de politique derrière ne protège rien, car les expéditeurs récupèrent le fichier et ne trouvent rien à appliquer. Un fichier de politique sans enregistrement DNS n’est jamais récupéré, car rien ne dit à un expéditeur d’aller voir. Les deux moitiés doivent être en place, et le fichier doit être servi en HTTPS avec un certificat valide pour mta-sts.example.com.
Les expéditeurs décident de récupérer à nouveau le fichier en comparant l’id du DNS à celui qu’ils ont en cache. Modifier la politique en laissant l’id tel quel fait que tout expéditeur qui en a déjà une copie continue d’appliquer l’ancienne jusqu’à l’expiration du max_age, ce qui, avec une durée correctement longue, peut représenter des semaines.
C’est la panne qui arrête le courrier, et pas seulement celle qui ne le protège pas. Ajouter un serveur de messagerie, changer de prestataire ou garder un MX de secours qui n’est jamais entré dans la politique signifie que les expéditeurs en mode enforce refusent de lui remettre le courrier. Confronter les lignes mx aux enregistrements MX que le domaine publie en ce moment est la vérification la plus utile qui soit, et c’est ce que fait cet outil avec la politique que vous collez.
mx.*.example.com et *example.com sont tous deux invalides, et *.example.com ne couvre pas example.com lui-même. La règle est étroite à dessein, et un motif écrit comme le ferait un shell laisse justement à découvert les hôtes qu’il devait couvrir.
MTA-STS dit aux expéditeurs de refuser une connexion qu’ils ne peuvent pas authentifier. Il ne vous dit pas quand cela s’est produit. Sans enregistrement de rapports, un certificat qui expire un vendredi produit du silence au lieu d’une alerte, et le premier signal est quelqu’un qui signale que son courrier a rebondi.
