Analyser les en-têtes d’e-mails sans téléverser le message : localement dans le navigateur plutôt que dans un outil web

La manière habituelle d’analyser un en-tête d’e-mail est la suivante : copier l’en-tête depuis le client de messagerie, le coller dans un outil en ligne, le faire analyser. C’est pratique, mais l’en-tête complet est alors envoyé au serveur de l’exploitant de l’outil. Peu de personnes savent exactement ce qu’elles transmettent ainsi.

Ce qui figure réellement dans un en-tête

Un en-tête complet d’un e-mail issu d’un environnement d’entreprise contient généralement :

• Noms d’hôtes internes et adresses IP : Chaque ligne Received documente un serveur sur le chemin de livraison, y compris les serveurs Exchange internes, les passerelles et les équilibreurs de charge avec leur FQDN et souvent une adresse IP privée. L’ensemble fournit une esquisse de l’infrastructure de messagerie.
• Données personnelles : Adresses de l’expéditeur et des destinataires, noms d’affichage, objet, Message-ID et, selon le client, l’adresse IP de l’expéditeur d’origine.
• Logiciels et versions : Les lignes Received et les en-têtes spécifiques aux produits indiquent les produits utilisés, parfois avec leurs versions.
• Évaluation interne à l’organisation : Dans Microsoft 365, par exemple, l’évaluation complète du spam et de l’authentification, les identifiants du tenant et la classification interne du message.

Pour un attaquant, il s’agit de matériel utile à la préparation ; du point de vue de la protection des données, ce sont des données personnelles : expéditeur, destinataires et objet d’un message concret. Selon la loi révisée sur la protection des données, le traitement par un outil en ligne étranger reste une communication à un tiers, potentiellement à l’étranger. Dans le cas d’un en-tête provenant d’un ticket de support d’un client, la question se pose avec encore plus d’acuité : il est difficile de justifier l’insertion de ses données dans un outil web tiers sans base légale ni consentement.

L’analyse n’a pas besoin de serveur

Le point essentiel : un en-tête n’est que du texte et son analyse n’est que du parsing. Trier chronologiquement la chaîne Received, différencier les horodatages, décoder Authentication-Results, comparer les domaines : rien de cela ne nécessite de composant serveur. Tout s’exécute en JavaScript dans le navigateur, sans que l’en-tête ne quitte l’appareil.

Un outil conçu de cette manière se distingue fondamentalement, en matière de protection des données, d’un analyseur en ligne classique : aucune transmission, aucun stockage chez l’exploitant, aucun fichier journal contenant les en-têtes de tiers. L’analyse d’un en-tête client reste ainsi comparable à l’ouverture du fichier dans un éditeur local, mais en plus lisible.

Ce qu’un outil local peut faire

L’analyseur d’en-têtes d’e-mails de ce site est conçu selon ce principe. L’en-tête collé est évalué exclusivement localement dans le navigateur. Les fonctionnalités montrent que rien n’est perdu :

• Chemin de livraison avec durées : La chaîne Received est ordonnée chronologiquement, le temps passé à chaque étape est calculé et le segment le plus long est mis en évidence. Il est ainsi possible de voir où une livraison lente a réellement été bloquée. Les décalages d’horloge entre serveurs sont détectés et signalés.
• Chiffrement du transport par saut : La version TLS et le chiffrement sont lus dans les lignes Received lorsque le serveur destinataire les consigne ; Microsoft, Postfix et Exim utilisent des formats différents.
• Authentification : Résultats SPF, DKIM et DMARC issus de Authentication-Results (RFC 8601), avec des détails tels que header.d, smtp.mailfrom et compauth de Microsoft avec code de motif.
• Alignement DMARC : Les domaines From, Envelope-From et DKIM sont affichés côte à côte et évalués selon l’alignement strict et relâché.
• Intégrité ARC et DKIM : Des traces dédiées dans le graphique de flux montrent de quel point à quel point le hash DKIM est resté intact et à partir de quelle étape la chaîne ARC a conservé les résultats de vérification.
• Environnements Microsoft : Les champs du filtre antispam (X-Forefront-Antispam-Report, SCL, CAT) sont décodés, les transitions entre tenants et la classification hybride sont signalées dans le chemin de livraison.

Une limitation s’applique à tout outil d’analyse d’en-têtes, local ou non : il affiche l’évaluation documentée du serveur destinataire, pas une vérification indépendante. L’en-tête ne permet pas de savoir si un enregistrement SPF est toujours identique aujourd’hui à ce qu’il était au moment de la réception.

Mise en contexte des autres outils

Certains autres fournisseurs effectuent désormais aussi l’analyse côté client ; un examen de la déclaration de confidentialité et de la console réseau du navigateur permet de déterminer si aucune requête contenant l’en-tête n’est réellement envoyée lors du collage. Pour les analyseurs classiques côté serveur, la règle est simple : ne pas y coller d’en-têtes issus d’environnements de production ou de tiers, tout au plus des exemples anonymisés.

Pour les analyses régulières d’en-têtes liés à des incidents ou au support, un outil exécuté localement est donc le choix naturel : la question de savoir où les données ont atterri ne se pose pas.