Résumé

  • Le modèle expérimental du RFC 5335 permettait d’accompagner une adresse non ASCII d’une adresse de repli ASCII. En cas d’incompatibilité du chemin SMTP, le mécanisme de rétrogradation pouvait choisir cette seconde destination ; la norme admettait qu’elle puisse appartenir à une autre boîte ou à une autre personne.
  • Le RFC 6530 a ensuite constaté que la liaison entre les deux adresses ne pouvait pas être authentifiée de manière satisfaisante, que les premières implémentations interopéraient mal et que la complexité durable dépassait le bénéfice. Le modèle normalisé a supprimé la rétrogradation en transit.

L’association figurait dans le message, pas dans une preuve d’identité

Deux chaînes apparaissent dans la même structure. La première utilise des caractères UTF-8 et correspond à l’adresse que l’expéditeur veut atteindre. La seconde ne contient que de l’ASCII et doit permettre au message de traverser un environnement ancien. Un logiciel peut parser la paire, vérifier sa grammaire et conserver chaque octet sans erreur.

Il n’a toujours pas répondu à la question essentielle : qui a le droit d’affirmer que l’adresse B représente le même destinataire que l’adresse A ?

Une adresse électronique n’est pas la traduction libre d’un nom affiché. Sa partie locale est interprétée par le domaine qui l’héberge. Une translittération plausible peut désigner une autre boîte. Un alias autrefois correct peut avoir expiré. Une adresse de groupe peut être associée à une adresse personnelle. Une organisation peut réattribuer un identifiant ASCII après le départ de son titulaire initial.

Le RFC 5335 ne promettait pas l’identité des destinations. Il signalait au contraire que les adresses ASCII et non ASCII pouvaient conduire à des boîtes, voire à des personnes, distinctes. La sélection pouvait dépendre des capacités des agents de transfert rencontrés. Le même message, adressé au même identifiant initial, pouvait ainsi changer de destinataire parce que son itinéraire technique avait changé.

Le champ transportait une déclaration. Il ne transportait ni l’auteur de cette déclaration, ni la portée de son mandat, ni sa date de validité, ni une preuve que le titulaire l’avait approuvée.

La capacité d’un relais ne constitue pas un mandat

Le mécanisme de rétrogradation du RFC 5504 rendait la conséquence opérationnelle. Lorsqu’un chemin d’enveloppe non ASCII disposait d’un paramètre ALT-ADDRESS, le système pouvait remplacer ce chemin par l’adresse ASCII décodée. Si le domaine changeait, il fallait parfois abandonner la connexion courante et résoudre une nouvelle route vers le domaine de repli.

La transition n’était donc pas seulement graphique. Elle pouvait changer l’identifiant, le domaine administratif, les politiques antispam, le lieu de conservation et la personne qui ouvrait la boîte.

Le déclencheur, pourtant, restait une information étroite : un serveur suivant n’annonçait pas la capacité expérimentale requise. Ce serveur avait autorité sur ce qu’il acceptait. Il n’avait pas, de ce seul fait, autorité sur l’identité humaine visée par l’expéditeur.

Une architecture sûre limite la conclusion tirée de l’observation. « Ce relais ne peut pas transporter la forme originale » peut justifier un nouvel itinéraire capable, une nouvelle tentative ou un échec visible. Elle ne suffit pas à conclure : « cette autre adresse est la même personne ».

La discipline rejoint la distinction de Lu Heng entre un registre et l’autorité qu’une institution projette à travers lui. Le fait qu’une paire soit enregistrée rend l’association observable. Il ne transforme pas le gestionnaire du champ, le relais ni l’intermédiaire en mandataire du destinataire.

La provenance de la transformation ne validait pas son motif

Les champs Downgraded-* cherchaient à garder la trace des informations remplacées. C’était utile : un opérateur pouvait voir qu’une adresse originale avait été substituée, et certaines données restaient disponibles pour l’analyse.

Mais la provenance de l’opération et l’autorité de l’opération sont deux preuves différentes. Un en-tête peut raconter que A est devenu B sans établir que le propriétaire de A avait accepté B. Il peut aussi avoir été inséré par un acteur malveillant. Le RFC 5504 soulignait les problèmes de confiance de ces nouveaux champs, les pertes d’information possibles et les effets de la réécriture sur les signatures.

Le cas multi-destinataire révélait une autre tension. Inscrire l’adresse originale de chaque destinataire dans un en-tête visible risquait de révéler les autres adresses. La procédure interdisait donc l’ajout de Downgraded-Rcpt-To lorsque plusieurs destinataires partageaient la transaction. La confidentialité exigeait de réduire la trace disponible.

Ce choix était défendable. Il montrait toutefois qu’aucun reçu universel ne survivait à toutes les formes de transaction. Un audit devait connaître la structure d’enveloppe, la politique de confidentialité et les journaux du système de transformation ; lire le message final ne suffisait pas toujours.

Le succès SMTP répondait à la mauvaise question

Une adresse de repli peut accepter le message. Le serveur final peut répondre positivement. Les métriques peuvent annoncer zéro rebond. Pourtant, l’intention initiale reste peut-être inachevée.

La réception par une boîte prouve un résultat de transport borné. Elle ne prouve pas que cette boîte est contrôlée par la personne visée, que l’adresse de repli était encore autorisée, que le message sera présenté au même utilisateur ou qu’une réponse proviendra de la même identité.

Une chaîne de preuve honnête conserve séparément l’adresse demandée, la capacité observée, l’auteur de la liaison, la preuve d’approbation, l’adresse effectivement choisie, le domaine après substitution et le reçu du serveur final. Elle ne remplace pas cette chaîne par un badge « livré ».

La tentation économique va dans l’autre sens. Une plateforme préfère un taux d’acceptation élevé. Un opérateur préfère éviter un incident visible. Une équipe produit préfère un seul état. Ces incitations récompensent la substitution silencieuse, alors que l’échec explicite protège parfois mieux la volonté de l’expéditeur.

L’expérience a réfuté son propre raccourci

Le RFC 5335 appartenait à une série expérimentale publiée en 2008. Le RFC 6532 l’a remplacé sur le chemin des normes en 2012. Le bilan du RFC 6530 est précis : le modèle antérieur reposait sur des équivalents ASCII, mais la paire ne pouvait pas être authentifiée correctement ; les implémentations initiales ont rencontré des problèmes d’interopérabilité ; les exigences et les implications à long terme étaient trop complexes.

La nouvelle architecture a donc supprimé la rétrogradation en transit. Elle privilégie le support UTF-8 natif de bout en bout, dans un environnement dont le transport garantit la propreté 8 bits. Elle ne prétend pas qu’un relais ancien peut être franchi en renommant le destinataire.

Ce renoncement est instructif. Une transition paraît simple tant qu’elle est décrite comme une conversion de caractères. Elle devient lourde dès qu’elle doit préserver l’identité, l’autorisation, la confidentialité multi-destinataire, la vérifiabilité, les signatures et la compatibilité des logiciels.

La leçon dépasse le courrier. Les systèmes d’identité conservent des alias, des comptes de récupération et des noms historiques. Chaque association doit répondre à la même question : existe-t-il une preuve actuelle, révocable et attribuable que les deux identifiants peuvent représenter le même principal dans cette opération précise ? Sans elle, le repli n’est pas une continuité. C’est un nouveau destinataire présenté comme l’ancien.

Sources