Résumé

  • STARTTLS protégeait une connexion SMTP, mais le message survivait à cette connexion dans les files d’attente et pouvait rencontrer plus tard un relais qui privilégiait la livraison. RFC 8689 a fait de REQUIRETLS une obligation transportée avec chaque message.
  • Si aucun MX ne présente une identité valide, une session TLS acceptable et l’annonce REQUIRETLS après chiffrement, le relais doit produire un avis de non-remise au lieu de retomber en clair. La protection reste saut par saut : les MTA de confiance voient toujours le contenu.

Un certificat arrive à expiration. L’administrateur du domaine destinataire doit être prévenu, mais sa propre politique MTA-STS ou DANE empêche les serveurs conformes de lui transmettre le message d’alerte. La sécurité fonctionne si strictement qu’elle bloque la description de sa panne.

Le RFC 8689 a prévu une sortie étroite : l’en-tête TLS-Required: No. Il demande au relais d’essayer STARTTLS, mais de ne pas laisser la politique TLS publiée par le destinataire rendre la livraison impossible. Ce cas curieux révèle toute l’architecture de REQUIRETLS. Le protocole ne décide pas simplement entre « chiffrement » et « absence de chiffrement ». Il distribue le droit de dire quelle sorte d’échec est acceptable.

L’autre face du mécanisme est plus connue. Un expéditeur peut marquer un message de manière à refuser toute remise si les relais suivants ne préservent pas une liaison TLS authentifiée. Cette volonté doit franchir les files, les reprises, les alias et les changements de connexion. Elle ne peut donc pas rester une propriété de la poignée de main initiale.

Une connexion sécurisée ne suffisait pas à gouverner l’itinéraire

Le RFC 2487, en 1999, a introduit STARTTLS dans SMTP. Son compromis venait de la mission historique du courrier public : accepter des correspondants très hétérogènes et acheminer malgré les écarts de capacité. Rendre TLS immédiatement obligatoire sur tout MX aurait créé des îlots incompatibles. La livraison restait prioritaire.

Le RFC 3207 a révisé l’extension en 2002. Le serveur annonce STARTTLS, le client le demande, puis la réponse 220 ouvre la négociation TLS. Une fois celle-ci terminée, chaque côté oublie les informations apprises en clair et le client envoie un nouvel EHLO. L’annonce protégée peut différer de la première.

Ce second salut établit une frontière de confiance pour la connexion courante. Il ne suit pas le message après son acceptation. SMTP est un système de stockage et transfert : le serveur écrit le courrier en file, ferme la session, attend, choisit un autre MX et devient client d’un autre serveur. La règle de la première connexion est morte alors que le message vit encore.

Deux politiques de domaine ont ensuite renforcé le côté destinataire. Le RFC 7672 associe SMTP DANE à des enregistrements TLSA validés par DNSSEC. Le RFC 8461 permet au domaine de publier par HTTPS une politique MTA-STS mise en cache, avec noms MX autorisés et validation PKIX. Ces mécanismes disent ce qu’un domaine destinataire exige. Ils ne donnaient pas encore à l’auteur la possibilité de distinguer un seul message sensible au milieu d’un trafic ordinaire.

Le choix entra dans l’enveloppe

Publié en 2019, le RFC 8689 a défini une capacité EHLO, REQUIRETLS, et un paramètre sans valeur sur la commande existante :

MAIL FROM:<sender@example> REQUIRETLS

Il n’a pas ajouté de verbe. L’enveloppe était l’endroit décisif : elle dirige le transfert SMTP présent, tandis qu’un en-tête fait partie du contenu remis. Le client ne peut employer le paramètre qu’après avoir créé une session TLS répondant à plusieurs preuves.

Le MX doit être rattaché au domaine par DNSSEC ou contrôlé par MTA-STS lorsque le DNS ne l’authentifie pas. Le certificat du serveur doit réussir une chaîne de confiance acceptée ou la validation DANE. Enfin, le serveur doit réannoncer REQUIRETLS dans l’EHLO envoyé après STARTTLS. Une promesse vue seulement en clair n’a pas cette valeur.

Le serveur qui accepte le message le marque en interne. Le RFC ne dicte ni colonne de base de données ni bit de fichier de file d’attente. Il impose le résultat : lorsqu’il relaiera le message, il devra reconstruire les conditions et replacer le paramètre dans le nouveau MAIL FROM.

Si un alias local produit plusieurs destinataires, toutes les instances gardent la même marque. L’obligation accompagne le traitement du message ; elle n’est pas une propriété accidentelle de la première session.

Le relais devait réunir quatre preuves

Lors d’une transmission ultérieure, « TLS actif » n’est qu’une partie du dossier. Le relais choisit d’abord le prochain serveur selon le routage du RFC 5321. Il vérifie que le nom MX représente bien le domaine. Il établit TLS et valide le certificat. Puis il exige l’annonce REQUIRETLS dans la réponse EHLO protégée.

Chaque élément ferme une substitution différente. Le chiffrement protège les octets contre l’écoute. Le certificat ou DANE lie la clé à une identité. DNSSEC ou MTA-STS limite les noms autorisés à représenter la destination. L’annonce après TLS atteste que le prochain MTA accepte la responsabilité de conserver la marque.

Une connexion chiffrée vers un faux MX reste un mauvais résultat. Un certificat valide sur le bon serveur ne prouve pas que celui-ci saura transmettre l’exigence. Un tableau de bord réduit à « TLS : oui » mélange donc la cryptographie, l’identité, la politique et la continuité de garde.

L’échec retira le droit de transmettre

Si le premier MX ne satisfait pas les conditions, le relais quitte la tentative et passe au suivant. Il peut encore livrer au même serveur des messages ordinaires. REQUIRETLS ne condamne pas un domaine ; il limite une enveloppe précise.

Lorsque tous les MX ont échoué, le message ne doit pas être transmis au domaine. Le RFC 8689 recommande 5.7.30 si le serveur ne prend pas REQUIRETLS en charge, et 5.7.10 si la session TLS protégée ne peut être établie. Un avis de non-remise part vers le reverse-path.

La nouveauté historique tient à cette conséquence. Avec TLS opportuniste, l’échec de négociation pouvait autoriser une tentative moins protégée. Avec REQUIRETLS, il enlève l’autorité d’envoyer. La disponibilité perdue devient le prix explicite d’une contrainte respectée.

Ce prix peut venir d’une erreur et non d’une attaque : certificat périmé, politique inaccessible, MX secondaire ancien, annonce oubliée après la poignée de main. Le message aurait pu arriver en clair. Le protocole choisit néanmoins un échec vérifiable plutôt qu’un succès qui change silencieusement la promesse de départ.

Le diagnostic devait être protégé lui aussi

Un avis de non-remise cite souvent les en-têtes du courrier fautif. Il peut révéler expéditeur, destinataire, objet ou étapes de routage. Protéger l’aller puis renvoyer le diagnostic en clair ouvrirait une fuite latérale.

Tout avis de non-remise issu d’un message REQUIRETLS doit donc porter REQUIRETLS, même si la cause initiale n’avait rien à voir avec TLS. Pour limiter le contenu reproduit, il est traité comme si l’option DSN RET=HDRS avait été demandée ; RET=FULL doit être ignoré.

Le retour possède pourtant un autre chemin. Les avis de non-remise utilisent un chemin de retour vide afin d’empêcher une boucle d’erreurs. Le domaine d’origine peut ne pas offrir la même prise en charge que la destination. Le RFC avertit alors que l’avis protégé peut se perdre et ménage un traitement particulier au message dont le chemin de retour est vide.

L’absence de diagnostic ne prouve donc pas une remise. Le courrier original a pu être retenu correctement tandis que l’explication ne trouvait aucun retour compatible.

L’en-tête négatif ne commandait pas le texte clair

TLS-Required: No répond au paradoxe d’ouverture. Il indique au MTA expéditeur de ne pas laisser DANE ou MTA-STS provoquer un échec lorsque l’auteur souhaite que le message passe malgré une mauvaise configuration. STARTTLS reste souhaitable et doit être tenté lorsqu’il est disponible.

Le champ ne force jamais le serveur destinataire à accepter une liaison en clair. Celui-ci peut exiger STARTTLS à son entrée et refuser la transaction. La politique de l’auteur module le comportement du relais ; elle n’abolit pas le contrôle du destinataire.

Si le paramètre REQUIRETLS figure déjà dans l’enveloppe, il l’emporte et le champ est ignoré pour le traitement. Deux champs TLS-Required dans le même message sont interdits. Le contenu ne peut donc pas affaiblir une obligation négociée sur une enveloppe protégée.

Changer d’auteur rompait la chaîne mécanique

Le relais ordinaire garde le même message. Une liste de diffusion, un redirecteur, un script Sieve ou une réponse automatique peut en créer un nouveau. Le RFC 8689 leur demande de reprendre la décision d’entrée dans la mesure du possible.

Cette formule reconnaît une limite. Une liste peut joindre cent domaines, dont certains sans REQUIRETLS. Maintenir l’exigence rend une partie de la diffusion impossible. Un filtre côté utilisateur peut ignorer la marque SMTP, car elle n’apparaît pas nécessairement dans le contenu livré.

La technologie rencontre ici une question institutionnelle : l’intermédiaire transporte-t-il encore la parole de l’auteur, ou devient-il l’auteur d’un autre message ? La norme rend cette frontière visible sans prétendre la résoudre par un champ universel.

Les relais restaient des dépositaires du texte

REQUIRETLS n’est pas du chiffrement de bout en bout. Chaque MTA termine TLS, voit le contenu, puis ouvre une autre session. Un relais malveillant peut mentir sur sa capacité ou supprimer la marque. Le RFC l’exclut du modèle de menace puisqu’il détient déjà le texte en clair.

Le mécanisme protège contre l’écoute passive, le retrait de STARTTLS, la substitution de MX et la rétrogradation accidentelle entre systèmes conformes. Il n’authentifie pas l’auteur humain, ne chiffre pas les files au repos et ne prouve pas les sauts qui suivent celui observé.

Le registre SMTP de l’IANA atteste l’attribution du mot REQUIRETLS et son RFC. Il ne mesure ni déploiement, ni trafic, ni conformité.

L’apport durable est une règle de continuité. Dans un réseau où les connexions disparaissent avant les messages, l’intention doit être stockée, rejouée et contrôlée à chaque transfert. REQUIRETLS n’a pas promis que le courrier arriverait secrètement. Il a permis de dire qu’un courrier qui ne pouvait plus respecter sa condition ne devait pas arriver autrement.