Analyse Forensique de Courriels - Analyseur Gratuit d'En-têtes, d'Authentification et de Pièces Jointes .eml
Analyse Forensique de Courriels
Chargez un fichier .eml brut ou un .msg Outlook pour reconstruire sa chaîne de livraison, vérifier hors ligne son hash de corps DKIM, et contrôler ses pièces jointes, archives et liens - sans rien téléverser.
Déposez ici un fichier .eml ou .msg
ou cliquez pour parcourir votre appareil
Choisir un messageVue d'ensemble du message
Les champs d'enveloppe déclarés par ce message, et ce qui s'en distingue.
Chaîne d'en-têtes
Chaque en-tête Received: reconstruit dans l'ordre où le message a réellement voyagé, et tracé sur un axe temporel commun ci-dessus, afin qu'un saut trop long ou un horodatage désordonné soit visible d'un coup d'œil.
Authentification
Cet outil ne peut qu'afficher et interpréter l'en-tête Authentication-Results déjà apposé par un serveur de messagerie destinataire - il ne peut pas interroger le DNS pour revérifier de façon indépendante SPF, DKIM ou DMARC. Un résultat entièrement positif n'est fiable que s'il a été apposé par votre propre infrastructure de messagerie ; un en-tête ajouté par un relais intermédiaire non fiable ne prouve rien. La seule exception est le hash de corps DKIM, recalculé ici à partir du message lui-même - voir le panneau ci-dessous pour savoir exactement ce qu'une correspondance prouve et ne prouve pas.
En-têtes
Chaque en-tête exactement tel que stocké, et la même liste décodée et signalée en cas d'anomalie, comme un From ou un Subject dupliqué.
Corps & liens
Le corps HTML est affiché dans un cadre isolé (sandbox) avec les scripts désactivés, et les images ou ressources distantes qu'il référence ne sont jamais chargées - seulement comptées.
Pièces jointes
Chaque fichier joint, son type déclaré comparé à ce que ses propres octets sont réellement, un hash SHA-256, et toute ruse de double extension. Les pièces jointes de type archive sont ouvertes et leur contenu subit les mêmes vérifications, sans que rien à l'intérieur ne soit jamais exécuté.
Analyse de l'expéditeur
Vérifications du nom d'affichage et de l'adresse, ainsi qu'un examen purement heuristique du domaine d'envoi à la recherche de libellés internationalisés (punycode) et de caractères visuellement trompeurs.
Chaînes
Texte imprimable trouvé n'importe où dans le fichier brut.
--
Source brute
La source .eml brute complète, exactement telle que lue dans le fichier.
Comprendre l'analyse forensique des en-têtes de courriel
Ce que montre réellement la chaîne Received
Chaque serveur de messagerie qui traite un message ajoute son propre en-tête Received: avant de faire suivre le message, si bien que la source brute se retrouve avec le saut le plus récent listé en premier. Lire cette chaîne dans l'ordre où le message a réellement voyagé - du saut le plus ancien au plus récent - reconstruit le véritable chemin de livraison : de quel serveur il est parti, quels serveurs l'ont relayé, et approximativement combien de temps chaque saut a pris. Un saut dont l'horodatage est antérieur à celui qui le précède, ou un écart de plusieurs heures là où aucun n'est attendu, est une piste qui mérite d'être creusée, pas une preuve en soi - le décalage d'horloge entre serveurs est courant et anodin.
Pourquoi les résultats d'authentification ne peuvent pas être revérifiés ici
SPF, DKIM et DMARC dépendent tous de résolutions DNS interrogeant les enregistrements publiés du domaine d'envoi au moment où le message a été livré. Une page de navigateur n'a aucun moyen d'effectuer cette résolution après coup, et même si elle le pouvait, les enregistrements peuvent avoir changé depuis. Ce que cet outil peut faire, c'est lire l'en-tête Authentication-Results que votre propre serveur de messagerie a déjà apposé, et expliquer ce qu'il indique. Cet en-tête n'est significatif que si vous faites confiance à l'infrastructure qui l'a ajouté - un attaquant qui contrôle un saut antérieur peut ajouter un faux en-tête prétendant que tout est passé avec succès.
Pourquoi le corps HTML s'exécute dans un bac à sable
Un courriel HTML est, fonctionnellement, une page web non fiable écrite par quelqu'un d'autre. Cet outil le rend à l'intérieur d'un iframe dont toutes les permissions de sandbox sont désactivées - aucun script, aucun accès de même origine, aucune soumission de formulaire, aucune fenêtre pop-up - après avoir aussi retiré les balises script/style, les attributs de gestionnaire d'événements et les liens javascript: du balisage lui-même. Les images distantes et autres ressources hébergées à l'extérieur référencées dans le HTML ne sont jamais récupérées : les charger confirmerait silencieusement à l'expéditeur du message qu'il a été ouvert, ce qui est exactement l'objet d'un pixel espion.
100 % privé, dans le navigateur
L'analyse des en-têtes, le décodage MIME, l'interprétation de l'authentification et le hachage des pièces jointes s'exécutent tous localement dans votre navigateur. Le message n'est jamais téléversé nulle part. Cela compte ici plus que presque partout ailleurs sur ce site : les courriels que l'on souhaite le plus vérifier sont ceux qui ressemblent à de l'hameçonnage, à une fraude à la facturation ou à une compromission de compte - exactement les messages qui ne devraient pas être transmis à un serveur tiers pour obtenir une réponse.
Des indices, pas des preuves
Tout ce qui figure sur cette page décrit ce qui est stocké dans le fichier, ce qui n'est pas la même chose que l'intention. Un en-tête Authentication-Results manquant peut signifier qu'un message n'a jamais été vérifié par un serveur auquel vous faites confiance, ou simplement qu'il a été envoyé depuis une boîte aux lettres qui n'effectue pas ces vérifications. Un domaine en punycode peut être un nom d'entreprise internationalisé parfaitement légitime. Un Reply-To différent est une pratique courante pour de nombreuses listes de diffusion et systèmes d'assistance. Traitez chaque constat ici comme une piste à recouper avec le contexte complet - de qui vient le message, ce qu'il demande, et s'il correspond à la façon dont cet expéditeur communique habituellement - et là où l'enjeu est important, faites appel à une personne qualifiée plutôt que de vous fier à une seule lecture automatisée.
Points clés à retenir
- La chaîne de livraison est reconstruite, pas devinée : chaque en-tête Received: est analysé et replacé dans l'ordre où le message a réellement voyagé.
- Les résultats d'authentification sont rapportés, jamais revérifiés : les vérifications SPF/DKIM/DMARC exigent une résolution DNS en direct, que cette page n'effectue délibérément pas.
- Le corps HTML ne peut jamais exécuter de code : il est assaini, puis rendu dans un cadre entièrement isolé avec les scripts désactivés.
- Les images distantes ne sont jamais chargées : les ressources de type pixel espion sont comptées et signalées, pas récupérées.
- Rien ne quitte votre appareil : chaque analyse, hachage et vérification s'exécute côté client, dans votre navigateur.