Mon blog

Complétant l'ancienne série de RFC sur l'internationalisation du courrier électronique, ce document normalise la procédure de repli (downgrade) que doivent utiliser les MTA lorsqu'ils essaient de transmettre un message RFC 5335 à un autre MTA si ce dernier ne gère pas l'extension UTF8SMTP du RFC 5336. Ce mécanisme de repli a finalement été complètement supprimé lors de la parution des normes définitives, autour du RFC 6530, et n'a désormais qu'un intérêt historique.

Écrit par des employés de JPRS, le registre du .jp, c'est un document plutôt simple malgré la complexité du sujet. En effet, lorsque les autres RFC sur l'internationalisation complète du courrier (comme les RFC 5335 ou RFC 5336) seront déployés, ils ne le seront pas instantanément sur toute la planète. Si on se fie au lent déploiement des extensions précédentes (comme la transparence aux caractères « 8 bits » du RFC 2045), on peut prévoir d'importants délais, de l'ordre de dix ans ou plus, avant que tous les MTA suivent le nouveau mécanisme. Que faire en attendant si un MTA veut transmettre un message complètement internationalisé à un MTA ancien, qui ne sait pas quoi en faire ? Tous les MTA écrits avant le RFC 5336 n'acceptent en effet que les enveloppes et les en-têtes en ASCII.

La solution choisie (introduite par le RFC 5336, sections 3.1 à 3.4, résumée en section 1 de notre RFC) est, soit de renoncer à délivrer le message, la plus simple mais évidemment pas satisfaisante, soit de mettre en œuvre le mécanisme de repli (downgrade) que normalise notre RFC 5504. Ce mécanisme consiste à convertir l'enveloppe SMTP et les en-têtes du message pour être acceptable par le vieux serveur. Elle n'est pas complètement réversible et donc aucun upgrade ne correspond à ce downgrade.

Pour permettre de se souvenir d'une partie de ce qui a été fait, des nouveaux en-têtes apparaissent, préfixés de Downgraded- et qui indiquent l'ancienne valeur. Ils sont encodés en UTF-8 et surencodés avec la méthode du RFC 2047 (Mon =?UTF-8?Q?h=C3=B4tel_et_mes_horaires?= pour « Mon hôtel et mes horaires »).

La section 3 décrit ces en-têtes Downgraded:. 3.1 couvre le repli de l'enveloppe (paramètres des commandes SMTP MAIL FROM et RCPT TO, voir aussi la section 4). Les adresses qu'elle contient se replient sur le paramètre ALT-ADDRESS s'il est présente (sinon, ce destinataire est abandonné).

3.2 et 3.3 couvrent le repli des en-têtes du message comme From:.

La section 4 revient sur le repli de l'enveloppe : celui-ci ne peut se faire que si l'adresse a un paramètre ALT-ADDRESS (cf. RFC 5336).

La section 5, elle, analyse en détail les problèmes que peuvent poser certains en-têtes lors du repli. Ainsi, Received: peut contenir des adresses de courrier :

Received: from fallback1.mel.teaser.net (fallback1.mel.teaser.net [213.162.54.52])
        by mail.bortzmeyer.org (Postfix) with ESMTP id 146B5941E4
        for <stéphane+blog@bortzmeyer.org>; Tue, 14 Oct 2008 22:29:11 +0200 (CEST)

et ces adresses doivent également se replier en ASCII.

Quant à la partie 6, elle traite le cas où le corps est structuré selon MIME (RFC 2045) et comprend donc des pseudo en-têtes comme Content-Description: qui devront peut-être également se replier. À propos de MIME, il faut noter que le repli ne considère pas le corps des messages. Si le serveur SMTP suivant, non seulement ne gère pas UTF8SMTP mais ne gère pas non plus le transport « huit bits », il faudra également modifier le corps du message pour le passer en un encodage qui tient en sept bits (cf. section 8.2).

La section obligatoire sur la sécurité (section 7) couvre notamment le fait que le repli, comme n'importe quel processus qui modifie le message en cours de route, a de fortes chances d'invalider toute signature apposée à ce message, par exemple avec DKIM (RFC 6376). Les autres méthodes de signature comme PGP (RFC 4880) peuvent également être affectées.

Voyons un exemple (non testé par manque d'implémentations), tiré de l'annexe A.1. Si le message original était :

   # Enveloppe SMTP
   MAIL FROM: <stéphane@bortzmeyer.org>
               ALT-ADDRESS=stephane@bortzmeyer.org
   RCPT TO: <françoise@example.org>
             ALT-ADDRESS=francoise@example.net
   RCPT TO: <rené@example.org>

   # Message proprement dit 
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: C'est bien de pouvoir écrire en français
   # La syntaxe ci-dessous a été introduite par le RFC 5335, section 4.4, pour 
   # représenter les ALT-ADDRESS
   From: Stéphane Bortzmeyer <stéphane@bortzmeyer.org
      <stephane@bortzmeyer.org>>
   To: Françoise Durand <françoise@example.org
      <francoise@example.net>>
   Cc: René Dupont <rené@example.org>

   # Corps du message

la version de repli sera :

   # Enveloppe SMTP
   MAIL FROM: <stephane@bortzmeyer.org>
   RCPT TO: <francoise@example.net>
   # René a disparu, il n'avait pas d'adresse de repli

   # Message proprement dit 
   Downgraded-Mail-From: =?UTF-8?Q?<st=C3=A9phane@bortzmeyer.org>_?=
    =?UTF-8?Q?<stephane@bortzmeyer.org>?=
   Downgraded-Rcpt-To: =?UTF-8?Q?<fran=C3=A7oise@example.org>_?=
    =?UTF-8?Q?<francoise@example.net>?=
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: =?UTF-8?Q?C'est bien de pouvoir =C3=A9crire en fran=C3=A7ais?=
   From: =?UTF-8?Q?St=C3=A9phane Bortzmeyer?= <stephane@bortzmeyer.org>
   Downgraded-From: =?UTF-8?Q?St=C3=A9phane Bortzmeyer_<st=C3=A9phane@bortzmeyer.org_?=
       =?UTF-8?Q?<stephane@bortzmeyer.org>>?=
   To: =?UTF-8?Q?Fran=C3=A7oise Durand?= <francoise@example.net>
   Downgraded-To: =?UTF-8?Q?_Fran=C3=A7oise Durand?=
       =?UTF-8?Q?<fran=C3=A7oise@example.org>_<francoise@example.net>>?=
   Cc: =?UTF-8?Q?Ren=C3=A9 Dupont?= Internationalized address
       =?UTF-8?Q?ren=C3=A9@example.org?= removed:;
   Downgraded-Cc: =?UTF-8?Q?Ren=C3=A9 Dupont_?=
     =?UTF-8?Q?<ren=C3=A9@example.org?>=

   # Corps du message