MTA-STS bloqué en mode testing : comment passer en enforce sans risque
La réponse courte
En mode: testing, les serveurs expéditeurs vérifient le TLS de vos serveurs de messagerie mais livrent quand même quand la vérification échoue ; ils se contentent de le signaler (RFC 8461 §5). Pour passer en enforce : lisez les rapports TLS-RPT jusqu'à ce qu'ils soient propres, assurez-vous que chaque MX figure dans la politique et sert un certificat valide pour son propre nom, changez le mode, et changez l'id dans votre enregistrement _mta-sts.
Ce que fait un expéditeur, mode par mode
Le fichier de politique décide de ce que fait un serveur expéditeur quand il ne parvient pas à établir une connexion sécurisée avec l'un de vos hôtes MX :
| Mode | Certificat valide, MX dans la politique | La vérification échoue |
|---|---|---|
none | Livre comme s'il n'y avait pas de politique | Livre |
testing | Livre via TLS | Livre quand même et signale l'échec |
enforce | Livre via TLS | Ne livre pas à cet hôte ; essaie un autre MX listé, ou met en file d'attente et réessaie |
Les expéditeurs conservent votre politique pendant max_age secondes et ne la récupèrent à nouveau que lorsque l'id de votre enregistrement TXT _mta-sts change. Modifiez le fichier sans changer l'id, et les expéditeurs qui l'ont en cache continuent d'appliquer l'ancien mode jusqu'à l'expiration de max_age.
Ce que testing laisse ouvert, et ce qu'enforce peut casser
- Testing ne protège rien. Quelqu'un qui supprime STARTTLS ou répond avec un faux certificat reçoit quand même le courrier : en mode testing, l'expéditeur livre quand même. RFC 8461 §5
- Un MX absent de la politique ne reçoit plus de courrier en enforce. Les expéditeurs ne livrent qu'aux hôtes qui correspondent à une ligne mx:. RFC 8461 §4.1
- Un certificat qui ne nomme pas l'hôte MX échoue. Enforce exige un certificat valide, non expiré, émis par une AC publique et correspondant au nom d'hôte du MX lui-même. RFC 8461 §4.1
- Le fichier de politique doit être servi exactement. En HTTPS sur mta-sts.<votre domaine>, à /.well-known/mta-sts.txt, avec un certificat valide, en text/plain et sans redirection. Un expéditeur qui ne peut pas le récupérer garde sa copie en cache jusqu'à son expiration. RFC 8461 §3.3
Contrôlez votre politique MTA-STS
Le contrôle gratuit du domaine lit votre enregistrement _mta-sts et votre fichier de politique, et vous indique le mode, le max_age, si le fichier a pu être récupéré et quels hôtes MX la politique oublie.
Gratuit, sans compte. Nous lisons uniquement le DNS public et ce que vos serveurs montrent à quiconque s'y connecte.
Corriger, étape par étape
Publiez d'abord TLS-RPT
Ajoutez un enregistrement TXT sur _smtp._tls.example.com avec v=TLSRPTv1; rua=mailto:tls-reports@example.com. Les expéditeurs vous envoient alors un rapport quotidien des réussites et des échecs TLS (RFC 8460).
Lisez les rapports jusqu'à ce qu'ils soient propres
Cherchez les échecs par hôte MX. Une série de rapports propres sur une période normale de trafic de messagerie, souvent deux semaines environ, est le signal qu'enforce est sans risque.
Faites correspondre chaque MX à la politique
Chaque hôte MX doit correspondre à une ligne mx: du fichier de politique. Un motif tel que *.mail.example.com ne couvre qu'un seul label.
Vérifiez le certificat de chaque MX
Chaque MX doit présenter un certificat valide, non expiré, émis par une AC publique et contenant son propre nom d'hôte. Un certificat interne ou auto-signé échoue en enforce.
Passez en enforce et augmentez max_age
Modifiez le fichier en mode: enforce et réglez max_age sur au moins une semaine (604800 secondes).
Changez l'id
Changez la valeur id dans l'enregistrement TXT _mta-sts, par exemple en y mettant la date et l'heure du jour. C'est ce qui indique aux expéditeurs de récupérer la nouvelle politique.
Avant d'ajouter plus tard un MX, mettez d'abord la politique à jour
Ajoutez la ligne mx: du nouvel hôte, changez l'id, attendez max_age, et seulement ensuite dirigez le courrier vers le nouvel hôte.
Erreurs fréquentes
Modifier le fichier mais pas l'id
Les expéditeurs qui ont mis en cache la politique testing continuent de l'appliquer jusqu'à l'expiration de max_age, ce qui peut prendre des semaines.
Dans le résultat SkyQon : nous récupérons le fichier de politique lui-même : notre résultat peut donc afficher enforce avant les expéditeurs. C'est l'id qui les amène à le récupérer.
Ajouter un nouveau MX avant de mettre à jour la politique
En enforce, les expéditeurs refusent de livrer à un hôte qui ne correspond à aucune ligne mx:.
Dans le résultat SkyQon : un constat nomme chaque hôte MX qui ne correspond à aucune ligne mx:. En mode enforce, il indique que les expéditeurs refuseront ou ignoreront ces hôtes ; en mode testing, que rien n'est encore refusé.
Servir la politique derrière une redirection
Beaucoup de serveurs web redirigent par défaut. RFC 8461 interdit de suivre une redirection pour le fichier de politique : les expéditeurs considèrent donc MTA-STS comme absent.
Dans le résultat SkyQon : un constat indiquant que la politique n'a pas pu être récupérée, avec la raison, par exemple une redirection ou un type de contenu autre que text/plain.
Un max_age de quelques minutes
Les expéditeurs récupèrent alors la politique sans arrêt et, un mauvais jour, ils reviennent plus vite à l'absence de politique.
Dans le résultat SkyQon : un constat quand max_age est inférieur à un jour.
Ce que SkyQon fait et ne fait pas
Ce que ça trouve
Votre enregistrement _mta-sts et votre fichier de politique : le mode, max_age, si chaque hôte MX correspond à une ligne mx:, si le fichier peut être récupéré, et si une adresse TLS-RPT est publiée.
Ce que vous obtenez
Dans le contrôle gratuit, un constat pour le mode testing et pour les hôtes MX que la politique oublie. Sur un domaine surveillé, une alerte tant que la politique reste en testing ou oublie un hôte MX. À partir de Pro, les rapports TLS-RPT que vous envoient les expéditeurs, lus et résumés.
Ce que ce n’est pas
Nous n'évaluons pas encore le certificat de chaque MX pour MTA-STS, et nous ne modifions pas votre fichier de politique. Vérifiez les certificats des MX avant de passer en enforce.
MTA-STS : les questions fréquentes
Combien de temps rester en mode testing ?
Ai-je besoin de TLS-RPT pour que MTA-STS fonctionne ?
Qu'arrive-t-il au courrier si le certificat d'un MX expire en enforce ?
MTA-STS protège-t-il le courrier que j'envoie ?
MTA-STS est-il la même chose que DANE ?
Quel max_age utiliser ?
Que fait mode: none ?
Pourquoi l'id compte-t-il autant ?
Sources
- RFC 8461 §3.1 : l'enregistrement TXT _mta-sts et son id
- RFC 8461 §3.2 : le fichier de politique, mode et max_age
- RFC 8461 §3.3 : récupération de la politique (HTTPS, sans redirection)
- RFC 8461 §4.1 : validation de l'hôte MX et du certificat
- RFC 8461 §5 : application de la politique dans chaque mode
- RFC 8460 : SMTP TLS Reporting (TLS-RPT)
Pages associées
Sachez quand vous pouvez passer en enforce sans risque.
Le contrôle gratuit montre votre mode MTA-STS actuel. À partir de Pro, SkyQon lit vos rapports TLS-RPT : vous voyez les échecs avant de basculer.