Résumé

  • La section 6.5 de draft-ietf-emailcore-as-30 demande aux implémentations réceptrices de pouvoir accepter du courrier avec ou sans confidentialité du transport, tout en laissant la conduite à tenir dans un cas précis à la politique locale. Le document reste un Internet-Draft en suivi par le directeur de domaine, pas un RFC.
  • Le texte précédent interdisait aux récepteurs d’exiger la confidentialité des expéditeurs. Les échanges publics de fin septembre portent sur l’utilité et la portée de la nouvelle obligation de capacité ; ils ne constituent ni une décision finale de l’IESG ni une preuve des pratiques de tous les opérateurs.

Dans une entreprise, un relais privé peut être configuré pour interrompre une session non chiffrée. L’administrateur a alors fixé une condition d’entrée ; il n’a pas nécessairement choisi un produit incapable de traiter techniquement une telle session. La distinction est familière à qui gère un service de messagerie, mais elle disparaît facilement quand un texte de normalisation utilise le verbe « accepter » sans préciser le niveau auquel il s’applique.

La révision 30 de l’applicability statement EMAILCORE rend ce niveau central. Son paragraphe 6.5 impose aux émetteurs SMTP de recourir à la confidentialité lorsqu’elle est disponible et acceptée par le destinataire. Il formule ensuite, pour les récepteurs, une capacité à recevoir avec ou sans confidentialité. La phrase suivante réserve explicitement le choix concret de l’émetteur ou du récepteur à la politique locale. En révision 29, l’injonction adressée aux récepteurs était différente : ne pas exiger des expéditeurs une confidentialité sur le trajet.

Le journal des modifications signale la réécriture de cette partie durant l’examen de l’IESG. Il serait faux de présenter la formulation ancienne comme le texte actuel, ou l’édition nouvelle comme un simple changement cosmétique.

Ce glissement n’a pas clos la discussion. La fiche Datatracker indique toujours un Internet-Draft actif, à la révision 30, dans l’état « AD Followup ». Des positions DISCUSS restent visibles au scrutin ; certaines remontent à la révision 29 et ne portent pas toutes sur la même objection. Le 18 septembre, John Klensin, l’un des rédacteurs, a précisé dans une réponse à Roman Danyliw que certains propos étaient personnels et n’avaient pas encore été soumis au groupe de travail.

Le 28 septembre, Eric Rescorla a demandé pourquoi conserver une obligation que ses défenseurs jugeraient sans effet supplémentaire ; Rob Sayre a mis en avant la séparation entre possibilité technique et décision d’exploitation. Ces interventions sont des arguments attribuables à leurs auteurs, non une position officielle consolidée de l’IETF.

Une autre erreur serait d’ignorer la règle déjà en vigueur. RFC 3207 traite de STARTTLS et indique qu’un serveur SMTP référencé publiquement ne doit pas imposer ce mécanisme pour la livraison locale ; il distingue le serveur non référencé publiquement, qui peut l’exiger. Le périmètre compte : ce texte ne dit pas que tout service doit admettre toute session en clair. Il ne répond pas non plus à la question plus générale de la capacité que devrait conserver chaque implémentation conforme à un futur document EMAILCORE.

RFC 8689 se situe encore ailleurs. REQUIRETLS donne à un message particulier une instruction qui peut faire échouer sa transmission plutôt que de renoncer à la confidentialité sur des relais qui prennent ce mécanisme en charge. Une précédente couverture de BTW examine ce choix attaché au message. L’actuelle question n’est pas de réexpliquer cette option, mais de savoir ce qu’un standard devrait demander au logiciel récepteur lui-même. Capacité du produit, politique du relais, cas du serveur public et exigence d’un message ne sont pas des synonymes.

L’enjeu pratique est celui de la marge de décision laissée à chacun. Un éditeur peut livrer un produit capable de recevoir en clair sans dicter l’ouverture d’un relais privé. Un opérateur peut appliquer une règle de chiffrement stricte sans modifier les possibilités de son logiciel. Mais si ces deux étages se confondent dans la lecture d’un standard, une exigence de conformité pourrait être invoquée à tort pour lever une restriction locale. À l’inverse, supprimer totalement la capacité du produit rendrait plus coûteuse une exception d’interopérabilité.

Le brouillon ne mesure pas ces coûts et n’a pas encore acquis le statut d’une norme publiée.

Sources