Structure MIME d'un e-mail : multipart/alternative, la partie texte brut et les encodages

Ce que c'est

Un e-mail est un bloc d'en-têtes suivi d'un corps ; MIME permet au corps d'être un arbre de parties, chacune avec son propre Content-Type. Un message comportant des versions texte et HTML utilise multipart/alternative. La RFC 2046 exige que les parties soient placées dans un ordre de préférence croissant, le format préféré étant en dernier, si bien que text/plain vient en premier et text/html en dernier ; les clients affichent la dernière partie qu'ils savent rendre. Les images intégrées se trouvent dans une enveloppe multipart/related autour de la partie HTML ; les pièces jointes se trouvent dans un multipart/mixed englobant. Les corps contenant des octets non-ASCII déclarent un Content-Transfer-Encoding : quoted-printable pour un texte majoritairement ASCII (les lignes encodées sont limitées à 76 caractères avec des sauts souples) ou base64 pour le binaire. Des champs d'en-tête comme Subject et les noms d'affichage ne peuvent pas transporter d'UTF-8 brut dans le courrier électronique classique ; les mots encodés de la RFC 2047 (=?utf-8?q?...?=, au plus 75 caractères chacun) les enveloppent.

Pourquoi c'est important

Un e-mail sans partie texte, avec une partie texte qui se contente de dire « consultez ceci dans un client HTML », ou avec un sujet dont les trémas arrivent sous forme de points d'interrogation, est perçu comme du spam aussi bien par les filtres que par les personnes. La plupart des bugs de gabarit se situent à ce niveau : l'échappement, l'encodage et la longueur de ligne, pas le texte lui-même.

Comment l'appliquer

• Générer la partie texte brut à partir des mêmes données que le HTML plutôt qu'en supprimant les balises : les titres deviennent des lignes, les liens deviennent label: URL, les tableaux deviennent des listes. Garder les deux gabarits au même endroit, de sorte qu'une modification de l'un soit aussi une modification de l'autre.
• Construire les messages avec la bibliothèque MIME de la plateforme (par exemple le module email de Python) ; ne jamais concaténer les frontières (boundaries) à la main.
• Échapper chaque variable insérée dans la partie HTML selon les mêmes règles que pour les pages web, et garder la partie texte exempte d'entités HTML.
• Laisser la bibliothèque choisir quoted-printable pour le texte et base64 pour les pièces jointes ; garder les lignes source courtes, car le format du message (RFC 5322) limite les lignes à 998 caractères et en recommande 78.
• Faire passer les sujets et noms d'affichage non-ASCII par des mots encodés ; tester avec un nom contenant des trémas et un émoji.
• Utiliser des URL HTTPS absolues et du CSS en ligne ; les feuilles de style et scripts externes sont ignorés ou bloqués par les clients de messagerie.

Pièges

Une partie texte rédigée une fois puis oubliée lorsque le HTML change. Des parties alternatives dans le mauvais ordre, de sorte que les clients préférant le texte affichent la mauvaise partie. Un jeu de caractères déclaré comme UTF-8 alors que les octets sont en Latin-1. Des images multipart/related sans références Content-ID, qui arrivent alors comme pièces jointes. Des redirecteurs de suivi dans la partie texte, où c'est l'URL brute que voit le lecteur.