RFC 6857 : Post-delivery Message Downgrading for

RFC 6857 : Post-delivery Message Downgrading for
Internationalized Email Messages
Stéphane Bortzmeyer
<[email protected]>
Première rédaction de cet article le 12 mars 2013
Date de publication du RFC : Mars 2013
http://www.bortzmeyer.org/6857.html
—————————-
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 <http://www.bortzmeyer.org/courrier-entierement-interna
html> 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 1 .
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,
1. Pour voir le RFC de numéro NNN, http://www.ietf.org/rfc/rfcNNN.txt, par exemple http://www.ietf.org/
rfc/rfc6858.txt
1
2
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é[email protected]
ou From: [Caractère Unicode non montré 2
][Caractère Unicode non montré ][Caractère
Unicode non montré ][Caractère Unicode non montré ][Caractère Unicode non montré
][Caractère Unicode non montré ]@[Caractère Unicode non montré ][Caractère
Unicode non montré ][Caractère Unicode non montré ][Caractère Unicode non montré
][Caractère Unicode non montré ][Caractère Unicode non montré ][Caractère Unicode
non montré ].[Caractère Unicode non montré ][Caractère Unicode non montré ][Caractè
Unicode non montré ][Caractère Unicode non montré ], 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 &#339;uf et qui vole un &#339;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.
2. Car trop difficile à faire afficher par LATEX
—————————http://www.bortzmeyer.org/6857.html
3
Deux exceptions : les noms de domaines et la partie locale des adresses. Les IDN sont réécrits en Punycode (RFC 3492) donc [Caractère Unicode non montré ][Caractère Unicode non montré
][Caractère Unicode non montré ][Caractère Unicode non montré ][Caractère Unicode
non montré ][Caractère Unicode non montré ][Caractère Unicode non montré ][Caractère
Unicode non montré ].[Caractère Unicode non montré ][Caractère Unicode non
montré ][Caractère Unicode non montré ][Caractère Unicode non montré ] 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, [Caractère Unicode non montré ][Caractère Unicode non
montré ][Caractère Unicode non montré ][Caractère Unicode non montré ][Caractère
Unicode non montré ] 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: &#26446;@&#20013;&#22269;&#31185;&#23398;&#38498;.&#20013;&#22269;
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@&#2344;&#2312;&#2342;&#2367;&#2354;&#2381;&#2354;&#2368;.&#2349;&#2366;&#2352;&#234
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 <http://
www.iana.org/assignments/message-headers/perm-headers.html>. 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.
—————————http://www.bortzmeyer.org/6857.html