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.
Diagnostiquer les rapports de connexions TLS échouées (TLS-RPT)
Adopter MTA-STS ou DANE laisse une chose hors de vue : **savoir si la remise échoue réellement n'appartient qu'au côté expéditeur.** TLS-RPT est l'arrangement qui comble ce vide. Inscrivez une adresse de rapport dans l'enregistrement TXT `_smtp._tls` et **les serveurs expéditeurs vous enverront un rapport quotidien.** Cet outil récupère cet enregistrement et rapporte si sa forme se conforme à la RFC 8460.
**TLS-RPT n'est pas en soi une défense, mais un moyen d'observation.** Il ne fait rien pour arrêter une attaque ; il se borne à vous dire combien de fois l'établissement de TLS a échoué. **Sans cette observation, pourtant, nul moyen de juger du moment de passer MTA-STS à `enforce`.** Si la remise s'arrêtait à l'instant où l'obligation commence, vous ne l'apprendriez qu'à la première plainte. **L'ordre établi en pratique consiste donc à poser d'abord TLS-RPT, à tenir MTA-STS à `testing` tout en lisant les rapports, et à ne passer à `enforce` qu'une fois assuré que rien n'échoue.**
Comment s'en servir
- Saisissez le domaine Indiquez le seul domaine, sous la forme `example.com`.
- Contrôlez l'enregistrement TXT **Cherchez `v=TLSRPTv1` et un `rua=`.**
- Confirmez la forme de l'adresse de rapport Elle s'écrit avec `mailto:` ou `https:`. **Confirmez aussi que cette adresse peut réellement recevoir.**
- Décidez qui lira les rapports **Le poser sans jamais les lire ne mène à rien.** Décidez qui regarde, et quand.
Astuces pour en tirer le meilleur parti
- 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.
Dans quels cas s'en servir
Avant de porter MTA-STS à l'obligation
**Vous mesurez si quelque chose échoue tant que vous demeurez à `testing`**, ce qui fonde votre décision.
Pour remarquer tôt un souci de remise
Vous apprenez que des échecs surviennent sans attendre qu'on vous le signale.
Pour surveiller après l'adoption de DANE
**Un décalage entre certificat et enregistrement TLSA paraît dans les rapports comme un échec.**
Pour confirmer la forme de votre enregistrement
Une erreur dans l'écriture de `rua` se manifeste par l'absence de tout rapport.
Vocabulaire de TLS-RPT
- _smtp._tls TXT
- **L'enregistrement DNS portant l'adresse de rapport.** Il s'écrit sous la forme `v=TLSRPTv1; rua=mailto:...`.
- Rua
- Où les rapports doivent parvenir. **Indiquez une adresse électronique ou un point HTTPS prêt à les recevoir.**
- RFC 8460
- La norme définissant le format de TLS-RPT et le contenu d'un rapport.
- Rapport quotidien
- Le rapport qu'un serveur expéditeur envoie pour une journée. Il porte le compte des succès et des échecs ainsi que les motifs de ces derniers.
- MTA-STS
- L'arrangement qui impose TLS. **TLS-RPT lui est associé afin de voir comment cette imposition se passe réellement.**
- DANE
- L'arrangement qui valide les certificats sur la prémisse de DNSSEC. **Les ennuis de ce côté ressortent eux aussi dans les rapports TLS-RPT.**
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é.