Vérificateur d'enregistrement TLS-RPT (SMTP TLS Reporting)
Récupère l'enregistrement TXT _smtp._tls d'un domaine pour diagnostiquer si la destination des rapports (rua) pour les connexions TLS échouées est correctement configurée selon la RFC 8460. Utile en complément de MTA-STS/DANE.
Astuces
- TLS-RPT est déclaré par le domaine destinataire mais utilisé par les serveurs de messagerie expéditeurs, qui s'en servent pour savoir où envoyer les statistiques lorsqu'une connexion TLS vers votre domaine échoue.
- Le champ rua peut indiquer une adresse mailto:, un point de terminaison https:, ou les deux séparés par des virgules, ce qui permet d'envoyer les rapports à la fois vers une boîte aux lettres et vers un collecteur automatisé.
- Les rapports arrivent au format JSON (application/tlsrpt+json, souvent compressé en gzip) ; il est donc utile de mettre en place un analyseur ou une boîte aux lettres dédiée plutôt que de vouloir les lire à l'œil nu.
- Juste après le déploiement de MTA-STS ou DANE, il est conseillé de surveiller les rapports TLS-RPT pendant un certain temps afin de repérer une éventuelle erreur de configuration passée inaperçue.
- Les grands fournisseurs de messagerie comme Google, Microsoft et Yahoo envoient tous des rapports TLS-RPT, si bien que les domaines qui échangent beaucoup de courrier avec eux tirent le plus grand bénéfice de son adoption.
Questions fréquentes
Anecdote — La faille des « échecs silencieux » que TLS-RPT est venu combler
TLS-RPT (TLS Reporting, RFC 8460) a été publié en 2018, quasiment en même temps que MTA-STS (RFC 8461). Les deux ont été développés au sein du même groupe de travail et ont beaucoup en commun — tous deux s'appuient sur un enregistrement TXT du DNS, et tous deux ont été poussés conjointement par Google, Microsoft, Yahoo et d'autres —, mais ils jouent des rôles très différents. MTA-STS est la couche d'application qui impose TLS ; TLS-RPT est la couche d'observabilité qui révèle ce qui s'est réellement passé une fois cette contrainte appliquée.
Avant l'existence de TLS-RPT, un échec de négociation TLS lors d'une livraison SMTP n'était, dans la plupart des cas, consigné que sur le serveur expéditeur, sans jamais être signalé à l'administrateur du domaine destinataire. Un certificat expiré ou une politique MTA-STS mal configurée pouvait interrompre silencieusement la livraison du courrier, et personne ne s'en apercevait avant que le courrier cesse réellement d'arriver — un véritable angle mort opérationnel.
Avec TLS-RPT en place, un rapport agrégé quotidien est envoyé à la destination indiquée dans rua. Le rapport est un JSON structuré (application/tlsrpt+json, souvent compressé en gzip) contenant le nombre de succès et d'échecs et, pour les échecs, la cause sous-jacente (incompatibilité de certificat, échec de la négociation STARTTLS, etc.) — conçu pour être traité par des outils de supervision plutôt que lu par un humain.
En pratique, TLS-RPT est généralement configuré conjointement avec MTA-STS ou DANE. Déployer uniquement l'application forcée ne permet pas de détecter si une erreur de configuration bloque silencieusement du courrier légitime ; surveiller les rapports TLS-RPT permet de déployer cette application forcée en toute sécurité.