Analyseur d'en-têtes email

Les en-têtes email suivent la RFC 5322 : un bloc de champs `Nom: valeur` séparés par deux-points, placé au-dessus du corps du message, avec les valeurs longues repliées sur des lignes de continuation qui commencent par une espace ou une tabulation. Certains champs n'apparaissent qu'une fois (From, To, Subject, Date, Message-ID) ; Received non - chaque serveur de messagerie qui traite le message ajoute sa propre ligne Received au-dessus de ce qui existait déjà.

Puisque chaque saut ajoute sa ligne en haut, le bloc d'en-têtes se lit du plus récent au plus ancien : la ligne Received la plus proche du haut du fichier correspond au dernier serveur ayant traité le message avant qu'il n'arrive au lecteur, et celle la plus proche de From/To/Subject en bas correspond au premier saut, généralement le client expéditeur ou son relais sortant. Un outil d'analyse doit inverser cet ordre pour parcourir la chaîne chronologiquement avant de pouvoir calculer quoi que ce soit de significatif sur les délais.

Chaque ligne Received regroupe plusieurs sous-champs dans une chaîne peu structurée : `from <hôte expéditeur>` (ce que le serveur récepteur a reçu comme déclaration, sans vérification indépendante), `by <hôte récepteur>`, éventuellement `with <protocole>` (ESMTP, ESMTPS, etc.), et - après le dernier point-virgule - un horodatage au format date-heure RFC 5322 marquant le moment où ce saut a enregistré la réception.

• Ligne Received la plus haute = saut le plus récent ; ligne Received la plus basse = premier saut (la chaîne se lit du plus récent au plus ancien)
• L'horodatage se trouve toujours après le DERNIER point-virgule d'une ligne Received, selon la RFC 5322 §3.6.7
• Un en-tête replié (ligne de continuation commençant par espace/tabulation) est un seul champ logique réparti sur plusieurs lignes physiques
• From, To, Subject, Date et Message-ID apparaissent normalement une seule fois ; Received et Authentication-Results peuvent se répéter à chaque saut

Une fois la chaîne Received remise dans l'ordre chronologique, l'écart entre l'horodatage d'un saut et celui du suivant correspond au temps de transit de ce tronçon - le temps pendant lequel le message a stationné quelque part, ou la durée d'une connexion lente, entre les deux serveurs. Additionner tous les écarts entre sauts, de la première à la dernière ligne Received, donne le temps total passé par le message dans le système de messagerie, depuis le serveur d'origine jusqu'au dernier saut de livraison.

Un écart anormalement long isolé - des minutes alors que chaque autre saut prend une ou deux secondes - désigne généralement une cause précise à ce serveur : un délai de greylisting (rejet temporaire délibéré pour filtrer les spams), une file d'attente saturée sous charge, ou une étape d'analyse anti-spam retenant le message. Un horodatage manquant sur un saut (ligne Received malformée ou tronquée) casse la chaîne à cet endroit précis ; le délai reste calculable sur les sauts qui s'analysent correctement, mais pas à travers cet écart-là.

Le décalage d'horloge entre serveurs est une cause réelle et banale d'un délai négatif ou incohérent - toute anomalie n'est pas un problème de routage. Un saut dont l'horloge serveur avance de quelques secondes par rapport au suivant peut afficher un petit écart négatif même sur un courrier parfaitement légitime.

L'en-tête Authentication-Results (RFC 8601) est l'endroit où un serveur de messagerie récepteur enregistre ce qu'il a conclu pour SPF, DKIM et DMARC sur ce message - ajouté par le serveur lui-même, pas par l'expéditeur, ce qui explique pourquoi il ne faut lui faire confiance que s'il provient d'une pile d'en-têtes que l'on contrôle ou d'un saut dont on sait qu'il a réellement effectué les vérifications. L'en-tête porte une ou plusieurs paires `méthode=résultat` : `spf=pass`, `dkim=fail`, `dmarc=none`, etc.

SPF (Sender Policy Framework, RFC 7208) vérifie si l'adresse IP qui s'est connectée pour livrer le message est autorisée à envoyer pour le domaine figurant dans l'adresse envelope-from, en interrogeant l'enregistrement TXT SPF de ce domaine. Un `pass` signifie que l'IP expéditrice correspondait à une entrée autorisée ; `fail` ou `softfail` signifie qu'elle ne correspondait pas ; `neutral` signifie que la politique du domaine refuse explicitement de trancher ; `none` signifie qu'aucun enregistrement SPF n'était publié du tout.

DKIM (DomainKeys Identified Mail, RFC 6376) vérifie une signature cryptographique attachée au message par rapport à une clé publique publiée dans le DNS du domaine signataire. Un `pass` signifie que la signature se vérifie et que les en-têtes/corps signés n'ont pas été altérés en transit ; `fail` signifie qu'une signature est présente mais ne se vérifie pas (altération, ou une étape de transfert ayant modifié un en-tête signé) ; `none` signifie que le message ne portait aucune signature DKIM à vérifier.

DMARC (RFC 7489) n'effectue pas sa propre vérification cryptographique ou IP - c'est une couche de politique qui exige que SPF ou DKIM passe ET soit aligné : le domaine ayant validé SPF ou DKIM doit correspondre (ou être un sous-domaine) au domaine affiché dans le From visible. Un message peut passer SPF et DKIM individuellement et échouer DMARC quand même si aucun des deux passages n'est aligné avec le domaine du From - c'est exactement la faille que les techniques d'usurpation cherchent à exploiter.

Au-delà des champs standards RFC 5322, la plupart des systèmes de messagerie récepteurs ajoutent leurs propres en-têtes `X-` non normalisés, enregistrant un verdict anti-spam avant que le message n'atteigne une boîte de réception. `X-Spam-Status` et `X-Spam-Score` (ajoutés par des filtres comme SpamAssassin) rapportent un score calculé et un verdict oui/non par rapport au seuil du système récepteur ; `X-Spam-Flag` est un marqueur oui/non plus simple que certains filtres posent à la place. `X-Spamd-Result` est l'équivalent chez Rspamd, listant généralement les règles individuelles déclenchées et leur contribution en points.

Ces en-têtes reflètent une décision déjà prise par le serveur RÉCEPTEUR sur un message qu'il a accepté - ils ne disent rien de la façon dont un autre serveur, ou un autre filtre avec d'autres règles, aurait noté le même message. Un X-Spam-Status propre sur une copie transférée ne signifie pas que le serveur du destinataire d'origine a vu la même chose, car les sauts intermédiaires peuvent retirer ou réécrire ces en-têtes entièrement.

`X-Originating-IP` et des champs propres à certains fournisseurs comme `X-MS-Exchange-Organization-SCL` (le niveau de confiance anti-spam numérique de Microsoft) ou `X-Google-SMTP-Source` apportent un contexte supplémentaire que telle ou telle plateforme de messagerie a choisi d'ajouter. Aucun de ces champs n'est normalisé comme le sont Received ou Authentication-Results - leur présence, leur format et leur signification varient selon le système de messagerie ; ils se lisent comme des signaux complémentaires, pas comme un substitut aux verdicts SPF/DKIM/DMARC.

Une adresse From usurpée se manifeste le plus souvent par un décalage entre ce que rapporte Authentication-Results et ce qu'affiche l'en-tête From visible : un DMARC en échec alors que le domaine du From paraît légitime est le signal le plus fort à lui seul, car cela signifie qu'aucun passage SPF ni DKIM aligné ne vient étayer le domaine que le lecteur voit réellement. Un premier saut Received dont l'hôte `from` n'a aucun lien évident avec le domaine expéditeur annoncé constitue un second signal, indépendant, à vérifier par rapport à l'infrastructure de messagerie propre à ce domaine.

Un délai anormal se lit sur les mêmes horodatages saut par saut que ceux utilisés pour l'analyse habituelle du temps de transit - seul le motif recherché change. Un message affichant un délai total important concentré sur un seul saut précis (plutôt que réparti régulièrement sur plusieurs) désigne ce serveur-là : une file d'attente, un greylisting, ou une étape d'analyse, et non un problème de routage général sur tout le trajet.

Rien de tout cela ne nécessite de résoudre un nom d'hôte, de géolocaliser une IP, ou de contacter un quelconque serveur - chaque signal ci-dessus est présent dans le texte collé lui-même. Une valeur d'en-tête désignant un hôte ou une IP suspecte constitue une piste à investiguer séparément (via une recherche DNS ou WHOIS sur cette valeur précise), pas quelque chose que le bloc d'en-têtes résout de lui-même.