Les réseaux permettent aujourd'hui de transférer les éléments les plus variés : textes richement mis en page, sons, images fixes ou animées, séquences interactives, etc. Tout cela en devient presque banal. Pourtant, certains ne peuvent toujours pas recevoir correctement un message contenant des lettres accentuées ! Pourquoi une chose qui a l'air si simple : transmettre les accents dans un message électronique, semble encore si hasardeuse ?

A la différence du Web, technique récente qui traite convenablement les accents depuis ses débuts, la messagerie est ancienne ; c'est une des premières applications de la communication entre machines. La messagerie Internet est décrite dès 1973. Aussi, les techniques utilisées aujourd'hui portent encore des stigmates de leur évolution, comme certains reptiles qui nous rappellent par des détails leurs origines préhistoriques.

• le RFC 821 décrit le protocole de transfert de messages SMTP (Simple Message Transfer Protocol),
• le RFC 822 décrit le format des messages textuels de l'Internet ; on parle du format SMTP, cette appellation pratique est assez impropre car ce format ne présume pas en théorie de l'usage du protocole SMTP pour l'acheminement du message.

Les insuffisances des RFC822 et 821

On distingue dans un message SMTP deux parties séparées par une ligne vide. La première contient les en-têtes du message : «Subject:<», «To:<», «From:<», «Received:»<, etc.
La deuxième partie est le corps du message. A priori, il n'a aucune structure particulière, il est constitué de lignes de moins de 1000 caractères écrits dans l'alphabet US-ASCII. Cet alphabet permet de représenter sur 7 bits : 32 caractères de contrôle, 26 lettres majuscules, 26 lettres minuscules, 10 chiffres, 32 caractères de ponctuation, l'espace et une touche d'effacement. Le huitième bit de l'octet, n'est pas utilisé.

A quoi bon, dans un réseau presque exclusivement américain, concevoir une messagerie plus riche ? Le problème des autres langues et de leurs alphabets n'est pas simple :

• il existe de par le monde de nombreux alphabets qu'on ne peut pas tous représenter, même avec 8 bits,
• certains recoins du réseau utilisent le huitième bit pour fiabiliser le transfert des données par contrôle de la parité,
• même le codage des caractères US varie d'un constructeur informatique à l'autre.

Le choix d'utiliser le plus petit dénominateur commun des éléments de service disponibles a toujours été et reste un frein fort aux évolutions tant il est plus important d'être reçu par tous.

Nous allons maintenant plonger dans le fonctionnement de la messagerie pour comprendre comment les accents passent encore mal et expliquer comment il est possible d'y remédier.

La représentation des messages

MIME (Multipurpose Internet Message Extensions RFC 2045 ) remplace en 1996 les RFC 1341 et 1342 de 1992 sur le même sujet et il décrit le format des messages multimédias de l'Internet. Il prévoit que les en-têtes d'un message puissent décrire la nature du message. Ainsi, le corps n'est plus un simple jeu de données à transférer ; il possède des attributs. Les messages accentués sont un cas particulier d'un message multimédia.

Voici un exemple simplifié d'en-tête de message :
Date: Thu, 22 May 1997 21:36:17 +0200 To: rd@dr15.cnrs.fr From: Serge.Aumont@cru.fr (Serge Aumont) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfert-Encoding: Quoted-Printable < Vous reconnaissez les champs Date: To: From: <, les 3 autres champs sont relatifs au format du message :

1. Mime-Version: 1.0 <ce champ indique à quelle norme (RFC) sont relatives les indications des deux autres champs. Actuellement, on ne rencontre que la valeur 1.0. Ne soyons pas trop pressés de faire cohabiter d'autres versions du standard de messagerie multimédia...
2. Content-Type: < Spécifie la nature du message. Ce champ indique, par exemple, que ce message est une image, un texte, une animation. Notre propos se limite aux textes simples, le type de contenu Mime est "text/plain".

   «charset= » est un attribut du «text/plain» qui spécifie dans quel alphabet est rédigé ce texte. Dans l'exemple, iso-8859-1 est la référence de l'alphabet latin (spécification de l'ISO qui code sur 8 bits tous les caractères des langues latines avec les accents des langues latines, seule subsiste une difficulté avec les ligatures comme le « e » dans l'« o »). À noter donc la possibilité d'utiliser d'autres alphabets (cyrillique, kanji, ...). On rencontre aussi, souvent, la valeur US-ASCII pour indiquer que le message est écrit dans l'alphabet américain. Contrairement à l'alphabet latin, l'US-ASCII contient moins de 128 caractères et peut donc être codé sur 7 bits.

   «text/plain» et «Charset» définissent complètement la nature du texte.

3. Content-Transfert-Encoding: < spécifie dans quel codage sera transféré le document. En effet, Mime prévoit la cohabitation de strates différentes dans le service de transport des messages et donc la nécessité de coder ces messages pour les faire passer à travers des réseaux dont certaines parties écrasent le 8ème bit. Il ne servirait à rien de spécifier le charset iso-8859-1 sans préciser le codage utilisé dans le transfert, vous risqueriez de continuer à voir des é transformés en i par perte du 8ème bit. Il existe plusieurs codages, base64, 7bit, binary, 8bit et le Quoted-Printable. Pour le transfert de texte, 8bit et le Quoted-Printable sont les deux principaux.
   • 7bit indique que le message ne contient plus que des caractères de l'alphabet US-ASCII, soit parce que le message ne contenait aucun caractère accentué, soit parce qu'ils ont déjà été encodés par un mécanisme autre que ceux décrits ci-après.
   • binary ou 8bit sont des indications que le texte contient des données sur huit bits sans aucun codage pour le binary et juste une notion de lignes pour 8bit.
   • le Quoted-Printable (QP) est un codage sur 7 bits de toutes les valeurs de caractères d'un alphabet 8 bits. Exemple : é est codé «=E9» , è est codé «=E8». Bien sûr, le caractère = est lui même codé «=3D». Ainsi, moyennant une légère dilatation, le message peut passer sous la toise à 7 bits sans perte d'information. Il suffit de décoder le QP lors de la réception pour retrouver le message lisible.

   Notons que si le format "binary" ou "8bit" permet la présence de caractères 8bits dans le corps du message, les en-têtes doivent ne comporter que des caractères 7 bits. On utilise donc un format particulier pour les en-têtes comme l'objet du message (champ «Subject») et les champs décrivant l'émetteur et les destinataires («From», «To», «Cc» et «Bcc»). Ce format est décrit dans le RFC 2047. En résumé, on retiendra que si un champ de l'en-tête contient des caractères accentués, alors ceux-ci doivent être codés de la façon suivante :

   1. les mots ne contenant pas de caractères accentués ne sont pas codés ;
   2. les mots contenant des caractères 8bits sont transmis ainsi : =?Indication de l'alphabet?Q?Le mot au format Quoted-Printable?=< ou =?Indication de l'alphabet?B?Le mot au format Base 64?=< ;
   3. lorsque plusieurs mots consécutifs contiennent des caractères accentués, on peut utiliser le caractère «_» en lieu et place de l'espace. Ainsi, le sujet contenant «à bientôt» sera codé comme suit : =?iso-8859-1?Q?=E0_bient=F4t?=
      =?iso-8859-1?Q?=E0?= =?iso-8859-1?Q?bient=F4t?=<.
   Si l'usage conforme à MIME d'accents dans le corps des messages est parfaitement traité dans l'énorme majorité des produits de messagerie, il n'en est pas de même en ce qui concerne l'usage des accents dans les en-têtes de messages. Peut-être est-il encore prudent d'éviter d'utiliser cette possibilité, en particulier dans la partie commentaire de votre adresse From:< (ce paramètre est souvent nommé «name»ou «real name» dans les menus de configuration de votre commande de messagerie).

En première approximation, il suffit que toutes les interfaces messagerie appliquent les règles suivantes :

1. coder l'alphabet ISO-8859-1 en Quoted Printable ;
2. ajouter les 3 lignes d'en-tête Mime décrites avant de confier le message au réseau ;
3. décoder le Quoted Printable en exploitant les en-têtes Mime lors de la réception des messages.

Pourtant, pourquoi utiliser le codage QP quand on reste sur un réseau qui supporte le 8bit ? Le QP n'est pas sans inconvénients, car même lorsqu'elles affichent bien le QP, certaines commandes de messagerie ne l'impriment pas correctement, ou ne le sauvegardent que sous leur forme QP.

Le transfert des messages

Nous savons maintenant comment MIME généralise la représentation dite SMTP des messages textuels aux messages multimédias et comment les messages textuels accentués sont considérés comme un cas particulier des messages multimédias. Voyons maintenant comment ces messages transitent dans l'Internet, et les modifications qu'ils y subissent.

Il existe deux versions du protocole de transfert de messages, SMTP et ESMTP.

• SMTP (Simple Mail Transfer Protocol) est le plus ancien et le plus rustique. La lettre de ce protocole prévoit que seuls des caractères 7bits peuvent transiter sur le réseau, mais de nombreuses implémentations acceptent le transfert SMTP en 8bits. Pour la suite du propos, on distinguera donc SMTP7bit, qui n'accepte pas le huitième bit et le supprime (transformation du «é» en «i»), et SMTP8bit qui tolère le huitième bit sans l'altérer.
• ESMTP (Extended SMTP) est apparu en 93, actuellement spécifié dans les RFCs 1652, 1869, et 1870. Comme son nom l'indique, c'est une extension de SMTP. ESMTP permet de « négocier » le transfert en 8bit ou en 7bit. Comme pour SMTP, certaines implémentations peuvent être limitées au 7bit mais, à la différence de SMTP, deux agents ESMTP qui entrent en relations échangent mutuellement l'indication de leur capacité à recevoir du 8bit.

L'exemple ci-dessous montre une trace de négociation à l'établissement d'une session ESTMP. L'émetteur se présente au destinataire par la commande SMTP "EHLO" suivie de son nom. Le destinataire répond par un "250", suivi de son nom, puis par la liste des options acceptables.

toto@univ-rennes1.fr... Connecting to mailimailo.univ-rennes1.fr. via smtp... 220 mailimailo.univ-rennes1.fr ESMTP Sendmail 8.8.5/jtpda-5.2 ready at Tue, 3 Jun 1997 09:01:18 +0200 (MET DST) EHLO listes.cru.fr 250-mailimailo.univ-rennes1.fr Hello root@listes.cru.fr [195.220.94.165], pleased to meet you 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250 HELP < Parmi ces options, la seule qui nous intéresse dans cet article est l'option 8BITMIME qui permet à l'agent SMTP récepteur d'indiquer à l'agent SMTP émetteur que le transfert en 8bits est possible.

L'auto-conversion des formats

En théorie, lorsqu'un agent SMTP doit réémettre un message contenant des données codées sur 8 bits, il doit négocier avec son vis-à-vis (voir ci-dessus) l'aptitude de ce dernier à recevoir et, éventuellement, retransmettre correctement le huitième bit. En pratique, ESMTP, qui sait faire cette négociation, et SMTP, qui en est incapable, cohabitent dans l'Internet et continuerons à cohabiter encore longtemps.

La réaction d'un agent SMTP de l'ancienne génération, lorsqu'il reçoit des caractères 8bits, est imprévisible pour l'émetteur. Elle va, comme nous l'avons vu, de l'acceptation sans altération de ces caractères (SMTP 8bits), à la suppression du 8ème bit (transformation des «é» en «i»), en passant par le plantage de l'agent SMTP de certaines passerelles X400. Dans ces conditions, lorsqu'un agent ESMTP établit une connexion et que l'agent SMTP récepteur ne propose pas l'option 8BITMIME, alors l'agent ESMTP doit effectuer l'encodage du message dans un format 7 bits, le plus naturel de ces formats étant le Quoted-Printable. Par cette technique, on évite de transférer des caractères 8 bits vers des agents qui ne sont peut-être pas en mesure de les traiter correctement.

En pratique, il faut savoir que la règle ci-dessus ne s'applique qu'aux messages déjà au format MIME. Si le message a été édité à l'aide d'un logiciel de messagerie non Mime, alors, aucune auto-conversion n'est effectuée et l'agent ESMTP transfère les caractères 8 bits sans aucune transformation, prenant le risque de voir les caractères accentués altérés par l'agent SMTP récepteur.

Dans le cas où cet encodage a bel et bien eu lieu, la passerelle qui a effectué cette opération rajoute, dans la liste des en-têtes, une ligne :

X-Mime-Autoconverted: from 8bit to quoted-printable by serveur.emetteur.fr <

Pour le cas particulier de Sendmail, qui est le logiciel serveur SMTP le plus commun sur les machines Unix, à partir de sa version 8.8, le positionnement du « flag 7 » sur un « mailer » autorise le changement de codage par ce « mailer ». Dans ce cas, si la session ESMTP ne permet pas d'avoir la certitude du transfert des caractères 8bits, Sendmail recode le message. Il utilise alors une heuristique particulière basée sur le nombre de caractères 8 bits par rapport au nombre de caractères 7 bits présents dans le message : si ce taux est élevé, la conversion aura lieu du format 8bit vers le format base64, sinon elle se fera du format 8bit au format Quoted-Printable. Dans le premier cas, si le destinataire du message n'utilise pas Mime, le message est totalement illisible, dans le deuxième cas il est truffé de codes =Ex qui n'en facilitent guère plus la lecture.

Inversement, le positionnement du « Flag 9 » dans la définition du « mailer local » permet de forcer la conversion en 8bit des messages de type text/plain< codés en quoted-printable< avant leur remise en boîte aux lettres. Il signale alors la conversion effectuée par l'ajout d'une ligne d'en-tête :

X-Mime-Autoconverted: from quoted-printable to 8bit by serveur.recepteur.fr<

On imagine le confort pour l'utilisateur !

Quelle stratégie pour envoyer et recevoir correctement les accents

Nous l'avons vu, la stratégie optimale consiste à généraliser dans l'Internet l'association d'agents ESMTP pour la transmission des messages et d'utilitaires de messagerie codant et décodant le format MIME. Malheureusement, il existe encore des configurations qui ne répondent pas à ces critères.
Pour l'utilisateur francophone, la conséquence est qu'il arrive à échanger des textes correctement accentués avec certains de ses correspondants mais pas avec d'autres.
Essayons de résumer les cas les plus fréquents que l'on rencontre. Supposons que votre correspondant vous ait envoyé la phrase «à bientôt»

Si vous recevez :

• à bientôt
  Tout va bien !
• =E0 bient=F4t
  Deux cas de figures possibles entraînent l'impossibilité de décoder le QP :

  Cas 1. votre UA ne sait pas décoder le format Mime. Dans ce cas, vérifiez votre logiciel de messagerie. Il est difficile de faire une liste exhaustive des logiciels qui ont un fonctionnement correct ou incorrect vis-à-vis du format MIME.
  Dans le monde de la micro, les versions récentes d'Eudora, et notamment les versions Pro pour Macintosh, Windows 3.x, 95 ou NT ou bien Internet Exchange pour Windows 95 ou NT ont toutes une excellente réputation. En ce qui concerne les versions plus anciennes d'Eudora, on notera que les versions jusqu'à 1.5.2 incluse présentent des anomalies notoires, comme l'absence de décodage des caractères accentués du sujet, ou bien, dans certaines circonstances, l'absence complète de décodage des messages au format Quoted-Printable lorsque le dernier mot du sujet contient un caractère accentué.
  Dans le monde des stations de travail Unix, le logiciel Exmh dispose d'un bon support MIME, sauf en ce qui concerne la fonction "faire suivre" un message ou bien l'envoi à des destinataires en "Bcc". Exmh, Zmail mais aussi Netscape sont des agents de messagerie MIME. Si l'on préfère une commande en mode ligne, choisir Elm ou Mutt, mais fuir impérativement la commande Unix mail.

  Cas 2. les infos MIME de l'en-tête du message sont fausses ou erronées. Dans ce cas, le problème est lié au logiciel utilisé par l'émetteur. Mis à part l'inciter à utiliser une version corrigée de son logiciel, il sera difficile pour vous d'améliorer la situation.

• ` bienttt
  troncature du 8ème bit par un agent SMTP.
  Dans cas, on peut recommander à l'émetteur d'activer, pour autant qu'elle existe, la fonctionnalité Quoted-Printable de son logiciel de messagerie. Les messages seront donc transmis en n'utilisant que des caractères 7 bits qui ne seront pas altérés par les agents SMTP entre l'émetteur et le destinataire. Si cette technique n'est pas applicable, il faut demander aux divers administrateurs de messageries concernés de corriger leurs agents SMTP.
• * bient*t
  (l'étoile est en fait un caractère bizarre, genre carré) : lecture du message dans une police qui n'est pas iso-8859-1. Cas typique de la lecture par NCSA Telnet sur un Mac ou un PC DOS sans activation de la conversion.
  Dans ce cas, une solution simple consiste, sur un Macintosh par exemple, à activer dans le menu Sessions - Translation, la ligne iso-8859-1. Il n'est pourtant pas absolument certain que cette technique donne satisfaction dans tous les cas, car son succès est très dépendant du logiciel utilisé pour lire le courrier sur le serveur.
• bientt
  la police de caractères que vous utilisez n'est pas à la norme iso-8859-1 et ne connaît pas les lettres accentuées. Changez de police,

Le cas des passerelles

SMTP n'est pas le seul standard de messagerie, X400 est une norme de messagerie qui a joué un rôle important et cohabite depuis longtemps avec la messagerie SMTP à travers des passerelles.

Les passerelles X400/SMTP assurent non seulement le routage des messages à la frontière entre les mondes X400 et SMTP mais aussi la conversion du format des messages. En effet, la représentation d'un message et son codage sont complètement différents dans SMTP et X400.

Il est impossible de décrire ici le détail du processus de conversion d'un message MIME vers le monde X400 où cohabitent des versions différentes de la norme (X400-84, X400-88). Signalons une méthode de représentation des caractères accentués utilisée jusqu'à présent : la convention T50 qui consiste à représenter un caractère accentué à l'aide d'un backspace (retour en arrière). Ainsi, un é peut être représenté par la séquence «e BACKSPACE '».
Sur de nombreux terminaux, cette séquence de trois caractères se traduit par l'affichage du caractère espéré ; mais cette méthode n'est bien sûr pas adaptée aux environnements complexes actuels et son emploi par des passerelles X400/SMTP est responsable des désordres constatés avec les UA MS-Mail ou CC-MAil.

Le service commercial de passerelle X400 d'ATLAS est en passe d'abandonner cette méthode pour l'emploi du codage X400-88 «General Text» au niveau de la passerelle elle-même. On retrouve ensuite la même logique de conversion des messages subordonnée à la négociation des éléments de services supportés par les agents de transfert du monde X400.

Alors, que faire ?

Les spécifications des services de messageries ont évolué, les meilleurs logiciels de messagerie, les plus rapides, les plus sûrs, ceux qui offrent les meilleures fonctionnalités sont justement aussi ceux qui traitent correctement le cas des accents, tant pour le problème d'acheminement des messages que pour celui des interfaces de lecture et de composition des messages.

Il faut les adopter car il n'y a plus de bonnes raisons de se passer des accents dans la messagerie. Utilisateur, vérifiez que vous n'avez pas déjà tout ce qui faut pour traiter ce problème, sinon, faites pression sur l'administrateur de votre messagerie pour qu'il mette en place ces solutions !