appuyez sur ⌘K pour changer d’outil
EMAIL AUTH

Analyseur d'En-têtes de Mail

Analyse les en-têtes d'e-mail et trace les routes de livraison.

local
message-header
§01 À PROPOS DE CET OUTIL

Vue d’ensemble

Chaque serveur de messagerie qui traite un message ajoute un en-tête Received en tête. Lus dans l’ordre, ces en-têtes constituent le trajet de livraison : quel hôte a remis le message à quel autre, et quand. Lus en regard des résultats d’authentification, ils vous disent si le message provient bien de là où il le prétend.

Cet outil déplie les en-têtes, reconstitue le trajet sous forme de liste numérotée de sauts avec les délais par saut, et fait remonter séparément les en-têtes d’authentification pour que vous n’ayez pas à les chercher au milieu du bruit.

Utilisation

  1. Dans votre client de messagerie, ouvrez le message original ou sa source brute. Dans Gmail, c’est Afficher l’original ; dans Outlook, Propriétés → En-têtes Internet ; dans Apple Mail, Présentation → Message → Source brute.
  2. Collez tout, du haut du message jusqu’à la première ligne vide. Le corps n’est pas nécessaire.
  3. Lisez la liste des sauts de haut en bas — le saut 1 est l’origine.
  4. Lisez les résultats d’authentification en dessous.

Lire la liste des sauts

Chaque ligne affiche l’hôte émetteur (from), l’hôte destinataire (by) et le délai écoulé depuis le saut précédent. Une livraison normale compte deux à cinq sauts et s’achève en quelques secondes.

Le sens importe. Les relais ajoutent en tête plutôt qu’à la fin, si bien que les en-têtes bruts se lisent du plus récent au plus ancien ; la liste présentée ici est inversée pour se lire dans le sens du voyage du message. Quand vous la comparez à la source brute, souvenez-vous qu’elles sont à l’envers l’une par rapport à l’autre.

Les délais proviennent de la date inscrite dans chaque en-tête Received, et ces horodatages sont écrits par des machines différentes dont les horloges sont réglées indépendamment. Un écart d’une ou deux secondes, y compris négatif, relève de la dérive et ne prouve rien. Un trou de plusieurs minutes ou de plusieurs heures est réel, et signifie presque toujours que le serveur destinataire a mis le message en file d’attente — la mise en liste grise, qui diffère délibérément un expéditeur inconnu, en est de loin la cause la plus fréquente.

Lire les résultats d’authentification

Quatre en-têtes comptent, et ils répondent à des questions différentes :

  • Received-SPF — l’adresse IP qui s’est connectée était-elle autorisée à envoyer pour le domaine de l’expéditeur d’enveloppe ? SPF contrôle l’enveloppe (MAIL FROM), qui n’est pas l’en-tête From: que votre destinataire voit. Un message peut passer SPF et afficher malgré tout un expéditeur falsifié.
  • DKIM-Signature — une signature cryptographique portant sur des en-têtes sélectionnés et sur le corps, vérifiable avec une clé publique publiée dans le DNS du domaine signataire. d= est le domaine signataire et s= le sélecteur : les deux localisent ensemble la clé à <selector>._domainkey.<domain>.
  • Authentication-Results — le verdict propre au serveur destinataire, combinant SPF, DKIM et DMARC. C’est la ligne à lire en premier, parce qu’elle est écrite par la seule machine de la chaîne à laquelle vous ayez une raison de faire confiance.
  • ARC-Authentication-Results — le verdict enregistré par un intermédiaire avant qu’il ne modifie le message. Les listes de diffusion réécrivent les en-têtes et cassent DKIM par conception, et ARC existe pour que le résultat d’origine y survive.

DMARC est celui qui détermine ce que les destinataires font réellement. Il exige que SPF ou DKIM passe et soit aligné — le domaine qui passe doit correspondre au domaine de l’en-tête From: visible. L’alignement explique pourquoi un message peut afficher spf=pass et dkim=pass et échouer tout de même à DMARC : les deux ont passé, mais pour le mauvais domaine.

Exemples

  • « Nos e-mails partent en spam. » Lisez Authentication-Results sur un message que vous vous êtes envoyé chez un autre fournisseur. Si DKIM passe mais que DMARC échoue, le problème est l’alignement, pas la signature.
  • Un message d’hameçonnage convaincant. Comparez le from du saut 1 au domaine de l’en-tête From: visible. Falsifier un nom d’affichage est trivial ; falsifier un premier saut qui corresponde à la véritable infrastructure du domaine revendiqué ne l’est pas.
  • Une livraison qui prend vingt minutes. Trouvez le saut porteur du délai. S’il s’agit du premier serveur entrant du destinataire, la mise en liste grise est la réponse probable et elle se résout d’elle-même à la nouvelle tentative.
  • Du courrier qui a cessé d’arriver après un changement DNS. Vérifiez SPF dans les résultats. Deux enregistrements SPF sur un même domaine, ou un enregistrement qui dépasse la limite de dix consultations, produisent tous deux un échec permanent qui a l’air d’un mystère.
  • Une liste de diffusion qui casse votre signature. Cherchez les en-têtes ARC. Leur présence vous dit qu’un intermédiaire a modifié le message et a consigné le verdict antérieur.

Remarques

Les lignes de continuation sont dépliées avant l’analyse. Les en-têtes longs sont repliés sur plusieurs lignes précédées d’une espace, et un analyseur qui lit ligne par ligne sans les rejoindre tronquera précisément les en-têtes qui comptent le plus.

Les valeurs from et by sont lues uniquement en début de clause. Un en-tête Received sans clause from contient souvent malgré tout la chaîne envelope-from à l’intérieur d’un commentaire, et la traiter comme l’hôte connecté afficherait une adresse fournie par l’attaquant comme origine du message — précisément le fait que vous êtes venu vérifier ici.

Tout ce qui précède décrit ce que disent les en-têtes. Les en-têtes écrits avant la première machine que vous contrôlez peuvent être fabriqués intégralement : la chaîne est donc une preuve concernant votre propre infrastructure, et une simple affirmation concernant tout ce qui se trouve en amont.

Pour inspecter un message enregistré plutôt que ses seuls en-têtes, utilisez le visualiseur EML.

FAQ
Les en-têtes que je colle sont-ils envoyés quelque part ?
Non. Les en-têtes sont dépliés et analysés dans la page ; il n'y a aucune requête réseau. Cela compte ici parce que des en-têtes complets contiennent des adresses de destinataires, des noms d'hôtes internes et des identifiants de messages.
Pourquoi la liste des sauts est-elle dans l'ordre inverse des en-têtes bruts ?
Parce que chaque relais ajoute sa propre ligne Received en tête, si bien que l'ordre brut va du plus récent au plus ancien. La liste est inversée pour que le saut 1 soit l'expéditeur d'origine et le dernier saut votre boîte aux lettres — le sens dans lequel le message a réellement voyagé.
Puis-je faire confiance aux premiers sauts ?
Seulement à partir du premier serveur que vous contrôlez, en allant vers l'intérieur. Tout ce qui précède a été écrit par des machines que vous n'exploitez pas et peut être fabriqué de toutes pièces. Lisez la chaîne de bas en haut et cessez de lui faire confiance à la frontière de votre propre infrastructure.
Un saut affiche un tiret au lieu d'un hôte émetteur. Est-ce un problème ?
Non. Les relais internes n'enregistrent souvent qu'une clause `by` sans `from`, ce qui est normal pour une livraison locale, un transfert LMTP et un filtrage sieve. Un tiret signifie que l'en-tête n'avait véritablement pas de clause from, pas que l'analyse a échoué.
Que signifie un long délai sur un saut ?
En général une mise en liste grise (greylisting) ou une file d'attente sur le serveur destinataire. Les délais sont calculés à partir des horodatages d'en-têtes Received consécutifs, et ces horloges appartiennent à des machines différentes : un délai légèrement négatif ou nul relève donc de la dérive d'horloge et non du voyage dans le temps.