Vérificateur de politique MTA-STS
Récupère l'enregistrement TXT _mta-sts et le fichier de politique mta-sts.txt d'un domaine pour diagnostiquer si le chiffrement TLS obligatoire du transport des e-mails (MTA-STS) est correctement configuré.
Astuces
- MTA-STS est vérifié par le serveur expéditeur, pas par le destinataire. Une fois publié, les serveurs tiers exigeront TLS pour envoyer du courrier vers votre domaine.
- Déployez d'abord en mode testing pendant quelques semaines à un mois avant de passer en enforce, afin d'éviter une mauvaise surprise en cas de rejet de remise inattendu.
- max_age est généralement fixé entre 604800 secondes (7 jours) et 31557600 secondes (1 an). Une valeur trop courte oblige à récupérer le fichier de politique plus fréquemment.
- Un caractère générique (*.example.com) est utilisable dans le champ mx, mais le SAN (Subject Alternative Name) du certificat TLS doit correspondre à ce générique.
- Publier uniquement l'enregistrement DNS ou uniquement le fichier de politique n'a aucun effet : MTA-STS ne s'active que lorsque les deux sont présents simultanément.
Questions fréquentes
Anecdote — Pourquoi STARTTLS ne suffisait pas et comment MTA-STS est né
Pendant des décennies, le chiffrement en transit de SMTP a reposé sur STARTTLS (normalisé en 1999), qui ouvre la connexion en clair avant de basculer vers TLS. En 2014, des chercheurs en sécurité ont confirmé des attaques réelles de « STARTTLS stripping » : comme la négociation STARTTLS elle-même se déroule avant que le chiffrement n'entre en jeu, un attaquant présent sur le trajet pouvait réécrire la réponse du serveur pour masquer sa prise en charge de STARTTLS, incitant l'autre partie à revenir au texte en clair.
La cause profonde tenait au fait que STARTTLS était délibérément conçu pour revenir au texte en clair lorsque l'autre partie ne prenait pas TLS en charge — une fonctionnalité de compatibilité que les attaquants pouvaient exploiter en feignant simplement l'absence de support TLS. Vers 2015, les propres mesures de Google ont montré que le STARTTLS stripping se produisait à grande échelle dans certains pays et chez certains fournisseurs d'accès.
MTA-STS (RFC 8461, publié en 2018) fut la réponse de l'industrie, développée conjointement par Google, Microsoft, Yahoo et d'autres. Un domaine déclare sa prise en charge de MTA-STS via un enregistrement TXT du DNS, puis publie un fichier de politique récupéré en HTTPS listant les hôtes MX autorisés et les exigences TLS. Une fois récupérée, la politique est mise en cache pendant max_age, ce qui permet de détecter et de rejeter une tentative de rétrogradation ultérieure au lieu de l'accepter silencieusement.
MTA-STS est souvent associé à TLS-RPT (TLS Reporting, RFC 8460), qui permet aux propriétaires de domaine de recevoir des rapports lorsqu'un serveur expéditeur échoue à établir une connexion TLS. MTA-STS assure l'application forcée, TLS-RPT l'observabilité — utiliser les deux ensemble est aujourd'hui la pratique recommandée.