Outils gratuits

Vérificateur MTA-STS et TLS-RPT

Tapez un domaine : vous voyez si le courrier qui lui est envoyé doit arriver chiffré. Le vérificateur lit l’enregistrement _mta-sts, récupère le fichier de politique comme le ferait un serveur expéditeur, le compare à vos serveurs MX, et lit l’enregistrement TLS-RPT qui dit aux expéditeurs où signaler les échecs.

Les requêtes DNS vont de votre navigateur à des résolveurs publics. Notre serveur récupère un seul fichier, la politique du domaine que vous tapez, et garde la réponse dix minutes.

Ce que regarde le vérificateur

L’enregistrement _mta-sts
Un enregistrement TXT qui dit qu’une politique existe et porte son identifiant. Les expéditeurs ne relisent la politique que si l’identifiant change : oubliez de le changer et vos modifications ne sont pas vues.
Le fichier de politique
Servi à l’adresse https://mta-sts.votredomaine/.well-known/mta-sts.txt, avec un certificat valide et sans redirection. Il donne le mode, les serveurs MX autorisés et la durée pendant laquelle les expéditeurs peuvent le garder.
Vos serveurs MX face à la politique
Chaque serveur MX du domaine doit correspondre à une ligne « mx ». En mode « enforce », un expéditeur refuse de remettre à un serveur que la politique ne cite pas.
L’enregistrement TLS-RPT
Un enregistrement TXT sur _smtp._tls qui donne l’adresse où les expéditeurs signalent, chaque jour, les remises qui n’ont pas pu être chiffrées.

Comment lire le résultat

Appliqué
Les expéditeurs qui prennent en charge MTA-STS (Google, Microsoft et d’autres) ne remettent que par TLS avec un certificat valide, aux serveurs que vous avez listés. Un attaquant sur le chemin ne peut plus retirer le chiffrement.
En test
Les expéditeurs remettent comme d’habitude et signalent seulement ce qui aurait échoué. C’est la bonne première étape : restez-y jusqu’à ce que les rapports soient propres, puis passez à « enforce ».
Publié mais inutilisable
Un enregistrement sans politique lisible ne protège rien, et chaque expéditeur revient à la remise ordinaire. Le constat dit quelle partie échoue.

Les erreurs que l’on rencontre

Ce qui se passe mal le plus souvent à la mise en place de MTA-STS, et comment le corriger.

Le fichier de politique ne peut pas être récupéré

Pourquoi. L’hôte mta-sts.votredomaine n’existe pas, répond par une redirection, ou présente un certificat expiré ou qui ne couvre pas ce nom exact. Les expéditeurs ne suivent pas les redirections et n’acceptent pas ici un certificat invalide.

Correction. Créez l’hôte mta-sts, servez le fichier directement en HTTPS à /.well-known/mta-sts.txt avec un certificat valide pour mta-sts.votredomaine, et répondez 200 sans redirection.

Un serveur MX n’est pas dans la politique

Pourquoi. Un serveur de messagerie a été ajouté ou le fournisseur a changé, et la politique cite encore les anciens serveurs. En mode « enforce », le courrier vers le serveur non cité est refusé par les expéditeurs qui appliquent MTA-STS.

Correction. Ajoutez une ligne « mx » par serveur (ou un joker comme *.mail.protection.outlook.com), puis changez l’identifiant de l’enregistrement _mta-sts pour que les expéditeurs relisent la politique.

Les changements de politique ne sont pas pris en compte

Pourquoi. Les expéditeurs gardent la politique pendant max_age secondes et ne relisent le fichier que si l’identifiant de l’enregistrement TXT change.

Correction. Changez l’identifiant (une date et une heure, c’est l’usage) à chaque modification du fichier. Avant un changement de fournisseur de messagerie, publiez d’abord les deux séries de serveurs.

Questions

MTA-STS, est-ce la même chose que STARTTLS ?

Non. STARTTLS propose le chiffrement, mais un attaquant sur le chemin peut retirer la proposition et le courrier passe en clair. MTA-STS dit aux expéditeurs que le chiffrement, avec un certificat valide, est exigé pour votre domaine.

Quelle valeur de max_age choisir ?

D’une semaine (604800) à quelques semaines une fois en « enforce » ; un jour pendant les tests. Le maximum est d’un an. Une valeur longue protège plus longtemps, mais fait durer une erreur.

Ai-je besoin de TLS-RPT ?

Il est facultatif, mais sans lui vous n’apprenez jamais que des remises échouent. Publiez-le avant la politique, et lisez les rapports avant de passer à « enforce ».

Qu’envoyez-vous à vos serveurs ?

Les requêtes DNS vont de votre navigateur à des résolveurs publics. Le fichier de politique est récupéré par notre serveur, parce qu’un navigateur n’a pas le droit de le lire depuis un autre site : il reçoit le domaine que vous avez tapé, récupère ce seul fichier, et garde la réponse dix minutes.