Résumé

  • Publiée le 10 septembre 2026, la révision 05 de draft-ietf-mailmaint-smtputf8-syntax remplace une énumération de classes de caractères par la classe IdentifierClass de PRECIS et rend obligatoire l’application des règles contextuelles pertinentes.
  • Deux nouveaux cas sont explicitement refusés : U+3164 HANGUL FILLER, susceptible de ne rien afficher, et U+0640 ARABIC TATWEEL, qui allonge la lettre précédente et permet de multiplier les graphies visuelles.
  • Ce filtre statue sur l’admissibilité d’une chaîne. Il ne prouve ni l’existence d’une boîte, ni le contrôle par une personne, ni une route SMTPUTF8 complète, ni la remise du message.
  • Le libellé actuel conserve une ambiguïté littérale entre un espace entre guillemets et les signes de ponctuation employés par l’adresse. Cette phrase appelle une clarification, pas une correction clandestine de chaque fournisseur.

Deux systèmes, une seule apparence

Le scénario le plus révélateur n’est pas une attaque spectaculaire. C’est un ticket banal : l’inscription a réussi, mais la connexion échoue. Le support copie l’adresse affichée dans un second outil et obtient un autre compte. Une inspection par points de code montre que la première chaîne contient U+3164 juste avant un séparateur. La police n’en rend aucune trace.

Le navigateur, l’API, la base, l’index de recherche et le serveur de courrier n’ont pas nécessairement la même bibliothèque Unicode. L’un conserve la séquence, l’autre la normalise, un troisième la rejette. Si le journal ne stocke que la forme rendue, la cause disparaît au moment même où l’événement est consigné.

La révision 05 de SMTPUTF8 Email Addresses ajoute ce HANGUL FILLER à ses exemples négatifs. Elle ajoute aussi U+0640 ARABIC TATWEEL. Ce dernier est classé comme lettre par Unicode, mais sa fonction graphique consiste à étirer ce qui le précède ; plusieurs insertions peuvent produire plusieurs chaînes derrière une apparence apparentée.

Le Datatracker présente le texte comme un Internet-Draft actif du groupe Mail Maintenance, visant le statut Proposed Standard. Son historique date la révision du 10 septembre. Ce sont les coordonnées d’une proposition, pas la preuve d’un RFC, d’un déploiement ou d’un incident.

La règle ne recopie plus sa propre table

Dans la révision 04, la deuxième règle énumérait les catégories A, H, K et certains éléments de F définis par le RFC 8264, avec la ponctuation de l’adresse. La révision 05 adopte une formulation différente : les points de code doivent être valides dans IdentifierClass et ceux qui sont contextuels doivent satisfaire la règle correspondante.

Le déplacement est institutionnel autant que technique. Une liste recopiée devient vite une variante locale : elle peut rester figée, perdre une exception ou transformer « valable sous condition » en « permis ». Une référence à PRECIS désigne une procédure partagée. Elle rend aussi visible l’origine de la décision.

Le RFC 8264 distingue quatre issues : valide, règle contextuelle requise, interdit et non attribué. IdentifierClass admet notamment les lettres et chiffres traditionnels ainsi que l’ASCII imprimable. Il exclut les anciens jamos coréens, les contrôles, les propriétés ignorables, les espaces non couverts, divers symboles, les formes de compatibilité et d’autres catégories jugées peu sûres pour un identifiant.

Le cadre ne prétend pourtant pas tout faire. Un profil d’application doit encore préciser les transformations de largeur, les mappages supplémentaires, la casse, la normalisation et la direction. Référencer IdentifierClass n’efface donc pas les choix locaux ; cela leur donne une limite commune qu’il faut versionner.

U+0640 montre la puissance d’une exception

La catégorie générale « lettre » paraît rassurante, mais elle n’est pas le dernier mot. Le RFC 5892 place U+0640 dans une table d’exceptions et le marque DISALLOWED, alors que le calcul par propriétés l’aurait autrement classé PVALID. Un validateur incomplet peut donc produire une réponse plausible et fausse.

Le jeu de tests public des auteurs ajoute d’autres frontières : contrôles bidirectionnels, lettres pleine chasse, anciens jamos combinatoires et syllabe coréenne précomposée. Il permet de répéter le raisonnement. Il ne permet pas d’affirmer que tous les produits utilisent cette version, ni qu’un résultat de bibliothèque traverse sans altération l’inscription, l’authentification, l’export et l’enveloppe SMTP.

La troisième règle du projet interdit aussi plus d’une écriture non ASCII dans la même adresse, après avoir écarté l’ASCII du décompte. L’annexe Unicode nº 24 fournit la propriété Script employée ici. Cette convention vise l’interopérabilité d’un identifiant ; elle n’accorde ni ne retire une légitimité aux personnes multilingues.

Un espace entre guillemets reste à expliquer

La nouvelle phrase contient une couture visible. Elle autorise littéralement les points de code valides d’IdentifierClass « et un espace » placé entre guillemets, alors que les exemples suivants évoquent séparément le point, la barre oblique et l’arobase. Le fichier source public porte le même texte.

Ce peut être une coquille, un raccourci vers la grammaire mailbox ou un passage encore en chantier. Les sources consultées ne permettent pas de trancher. Or la ponctuation sépare le local-part du domaine et interagit avec les formes citées : une règle de classe et une production grammaticale ne sont pas interchangeables.

La discipline appropriée consiste à conserver la version et l’interprétation utilisées, puis à suivre une correction publique. Un fournisseur qui modifie silencieusement la phrase fabrique une politique privée ; il ne termine pas le travail du groupe.

Une adresse admise n’est pas une identité attestée

Le RFC 6532 a permis l’usage direct de l’UTF-8 dans les en-têtes et les adresses du courrier internationalisé. Le projet actuel cherche à sélectionner, dans cet espace, des chaînes plus aptes à l’interopérabilité. Aucun des deux textes ne prouve qui est derrière la chaîne.

Une adresse syntaxiquement admissible peut ne correspondre à aucune boîte. Une réponse à un défi peut démontrer un contrôle temporaire sans établir une identité civile ou un mandat professionnel. Une application peut accepter la chaîne et la déformer lors d’une restauration. Un premier relais compatible SMTPUTF8 ne garantit pas que chaque étape du trajet le soit.

L’article historique de BTW sur SMTPUTF8 traitait cette continuité de trajet et l’absence de rétrogradation générale du local-part. La présente actualité traite d’un autre contrôle, antérieur : le prédicat qui décide si la chaîne entre. Les deux responsabilités doivent rester séparées.

Une preuve d’admission plutôt qu’un booléen

Le reçu minimal conserve les octets UTF-8, la séquence ordonnée des points de code et leur rôle grammatical. Pour chaque caractère non ASCII, il consigne la disposition IdentifierClass, l’éventuelle règle contextuelle, son résultat et le calcul d’écriture. Il nomme aussi les politiques de mappage, de casse, de normalisation et de direction.

Il faut ensuite la version des données Unicode/PRECIS, celle du validateur, la surface appelante, l’heure, l’action et le chemin de correction proposé à l’utilisateur. L’interface d’exploitation peut juxtaposer une représentation échappée et la forme lisible, sans exposer inutilement la valeur brute.

Ce reçu est une proposition éditoriale de Daniel Kade, non une obligation de l’IETF. Il ne centralise pas la politique des comptes. Il permet simplement de déterminer si deux services ont évalué le même objet avec la même règle, au lieu de donner au rendu graphique le dernier mot.

Sources