Analyseur d’en-têtes d’e-mail

Ce qu’un en-tête d’e-mail peut montrer : et ce qu’il ne peut pas montrer

Un e-mail Internet se compose de champs d’en-tête nommés, suivis d’une ligne vide et du corps du message. La norme RFC 5322 définit ce format, notamment le repliement des champs : une ligne commençant par une espace prolonge le champ précédent. L’analyseur déplie ces continuations avant d’interpréter les données. Il s’arrête à la première ligne vide ; le corps et les pièces jointes ne sont donc pas analysés.

Les agents de transfert de courrier ajoutent normalement un champ Received en tête à chaque passage par un serveur. Dans la source brute, ces champs apparaissent donc du plus récent au plus ancien. Le rapport les inverse pour afficher une chronologie depuis l’origine. Un intervalle n’est indiqué que si les deux horodatages voisins sont interprétables. Un intervalle négatif est signalé comme un possible décalage d’horloge et empêche le calcul du temps de transit total ; il n’est jamais remplacé discrètement par zéro.

Comprendre la section d’authentification

La norme RFC 8601 définit Authentication-Results, un champ ajouté par le système destinataire pour consigner des résultats tels que spf=pass, dkim=pass ou dmarc=fail. L’analyseur conserve les champs Authentication-Results dupliqués, car un message peut traverser plusieurs domaines administratifs. Il garde aussi les propriétés associées comme smtp.mailfrom, header.d et header.from telles qu’elles ont été déclarées.

Une DKIM-Signature contient des métadonnées comme le domaine signataire (d=), le sélecteur (s=), l’algorithme (a=), l’identité (i=) et de longues valeurs cryptographiques (b= et bh=). Le rapport relève les balises utiles et la présence des valeurs de signature, mais exclut volontairement les blocs de signature des exports JSON. Il n’effectue ni requête DNS ni vérification cryptographique.

La norme RFC 8617 définit Authenticated Received Chain (ARC). Une instance ARC est structurellement complète lorsqu’elle contient un élément ARC-Seal, un ARC-Message-Signature et un ARC-Authentication-Results portant le même i=. Ici, « complète » décrit uniquement ces trois éléments ; la chaîne n’est pas pour autant valide ou digne de confiance.

Exemple de routage

Supposons que la source brute contienne deux champs Received. Le champ inférieur indique qu’une origine a remis le message à un relais à 10:00:03 +0000 ; le champ supérieur, que le relais a atteint le destinataire à 10:00:10 +0000. Le rapport affiche d’abord l’événement d’origine et calcule un intervalle observé de 7 secondes. Les fuseaux horaires sont respectés : entre 10:00:03 +0000 et 12:00:06 +0200, l’intervalle est de 3 secondes, pas de deux heures. Si le second horodatage normalisé précède le premier de cinq secondes, le rapport signale un décalage d’horloge et laisse le total indisponible.

Périmètre de confiance et pièges courants

La norme RFC 5321 décrit le transport SMTP et les informations de trace ajoutées par les serveurs. Des en-têtes reçus hors d’un système de messagerie fiable peuvent être inventés. Commencez votre chaîne de confiance à un destinataire que vous contrôlez, puis ne remontez que jusqu’au point justifié par ses journaux et ses politiques. Une différence entre les domaines du From visible et du Return-Path est courante avec les listes de diffusion, les services de transfert et les plateformes transactionnelles ; c’est une observation, pas une preuve d’usurpation.

Les objets et noms d’affichage codés peuvent utiliser les mots codés de la RFC 2047. L’analyseur décode les formes Base64 ou quoted-printable courantes en UTF-8, ISO-8859-1 et Windows-1252 ; une codification non prise en charge reste visible avec un avertissement. Il limite les très grandes collections de champs et de relais afin de préserver la réactivité du navigateur. Pour une réponse à incident, conservez séparément le message original : les exports sont des rapports synthétiques qui excluent volontairement l’entrée brute, le corps, les pièces jointes et les blocs de signature DKIM.

Confidentialité et exports

L’analyse, la sélection, la copie et la création des exports s’effectuent localement dans l’onglet actuel. Les étapes de l’entonnoir utilisent un stockage de session propre à l’onglet, et non l’URL : les en-têtes bruts ne sont ni envoyés via Livewire ni exposés dans les paramètres de navigation. La saisie est limitée à 512 Kio. Le CSV de la chronologie utilise UTF-8 avec marque d’ordre des octets et des lignes CRLF ; les cellules commençant par un caractère de formule de tableur sont neutralisées. Le JSON contient les observations analysées et la réserve du rapport, pas l’en-tête original.