Résumé

  • Une adresse ASCII et une adresse SMTPUTF8 peuvent coexister dans le même contact EPP ; le marquage de l'une comme principale n'efface pas l'autre et ne vérifie aucune boîte.
  • La même décision de divulgation s'applique aux deux, tandis que stockage EPP, acheminement SMTP et présentation publique RDAP restent trois surfaces distinctes.

Une extension de données crée souvent une exception de gouvernance. RFC 9873 évite ce piège : le drapeau de divulgation de l'adresse électronique défini par RFC 5733 doit aussi s'appliquer à toute adresse ajoutée. L'opérateur ne peut pas protéger le champ de base et exposer l'extension par simple oubli d'architecture.

Le nouveau champ répond pourtant à un besoin concret. Il peut contenir une adresse ASCII ou SMTPUTF8, servir de solution de repli et recevoir l'attribut facultatif primary. Les messages peuvent être redirigés d'une adresse vers l'autre ; une réponse peut revenir avec une autre adresse ou une autre écriture. La préférence indique donc un ordre de traitement, pas une identité unique.

La frontière de capacité est explicite. Selon RFC 5730, client et serveur déclarent leurs espaces de noms au début de la session. S'ils négocient l'extension, ils doivent accepter, valider, conserver et restituer l'adresse supplémentaire, et prendre en charge SMTPUTF8 pour l'envoi ou la réception. Sans négociation réussie, les données étendues ne doivent circuler dans aucun sens. Cette preuve s'arrête au protocole EPP.

Le modèle d'état est tout aussi précis. Un élément vide supprime l'adresse lors d'une mise à jour ou signale son absence lors d'une consultation ; il ne peut pas porter l'attribut principal. En revanche, un élément non vide, même principal, ne dit rien sur les enregistrements MX, l'existence de la boîte, la qualité d'une redirection, la remise finale, la lecture ou la personne qui répond.

L'internationalisation exige ensuite une discipline que la simple acceptation d'octets ne fournit pas. RFC 6530 décrit le cadre général et RFC 6531 l'extension SMTP. RFC 9873 recommande des répertoires de caractères maîtrisés, des domaines conformes à IDNA2008 et des essais de stockage sur les séquences combinatoires. RFC 5895 éclaire le mappage côté interface, et les tables IDNA de l'IANA fournissent la référence enregistrée. Une chaîne valide peut néanmoins rester visuellement ambiguë.

La publication publique forme encore une autre couche. Une adresse supplémentaire peut être traitée comme l'adresse de base, y compris dans RDAP, dont STD 95 fixe le cadre. Cela ne commande pas l'affichage littéral de chaque valeur conservée. L'avis ICANN de 2026 rappelle, dans son contexte propre, qu'un formulaire ou une adresse pseudonymisée peut constituer un mécanisme public. Ce texte n'atteste aucune mise en œuvre de RFC 9873.

La doctrine des couches de réalité de Heng Lu oblige à nommer séparément capacité négociée, valeur configurée, forme normalisée, stockage, divulgation, tentative SMTP, résultat de transport, action du destinataire et projection publique. Son principe de spécification initiale minimale justifie un noyau étroit et interopérable, à condition de ne pas dissimuler les décisions locales. La primauté du code en fonctionnement demande enfin des traces rejouables, pas une case verte.

Le risque de direction apparaît quand un produit aval transforme primary=true en « contact vérifié », quand une acceptation SMTP devient « destinataire informé », ou quand l'adresse étendue échappe au contrôle de divulgation commun. RFC 9873 offre une structure plus riche ; elle ne délivre pas de reçu humain.

Sources