Résumé

  • Le mot encodé de la RFC 2047 transporte du texte non ASCII dans certaines zones d’un en-tête ; son décodage produit un affichage, non l’identité authentifiée d’un expéditeur.
  • Une enquête solide conserve séparément l’en-tête brut, l’analyse syntaxique, le jeu de caractères, l’adresse, la couverture de signature et le rendu présenté à l’utilisateur.

Dans un dossier d’incident, l’image et le message source ne devraient jamais occuper la même colonne. L’image répond à une question précieuse : qu’a vu cette personne, dans ce client, à cet instant ? Le source en pose d’autres : quels octets ont été reçus, comment le champ a-t-il été découpé, quelle adresse a été reconnue et quelles parties ont été authentifiées ? Réduire le tout au nom visible revient à effacer la chaîne de transformation au moment même où elle devient utile.

La RFC 2047, publiée en novembre 1996 sous le nom de Keith Moore, a organisé une transformation très précise. La messagerie devait transporter des objets et des langues que la grammaire historique des en-têtes, largement fondée sur l’ASCII, n’exprimait pas directement. Elle devait aussi traverser des logiciels qui repliaient les lignes, déplaçaient des champs ou interprétaient mal des constructions rares. La solution a réservé une enveloppe composée de caractères ASCII ordinaires afin qu’un lecteur averti puisse retrouver le texte destiné à l’affichage.

La forme générale est =?charset?encoding?encoded-text?=. Le premier terme désigne le jeu de caractères, le second une méthode Q ou B, le dernier porte les octets représentés. B reprend Base64 dans ce contexte MIME. Q ressemble au quoted-printable et donne au souligné la valeur d’un espace. Un mot encodé complet est limité à 75 caractères ; une ligne qui en contient est bornée à 76. Un texte plus long peut donc être réparti sur plusieurs unités.

Cette enveloppe a une grande valeur d’interopérabilité. Elle ne dit rien, à elle seule, sur la personne nommée par le texte retrouvé.

Une place autorisée n’est pas une nouvelle grammaire

La RFC ne permet pas de déposer un mot encodé n’importe où. Il peut remplacer du texte dans un champ comme Subject, apparaître dans un commentaire ou former un mot d’une phrase, notamment le nom d’affichage qui précède une adresse. Il est interdit dans un addr-spec, dans une chaîne entre guillemets, dans Received et dans les paramètres structurés de Content-Type ou Content-Disposition.

La conséquence opérationnelle est forte. Après décodage, un caractère @, deux-points ou chevron peut ressembler exactement au signe syntaxique voisin. Il n’acquiert pourtant pas son pouvoir. Le lecteur doit d’abord analyser le champ structuré en jetons, reconnaître ensuite les mots encodés aux emplacements licites, puis produire le texte affiché. Il ne doit pas recommencer l’analyse de l’adresse avec la ponctuation nouvellement visible.

La RFC 5322 distingue ainsi le nom d’affichage de l’addr-spec dans une boîte aux lettres. Le premier facilite la lecture humaine ; le second appartient à la syntaxe de l’adresse. Elle distingue aussi From, qui exprime le rôle d’auteur dans le format du message, de Sender, qui peut désigner l’agent responsable de la transmission réelle. Ces champs formulent des assertions. La conformité de leur syntaxe n’authentifie ni une personne ni son pouvoir d’agir.

Un client qui cache l’adresse derrière une pastille de contact n’a pas fusionné ces deux objets. Il a choisi de rendre l’un d’eux moins visible.

L’espace que l’écran ne montre plus

Lorsque deux mots encodés adjacents sont séparés par un espace linéaire, cet espace est ignoré à l’affichage. La règle permet de replier proprement une longue expression sans créer un blanc artificiel au milieu du nom. Elle explique aussi pourquoi la chaîne visible ne constitue pas une transcription des octets transmis.

Chaque unité reste autonome : une séquence d’échappement ou un caractère multioctet ne peut pas commencer dans l’une et finir dans la suivante. Plusieurs écritures brutes peuvent néanmoins aboutir au même résultat visible. Deux jeux de caractères capables d’exprimer la même lettre, les méthodes Q et B, des positions de repli différentes ou des variations admises dans l’écriture hexadécimale peuvent disparaître lors de la présentation.

L’inverse est tout aussi important. Un logiciel qui ne connaît pas le jeu de caractères peut conserver la syntaxe brute, tenter un affichage approximatif ou signaler l’échec. Un mot mal formé n’impose pas de bloquer tout le message. Deux clients peuvent donc présenter différemment la même entrée sans que l’unique capture du serveur suffise à reconstruire l’expérience du lecteur.

Le bon constat n’est pas « le décodage est dangereux ». C’est « le décodage est un acte observable qui consomme de la provenance ».

UTF-8 direct : une autre voie, les mêmes séparations

La RFC 6532 autorise plus tard l’emploi direct d’UTF-8 dans de nombreux corps de champs lorsque l’environnement de courrier internationalisé le permet. Elle recommande la normalisation NFC et rappelle les difficultés de sécurité liées aux représentations Unicode équivalentes ou confusables. L’enveloppe RFC 2047 peut alors devenir inutile pour ce texte, mais l’octet, le point de code, le glyphe et l’identité ne deviennent pas un seul objet.

Les parcs réels restent mélangés. Un message arrive en UTF-8 direct, un autre avec des mots encodés, un troisième a traversé une passerelle. Si l’observabilité ne conserve que la chaîne finale, elle ne peut plus expliquer quelle voie a été prise, si un remplacement a eu lieu, ni quelle normalisation a précédé l’écran.

La signature a son propre sujet

La RFC 6376 construit une autre preuve. DKIM applique une canonicalisation au corps et à une liste déclarée de champs, puis vérifie une signature rattachée principalement à un domaine signataire. Un résultat valide peut démontrer que ces données ont survécu selon les règles choisies et la clé du domaine. Il ne transforme pas le nom d’affichage décodé en personne vérifiée et ne garantit pas que tous les champs visibles figuraient dans la signature.

Un panneau qui juxtapose « DKIM valide » et un nom convivial crée donc une jointure. Pour l’auditer, il faut connaître l’instance exacte du champ From, les octets couverts, la liste des champs signés, la canonicalisation, le domaine signataire, l’adresse analysée, les mots encodés reconnus et le rendu final. Sans ces arêtes, deux résultats exacts répondant à deux questions différentes ressemblent à une seule certification générale.

Une quittance de rendu

Une reconstruction défendable commence par le point d’observation et un hachage protégé du champ brut. Elle conserve l’ordre des champs, les replis et fins de ligne, les versions du parseur et du décodeur, les limites de jetons, la position de chaque mot encodé, le charset annoncé, le choix Q ou B, les erreurs et caractères de remplacement. Elle note les points de code obtenus, la normalisation, les alertes de script ou de direction, puis sépare le nom d’affichage de l’addr-spec.

À côté figurent les faits DKIM : champs couverts, canonicalisation, résultat et domaine signataire. Enfin viennent le texte réellement rendu, la langue de l’interface, les polices de repli et l’avertissement visible. Une lacune sur les octets, la version du logiciel ou le contexte d’écran doit rester une lacune.

Cette quittance contient potentiellement des données personnelles. Elle n’autorise aucune collecte illimitée : minimisation, contrôle d’accès et durée proportionnée restent nécessaires.

Le profil IETF de Keith Moore recense ses contributions publiées. Un article historique de l’University of Tennessee datant de 2008 indique qu’il y a travaillé de 1991 à 2007 et qu’il participait aux groupes de normalisation de l’IETF depuis 1990. Ce sont des repères datés, pas une fonction actuelle. La contribution pertinente demeure la règle elle-même : rendre un nom lisible sans prétendre que sa lisibilité établit l’expéditeur.

Sources