Les entêtes « Received » d'un mail sont importants pour comprendre le chemin qu'un message a pris pour arriver chez nous, dans notre « boîte mail »^[1]. Mais leur intérêt s'explique surtout par la nécessité d'identifier l'expéditeur de mails frauduleux. C'est le seul moyen de connaître l'origine exacte d'un e-mail.

Chaque ordinateur – agissant comme serveur ou client – qui est à un quelconque moment impliqué dans le transfert, ajoute un ou plusieurs entêtes Received aux mails qu'il reçoit et/ou envoie.

Trouver les entêtes Received

Votre Client Mail doit certainement avoir une fonction pour visualiser tous les entêtes d'un mail que vous êtes en train de lire. Les entêtes Received, se suivent souvent en un seul bloc, mais ce n'est pas toujours le cas.

Exemple

Les entêtes suivants précèdent un message reçu via une Liste de Distribution (faire défiler). Ne paniquez pas ! Faites pour l'instant abstraction de vos doutes; si vous ne vous y retrouvez pas tout de suite, ce n'est pas grave, car il se trouve que ce n'est pas encore nécessaire.

Si vous voulez tout savoir sur ces entêtes, consultez le RFC 5321, Chapitre 4.4.

DMARC-Filter: OpenDMARC Filter v1.3.2 mx0.infini.fr DCA7D4747C52
To: gnupg-users@gnupg.org
Subject: gpg: signing failed: No secret key
Date: Thu, 07 Sep 2023 18:03:28 +0000
Message-ID: <268a77d8-45c3-5219-9571-6ee1a989cd34@onionmail.org>
MIME-Version: 1.0
Precedence: list
From: isp_stream via Gnupg-users <gnupg-users@gnupg.org>
Reply-To: isp_stream <ipstream@onionmail.org>
Content-Type: multipart/mixed; boundary="===============1564869149125821414=="
Errors-To: gnupg-users-bounces@gnupg.org
Sender: "Gnupg-users" <gnupg-users-bounces@gnupg.org>

Ici, la suite des entêtes Received est parfois interrompu par les résultats des filtres DKIM et DMARC, si nous les supprimons ou les occultons, c'est déjà plus facile à lire :

1) Received: from mx0.infini.fr (1.lvs.ha01.infini.local [192.168.101.64])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
    key-exchange X25519 server-signature RSA-PSS (2048 bits))
    (No client certificate requested)
    by dov02.infini.local (Postfix) with ESMTPS id 94FE92891ABE
    for <utilisateur@compte_infini.fr>; Thu, 7 Sep 2023 20:05:13 +0200 (CEST)

2) Received: from localhost (localhost [127.0.0.1])
    by mx0.infini.fr (Postfix) with ESMTP id 5F23E4747C59
    for <utilisateur@compte_infini.fr>; Thu, 7 Sep 2023 20:05:13 +0200 (CEST)

3) Received: from mx0.infini.fr ([127.0.0.1])
    by localhost (mel01.infini.local [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id E2iJUjKybogd for <utilisateur@compte_infini.fr>;
    Thu, 7 Sep 2023 20:05:11 +0200 (CEST)

4) Received: from lists.gnupg.org (lists.gnupg.org [217.69.76.57])
    by mx0.infini.fr (Postfix) with ESMTP id DCA7D4747C52
    for <utilisateur@compte_infini.fr>; Thu, 7 Sep 2023 20:05:09 +0200 (CEST)

5) Received: from localhost ([127.0.0.1] helo=trithemius.gnupg.org)
    by lists.gnupg.org with esmtp (Exim 4.84_2 #2 (Debian))
    id 1qeJLt-0000pv-QO; Thu, 07 Sep 2023 20:03:37 +0200

6) Received: from ellsberg.gnupg.com ([176.9.119.14])
    by lists.gnupg.org with esmtps (Exim 4.84_2 #2 (Debian))
    id 1qeJLm-0000pi-FX
    for <mm.gnupg-users@lists.gnupg.org>; Thu, 07 Sep 2023 20:03:30 +0200

7) Received: from mail.onionmail.org ([173.249.33.206])
    by ellsberg.gnupg.com with esmtps (Exim 4.94.2 (Devuan))
    (envelope-from <ipstream@onionmail.org>) id 1qeJLl-0007f6-UA
    for <gnupg-users@gnupg.org>; Thu, 07 Sep 2023 20:03:30 +0200

8) Received: from localhost
    by mail.onionmail.org (ZoneMTA) with API id 18a70d0376f000206c.001
    for <gnupg-users@gnupg.org>; Thu, 07 Sep 2023 18:03:28 +0000

Reconstruire les étapes de la transmission

Une chose qui doit être claire tout de suite : l'ordre de ces entêtes dans le mail n'indique pas forcément l'ordre de leur création; le fait que deux entêtes Received se suivent, ne devrait pas être compris comme une preuve de leur succession dans le temps. Bien que cela soit souvent pertinent ( comme dans l'exemple ) et corresponde au concept, il peut avoir des exceptions. Mais ce n'est pas grave, parce que ces entêtes sont logiquement connectés entre eux, comme les maillons d'une chaine, et chaque maillon ( sauf le premier ) connaît son prédécesseur !

Autrement dit, nous pouvons mélanger les huit entêtes Received et les mettre dans n'importe quel ordre, et saurons encore d'où vient le mail et par quelles instances intermédiaires il est passé avant d'arriver chez nous.

Les trois éléments qui reviennent dans la plupart des entêtes Received, sont aussi présents dans le tout premier :

Le serveur précédent: from mx0.infini.fr (1.lvs.ha01.infini.local [192.168.101.64])
Le serveur actuel, qui est en train d'ajouter l'entête Received: by dov02.infini.local
L'adresse à qui le mail doit être transmis ensuite.: for <utilisateur@compte_infini.fr>

Rappelez-vous qu'un « serveur » n'est d'abord qu'un logiciel, ou même seulement une instance parmi plusieurs possibles de ce même logiciel qui est exécuté quelque part. Les noms qui sont affichés peuvent donc représenter des processus, exécutés sur la même machine. Si vous comparez les deux premiers éléments, “from” et “by”, vous ne voyez pas d'adresse IP pour dov02.infini.local. L'IP 192.168.101.64, par contre, est une adresse locale, donc pas joignable par l'extérieur du réseau, à qui appartient ce serveur.

Savoir à qui nous avons affaire

Deux petits outils, ping^[2] et whois^[3], disponibles sur tous les systèmes d'exploitation, aident à l'identification des ordinateurs, connectés à l'Internet.

Ping

Essayez de contacter directement, à partir de votre propre ordinateur, le serveur mx0.infini.fr. Comme l'adresse 192.168.101.64 ne peut pas être « visible » pour vous, qu'est-ce qui se passe ? Il est facile d'employer l'outil ping pour tester :

:~$ ping mx0.infini.fr

PING mx0.infini.fr (185.204.160.198) 56(84) bytes of data.

64 bytes from mx0.infini.fr (185.204.160.198): icmp_seq=1 ttl=51 time=36.1 ms

64 bytes from mx0.infini.fr (185.204.160.198): icmp_seq=2 ttl=51 time=36.2 ms

(...)

Whois

Et voilà. L'IP, qui est utilisée dans l'entête Received n'est pas la même que celle qui est exposée à l'Internet. Avant d'en tirer une conclusion, nous essayons l'inverse : Ayant trouvé une adresse 185.204.160.198, comment pouvons-nous savoir à qui appartient cette adresse ? C'est l'outil whois qui nous vient en aide :
:~$ whois 185.204.160.198
La réponse à cette commande est assez longue et – si vous l'exécutez pour la première fois – contient une quantité surprenante d'informations, certainement utiles pour « quelqu'un ». Mais nous, nous allons nous servir des mêmes données, et nous essaierons donc de les localiser :

Le nom de l'organisme qui possède cet adresse IP
La plage d'adresses, dont celle-ci fait partie
le contact pour signaler les abus d'un service
Éventuellement d'autres informations, qui permettent de déduire l’appartenance de cette entreprise à un grand groupe et/ou des coopérations.

Ayant supposé que l'adresse 185.204.160.198 « appartient » à Infini, car elle est attribuée à mx0.infin.fr, nous apprenons donc que c'est plutôt l'entreprise Xancom qui fournit l'adresse à Infini. Ceci est d'abord dû au fait que Xankom est tout simplement le « Fournisseur d'Accès Internet » de Infini.

Nous apprenons aussi, que 185.168.160.198 fait partie de la plage d'adresses 185.204.160.0 - 185.204.160.255. En effet, les organismes qui achètent des adresses IP en possèdent parfois plusieurs plages. Celle-ci comprend donc 256 adresses. Au regard de ce constat, nous pouvons parfois estimer le degré d'engagement d'une structure dans l'organisation des services, surtout, quand nous arrivons à voir toutes les plages d'adresses, qui appartiennent à une seule entreprise^[4].

En cas d'abus, la plage d'adresses peut être sujette au filtrage et/ou blockage. Ceci n'est pas notre problème pour le moment. Par contre, si nous supposons qu'un service, mis à disposition par l'entreprise qui possède une adresse IP, a été utilisé dans des activités frauduleuses ( SPAM n'est pas assez spécifique ici ), nous savons maintenant où nous plaindre : <sysadmin@dm-p.com> est l'adresse mail affiché comme “Abuse Contact” dans la dernière ligne du commentaire en haut.

Mais ATTENTION ! Avant d'informer le département chargé de la gestion des abus d'un organisme, assurez-vous que celui-ci est vraiment responsable du premier serveur, concerné par la transmission d'un mail. Ceux qui suivent ne vont pas – et ne peuvent pas – intervenir pour arrêter des arnaques ou pour les éviter dans l'avenir.

Il y a peu d'autres choses à apprendre de cette réponse de Whois. D'autres recherches peuvent être plus intéressantes encore, ou – malheureusement – beaucoup moins.

Remonter dans le temps

Les actions précédentes nous expliquent le tout premier entête Received de la liste en haut ( ouvrez ce lien dans un autre onglet ou fenêtre pour pouvoir suivre par la suite ) :

Nous savons que le mail en question a été livré par mx0.infini.fr à dov02.infini.local (ce qui est un nom interne à Infini, qui n'a pas de représentation dans l'Internet – testez si vous voulez ).
En fin du compte, le mail sera expédié à <utilisateur@compte_infini.fr>, notre adresse mail.
Le fait que mx0.infini.fr soit joignable via Internet – disposant de l'adresse IP 185.204.160.198 – signifie que cette machine peut recevoir des messages de n'importe où. Notre message peut, donc, provenir de quelque part en dehors d'Infini.

Pour avancer ( ou reculer dans le temps ), il suffit de chercher l'entête Received qui contient “by mx0.infini.fr”, parce qu'il va nous apprendre qui a cherché à contacter l'infrastructure d'Infini.

▼ Mais il y en a deux. Dans un cas, l'expéditeur du message est localhost, c'est à dire un autre processus sur la même machine; nous ignorons cet entête tout de suite.

▼ Nous prenons connaissance d'un événement similaire dans l'entête suivant, où localhost reçoit le message de mx0.infini.fr. Bon. C'est cool, mais ... SUIVANT !

▼ Enfin. C'est le quatrième entête, où il se passe quelque chose, car mx0.infini.fr reçoit le mail de « lists.gnupg.org ». Nos pouvons de nouveau faire des recherches sur cette machine, mais nous voyons déjà que son adresse IP est également fournie (vérifiez avec un ping). Le whois peut nous informer que le propriétaire de l'adresse est une entreprise en Allemagne, qui a envoyé le mail à Infini.

▼ Puis ça continue. D'abord nous voyons que le mail a été passé d'un processus local à un autre sur la machine de lists.gnupg.org ( entête 5 ).

▼ Dans l'entête 6, lists.gnupg.org reçoit le message de ellsberg.gnupg.com. Nous vérifions que l'adresse IP affichée est authentique ( ping ). Elle appartient à une autre entreprise allemande.

▼ Une autre transmission via Internet est documentée dans l'entête 7. elsberg.gnupg.org reçoit le message de mail.onionmail.org, IP 173.249.33.206. C'est un peu ennuyeux, mais le propriétaire de l'adresse est de nouveau une entreprise allemande.

▼ L'entête 8 est la dernière, et là, le mail est envoyé à mail.onionmail.org par localhost. Ça ne nous intéresse plus.

Il est finalement établi que mail.onionmail.org, plus précisément un serveur avec l'adresse IP 173, 249.33.206 a injecté le mail. Regardez encore une fois l'entête 7 : le destinataire de ce message n'est pas un compte chez Infini, mais gnupg-users@gnupg.org^[5]. Ce qui change de l'entête 4, où l'adresse <utilisateur@compte_infini.fr> apparaît pour la première fois. Il n'est pas difficile de comprendre que le mail a été adressé à une liste de distribution, et que les destinataires finaux sont déterminés seulement à la fin, car c'est cette liste elle-même qui connaît ces adresses.

À quoi bon ?

La procédure décrite jusque là sert à éliminer des doutes par rapport à

l'authenticité d'un message
quand les fautes d'orthographe et de grammaire dans un texte suggèrent que les faits que votre ancien camarade de l'école vous présente ne sont pas des faits réels, et ne sont en fait pas non plus relayés par votre ancien camarade de l'école.
l'authenticité de l'adresse de l'expéditeur d'un message
ou quand votre banque du coin de la rue se trouve tout à coup en Côte d'Ivoire.
la représentation d'un organisme par l'expéditeur d'un message
car votre fournisseur d'électricité ne sait sûrement rien de tout cela.
l'intérêt que prétend porter l'expéditeur d'un message à vos affaires
quand vous ne vous souvenez pas d'avoir été tellement généreux, au point qu'une princesse africaine ait pu en entendre parler.
notre compréhension d'un échange précis par mail, en prophylaxie contre n'importe quel potentiel piège
quand le même fournisseur d'électricité vous demande votre avis, mais la demande vient d'une entreprise en Belgique dont vous n'avez jamais entendu parler. Et il se trouve que votre fournisseur d'électricité paye effectivement un argent de fou pour ce service à la con.

Ça sert aussi à comprendre – tout simplement – ce qui se passe. L'exemple choisi pour les explications sur cette page ne contient aucun élément nocif. Mais tout ce qui paraît logique et normal après la lecture, peut être flou et/ou évidemment faux ( et faussé ) dans d'autres mails que vous recevez réellement !

PHAROS

PHAROS^[6] est le « Portail officiel de signalement des contenus illicites de l'Internet » du Ministre de l'Intérieur. PHAROS veut dire « Plateforme d’Harmonisation, d’Analyse, de Recoupement et d’Orientation des Signalements ». En théorie, vous pouvez y signaler des tentatives de Phishing, mais une vraie enquête de la part de la police nationale nécessite qu'il y avait déjà « préjudice » ( un dommage financier, notamment ). Si vous voulez juste signaler une campagne de mails frauduleux, cela peut contribuer aux procédures, mais comme les agents n'interviennent que ponctuellement, le résultat sera maigre.

En aucun cas les autorités publiques s'engageront à identifier des réseaux d'arnaqueurs et ne vont pas publier les noms d'entreprises dont il faut se méfier. Des punitions ne concerneront que la partie interlope de leur clientèle. ^[7]

Il reste à nous, les utilisateurs du système Mail, de les mettre à part. Une perte de la portée de leurs services payant est la meilleur sanction que nous pouvons leurs infliger, car ça leur fait perdre des clients, de l'argent, l'envie de soutenir les pratique des criminels.

La connaissance du système Mail est une condition essentielle, si nous voulons arrêter les abus.

Qu'est-ce qui peut se passer ?

L'analyse des entêtes Received ( et d'autres ), vous confronte à des situations très différentes de celle décrite plus haut. Vous pouvez attendre des surprises à chaque niveau de la transmission. En cas de fraudes, arnaques, chantages, “UCE” ( email commercial non-solicité ), Phishing etc. vous pouvez signaler le fait au département de gestion des abus du fournisseur, à qui appartient le serveur injectant le message. Dans ce signalement, ajoutez toujours le mail complet avec les entêtes authentiques.

L'adresse de l'expéditeur ( entête “From” ou « De » ) peut être fausse.: C'est à peu près la chose la plus simple à découvrir à l'aide des entêtes Received. Vous voulez comprendre pourquoi cette personne utilise une adresse fausse. Il faut en savoir plus pour pouvoir réagir.
L'adresse de l'expéditeur est la vôtre !: Bon. Au fond ce n'est pas autre chose qu'une adresse fausse. Si un arnaqueur se donne la peine de remplacer son adresse par la vôtre, il va en parler dans le texte du message..: « Je suis un hacker et ai piraté votre mail » ou similaire. Il n'a pas piraté votre ... boîte mail et il n'est probablement pas un hacker. Trouvez le service à l'origine du message et signalez le mail.
Les entêtes Received ne créent pas une suite cohérente.: Un ou plusieurs de ces entêtes sont faussés et étaient insérés par l'expéditeur ( ou par un truc à son service ). Regardez donc seulement les entêtes qui ont du sens; normalement vous identifiez ainsi facilement les entêtes faussés. Le derniers vont contenir des combinaisons de noms et d'adresses incohérentes et parfois carrément bizarres.
L'analyse des entêtes converge vers un résultat improbable ou vous n'en êtes pas sûr: Demandez d'abord au service que vous identifiez comme l'origine du mail. Présentez le mail, les entêtes et votre conclusion à des gens qui s'y connaissent ou demandez sur les plateformes d'échange dont se servent les adhérents d'Infini.
Une conclusion improbable ( mais pas impossible ) peut être Microsoft® comme service injectant un message frauduleux. C'est possible mais il faut encore une fois vérifier.

Ω

Références

↑ Received est un “Trace header” ( entête de trace ), comme décrit dans les RFC 2076, RFC 5322 et surtout RFC 5321
↑ Ping – man-page en français : http://www.delafond.org/traducmanfr/man/man8/ping.8.html
↑ Whois – manpage en français : https://manpages.debian.org/unstable/manpages-fr/whois.1.fr.html
↑ Exemple « ColoCrossing », choisi délibérément : https://bgp.he.net/search?search%5Bsearch%5D=ColoCrossing&commit=Search
↑ La liste de distribution des utilisateurs de GnuPG : https://gnupg.org/documentation/mailing-lists.html
↑ Portail PHAROS : http://www.internet-signalement.gouv.fr/
↑ une liste de « services compétents » est affichée dans le premier paragraphe de ce texte : https://www.cybermalveillance.gouv.fr/tous-nos-contenus/actualites/comment-signaler-un-mail-de-phishing

[1] Received est un “Trace header” ( entête de trace ), comme décrit dans les RFC 2076, RFC 5322 et surtout RFC 5321

[2] Ping – man-page en français : http://www.delafond.org/traducmanfr/man/man8/ping.8.html

[3] Whois – manpage en français : https://manpages.debian.org/unstable/manpages-fr/whois.1.fr.html

[4] Exemple « ColoCrossing », choisi délibérément : https://bgp.he.net/search?search%5Bsearch%5D=ColoCrossing&commit=Search

[5] La liste de distribution des utilisateurs de GnuPG : https://gnupg.org/documentation/mailing-lists.html

[6] Portail PHAROS : http://www.internet-signalement.gouv.fr/

[7] une liste de « services compétents » est affichée dans le premier paragraphe de ce texte : https://www.cybermalveillance.gouv.fr/tous-nos-contenus/actualites/comment-signaler-un-mail-de-phishing

[1]

[2]

[3]

[4]

[5]

[6]

[7]

Les entêtes « Received » d'un E-Mail

Sommaire