Résumé

  • RFC 9755 distingue l’annonce du serveur de l’activation explicite par un client authentifié ; aucune des deux ne valide à elle seule l’identité, le magasin, l’index et l’interface.
  • La recette d’acceptation doit se terminer par un message témoin que l’usager peut lister, rechercher, ouvrir et utiliser, et non par une seule réponse protocolaire positive.

Un essai peut réussir au mauvais endroit. Une application dépose un message aux en-têtes internationalisés, le serveur répond OK, puis l’utilisateur visé ne le retrouve ni par son expéditeur ni dans un client pourtant pris en charge. Le dépôt n’était pas mensonger. Il répondait simplement à une question plus étroite que celle posée au service.

RFC 9755, norme publiée en mars 2025 et remplaçant RFC 6855, rend ces frontières explicites pour IMAP4rev1 ; IMAP4rev2 offre déjà des fonctions proches. UTF8=ACCEPT annonce l’ouverture de boîtes contenant des messages internationalisés et le retour de noms de boîtes en UTF-8. UTF8=ONLY inclut cette capacité et abandonne l’ancienne convention UTF-7 modifiée.

Une annonce n’active pas une session

Le client doit d’abord s’authentifier, puis envoyer ENABLE UTF8=ACCEPT. Même avec UTF8=ONLY, la commande reste celle-ci. Selon RFC 5161, la réponse ENABLED établit ce qui a réellement été activé ; CAPABILITY reste une description du serveur, pas une trace de la session.

Il faut donc conserver deux preuves : version et capacités du serveur, puis commande et réponse de chaque client réel. Une capture de configuration, séparée de la connexion testée, ne remplace aucune des deux.

Une chaîne valide n’est pas encore un compte

RFC 9755 n’étend pas LOGIN aux identifiants et mots de passe UTF-8. Leur transport passe par AUTHENTICATE. Le texte précise toutefois que cette légalité syntaxique ne garantit pas que le système de provisionnement accepte l’identité.

Le contrôle doit vérifier l’enregistrement dans la source d’identité, l’authentification avec le mécanisme de production, l’association à la bonne boîte et les autorisations sur chaque voie d’accès. Sans cela, le parseur reconnaît une chaîne que l’organisation n’a pas rendue opérante.

APPEND ouvre la preuve de stockage

Après activation, le serveur doit accepter les en-têtes UTF-8 dans APPEND ; sans activation, il doit refuser le même message en 8 bits. Cette paire positive/négative est précieuse. Elle ne dit pas que le message sera ensuite visible.

RFC 9755 supprime l’ancien élément APPEND UTF8 et note qu’IMAP4rev1, IMAP4rev2 et JMAP ne fournissent pas d’indicateur fiable, message par message, sur son ancien usage. Il faut donc garder le message témoin, son empreinte, la réponse APPEND et l’identifiant attribué lorsqu’il existe, puis relire ce même message et comparer les champs promis.

Les noms de boîtes exigent un jeu d’essai autonome. Le RFC impose Net-Unicode et exclut plusieurs contrôles et séparateurs. RFC 5198 explique la normalisation NFC ; RFC 6532 la recommande pour les en-têtes et déconseille NFKC lorsqu’elle efface une orthographe. L’égalité visuelle, l’égalité d’octets et l’égalité en recherche ne sont pas la même promesse.

La documentation actuelle de Dovecot illustre cette couche : le stockage UTF-8 des noms de boîtes est un réglage distinct et sa modification peut casser les noms non ASCII existants. Ce n’est pas un recensement du marché, mais la preuve qu’un changement protocolaire n’est pas automatiquement une migration du stockage.

Deux BODYSTRUCTURE peuvent être conformes

Avec message/global, un client ignorant ce type peut voir une pièce jointe inconnue. Pour IMAP4rev1 activé, RFC 9755 permet deux traitements valides de BODYSTRUCTURE et oblige le client à comprendre les deux ; IMAP4rev2 suit RFC 9051. L’erratum 8697 corrige la comparaison en message/rfc822.

Un test sérieux couvre donc les deux formes rev1, la forme rev2, les en-têtes internationalisés imbriqués et la récupération de la partie brute. Un nombre de pièces jointes ou une vignette ne prouve pas que serveur et client interprètent la même structure.

La recherche est une autre frontière

Après ENABLE, SEARCH ne doit plus contenir de paramètre charset ; SORT et THREAD devraient utiliser UTF-8. Un ancien client peut donc lister correctement une boîte tout en formulant une recherche désormais incompatible. Les tests doivent conserver la requête exacte et les UID retournés pour plusieurs représentations NFC, les en-têtes, les noms de boîtes et le corps.

Le RFC reconnaît enfin que le même magasin peut être lu par IMAP, POP, webmail et des clients aux capacités différentes. Erreur explicite, notification, masquage ou substitut normalisé sont des choix de compatibilité, pas une équivalence. La question déjà traitée ailleurs de la garde de l’original d’un substitut n’est pas reprise ici : chaque voie officiellement prise en charge doit produire un résultat attendu, vérifié sur le même message.

La dernière preuve est humaine. L’utilisateur voit-il la boîte, trouve-t-il le message, reconnaît-il les adresses, ouvre-t-il les parties et peut-il répondre selon la politique ? Les RFC établissent le comportement du protocole, pas l’adoption d’un produit. Dans la distinction proposée par Heng Lu entre représentation symbolique et réalité exécutable, la capacité est le symbole ; l’usage observable est le fait. La chaîne normative comprend aussi l’internationalisation SMTP, la transformation de rétrogradation, son comportement POP simplifié et la base IMAP4rev2. Ces textes bornent l’interopérabilité ; ils ne transforment pas un trajet réussi en visibilité universelle.