Mon blog

Ce nouveau RFC normalise un mécanisme de repli (downgrade) lorsqu'un serveur POP ou IMAP a reçu des courriers entièrement internationalisés et qu'un client POP ou IMAP de l'ancienne génération, qui ne comprend pas les adresses en Unicode, veut récupérer ce courrier. Le mécanisme de ce RFC est plus complet (et plus complexe) que celui, concurrent, du RFC 6858.

Dans la première version du courrier électronique entièrement en Unicode (celle normalisée dans les RFC 5335 et suivants), il était prévu un repli effectué entre serveurs SMTP. Si un serveur détectait que le serveur suivant ne gérait pas la nouvelle norme, il se repliait automatiquement sur un format compatible. Ce mécanisme, spécifié dans le RFC 5504, était compliqué et fragile et a été abandonné dans la deuxième version du courrier électronique entièrement internationalisé, celle des RFC 6530 et suivants. Désormais, les seuls endroits où un repli (downgrade) peut se faire sont à l'expédition, dans le MUA (de manière non standardisée, c'est un problème d'interface utilisateur) ou bien par les serveurs POP ou IMAP, lorsqu'ils ont reçu un message internationalisé et découvrent après qu'un de leurs clients ne gère pas cette norme (chose qu'on ne peut pas savoir à l'avance). Les RFC 6856 et RFC 6855 ne définissent pas de mécanisme obligatoire pour ce cas. Ils prévoient plusieurs possibilités (rejeter les vieux clients, cacher le message, comme s'il n'avait jamais été reçu, etc) parmi lesquelles le repli automatique vers un format compatible. Un tel repli n'est jamais une solution satisfaisante (il fait perdre de l'information, on ne pourra pas toujours répondre aux messages en question) mais, dans certains cas, cela peut être la moins mauvaise solution. Pour éviter une prolifération de mécanismes de repli différents, donnant des résultats distincts, deux algorithmes de repli sont normalisés, un très simple à mettre en œuvre (et faisant perdre beaucoup d'information), dans le RFC 6858, et un plus proche de l'esprit du RFC 5504, qui respecte davantage le message original, essayant de garder le plus d'information possible (mais qui sera plus compliqué à programmer), celui de notre RFC 6857.

La grosse différence entre le courrier actuel, complètement internationalisé (RFC 6532), et la version immédiatement précédente (RFC 5322), est qu'il est désormais possible d'avoir de l'Unicode, encodé en UTF-8, dans tous les en-têtes, et y compris dans les adresses (on peut avoir From: stéphane@bortzmeyer.org ou From: المنصف@التحرير.تونس, qui étaient interdits dans le RFC 5322). Pour le reste du message, notamment le corps, le problème est réglé depuis longtemps par MIME. Mais ces en-têtes en Unicode ne sont pas compris par les vieux clients POP et IMAP et la question se pose donc : comment leur transmettre ?

La section 1.2 liste plusieurs solutions (en en oubliant une, qui était mentionnée dans d'autres RFC, cacher le message) : rejeter le message au moment de la distribution (si on sait qu'on a une majorité de clients anciens), envoyer un faux message qui dit qu'il y a intérêt à mettre à jour le client IMAP pour tout voir, ou bien effectuer un repli en transformant le message internationalisé en quelque chose de compatible, avec des en-têtes entièrement en US-ASCII. C'est cette dernière approche qui est choisie par notre RFC (et par son concurrent RFC 6858). Il reconnait pourtant qu'il n'existe pas de solution idéale à ce problème et que celle exposée ici est « la moins mauvaise ».

Donc, première opération, la plus importante, transformer (dégrader) les en-têtes, en section 3. (Les exemples sont tirés de l'annexe A du RFC, mais elle n'a malheureusement pas d'exemple avec les IDN.) La méthode est de diviser la valeur de l'en-tête en ses différentes composantes, et de transformer, dans chaque composante, l'UTF-8 dans l'encodage du RFC 2047. Cela marche bien pour des choses comme le nom affiché dans l'adresse, et c'est en général réversible (on ne perd donc pas d'information, mais le RFC ne mentionne pas ce point, pour ne pas susciter de faux espoirs ; voir le traitement des espaces par le RFC 2047 dans la section 6 de notre RFC). Ici, par exemple, le sujet et un en-tête inconnu ont été ainsi traités. L'original disait :

Subject: Qui télécharge de la musique vole un œuf et qui vole un œuf assassine les artistes
X-Hadopi: Ne pas lire ce message est une négligence caractérisée

Et la version après repli est :

Subject: =?utf-8?q?Qui_t=C3=A9l=C3=A9charge_de_la_musique_vole_un_=C5=93uf_et_qui_?=
 =?utf-8?q?vole_un_=C5=93uf_assassine_les_artistes?=
X-Hadopi: ?utf-8?q?Ne_pas_lire_ce_message_est_une_n=C3=A9gligence_caract=C3=A9ris?=
 =?utf-8?b?w6ll?=

On notera que c'est la forme actuellement utilisée par les MUA traditionnels, pour transmettre des caractères non-ASCII « déguisés » en ASCII. Le repli ramène donc à la situation antérieure au RFC 6532.

Deux exceptions : les noms de domaines et la partie locale des adresses. Les IDN sont réécrits en Punycode (RFC 3492) donc नईदिल्ली.भारत devient xn--o1b4de6ba0fj6h.xn--h2brj9c. Exception dans l'exception, cette traduction en Punycode n'est pas faite si la partie locale de l'adresse est elle-même en Unicode (voir l'exemple de M. Li plus loin).

Et une deuxième exception, plus sérieuse, les parties locales des adresses. On utilise aussi le RFC 2047 mais cette transformation est bien plus intrusive puisque le résultat ne sera pas, la plupart du temps, une adresse utilisable (le logiciel qui tenterait de répondre à un message qui a subi cette opération récupérer un avis de non-remise). Ainsi, नेहरू deviendra =?utf-8?b?4KSo4KWH4KS54KSw4KWC?= qui, typiquement, ne sera pas accepté par le serveur de messagerie indien... Cela s'applique pour tous les en-têtes qui peuvent contenir des adresses comme From:, To:, Cc:, etc.

Combinant ces deux exceptions, voici ce que deviendra l'adresse de M. Li, qui était :

From: 李@中国科学院.中国

et qui, après le repli, est :

From: =?utf-8?b?5p2OQOS4reWbveenkeWtpumZoi7kuK3lm70=?=

Joli, non ?

Lorsque l'opération fait perdre trop d'information, le serveur POP ou IMAP peut préserver l'ancien en-tête, globalement encodé en RFC 2047 (et non plus composante par composante), dans un en-tête dont le nom est préfixé par Downgraded-. Ainsi, avec un Message-ID:, il est globalement encodé (on ne cherche pas le nom de domaine, qu'il contient souvent) :

Message-ID: <50EF7C49.4060203@नईदिल्ली.भारत>

devient :

Downgraded-Message-ID: =?utf-8?b?PDUwRUY3QzQ5LjQwNjAyMDNA4KSo4KSI4KSm4KS/4KSy4KWN4KSy4KWALg==?=
 =?utf-8?b?4KSt4KS+4KSw4KSkPg==?=

Si on avait suivi l'autre algorithme, celui du RFC 6858, cet en-tête aurait tout simplement été retiré. Ces nouveaux en-têtes commençant par Downgraded- sont désormais enregistrés à l'IANA. Les en-têtes Downgraded-* expérimentaux du RFC 5504 sont officiellement abandonnés.

La deuxième opération, en section 4, concerne les parties MIME du message, et les messages encapsulés comme les accusés de réception de la section 6 du RFC 3461. Eux aussi contiennent de l'UTF-8 et doivent subir une opération de repli analogue.

La section 5, sur la sécurité, rappelle les limites de la méthode : on ne peut pas, en général, répondre aux messages ayant subi le repli (les adresses ont été massacrées), le message est plus difficile à analyser par le destinataire (il y a donc plus de possibilités de tromperie), les signatures DKIM sont presque à coup sûr invalidées (celles en PGP peuvent tenir bon, dans certains cas), etc.

Je ne connais pas encore d'implémentation de ce RFC particulier.