Résumé

  • L’id TXT signale qu’il faut rechercher une nouvelle politique. Il n’en contient ni n’en signe le texte, ne prouve pas que tous les expéditeurs l’ont obtenu et n’annule pas les caches encore valides. Pour un MTA donné, la règle applicable est un corps HTTPS authentifié, associé à une collecte et à une échéance max_age locales.
  • Une décision vérifiable relie découverte DNS, certificat du serveur de politique, octets et filiation du cache, parcours MX, STARTTLS, certificat du serveur de réception, file d’attente, nouvelle vérification et sort final. enforce limite un transport SMTP ; il ne prouve ni remise, ni secret de bout en bout, ni identité humaine, ni autorisation métier.

Deux décisions opposées peuvent être conformes

La scène initiale est un test construit, pas le récit d’une panne. L’expéditeur A voit le nouvel ID, authentifie mta-sts.<domaine>, télécharge le nouveau fichier et ouvre une nouvelle période de cache. Son état autorise le MX de secours.

B échoue à rafraîchir. RFC 8461 lui impose de conserver une politique non expirée lorsque la découverte ou la collecte en direct est indisponible. Le MX nouvellement résolu ne figure pas dans cette ancienne politique : B le rejette comme candidat et diffère le message. En revanche, un expéditeur sans cache valide qui verrait le TXT mais ne pourrait pas obtenir le fichier continuerait comme si MTA-STS n’était pas déployé.

Le site du destinataire ne suffit donc pas à expliquer une décision passée. Il faut demander quels octets authentifiés l’expéditeur pouvait appliquer à cet instant, et non quelle politique le destinataire affiche aujourd’hui.

L’ID annonce une variation ; il ne porte pas la règle

MTA-STS sépare découverte et contenu. Le TXT _mta-sts.<domaine-de-politique> fournit une version et un identifiant d’instance. Le registre IANA rend ces noms interopérables, sans certifier un enregistrement particulier ni l’adoption par un fournisseur.

L’ID n’est pas l’empreinte du fichier. Il ne lie ni mode, ni mx, ni max_age. Il ne dit pas si le nouveau corps a précédé le changement DNS, si toutes les vues autoritatives répondent pareil, si tous les relais HTTPS servent les mêmes octets ou si chaque expéditeur a achevé sa collecte.

L’ordre du déploiement devient donc une question d’autorité. Modifier le fichier sans l’ID laisse légitimement des expéditeurs sur l’ancien cache. Modifier l’ID avant la diffusion du fichier peut faire récupérer l’ancien corps avec une nouvelle durée. Un tableau qui ne conserve que le TXT courant décrit une intention, pas une réalité appliquée.

HTTPS authentifie un corps précis

Le fichier réside sur l’hôte de politique mta-sts.<domaine>, au chemin fixe /.well-known/mta-sts.txt. Le MTA expéditeur valide le certificat du serveur de politique : période valide, chaîne vers une racine qu’il accepte et identité DNS correspondant au nom mta-sts. Le SNI de cette connexion porte ce nom, non celui du futur MX.

Le corps énonce version, mode, max_age et, sauf en mode none, un ou plusieurs motifs MX. Les preuves doivent garder la réponse brute, son empreinte, le Content-Type, l’heure, la chaîne, le résultat de nom, la version du magasin de confiance, les valeurs analysées et l’échéance. Un simple booléen « configuré » perd la garde de la règle.

La première acquisition demeure fragile. Si le TXT existe mais que HTTPS échoue sans cache préalable, l’expéditeur se comporte comme si MTA-STS n’existait pas. Le protocole devient résistant à l’interférence après une collecte authentifiée ; il ne transforme pas l’absence DNS non signée en preuve authentifiée.

max_age produit plusieurs présents légitimes

La durée part de la collecte réussie de chaque expéditeur. Elle n’est pas une échéance universelle. Résolveurs régionaux, accès HTTPS, redémarrages, réplication et rafraîchissement anticipé créent des dates d’expiration différentes pour le même fichier.

C’est à la fois la continuité et le risque. Supprimer le cache à la première panne de rafraîchissement permettrait à un attaquant de désactiver enforce en bloquant le serveur de politique. Mais une politique longue et erronée reste contraignante après la réparation visible du destinataire.

La sortie propre passe par une politique none authentifiée, une courte durée, un nouvel ID, puis l’attente de tous les anciens caches susceptibles de se chevaucher. Effacer d’abord TXT et HTTPS n’est pas une révocation ; cela peut laisser une ancienne politique active tout en supprimant son chemin de libération.

La portée est un MX et une connexion

Le MTA parcourt les MX dans l’ordre SMTP habituel. Le nom du candidat doit correspondre à un motif mx appliqué. Le joker ne couvre que l’étiquette la plus à gauche : *.example.net ne couvre ni l’apex ni deux sous-niveaux.

Le serveur doit ensuite proposer STARTTLS et présenter un certificat PKIX non expiré, lié à une racine de confiance de l’expéditeur et valable pour le nom du MX. Le SNI SMTP porte ce nom. Le succès établit un prochain saut authentifié pour cet essai ; il n’authentifie pas l’auteur visible, le titulaire de la boîte ou le contenu.

Un candidat invalide se traite comme temporairement inaccessible et le parcours normal continue. Un MX de secours absent de la politique peut rester invisible jusqu’à la panne du primaire. Le voyant vert obtenu uniquement contre le primaire ne prouve donc pas le chemin de repli.

La file d’attente donne son effet au contrôle

En mode enforce, l’expéditeur ne livre pas au candidat qui échoue sur le nom MX, STARTTLS ou le certificat. Il ne peut pourtant pas transformer aussitôt cet échec en rejet définitif. Avant l’échec permanent, il doit vérifier dans le DNS si un nouvel ID de politique existe ; les règles de panne temporaire et de nouvelle tentative restent applicables.

Le report laisse au destinataire le temps de corriger. Le rejet définitif ferme la transaction. Il faut donc conserver ID de file, politique appliquée et échéance, ordre des candidats, échec exact, prochain essai, vérification finale du TXT et disposition. Une trace TLS sans transition de file ne prouve pas le sort du message.

TLSRPT décrit une population, pas un message

RFC 8460 permet aux expéditeurs participants de rapporter politiques détectées, volumes et classes d’échec. Les surfaces actuelles de Microsoft et Google montrent des implémentations en fonctionnement et des rapports de transport.

Le témoignage reste partiel : seuls les expéditeurs qui implémentent et livrent un rapport apparaissent. Un agrégat quotidien n’est pas un accusé de réception individuel. Il ne prouve ni lecture, ni conservation, ni secret chez chaque intermédiaire, ni décision commerciale.

L’analyse doit rapprocher publication du destinataire, état exécuté chez l’expéditeur et observation du rapporteur. Une politique peut être valide en syntaxe et absente d’un cache ; un ancien cache peut rester valide alors que le contrôleur du destinataire affiche le nouveau texte.

DANE et REQUIRETLS sont d’autres autorités

SMTP DANE authentifie par DNSSEC et TLSA. RFC 8461 interdit qu’un succès MTA-STS serve à contourner un échec DANE. La validation PKIX ne blanchit pas un résultat plus fort qui a échoué.

REQUIRETLS exprime une intention de l’auteur pour un message et dépend de relais compatibles. MTA-STS exprime une politique de domaine destinataire que les expéditeurs compatibles appliquent ; il ne classe pas la sensibilité d’un message. Aucun des deux ne crée un chiffrement du contenu de bout en bout par la seule présence de TLS entre MTA.

« MTA-STS réussi » ne signifie donc ni « l’auteur a exigé le secret », ni « le destinataire a accepté », ni « l’utilisateur a reçu », ni « l’action est autorisée ». La preuve s’arrête à l’opération contrôlée.

Rejouer une décision

L’unité minimale indexe domaine, expéditeur, tentative et heure. Elle relie octets TXT, ID, TTL et état DNSSEC ; réponse HTTPS et certificat ; empreinte, mode, MX, collecte et expiration ; RRset et ordre MX ; SNI, STARTTLS et certificat SMTP ; DANE ; file, actualisation, dernier contrôle ID ; TLSRPT et résultat final.

Les canaris doivent couvrir fichier sans nouvel ID, ID avant fichier, blocage HTTPS avec et sans cache, expiration, bascule vers le MX de secours, mauvais certificat de politique, mauvais certificat MX, publication de none et tentative de passage après échec DANE.

Le standard définit une langue mince ; le destinataire propose ; PKIX authentifie un corps ; chaque expéditeur lui donne une durée locale ; le SMTP réel le teste ; la file produit la conséquence. La dernière chaîne DNS ne mérite pas davantage d’autorité.

Sources