Tout ce qu'il faut savoir sur les en-têtes
d'emails
Comment lire et déchiffrer les en-têtes (headers) et codes sources des
emails et spams. L'adresse
électronique et les renseignements fournis par les polluposteurs ne disent pas
tout. La plupart des polluposteurs utilisent de fausses adresses électroniques
auxquelles ils apposent des noms de domaine tels que aol.com ou msn.com, mais
ils expédient leur pollupostage à partir de serveurs situés à Taiwan.Pour notre ami JO18 membre SoSWindows
.
Introduction
Ce document a pour objectif d'être une aide à la compréhension du mode de
fonctionnement des en-têtes d'emails. Il est, dans un premier temps, destiné
aux victimes d'emails non-sollicités (spam) désireuses d'en déterminer la
provenance réelle (généralement falsifiée). Il devrait également aider ceux
qui essayent de comprendre les autres types de falsification d'en-têtes d'email.
Il devrait enfin être utile aux lecteurs intéressés par une introduction générale
aux transferts de mails par Internet.
Bien que ce document évite volontairement de donner des informations trop précises
sur les diverses façons de trafiquer un email, les éléments qu'il contient
peuvent être détournés à cette fin par toute personne suffisamment déterminée.
L'auteur n'approuve formellement aucune falsification malveillante d'email, et
toute utilisation à cette fin des informations contenues dans ce document est
contraire à ses objectifs.
A cause de la nature des exemples donnés dans ce document, plusieurs noms de
domaines fictifs sont associés à des adresses IP (Internet Protocol). Les
risques que ces noms de domaines soient un jour attribués sont fatalement non
nuls. De même, si toutes les adresses IP utilisées dans les exemples sont
libres à l'heure où ces lignes sont écrites, elles seront sans aucun doute
attribuées un jour ou l'autre. Naturellement, rien dans ce document, n'est fait
dans le but de présumer de l'identité des futurs utilisateurs de ces noms de
domaines ou d'adresses IP.
D'où viennent les emails
Cette section consiste en une brève analyse de la vie d'un email. Ce survol
global est important pour comprendre ce que les en-têtes vous révèlent.
Au premier regard, il apparaît que l'email est passé directement de la machine
de l'expéditeur à celle du destinataire. En principe, ce n'est pas vrai : un
email classique passe au moins par quatre ordinateurs pendant son parcours. Cela
parce que la plupart des sociétés ont dédié un ordinateur appelé
"serveur de mails" spécialement pour la gestion du courrier électronique;
en temps normal, ce n'est pas le même ordinateur que les utilisateurs
consultent quand ils lisent leur courrier.
Dans la plupart des cas, où un fournisseur d'accès (ISP) a des clients qui se
connectent par leur ordinateur familial, l'ordinateur client est celui de
l'utilisateur, et le serveur est un ordinateur appartenant au fournisseur d'accès.
Quand un utilisateur envoie un courrier, il rédige son message de son propre
ordinateur, puis l'envoie au serveur de mail de son ISP. A cette étape,
l'ordinateur de l'expéditeur a fini son travail, mais le serveur de mail doit
continuer à acheminer le message. Il s'appuie alors sur un second serveur de
mails et ainsi de suite jusqu'à ce que le destinataire soit en mesure de
rapatrier le message sur son ordinateur, en l'effaçant, normalement, du serveur
de mail.
Illustration
Imaginons une paire d'utilisateurs fictifs,
et
. tmh est client de Immense ISP, Inc., utilisant un logiciel de mail appelé
Loris Mail (qui est par conséquent, également fictif); rth est membre du corps
enseignant du Bieberdorf Institute, disposant d'un ordinateur de bureau connecté
avec les autres ordinateurs de l'Institut.
Si rth veux envoyer une lettre à tmh, il la rédige de son ordinateur de bureau
(qui s'appelle, disons, alpha.bieberdorf.edu); le texte composé part donc de là
pour arriver au serveur de mail, mail.bieberdorf.edu. (A cet instant, aucune
intervention de rth n'est plus nécessaire, les étapes suivantes du processus
étant gérées directement par les machines). Le serveur de mail, voyant qu'il
y a un message pour quelqu'un à immense-isp.com, contacte le serveur de mail du
destinataire --appelé, disons mailhost.immense-isp.com--- et lui délivre le
message. Maintenant, celui-ci est stocké sur mailhost.immense-isp.com jusqu'à
ce que tmh se connecte de son ordinateur familial et vérifie sa boîte aux
lettres. A cet instant, le serveur de mail lui délivre tous les messages en
attente, dont la lettre de rth.
Illustration
Pendant toutes ces étapes, les en-têtes sont ajoutés au message trois fois :
pendant la rédaction du message, quelque soit le logiciel de mail utilisé,
quand le logiciel délègue le contrôle des opérations à mail.bieberdorf.edu;
et pendant le transfert du message de mail.bieberdorf.edu vers Immense.
(Normalement, la communication qui rapatrie le message ne rajoute pas d'en-têtes).
Observons comment évoluent ces en-têtes.
Généré par le logiciel de mail de rth et délivré à mail.bieberdorf.edu:
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
X-Mailer: Loris v2.32
Subject: Lunch today?
Son état quand mail.bieberdorf.edu remet le message à
mailhost.immense-isp.com :
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by
mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id:
X-Mailer: Loris v2.32
Subject: Lunch today?
Son état quand mailhost.immense-isp.com achève de traiter le message et le
stocke pour que tmh puisse le rapatrier :
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by
mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18
Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by
mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id:
X-Mailer: Loris v2.32
Subject: Lunch today?
Ce dernier ensemble d'en-têtes est celui que tmh voit dans la lettre quand
il télécharge et lit son courrier. Voici une analyse ligne par ligne de ces
en-têtes ainsi que le décryptage de chacun d'entre-eux.
Received: from mail.bieberdorf.edu
Cet email a été reçu d'un ordinateur qui s'appelle mail.bieberdorf.edu...
(mail.bieberdorf.edu [124.211.3.78])
... qui s'appelle vraiment mail.bieberdorf.edu (il s'identifie
correctement----voir la section correspondante pour plus de détails) et a pour
adresse IP 124.211.3.78.
by mailhost.immense-isp.com (8.8.5/8.7.2)
L'ordinateur qui a assuré la réception du mail était
mailhost.immense-isp.com; Il utilise un logiciel de mail appelé sendmail,
version 8.8.5/8.7.2 (ne vous inquiétez pas pour la signification des numéros
de version)
with ESMTP id LAA20869
L'ordinateur de réception a attribué au message le numéro ID LAA20869 (ce
numéro est utilisé en interne par l'ordinateur--- parfois par un
administrateur voulant reconnaître un message dans les archives de
l'ordinateur, mais cela n'a pas beaucoup de signification pour la plupart des
gens)
for
;
Le message est adressé à tmh@immense-isp.com. Remarquez que cet en-tête
n'a pas de rapport avec la ligne To: (section correspondante.)
Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Ce transfert de mail a eu lieu le Mardi 18 Mars 1997 à 14h39'24 (2h39mn24
de l'après-midi) en temps PST, qui compte 8 heures de moins que le temps GMT;
d'où le "-0800")
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by
mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
Cette ligne renseigne sur la remise du mail par alpha.bieberdorf.edu
(l'ordinateur de bureau de rth) à mail.bieberdorf.edu; Cette remise a eu lieu
à 14h36mn17 temps PST. L'ordinateur expéditeur s'appelle lui-même
alpha.bieberdorf.edu; il s'appelle réellement alpha.bieberdorf.edu, et son
adresse IP est 124.211.3.11. Le serveur de mail de Bieberdorf utilise sendmail
version 8.8.5, et il a attribué à ce message le numéro ID 004A21 pour le
traitement interne.
From: rth@bieberdorf.edu (R.T. Hood)
Le message fut envoyé par rth@bieberdorf.edu, qui a décliné sa véritable
identité (R.T. Hood)
To: tmh@immense-isp.com
La lettre est adressée à tmh@immense-isp.com.
Date: Tue, Mar 18 1997 14:36:14 PST
Le message a été rédigé à 14h36mn14 (temps PST) le Mardi 18 Mars 1997
Message-Id:
Ce message s'est vu attribué ce numéro (par mail.bieberdorf.edu) à des
fins d'identification. Cet ID est différent des numéros ID du SMTP et ESMTP de
la ligne Received : de l'en-tête parce qu'il est définitivement relié à ce
message. Les autres numéros ID sont uniquement associés à des échanges
particuliers entre des machines spécifiques, de sorte que le numéro ID d'un
ordinateur n'ait aucune signification précise pour une autre machine.
Quelquefois (comme dans cet exemple l'ID du message contient l'adresse email de
l'expéditeur; mais dans la plupart des cas, il n'a pas de réelle signification
par lui-même).
X-Mailer: Loris v2.32
Le message a été envoyé par un logiciel appelé Loris, version 2.32.
Subject: Lunch today?
Ligne explicite par elle-même
Protocoles de Mails
Cette section est un peu plus technique que les autres, et met l'accent sur les
détails concernant la faculté d'un mail de se transporter d'un point à un
autre. Vous n'êtes pas obligés de comprendre chaque mot, mais une certaine
habitude de ces notions peuvent grandement aider à comprendre ce qui se passe
dans certaines situations douteuses. Puisque certains messages de spammeurs créent
souvent et intentionnellement de telles situations (en partie pour tromper leurs
victimes), la capacité d'en comprendre les fondements peut-être assez utile.
Pour communiquer sur un réseau, les ordinateurs utilisent souvent des
"portes d'entrée" appelées ports; vous pouvez imaginer un port comme
un canal à travers duquel un ordinateur peut écouter les communications émanant
du réseau. Pour écouter plusieurs communications en même temps, un ordinateur
a besoin de plusieurs ports; pour les distinguer, ils sont généralement numérotés.
Pour les systèmes connectés à l'Internet, (ou tout autre système utilisant
le même protocole pour les emails), le port 25 revêt une importance particulière
pour le sujet qui nous occupe; c'est ce port qui est utilisé pour transmettre
et recevoir du courrier.
Situation normale
Retournons à l'exemple de la dernière section, en particulier au moment où
mail.bieberdorf.edu communique avec mailhost.immense-isp.com. Ce qui se passe en
fait, c'est que mail.bieberdorf.edu ouvre une connexion vers le port 25 de
mailhost.immense-isp.com, et envoie le message à travers cette connexion,
accompagné de quelques informations administratives. Pour ce faire, les
commandes utilisées et les réponses générées en retour par le système
destinataire sont plus ou moins compréhensible par l'Homme. Ce sont des
commandes émises dans un langage rudimentaire appelé SMTP, (pour Simple Mail
Transfer Protocol). Un espion éventuel écoutant les échanges entre les
machines verrait quelque chose comme la transcription suivante (les commandes émises
par mail.bieberdorf.edu sont en caractères gras) :
220 mailhost.immense-isp.com ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18
1997 14:38:58 -0800 (PST)
HELO mail.bieberdorf.edu
250 mailhost.immense-isp.com Hello mail.bieberdorf.edu [124.211.3.78], pleased
to meet you
MAIL FROM: rth@bieberdorf.edu
250 rth@bieberdorf.edu... Sender ok
RCPT TO: tmh@immense-isp.com
250 tmh@immense-isp.com... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11])
by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800
(PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id:
X-Mailer: Loris v2.32
Subject: Lunch today?
Do you have time to meet for lunch?
--rth
.
250 LAA20869 Message accepted for delivery
QUIT
221 mailhost.immense-isp.com closing connection
Cet échange complet dépend de cinq commandes qui constituent le cœur du SMTP
(il en existe quelques autres, mais ils sont en marge du processus réel engagé
pendant le passage du mail d'un point à l'autre de l'Internet) : HELO, MAIL
FROM, RCPT TO, DATA, et QUIT.
HELO identifie la machine expéditrice; "HELO mail.bieberdorf.edu"
doit être interprété comme " Bonjour, je suis mail.bieberdorf.edu".
L'expéditeur peut mentir; rien, en principe, ne peut empêcher
mail.bieberdorf.edu de dire "Bonjour, je suis frobozz.xyzzy.gov" (HELO
frobozz.xyzzy.gov) , ou même "Bonjour, je suis un ordinateur mal réglé"
(HELO un ordinateur mal réglé). Cependant, dans la plupart des cas, le
destinataire dispose d'outils pour s'en apercevoir et découvrir l'identité réelle
de l'ordinateur expéditeur.
MAIL FROM amorce le processus d'expédition; il signifie "J'ai un
courrier à délivrer de la part d'untel à untel". L'adresse mentionnée
apparaît apparaît à la ligne 'envelope from" (voir plus bas); elle n'est
pas forcément la même que la propre adresse de l'expéditeur ! Cet apparent
trou de sécurité est inévitable (après tout, l'ordinateur destinataire ne
sait rien sur qui utilise quel nom d'utilisateur sur la machine expéditrice),
et dans certaines conditions, cela se révèle être une fonction utile.
RCPT TO est la copie de MAIL FROM; elle précise le destinataire
du mail. Un email peut être envoyé à des destinataires multiples simplement
en incluant de multiples commandes RCPT TO (voir la section sur les
relais de mails, qui explique comment cette fonction peut-être abusée sur des
systèmes non sécurisés. L'adresse mentionnée se retrouve à la ligne "envelope
To" (voir plus bas); elle détermine réellement à qui le mail doit être
délivré, indépendamment de ce qui est inscrit à la ligne To: du message.
DATA démarre la réelle rédaction du mail. Tout ce qui est entré après
une commande DATA est considéré comme faisant partie du message. Il n'y a
aucune restriction quant à sa forme. Les lignes au début du message (avant la
première ligne blanche) qui démarrent par un simple mot et le
signe":" sont considérées comme en-têtes par la plupart des
logiciels de mail. Une ligne constituée seulement d'un point termine le
message.
QUIT coupe la connexion.
SMTP est entièrement décrit dans RFC 821. Des copies de RFC sont largement
distribuées sur le Web. Ce document vaut la peine d'être lu car il fait la
lumière sur la complexité du processus de traitement d'emails
Situations non courantes
Le scénario ci-dessus est quelque peu simplifié. On présume souvent que les
serveurs de mails de deux compagnies offrent un libre accès de l'un à l'autre.
Ceci était pratiquement toujours vrai dans les premiers temps de l'internet, et
c'est encore quelque fois le cas aujourd'hui , mais comme la sécurité est
devenue une préoccupation majeure, et que les compagnies et réseaux ont
grossi, faisant appel à plusieurs serveurs de mail distincts, cette situation
est de plus en plus inhabituelle.
Pare-feu (Firewall)
Beaucoup, peut-être même la plupart des compagnies ayant des ordinateurs sur
l'Internet sont protégées par une sorte de pare-feu. Un pare-feu est
simplement un ordinateur dont la tâche première est d'agir comme un gardien de
porte entre les ordinateurs d'une compagnie et le monde sauvage de l'Internet
(ainsi par exemple, des pirates ne peuvent facilement se connecter sur une
quelconque partie du réseau interne d'IBM pour y dérober des informations
confidentielles). Dans le cas d'un ordinateur essayant de délivrer un message
à un système situé derrière un pare-feu, cela signifie qu'on ne peut accéder
directement à ce système; il faut dialoguer avec le pare-feu.
Pas de surprises à ce stade; cela se présente juste comme un autre
"saut" dans le voyage d'un email, avec un pare-feu agissant comme tout
autre ordinateur transmettant le courrier. L'exemple ci-dessus peut-être modifié
pour ressembler à ceci:
Illustration
Si immense-isp.com a un pare-feu actif, voici à quoi ressembleront les en-têtes
de notre email. Observez la première ligne "Received: ". (Je vais
dire que l'ordinateur pare-feu s'appelle firewall.immense-isp.com; dans les
faits, donner un tel nom à un ordinateur équivaut à inciter tous les
apprentis hackers boutonneux de la planète à essayer de le forcer, aussi les
pare-feu sont ils généralement dotés de noms parfaitement neutres.)
Received: from firewall.immense-isp.com (firewall.immense-isp.com
[121.214.13.129]) by mailhost.immense-isp.com
(8.8.5/8.7.2) with ESMTP id LAA20869 for
; Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by
firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id LAA20869 for ; Tue, 18
Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by
mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id:
X-Mailer: Loris v2.32
Subject: Lunch today?
De façon similaire, si tout le courrier sortant de bieberdorf.edu était
routé à travers un pare-feu, il y aurait une autre ligne "Received:"
insérée par l'ordinateur pare-feu. De même, il est possible que soient
impliqués des ordinateurs qui ne sont pas strictement des pare-feu, mais
simplement des points de passage communs---peut-être immense-isp.com entretient
il un parc d'ordinateurs disséminés en plusieurs endroits géographiques différents,
avec plusieurs serveurs de mails distincts, et utilise une machine unique (appelée,
disons, mailgate.immense-isp.com) pour déterminer vers quel serveur de mails le
courrier doit être dirigé. Ainsi le groupe d'en-têtes suivant est un peu extrême
mais pas impossible:
Received: from mailgate.immense-isp.com (mailgate.immense-isp.com
[121.214.11.102]) by mailhost3.immense-isp.com (8.8.5/8.7.2) with ESMTP id
LAA30141 for
; Tue, 18 Mar 1997 14:41:08 -0800 (PST)
Received: from firewall.immense-isp.com (firewall.immense-isp.com
[121.214.13.129]) by mailgate.immense-isp.com (8.8.5/8.7.2) with ESMTP id
LAA20869 for
; Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from firewall.bieberdorf.edu (firewall.bieberdorf.edu
[124.211.4.13]) by firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id
LAA28874 for
; Tue, 18 Mar 1997 14:39:34 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by
firewall.bieberdorf.edu (8.8.5) with ESMTP id LAA61271; Tue, 18 Mar 1997
14:39:08 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by
mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id:
X-Mailer: Loris v2.32
Subject: Lunch today?
L'histoire de l'email peut-être retracée en lisant l'en-tête Received: de
bas en haut; ce message est parti de alpha.bieberdorf.edu vers
mail.bieberdorf.edu, vers firewall.bieberdorf.edu vers firewall.immense-isp.com
vers mailgate.immense-isp.com vers mailhost3.immense-isp.com, où il attend d'être
récupéré par tmh pour être lu.
Les relais
Voici de possibles en-têtes d'email ayant un "cycle de vie" très
différent que tout ce qui a été décrit jusqu'ici
Received: from unwilling.intermediary.com (unwilling.intermediary.com
[98.134.11.32]) by mail.bieberdorf.edu (8.8.5) id 004B32 for
; Wed, Jul 30 1997 16:39:50 -0800 (PST)
Received: from turmeric.com ([104.128.23.115]) by unwilling.intermediary.com
(8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 1997 19:36:28 -0500 (EST)
From: Anonymous Spammer
To: (recipient list suppressed)
Message-Id:
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???
De nombreux détails, dans cet en-tête, devraient indiquer au lecteur que
cet email est un spam, mais les éléments qu'il faut garder à l'esprit sont
les lignes "Received:" Ce message, provenant de turmeric.com, a été
dirigé vers unwilling.intermediary.com, puis vers sa destination finale, à
mail.bieberdorf.edu. D'accord, mais que vient faire là
unwilling.intermediary.com, puisqu'il n'a de rapport ni avec l'expéditeur ni
avec le destinataire ?
Comprendre la réponse requiert quelques notions de SMTP. En substance,
turmeric.com s'est simplement connecté au port SMTP de
unwilling.intermediary.com en lui disant "Envoie ce message à rth@bieberdorf.edu".
Cela s'est probablement opéré de la plus directe façon qui soit, en invoquant
la commande RCPT TO: rth@bieberdorf.edu. A cette étape,
unwilling.intermediary.com a pris en charge le traitement du message; comme il
lui a été demandé d'acheminer ce courrier vers un utilisateur d'un autre
domaine (bieberdorf.edu), il a trouvé le serveur de mails de cet autre domaine
et délivré son message comme d'habitude. Ce processus est appelé relais de
mail.
Historiquement, il existe de bonnes raisons d'autoriser les relais; sur la plus
grande partie du net, vers la fin des années 80, les ordinateurs envoyaient
rarement du courrier en communiquant directement entre eux. Ils traçaient plutôt
un chemin que le message devait emprunter et celui-ci était expédié étape
par étape tout au long de ce chemin. C'était un système assez peu pratique
(particulièrement parce que l'expéditeur devait souvent tracer le chemin
manuellement). Par analogie, imaginez une lettre partant de San Francisco vers
New York, avec une enveloppe libellée ainsi:
San Francisco, Sacramento, Reno, Salt Lake City, Rock Springs, Laramie,
North Platte, Lincoln, Omaha, Des Moines, Cedar Rapids, Dubuque, Rockford,
Chicago, Gary, Elkhart, Fort Wayne, Toledo, Cleveland, Erie, Elmira,
Williamsport, Newark, New York City, Greenwich Village, #12 Desolation Row,
Apt. #35, R.A. Zimmermann
Cela montre pourquoi ce modèle d'adressage est très utile si vous êtes
employé des Postes --le bureau de Gary, Indiana, doit seulement être capable
de communiquer avec les bureaux voisins de Chicago et Elkhart, plutôt que de
consacrer ses ressources à acheminer quelque chose vers New York. (Cela montre
aussi pourquoi ce n'est pas une bonne idée du point de vue du rédacteur de la
lettre, et pourquoi les emails ne sont plus désormais acheminés de la sorte!)
C'est exactement de cette façon que les emails étaient envoyés; aussi était-il
important qu'un ordinateur soit à même de donner à un autre des instructions
telles que "J'ai un courrier pour rth@bieberdorf.edu, qui doit être envoyé
par toi vers turmeric.com vers galangal.org vers asafoetida.com vers
bieberdorf.edu". D'où l'intérêt du relais.
De nos jours, toutefois, les relais sont couramment utilisés par des
publicitaires sans éthique comme une technique pour dissimuler la source de
leurs messages, en détournant les plaintes vers un site relais innocent, au
lieu de leur propre fournisseur d'accès. (Cela décharge aussi de l'ordinateur
des spammeurs vers ceux d'une tierce-partie innocente, le travail de traitement
d'adresses et de contact des destinataires; pour cette raison, il est largement
souligné que l'utilisation des es relais, particulièrement à grande échelle,
constituent un détournement de ressources.) L'essentiel ici est de réaliser
que le contenu d'un message a été formulé à son point de départ--turmeric.com
dans l'exemple ci-dessus; le lien intermédiaire, unwilling.intermediary.com,
est impliqué en tant qu'intermédiaire non volontaire. Il n'a pas de contrôle
sur l'expéditeur, pas plus que le bureau de poste de Gary n'a d'influence véritable
sur quelqu'un écrivant des lettres à San Francisco. (Il leur reste toutefois
la possibilité de désactiver les relais sur leurs sites!)
Un autre détail à noter dans l'en-tête: la ligne Message-Id: a été remplie,
non par la machine expéditrice (turmeric.com), mais par le serveur relais (unwilling.intermediary.com).
C'est une caractéristique commune des mails ayant transité par des serveurs
relais; il renseigne juste sur le fait que la machine expéditrice n'a pas
fourni de Message-Id.
En-tête d'enveloppe
Cette section sur le SMTP, au dessus, faisait allusion à une distinction entre
les en-têtes d"'enveloppe" et les en-têtes de "message".
Cette distinction et certaines de ces conséquences sont détaillées ici.
Brièvement, les en-têtes d"'enveloppe" sont en réalité générés
par la machine qui reçoit un message, plutôt que par celle qui l'envoie. Par
cette définition les en-têtes de la ligne Received: sont des en-têtes
d'enveloppes; toutefois, il y est habituellement fait référence en termes de
"envelope From" et "envelope To" uniquement.
L'en-tête envelope From est un en-tête dérivé de l'information de la
commande MAIL FROM. Par exemple, si une machine expéditrice dit MAIL FROM:
ginger@turmeric.com, l'ordinateur destinataire va générer un en-tête
enveloppe From qui ressemble à ça :
>From ginger@turmeric.com
Noter l'absence du signe ":".---On a "From" et non
"From:". Souvent, les en-têtes d'enveloppe ne sont pas suivis du
signe ":"; cette convention n'est pas universelle, mais s'en souvenir
peut se révéler judicieux.
Symétriquement, l'envelope To est dérivé d'une commande RCPT TO. Si l'expéditeur
dit RCPT TO: tmh@bieberdorf.edu, alors l'envelope To est tmh@bieberdorf.edu. Il
n'y a souvent pas de véritable en-tête contenant cette information; elle est
parfois incrustée dans l'en-tête Received:
Une conséquence importante de l'existence d'informations sur l'enveloppe se
situe dans le fait que les en-tête message From: et message To: sont sans
signification. Le contenu d'un en-tête From: est fourni par l'expéditeur,
c'est également le cas, contrairement à ce que l'on pourrait croire, des en-têtes
To:. Le routage du courrier se base uniquement sur les informations de
l'en-tête envelope To, jamais sur celles de l'en-tête message To:.
Pour en avoir une illustration, considérons un échange SMTP comme celui-ci:
HELO galangal.org
250 mail.bieberdorf.edu Hello turmeric.com [104.128.23.115], pleased to meet
you
MAIL FROM: forged-address@galangal.org
250 forged-address@galangal.org... Sender ok
RCPT TO: tmh@bieberdorf.edu
250 tmh@bieberdorf.edu... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
.
250 OAA08757 Message accepted for delivery
Voici les en-têtes correspondants (extraits pour plus de clarté):
>From forged-address@galangal.org
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)
for
...
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance
Remarquez que le contenu de l'envelope From, le message from:, et le message
to: sont tous spécifiés par l'expéditeur, et l'exactitude de ces informations
n'est pas garantie! Cet exemple illustre pourquoi les en-têtes From, From: et
To: ne doivent jamais inspirer confiance dans un mail qui peut avoir été
trafiqué; c'est simplement trop facile à falsifier.
De l'importance des en-têtes Received
Nous avons déjà vu dans les exemples précédents que les en-têtes Received:
fournissent un fichier détaillé retraçant l'historique du message, rendant
possible de tirer quelques conclusions sur l'origine d'un email même si les
autres en-têtes ont été falsifiés. Cette section explore les détails
relatifs à ces importants en-têtes, et en particulier, les moyens de détourner
les techniques courantes de falsification.
Incontestablement, la plus fiable protection contre les falsifications dans
l'en-tête Received: est l'information venant de l'expéditeur, enregistrée par
l'hôte destinataire. Rappelez vous que l'expéditeur peut mentir sur son
identité (en mettant la pagaille dans sa commande HELO vers le destinataire);
heureusement, les logiciels de mails actuels sont capables de détecter de
telles falsification et de les corriger.
Si, par exemple, l'ordinateur turmeric.com dont l'adresse IP est 104.128.23.115,
envoie un message à mail.bieberdorf.edu, et ment en disant HELO galangal.org,
la ligne Received: en résultant pourrait commencer comme ceci:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu
(8.8.5)...
(Le reste de la ligne est omis pour plus de clarté). Remarquez que, même
si l'ordinateur bieberdorf.edu n'annonce pas de façon explicite que
galangal.org n'est pas le véritable expéditeur de ce message, il enregistre
quand même la vraie adresse IP de l'expéditeur. Si une personne recevant ce
mail avait des raisons de penser que galangal.org apparait dans l'en-tête à
l'issue d'une manipulation, elle pourrait regarder du coté de l'adresse IP
104.128.23.115 (avec un utilitaire comme le programme UNIX nslookup) et voir que
cette adresse appartient en fait à turmeric.com (et non galangal.org). En
d'autres termes, enregistrer l'adresse IP de la machine expéditrice fournit
assez d'information pour confirmer une suspicion de falsification.
Plusieurs logiciels de courrier électronique peuvent automatiser ce processus,
en cherchant d'eux-même le nom de la machine expéditrice. (Ce processus de
recherche s'appelle reverse DNS (Domain Name Service)---"reverse"
parce qu'il inverse le processus habituel de conversion d'un nom vers une
adresse à des fins d'acheminement.) Si mail.bieberdorf.edu utilisait un
logiciel de mail capable de faire cela, la ligne Received commencerait par
quelque chose comme ceci:
Received: from galangal.org (turmeric.com [104.128.23.115]) by
mail.bieberdorf.edu...
Ici, la supercherie est claire comme du cristal; cette ligne dit
effectivement "turmeric.com dont l'adresse 104.128.23.115 reporte le nom
galangal.org". Inutile de dire qu'une information telle que celle-ci est
extrêmement utile pour identifier et traquer les emails falsifiés! (Pour cette
raison, les spammeurs essaient d'éviter d'utiliser des serveurs relais qui
reportent les informations d'inversion DNS. Quelquefois ils trouvent même des
ordinateurs qui n'assurent pas l'enregistrement des IP décrit dans le
paragraphe précédent--- même si on n'en trouve plus beaucoup sur le réseau désormais.)
Une autre astuce utilisée par les falsificateurs d'email, de plus en plus fréquemment,
est d'ajouter de faux en-têtes Received: avant d'envoyer le courrier incriminé.
Cela signifie que l'hypothétique email parti de turmeric.com pourrait contenir
une ligne Received: qui ressemblerait à celle-ci:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu
(8.8.5)...
Received: from nowhere by fictitious-site (8.8.3/8.7.2)...
Received: No Information Here, Go Away!
Évidemment, les deux dernières lignes n'ont aucun sens, écrites par l'expéditeur
et jointes au message avant son envoi.
Comme l'expéditeur n'a plus de contrôle sur le message une fois que celui-ci
quitte turmeric.com, et que les en-têtes Received: sont toujours ajoutés au début,
les lignes trafiquées apparaissent à la fin de la liste. Cela signifie que
quelqu'un lisant ces lignes de haut en bas, en retraçant l'historique du
message, peut sans risque rejeter tout ce qui se trouve après la première
ligne falsifiée; même si la ligne Received: qui suit semble plausible, elle
est forcément falsifiée.
Bien sûr, l'expéditeur n'est pas obligé d'utiliser des méthodes si
facilement repérables; un falsificateur vraiment sournois pourrait créer une
liste plausible de lignes Received: comme celle-ci :
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu
(8.8.5)...
Received: from lemongrass.org by galangal.org (8.7.3/8.5.1)...
Received: from graprao.com by lemongrass.org (8.6.4)...
Ici, la seule difficulté se trouve dans l'inexacte adresse IP pour
galangal.org dans la toute première ligne Received: . La manipulation aurait été
encore plus difficile à détecter si le falsificateur avait écrit la bonne
adresse IP pour lemongrass.org et graprao.com, mais le fait que l'IP ne soit pas
corrélée dans la première ligne révélerait quand même que le message a été
trafiqué, et "injecté" à travers le réseau par le site
104.128.23.115 (c'est à dire turmeric.com). Cependant, la plupart des
falsification d'en-têtes sont considérablement moins sophistiquées et les
lignes Received: supplémentaires ajoutées à des fins malveillantes sont
facilement repérables.
Liste d'en-têtes courants
Apparently-To: Les messages à destinataires multiples contiennent
quelquefois une longue liste d'en-tête au format "Apparently-To:rth@bieberdorf.edu"
(une ligne par destinataire). Ces en-têtes ne sont pas courants dans les
courriers légitimes; ils sont généralement l'apanage des mailing-lists, et
aujourd'hui, les mailing-lists utilisent généralement des logiciels assez
sophistiqués pour ne pas produire une pile énorme d'en-têtes.
Bcc : (Blind Carbon Copy). Si vous voyez cet en-tête dans un courrier
entrant, c'est que quelque chose ne va pas. Il est utilisé comme Cc: (voir
plus bas), mais n'apparaît pas dans les en-têtes. L'idée est de pouvoir
envoyer des copies d'email à des personnes qui ne désirent pas recevoir des
réponses, ou apparaître dans les en-têtes. Les Blind Carbon Copy sont appréciés
des spammeurs, pour leurs capacités à embrouiller les utilisateurs inexpérimentés
qui finissent par recevoir du courrier qui ne leur était apparemment pas
destiné;
Cc: (Carbon Copy, très significatif si vous vous souvenez des machines
à écrire). Cet en-tête est une sorte d'extension de "To:"; il précise
les destinataires additionnels. La différence entre "To:" et
"Cc:" dépend essentiellement du contexte; quelques logiciels de
mails les gèrent aussi différemment en traitant les réponses.
Comments: C'est un champ d'en-tête non standard. Il est plus
couramment rencontré sous la forme "Comments : l'expéditeur authentique
est
". Un en-tête de ce type est ajouté par certains logiciels de mails
(notamment le populaire programme freeware Pegasus) pour identifier l'expéditeur;
cependant, il est souvent ajouté manuellement (avec de fausses informations)
par les spammeurs. A considérer avec précaution, donc.
Content-Transfer-Encoding: Cet en-tête concerne MIME, un moyen usuel
de joindre un contenu non textuel dans un email. Il n'a pas de rapport direct
avec la délivrance du courrier, mais il influence la façon dont les
logiciels de mails compatibles interprètent le contenu du message.
Content-Type: Un autre type d'en-tête, qui renseigne les logiciels de
mails compatibles sur le type de contenu du message.
Date: Cet en-tête fait exactement ce que l'on suppose: Il précise la
date, normalement la date de rédaction et d'émission du message. Si cet en-tête
est omis par l'ordinateur de l'expéditeur, il devrait probablement être
ajouté par le serveur de mails ou même par un autre ordinateur durant le
parcours. Il ne devrait pas pour autant être pris pour parole d'évangile;
falsification mise à part, un nombre affolant d'ordinateurs, de par le monde,
ont leur horloge mal réglée.
Errors-To: Spécifie l'adresse où doivent être dirigés les rapports
d'erreurs du logiciel de mail, tel les messages d'échec du style
"utilisateur inexistant", (au lieu de l'adresse de l'expéditeur).
Ce n'est pas un en-tête courant dans la mesure l'expéditeur désire généralement
recevoir les rapports d'erreurs à l'adresse d'expédition, ce que la plupart
(pratiquement tous) des logiciels de serveurs de mail font par défaut.
From (sans le signe ":"). C'est l"envelope From" décrit
plus haut.
From: (avec le signe ":") C'est l"envelope From:" décrit
plus haut.
Message-Id: (ou Message-id: ou Message-ID:). Le Message-Id est plus ou
moins l'unique identifiant assigné à chaque message, d'habitude par le
premier serveur de mail rencontré. Par convention, il est au format "gibberish@bieberdorf.edu",
ou la partie "gibberish" pourrait être absolument n'importe quoi,
et la seconde partie est le nom de l'ordinateur ayant assigné l'ID.
Quelquefois, mais pas souvent, la partie "gibberish" inclut le nom
d'utilisateur de l'expéditeur. Tout email dans lequel le message ID est mal
formé( ex: caractère absent ou pas de signe @) ou dans lequel le site du
message ID n'est pas le véritable site d'origine, est probablement une
falsification.
In-Reply-To: Un en-tête Usenet qui apparaît occasionnellement dans
les mails, l'en-tête In-Reply-To: indique le message ID des messages précédents
ayant suscité une réponse. Cet en-tête n'apparaît habituellement pas, sauf
dans certains emails directement reliés à Usenet; les spammeurs sont réputés
pour l'utilisation qu'ils en font, probablement dans le but d'échapper aux
programmes de filtrage.
Mime-Version: (ou MIME-Version:) Encore un autre en-tête MIME, celui-là
spécifiant juste la version du protocole MIME utilisée par l'expéditeur.
Comme l'autre en-tête MIME, celui-ci peut-être ignoré; la plupart des
logiciels de courrier électronique sauront ce qu'ils doivent en faire.
Newsgroups: Cet en-tête apparaît seulement dans les emails relatifs
à Usenet.--- Soit des copies d'email postés sur Usenet, ou des réponses à
ces emails. Dans le premier cas, il indique le groupe de discussions vers
lequel le message a été posté; dans le second cas, il indique le groupe de
discussion vers lequel la réponse fut dirigée. La syntaxe de ces en-têtes
sont l'objet d'une petite guerre sainte, qui fait que deux types de syntaxes
sont utilisés, sans discernement pour le futur proche.
Organization: Un en-tête au format libre qui contient le nom de la
compagnie qui fournit l'accès au net à l'expéditeur. Celui-ci peut généralement
y entrer ce qu'il veut.
Priority: Un en-tête essentiel au format libre qui attribue une
priorité au mail. La plupart des logiciels de mail l'ignorent. Il est souvent
utilisé par les spammeurs, d'habitude sous un format "Priority:
urgent" ( ou quelque chose d'approchant) dans l'espoir que leur message
sera bien lu.
Received: Vu dans les descriptions précédentes.
References: Les en-têtes References: sont rares dans les emails, sauf
dans les copies de courrier Usenet. Il est utilisé sur Usenet pour identifier
les courriers en amont pour lesquels un message est une réponse. Quand il
apparaît dans un email, c'est habituellement une copie d'un en-tête Usenet.
Il peut aussi apparaître dans un email en réponse à un message Usenet, afin
qu'il soit répondu au message ID de ce mail aussi bien qu'aux références
initiales du message.
Reply-To: Spécifie l'adresse où doivent être dirigées les réponses.
Bien que de nombreuses façons d'utiliser légitimement cet en-tête existent
(votre logiciel de mail fait peut-être passer à la trappe vos champs adress
From: et vous souhaitez répondre à l'adresse exacte), il est également
abondamment utilisé par les spammeurs pour dévier les plaintes.
Occasionnellement, un spammeur naïf va réellement solliciter des réponses
en utilisant un en-tête Reply-To: pour les collecter, mais le plus souvent
cet en-tête envoie vers un email invalide ou vers celui d'une victime
innocente.
Sender: Cet en-tête n'est pas courant dans un email (X-Sender est le
plus souvent utilisé), mais il apparaît parfois, surtout dans les copies de
messages Usenet. Il est censé identifier l'expéditeur; dans le cas de
messages Usenet, c'est un élément plus fiable que la ligne From:
Subject: Un en-tête au format complètement libre, spécifié par
l'expéditeur dans le but, bien sûr de décrire l'objet du message.
To: Le "message To:" décrit précédemment. Remarquez que
l'en-tête To: n'est pas obligé de contenir l'adresse du destinataire!
X- est le terme générique des en-têtes commençant avec un X
majuscule et un trait d'union. Par convention, les en-têtes X- ne sont pas
standards et s'affichent à titre indicatif seulement. Inversement tout en-tête
non standard fourni à titre indicatif devrait se voir doté d'un nom commençant
par "X-". Cette convention est très peu respectée.
X-Confirm-Reading-To: Cet en-tête demande une confirmation de réception
ou de lecture. Il est souvent ignoré, probablement perturbé par certains
logiciels.
X-Distribution: En réponse aux spammeurs utilisant son logiciel,
l'auteur de Pegasus Mail a ajouté cet en-tête. Tout message envoyé avec
Pegasus vers un nombre suffisamment important de destinataires, contient un
en-tête supplémentaire disant "X-Distribution: bulk". C'est assez
explicite pour inciter les destinataires à filtrer ce type de courrier.
X-Errors-To: Like Errors-To:, Cet en-tête spécifie une adresse vers
laquelle les erreurs doivent être envoyées. Il est probablement moins
souvent respecté.
X-Mailer: (ou X-mailer:). Un en-tête de format libre ayant pour
objectif que le logiciel de mail utilisé par l'expéditeur s'identifie de
lui-même (comme publicité ou autre). Comme de nombreux spams sont envoyés
par des logiciels créés dans ce but, ce champ peut se révéler être pour
les filtres un utile fournisseur de matière première.
X-PMFLAGS: C'est un en-tête ajouté par Pegasus Mail; sa syntaxe n'est
pas évidente. Il apparaît dans tous les messages envoyés avec Pegasus, et
ne délivre au destinataire aucune information qui ne soit pas déjà fournie
par l'en-tête X-Mailer: .
X-Priority: Un autre champ de priorité, utilisé notamment par Eudora
pour attribuer une priorité (qui apparaît sous forme de notation graphique
dans le message).
X-Sender: En tête courant, comparable à l'en-tête Sender: des
groupes de discussions Usenet, cet en-tête prétend identifier l'expéditeur
avec une plus grande fiabilité que l'en-tête From:. En fait, il est presque
aussi facile à falsifier, et devrait être considéré avec la même
circonspection.
X-UIDL: C'est un identifiant unique utilisé par le protocole POP pour
retrouver le courrier sur un serveur. Il est habituellement ajouté entre le
serveur de mails du destinataire et son logiciel de mail; si du courrier
arrive sur le serveur de mail avec un en-tête X-UIDL, c'est probablement un
spam (l'utilisation d'un tel en-tête est sans intérêt, mais pour des
raisons inconnues, de nombreux spammeurs en ajoutent un).
