Résumé

  • SMTPUTF8 étendit les noms de boîte dans l’enveloppe et les valeurs d’en-tête à UTF-8, mais seulement après l’annonce de la capacité par chaque serveur ; ce dernier devait aussi annoncer 8BITMIME.
  • Un domaine pouvait devenir un A-label IDNA, mais aucune règle générale ne créait l’équivalent ASCII d’une partie locale. Au bout d’un chemin incapable, il fallait une transformation autorisée à la soumission, une autre route, une attente ou un échec.

Un nom familier n’était pas encore une adresse

MIME savait afficher un nom dans son écriture d’origine autour d’une adresse ASCII. RFC 6530 rappelle que ce nom visible ne fait pas partie de l’enveloppe SMTP. Il ne dirige donc pas la livraison.

IDNA avait internationalisé le domaine, à droite de @. La partie locale restait un nom géré par le système de livraison final. Un domaine Unicode possède une représentation A-label normalisée pour le DNS ; une partie locale n’a pas de translittération universelle. La remplacer peut viser une boîte inexistante, ou une autre personne.

Le courrier entièrement internationalisé exigeait ainsi un chemin capable de conserver le nom, pas seulement un écran capable de l’afficher.

L’expérience de rétrogradation fut abandonnée

RFC 6530 remplaça RFC 4952 et déclara devenues inutiles les spécifications expérimentales de rétrogradation en transit. Le relais intermédiaire n’avait pas l’autorité nécessaire pour fabriquer une identité ASCII.

Les textes Standards Track de février 2012 répartirent les fonctions. RFC 6531 définit le transport SMTP ; RFC 6532, les en-têtes UTF-8 ; RFC 6533, les notifications capables de conserver le destinataire internationalisé. L’ensemble ne fournit pas une table de traduction : il construit un environnement où l’enveloppe, le message et la preuve d’échec parlent de la même adresse.

Le mot SMTPUTF8 était un engagement complet

Le serveur place SMTPUTF8 dans sa réponse EHLO. Le registre IANA des extensions SMTP l’enregistre sans paramètre. RFC 6531 exige qu’un serveur qui l’annonce respecte entièrement la spécification et annonce aussi 8BITMIME.

Cette dépendance distingue les deux extensions. 8BITMIME garde les octets élevés d’un corps MIME. SMTPUTF8 étend les adresses d’enveloppe et les en-têtes qui portent les identités. Le second suppose un chemin d’en-têtes à huit bits propre, sans remplacer le premier.

Le client peut ajouter le paramètre sans valeur SMTPUTF8 à MAIL FROM. Il affirme que l’enveloppe, le message ou ses en-têtes ont besoin de cet environnement. Les séparateurs SMTP restent les mêmes ; le répertoire de caractères s’élargit.

Le chemin devint une condition d’accessibilité

Sans annonce SMTPUTF8, le client ne doit transmettre ni adresse internationale ni en-tête RFC 6532, même imbriqué dans MIME. Une boîte peut donc être accessible par un MX capable et bloquée par un autre. Essayer un autre MX ou attendre une réparation ne change pas son identité ; cela cherche un chemin qui puisse la porter.

L’agent de soumission dispose d’une latitude particulière, car l’auteur participe encore à cette frontière. S’il connaît un alias ASCII effectivement provisionné, il peut construire un message SMTP ordinaire. RFC 6531 ne définit pas cette transformation et n’autorise pas un relais de transit à improviser.

Faute de route ou de transformation légitime, le système peut rejeter, notifier, remettre en file ou essayer un hôte alternatif. L’échec préserve la distinction entre « ce chemin ne porte pas ce nom » et « cette boîte n’existe pas ».

UTF-8 entra dans la valeur, pas dans le nom du champ

RFC 6532 permet UTF-8 directement dans Subject, les adresses, certaines chaînes et des constructions Message-ID. Les noms de champs restent ASCII. La limite dure devient 998 octets, tandis que la recommandation de 78 unités reste mesurée en caractères : capacité de transport et largeur de lecture ne sont pas la même limite.

La normalisation ne peut pas créer une équivalence d’identité. RFC 6532 recommande NFC et déconseille NFKC lorsqu’elle effacerait une distinction d’orthographe. Le système final conserve l’autorité d’interpréter sa partie locale.

Le rapport d’échec devait garder le nom exact

RFC 6533 ajoute un type d’adresse UTF-8 et des formes utilisables dans ORCPT et les DSN. Certaines sont sûres sur sept bits afin de préserver l’adresse originale dans un rapport. Cet encodage n’est pas une boîte ASCII de remplacement ; il transporte la preuve de celle qui a échoué.

Un serveur annonçant SMTPUTF8 et DSN doit donc implémenter RFC 6533. Promettre le rapport sans conserver l’identité du destinataire rendrait l’échec impossible à corréler.

Une capacité n’était pas un titre de propriété

SMTPUTF8 prouve une aptitude à analyser et transporter des chaînes. Il ne prouve ni existence, ni possession, ni équivalence visuelle, ni livraison finale. Le domaine gère ses labels ; le système final gère son espace de boîtes ; le relais transporte ou échoue. Aucun n’acquiert le pouvoir d’inventer une personne de remplacement.

Sources et limites

Le cadre vient de RFC 6530, le transport de RFC 6531, les en-têtes de RFC 6532, les notifications de RFC 6533, et l’entrée actuelle du registre IANA. Ces sources ne mesurent ni support actuel, ni délivrabilité, ni propriété des boîtes.