Visionneuse d'E-mails EML

Vue d’ensemble

Un fichier .eml est un message conservé dans la forme sous laquelle il a voyagé : les en-têtes, une ligne vide, puis le corps. Les clients de messagerie en dissimulent l’essentiel, ce qui convient parfaitement jusqu’au jour où vous avez besoin de savoir ce que le message contenait réellement — un en-tête que votre client n’affiche pas, un objet arrivé en mojibake, ou la structure d’un message qui ne s’affiche pas comme prévu.

Ce lecteur coupe le fichier à la frontière des en-têtes, déplie les en-têtes repliés, décode les encoded-words MIME dans le jeu de caractères qu’ils déclarent, et vous présente à la fois les champs essentiels et le corps brut.

Utilisation

1. Enregistrez le message au format .eml, ou copiez sa source brute. Dans Thunderbird, faites glisser le message sur le bureau ; dans Apple Mail, Présentation → Message → Source brute ; dans Outlook, Enregistrer sous → Format de message Outlook puis exportez, ou passez par Fichier → Enregistrer sous → Texte.
2. Collez le contenu. Les en-têtes, une ligne vide, puis le corps : le format tient tout entier là-dedans.
3. Lisez les champs du résumé, puis parcourez le corps brut pour en saisir la structure.

Les encoded-words, ou pourquoi les objets arrivent illisibles

La spécification impose des en-têtes en pur ASCII. Le texte non ASCII y est donc transporté sous forme d’encoded-word : =?charset?encodage?données?=, où l’encodage vaut B pour base64 ou Q pour une variante du quoted-printable.

C’est le jeu de caractères indiqué au milieu qui fait toute la différence, et c’est précisément là que la plupart des outils se trompent. Les objets japonais sont encore couramment envoyés en ISO-2022-JP, un encodage à séquences d’échappement antérieur à Unicode et resté le réglage par défaut de plusieurs clients de messagerie. Le courrier d’Europe occidentale continue d’utiliser ISO-8859-1 et windows-1252. Un décodeur qui présume l’UTF-8 transforme tout cela en mojibake, et le résultat ressemble à un fichier corrompu plutôt qu’à une erreur de décodage.

Ce lecteur lit le jeu de caractères déclaré et décode en conséquence : =?ISO-2022-JP?B?…?= redevient du japonais lisible, et =?windows-1252?Q?it=92s?= redevient it's avec la bonne apostrophe typographique. Un jeu de caractères inconnu ou mal orthographié entraîne un repli sur l’UTF-8 plutôt qu’un échec.

Le pliage des en-têtes

Les en-têtes longs sont répartis sur plusieurs lignes, les lignes de continuation commençant par une espace. Un en-tête Received, ou un champ To comportant vingt adresses, occupera de nombreuses lignes dans le fichier, et ce découpage ne veut rien dire : c’est une règle de transport, pas une partie de la valeur.

Les en-têtes sont donc dépliés avant l’analyse, si bien qu’une valeur repliée est lue comme une seule chaîne. Bon à savoir quand vous lisez le texte brut vous-même : un grep sur la valeur d’un en-tête manquera tout ce qui se trouvait justement à cheval sur deux lignes.

Ce que montre le corps

Le corps est affiché exactement tel qu’il apparaît dans le fichier, et c’est délibéré.

La plupart des vrais messages sont des multipart/alternative (une version texte brut et une version HTML du même contenu) ou des multipart/mixed (le contenu plus les pièces jointes). Chaque partie possède son propre Content-Type, son propre jeu de caractères et son propre Content-Transfer-Encoding, et les parties sont séparées par une chaîne de délimitation déclarée dans les en-têtes de premier niveau.

Afficher une seule partie décodée comme s’il s’agissait « du message » masque cette structure — et cette structure est généralement ce que vous êtes venu voir : quelle partie un client restitue, si la version texte correspond à la version HTML, si une pièce jointe se trouve bien là où vous l’attendez. Le corps reste donc brut.

Cela implique qu’un corps en quoted-printable affiche =3D là où il y a un =, et un = en fin de ligne pour les sauts de ligne souples, et qu’une partie en base64 s’affiche en base64. S’il vous faut décoder l’une d’elles, copiez la partie concernée et passez-la dans le décodeur Base64 ou dans l’encodage/décodage d’URL.

Les en-têtes que votre client ne vous montre pas

Le résumé énumère les sept champs dont vous avez besoin la plupart du temps. Le texte brut que vous avez collé contient tout le reste, et plusieurs de ces en-têtes répondent à des questions que les clients escamotent.

• Return-Path est l’expéditeur d’enveloppe, c’est-à-dire la destination des rebonds. Il est posé par le serveur émetteur et diffère fréquemment de l’en-tête From:, celui qu’un humain voit. Quand SPF passe mais que DMARC échoue, cette divergence en est généralement la cause.
• List-Unsubscribe et List-Unsubscribe-Post sont ce qui fait apparaître le bouton de désabonnement en un clic dans Gmail. Un envoi en masse qui s’en passe finit plus souvent classé en spam.
• Auto-Submitted signale le courrier généré par une machine. Absent d’un message automatique, il déclenchera des réponses d’absence et des boucles de messagerie.
• In-Reply-To et References sont ce avec quoi les clients reconstituent un fil. Une réponse qui apparaît comme une nouvelle conversation est privée de l’un des deux.
• Content-Language et Accept-Language expliquent pourquoi un expéditeur multilingue a retenu la version qu’il a choisie.
• Les en-têtes X-* sont ce que l’infrastructure d’envoi a ajouté. Scores de spam, identifiants de campagne et noms de files internes s’y retrouvent, et c’est le moyen le plus rapide d’identifier quel système a réellement expédié un message.

Exemples

• Un objet qui arrive en charabia. Collez le message ici. Si l’objet est lisible, l’expéditeur est en règle et c’est le client de réception qui traite mal le jeu de caractères.
• « Le message ne s’affiche pas pareil dans Outlook. » Regardez la structure des délimiteurs. Un multipart/alternative dont les deux parties divergent explique la majorité de ces signalements.
• Un en-tête manquant. Les clients n’affichent qu’un sous-ensemble choisi. List-Unsubscribe, Auto-Submitted, X-Failed-Recipients et leurs semblables sont bien dans le fichier même si rien ne les montre.
• Vérifier ce que vous avez réellement envoyé. Enregistrez un message depuis votre propre dossier d’envoi et relisez-le. Les surprises d’encodage se repèrent beaucoup plus facilement sous forme brute.

Remarques

La séparation en-têtes / corps se fait à la première ligne vide, conformément au format. Un fichier dépourvu de toute ligne vide est traité comme n’étant fait que d’en-têtes, ce qui est exactement le comportement souhaitable quand on colle uniquement le bloc d’en-têtes.

Rien ici ne valide le message. Un .eml avec une Date mal formée, un Message-ID absent ou un délimiteur qui n’apparaît jamais dans le corps s’affichera exactement tel quel, parce que l’objectif est de voir ce que le fichier contient et non ce qu’il aurait dû contenir.

Pour le chemin d’acheminement, les délais saut par saut et les verdicts SPF, DKIM et DMARC, utilisez l’analyseur d’en-têtes d’e-mail. Il lit les mêmes en-têtes avec une autre question en tête.