This page is written in French, click on the flag to get the American text! 
|
Tout sur les en-têtes de messages
Introduction
Ce document est destiné à apporter une compréhension des en-têtes de messages. A la base, il est destiné à aider les victimes de messages non solicités ("spam") en tentant de déterminer la véritable source (généralement masquée) des e-mails qui les empoisonnent ; il devrait aussi aider à comprendre tout autre e-mail trafiqué. Il pourrait aussi être utile aux lecteurs intéressés par une introduction générale sur le transfert de courrier sur l'Internet.
Bien que ce document évite intentionnellement les propos "comment maquiller", des informations fournies pourraient être détournées dans ce but par quelqu'un de bien déterminé. L'auteur n'approuve en rien, bien sûr, la falsification des e-mails et tout tel usage de l'information fournie est contraire à son propos.
A cause de la nature des exemples de ce document, il y a plusieurs noms de domaines fictifs avec adresses IP associées (Internet Protocol). La chance qu'un de ces noms de domaines puisse, dans le futur, être utilisé n'est inévitablement pas nulle. De la même manière, toute adresse IP utilisée dans ces exemples est non identifiable à l'heure de ces écrits, mais elles seront sans doute affectées un jour.
Naturellement, rien dans ce document n'est destiné à illustrer en aucune manière, des noms de domaines ou des adresses IP futures.
D'où vient le message ?
Ce paragraphe est un simple examen de la vie d'un message.
Cette information de base est importante pour la compréhension de ce que les en-têtes de messages vous apprennent.
A première vue, il semble qu'un e-mail passe directement de la machine de l'expéditeur à celle du destinataire. Normalement, ce n'est pas vrai ; un e-mail type passe par au moins quatre ordinateurs dans sa durée de vie.
Il en est ainsi parce que la plupart des organisations ont une machine dédiée au traitement des messages, appelée "serveur mail" ; ce n'est, normalement, pas la même machine que les utilisateurs contactent quand ils prennent leur courrier. Dans le cas courant d'un fournisseur d'accès Internet auquel les utilisateurs se connectent de chez eux par modem, l'ordinateur "client" est la machine de l'utilisateur et le "serveur" est une machine qui appartient au FAI. Quand un utilisateur envoie un message, il compose normalement le message sur son propre ordinateur, puis l'expédie au le serveur mail du fournisseur. A ce stade, son ordinateur n'est plus concerné par le travail, mais le serveur de mail doit encore délivrer le message. Il le fait en trouvant le serveur du destinataire, en parlant à ce serveur et en délivrant le message. Tout se passe ensuite sur ce second serveur jusqu'à ce que le destinataire décide de lire son courrier en le récupérant sur son propre ordinateur, ce qui, normalemant, le supprime du serveur mail en même temps.
Illustration :
Considérons un couple d'utilisateurs fictifs, <rth@bieberdorf.edu> et
<tmh@immense-isp.com>. tmh est un utilisateur par modem de Immense ISP, Inc., employant un programme de messagerie appelé Loris Mail (lequel est, bien sûr, également fictif) ; rth est un membre du Bieberdorf Institute, avec une station sur son bureau qui est reliée en réseau à d'autres ordinateurs de l'Institut.
Si rth veut envoyer une lettre à tmh, il la compose sur sa station (appelée, disons, alpha.bieberdorf.edu) ; de là, le texte composé est passé au serveur de mails, mail.bieberdorf.edu. (c'est ce dernier que rth voit ; la suite du processus est prise en charge par les machines sans son intervention).
Le serveur mail, voyant qu'il a un message pour quelqu'un de immense-isp.com, contacte son serveur mail ---appelé, peut-être, mailhost.immense-isp.com--- et lui délivre le courrier. Maintenant, le message est stocké sur mailhost.immense-isp.com jusqu'à ce que tmh se connecte de son ordinateur à domicile et prenne son courrier ; à ce moment, le serveur mail lui délivre tout le courrier en attente, y compris la lettre de rth.
Illustration :
Durant cette procédure, des en-têtes vont être ajoutés au message en 3 occasions :
à la composition, quel que soit le programme de messagerie que rth utilise ; quand ce programme
passe le contrôle à mail.bieberdorf.edu et lors du transfert de Bieberdorf à Immense. (Normalement, l'ordinateur qui récupère le message n'ajoute aucun en-tête). Examinons l'évolution de ces en-têtes.
Généré par le mailer de rth et transmis à 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?
Tel qu'ils sont lorsque mail.bieberdorf.edu transmet 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:
<rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris
v2.32
Subject: Lunch today?
Tels qu'ils sont lorsque mailhost.immense-isp.com termine le traitement du message et
le met à la disposition de tmh :
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:
<rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris
v2.32
Subject: Lunch today?
Ce dernier exemplaire des en-têtes est celui que tmh voit sur la lettre quand il télécharge et lit son courrier. Voici une analyse ligne par ligne de ces en-têtes et ce que chacune signifie exactement.
Received: from mail.bieberdorf.edu
Ce message a été reçu par une machine se nommant elle-même mail.bieberdorf.edu...
(mail.bieberdorf.edu [124.211.3.78])
... qui s'appelle vraiment mail.bieberdorf.edu (c'est à dire qu'elle s'est identifiée correctement ---voir
le chapitre Néanmoins pour plus à ce sujet) et a l'adresse IP 124.211.3.78.
by mailhost.immense-isp.com (8.8.5/8.7.2)
La machine qui a reçu est mailhost.immense-isp.com ; elle utilise un programme de messagerie appelé sendmail, version 8.8.5/8.7.2 (ne vous souciez pas de ce que le numéro de version peut signifier à moins que vous le sachiez déjà).
with ESMTP id LAA20869
La machine qui a reçu a attribué le numéro d'identification LAA20869 au message. (utilisé de manière interne par la machine ---c'est une chose qu'un administrateur aurait besoin de savoir pour consulter le message dans le journal de la machine, mais çà n'a pas, d'habitude, de signification pour quelqu'un d'autre).
for <tmh@immense-isp.com>;
Le message a été adressé à tmh@immense-isp.com. Noter que cet en-tête n'est pas lié à la ligne To: (voir le chapitre Néanmoins).
Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Ce transfert de message a été effectué le mardi 18 mars 1997 à 14 heures 39:24 (2 heures 39:24 de l'après-midi) heure Pacifique (qui est à GMT moins 8 heures ; 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 informe sur le transfert de courrier de
alpha.bieberdorf.edu (la station de rth) à mail.bieberdorf.edu ; ce transfert a été effectué à 14 heures 36:17 Pacifique. La machine expéditrice s'est nommée alpha.bieberdorf.edu ; elle s'appelle réellement alpha.bieberdorf.edu, et son adresse IP est 124.211.3.11. Le serveur mail de Bieberdorf utilise la version 8.8.5 de sendmail, et a alloué le numéro d'identification 004A21 au courrier pour le traitement interne.
From: rth@bieberdorf.edu (R.T. Hood)
Le courrier a été envoyé par rth@bieberdorf.edu, qui donne son nom réel 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é composé le mardi 18 mars 1997 à 14 heures 36:14 Pacifique.
Message-Id:
<rth031897143614-00000298@mail.bieberdorf.edu>
Ce numéro a été donné au message (par mail.bieberdorf.edu) pour l'identifier. Cette identification est différente de celle de SMTP et de ESMTP dans l'en-tête Received: parce qu'il est attaché à ce message pour la vie ; les autres identifications sont seulement associées aux transactions spécifiques de ces machines spécifiques, si bien que le numéro d'identification d'une machine ne signifie rien pour une autre. Parfois (comme dans cet exemple) le numéro de message a l'adresse e-mail de l'expéditeur incluse ; plus souvent, il n'a aucun sens intelligible.
X-Mailer: Loris v2.32
Le message a été envoyé en utilisant un programme appelé Loris, version 2.32.
Subject: Lunch today?
Cà se comprend tout seul.
Protocoles de messagerie
Ce chapitre est un peu plus technique que les autres, et précise comment le courrier va d'un point à un autre. Vous n'avez pas besoin de comprendre chaque mot, mais la familiarisation avec ce sujet peut aider grandement à clarifier ce qu'il se passe dans des situations étranges. Comme les spammers créent souvent intentionnellement de telles situations étranges (en partie pour troubler leurs victimes), l'aptitude à comprendre ces situations peut être tout à fait utile.
Pour communiquer par le réseau, les ordinateurs utilisent souvent des "points d'entrée" appelés ports ; vous pouvez penser à un port comme à un canal à travers duquel un ordinateur peut écouter les communications en provenance du réseau. Pour écouter plusieurs communications en même temps, un ordinateur a besoin d'avoir de multiple ports ; pour les distinguer, ils sont generalement numérotés. Sur les systèmes connectés à l'Internet (ou tout autre système utilisant les mêmes protocoles pour le courrier), le port 25 est d'une importance particulière pour ces propos ; c'est le port qui est utilisé pour transmettre et recevoir le courrier.
Comportement normal
Revenons à l'exemple du chapitre précédent, et spécialement au point où mail.bieberdorf.edu communique avec mailhost.immense-isp.com. Ce qu'il se passe réellement là est que mail.bieberdorf.edu ouvre une connection vers le port 25 de mailhost.immense-isp.com, et envoie le courrier vers cette connexion, en même temps que des données techniques. Les commandes qu'il utilise pour çà, et les réponses émises par le system qui reçoit, sont plus ou moins lisibles par un humain ; ce sont des commandes dans un langage rudimentaire appelé SMTP, pour Simple Mail Transfer Protocol. Quelqu'un espionnant la "conversation" entre les
machines verrait quelque chose comme ce qui est tanscrit ci après (les commandes émises par mail.bieberdorf.edu sont en 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:
<rth031897143614-00000298@mail.bieberdorf.edu>
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
L'ensemble de la transaction dépend de cinq commandes qui constituent le coeur de SMTP (il y en a quelques autres, mais elles sont secondaires pour le processus réel d'envoi des messages d'un endroit à un autre) : HELO, MAIL FROM, RCPT TO, DATA, et QUIT.
HELO identifie la machine expéditrice ; "HELO mail.bieberdorf.edu"
doit être lu comme "Salut, je suis mail.bieberdorf.edu". L'expéditeur peut mentir ; rien,
en principe, n'empêche mail.bieberdorf.edu de dire "Salut, je suis frobozz.xyzzy.gov" (HELO frobozz.xyzzy.gov) ou même "Salut, je suis un ordinateur trafiqué" (HELO a misconfigured computer). Cependant, dans la plupart des circonstances, le destinataire a quelques outils pour découvrir ceci et déterminer l'identité réelle de la machine expéditrice.
MAIL FROM démarre le processus de messagerie ; çà signifie "J'ai du courrier à délivrer de un tel". L'adresse donnée est dans ce qui s'appelle l'"envelope From" (voir le chapitre Néanmoins) ; çà peut ne pas être la même que la propre adresse de l'expéditeur ! Ce trou de sécurité apparent est inévitable (après tout, la machine destinataire ne sait rien de qui a quel nom sur la machine expéditrice), et dans certaines circonstances, çà se révelle être une caractéristique utile.
RCPT TO est le pendant de MAIL FROM ; il spécifies le destinataire voulu du courrier. Un message peut être envoyé à des destinataires multiples simplement en incluant de multiples commandes RCPT TO (voir le chapitre sur les relais de messagerie, qui explique comment cette caractéristique est exploitée sur des systèmes non sécurisés). L'adresse donnée est dans ce qui est nommé l'"envelope To" (voir le chapitre Néanmoins) ; çà détermine réellement à qui le message sear délivré, indépendamment de ce que dit la ligne du message To:.
DATA démarre le vrai début du message. Tout ce qui est entré après une commande DATA
est considéré comme faisant partie du message ; il n'y a pas de restriction sur sa forme. Les lignes du début du message (avant la première ligne blanche) qui commencent par un mot seul and un "deux-points" sont considérés comme des en-têtes par la plupart des programmes de messagerie. Une ligne comportant seulement un point termine le message.
QUIT termine la connexion.
SMTP est complètement défini dans la RFC 821. Des copies des RFC sont largement disponibles sur le Web ; elle vaut le coup d'être lu, car elle apporte beaucoup de lumière sur les arcanes du processus de messagerie.
Scénarios inhabituels
Le scénario ci-dessus est plutôt simplissime. L'hypothése principale est que les serveurs de mail des deux organisations concernées ont un libre accès réciproque. Ceci était prsque toujours vrai aux premiers temps de l'Internet, et c'est parfois encore le cas de nos jours, mais comme la sécurité est devenue un problème plus important, et commes les organisations et les réseaux sont devenus plus gros, nécessitant parfois plusieurs serveurs différents, c'est devenu de plus en plus inhabituel.
Les Firewalls
Beaucoup de, peut-être la plupart des organisations avec des ordinateurs reliés à l'Internet sont protégés par une sorte de firewall = pare-feu. Un firewall est simplement un ordinateur dont la fonction première est d'agir comme un surveillant d'accès entre les propress machines de l'organisation et le grand monde sale du réseau (si bien que, par exemple, les crackers ne puissent pas facilement se connecter à un élément du réseau de la compagnie IBM et commencer à voler les secrets du groupe). Du point de vue d'un autre ordinateur essayant de délivrer du courrier à un système situé derrière le firewall, ce que cela signifie est qu'on ne peut pas parler directement au système ; on doit parler au firewall.
Pas de surprises là ; çà introduit juste un autre "étape" dans le cheminement de ce message, avec le firewall agissant comme juste une autre machine qui passe le courrier. Le shéma ci-dessus devrait être modifié pour ressembler à ceci :
Illustration.
Si immense-isp.com avait mis en place un firewall, voici ce à quoi les en-têtes de notre exemple de message pourraient ressembler. Noter les premières lignes Received:. (Je suppose que le firewall s'appelle firewall.immense-isp.com ; en fait, donner à une machine un nom comme "firewall" est une invitation pour chaque teenager cracker apprenti-célébrité dans le monde à essayer de le fracturer, aussi les firewalls ont d'habitude des noms parfaitement banals et innocents.)
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 <tmh@immense-isp.com>; 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:
<rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris
v2.32
Subject: Lunch today?
De façon similaire, si tout le courrier sortant de bieberdorf.edu était acheminé à travers un firewall, il y aurait une autre ligne Received: inserrée par ce firewall. Par la même occasion, il pourrait y avoir ds machines concernées qui ne seraient pas vraiment des firewalls, mais simplement des points d'acheminement ---peut-être
des machines de maintenance de immense-isp.com dans beaucoup d'emplacements physiques, avec plusieurs serveurs mail différents, et utiliserait une seule machine (appelée, disons,
mailgate.immense-isp.com) pour décider vers quel serveur mail entrant le diriger. D'où l'exemple d'en-tête suivant un peu extreme, mais plausible :
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 <tmh@immense-isp.com>; 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 <tmh@immense-isp.com>; 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 <tmh@immense-isp.com>; 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:
<rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris
v2.32
Subject: Lunch today?
L'histoire du message peut être reconstituée en lisant les en-têtes Received: de bas en haut ; il vient 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 que tmh s'en préoccupe et le lise.
Les relais de messagerie
Voici des en-têtes possibles d'un message qui a eu un "cycle de vie" très différent de tout ce qui a été décrit jusqu'à présent :
Received: from unwilling.intermediary.com
(unwilling.intermediary.com [98.134.11.32]) by mail.bieberdorf.edu (8.8.5) id
004B32 for <rth@bieberdorf.edu>; 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
<junkmail@turmeric.com>
To: (recipient list
suppressed)
Message-Id:
<w45qxz23-34ls5@unwilling.intermediary.com>
X-Mailer: Massive
Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???
Diverses choses dans cet en-tête pourraient guider le lecteur vers le fait qu'il s'agit d'un message électronique bidon, mais les choses à bien voir ici sont les lignes Received:. Ce message a son origine à turmeric.com, est passée à unwilling.intermediary.com, et à sa destination finale à mail.bieberdorf.edu. Tout çà est bien beau ; mais que fait unwilling.intermediary.com
ici, puisqu'elle n'a rien à faire avec l'expéditeur ni le destinataire ?
Pour comprendre la réponse, une connaissance de SMTP est requise. Essentiellement, turmeric.com s'est simplement connecté au port SMTP de unwilling.intermediary.com et lui a dit "Envoi ce message à rth@bieberdorf.edu". Il a fait çà, probablement, de manière tout à fait directe, en disant RCPT TO: rth@bieberdorf.edu. A cette étape, unwilling.intermediary.com a pris le contrôle du processus de messagerie ; puisqu'on lui a dit de l'envoyer à un utilisateur d'un autre domaine (bieberdorf.edu), il s'y est mis et a trouvé le server mail de ce domaine et a manipulé le courrier à la manière habituelle. Ce processus est connu comme relai de messagerie.
Sur le plan historique, il y a de bonnes raisons pour permettre ce relai de messagerie ; sur une grande partie du réseau jusqu'à peu près la fin des années 1980, les machines envoyaient rarement le courrier en se parlant directement. Plutôt, elles déterminaient un itinéraire pour le message, et l'envoyaient étape par étape le long de cet itinéraire. C'était un système compliqué (spécialement en ce que l'expéditeur devait déterminer l''itinéraire à la main !) Par analogie, imaginons d'envoyer une lettre de San Francisco à New York, et écrivant l'adresse de l'enveloppe 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
Ceci montre clairement pouquoi c'est un mode d'adressage utile si vous êtes un employé du service postal ---le bureau de poste de Gary, Indiana n'a qu'à pouvoir communiquer avec les bureaux voisins de Chicago et d'Elkhart, au lieu d'avoir à employer ses ressources à imaginer comment envoyer quelque chose à New York. (C'est aussi clair que ce n'est pas une bonne idée du point de vue du rédacteur de la lettre, et qu'il n'est plus habituel d'acheminer de cette manière !) C'est exactement comme le courrier était expédié ; aussi il était important qu'une machine soit capable de donner d'autres instructions qui disaient "J'ai une lettre pour rth@bieberdorf.edu, à envoyer par vous à turmeric.com puis à galangal.org puis asafoetida.com pus bieberdorf.edu". D'où le relai de messageie.
A notre époque moderne, cependant, le relai de messagerie est habituellement utilisé par des publicitaires sans éthique comme technique pour masquer la source de leurs messages, reportant les plaintes sur les site-relais (innocents) plutôt que sur les vrais FAI des spammers.
(il tranfère aussi le travail d'adressage et de contacter les destinataires des machines des spammers à celles d'un tiers non concerné ; on sent bien que le relai de messagerie, particulièrement à grande echelle, constitue du vol de service pour cette raison). Le point essentiel est ici de réaliser que le contenu du message a été formulé par l'expéditeur ---turmeric.com dans l'exemple ci-dessus ; le lien intermédiaire, unwilling.intermediary.com, est concerné seulement comme intermediary involontaire. Ils n'ont aucun contrôle sur l'expéditeur, comme le bureau de poste de Gary n'a pas d'influence réelle sur quelqu'un qui écrit des lettres de San Francisco. (Ils ont, cependant, le pouvoir de cesser de relai de messagerie sur leur site !)
Une autre chose à noter dans les exemples d'en-têtes : la ligne Message-Id: a été remplie, non pas par la machine expéditrice (turmeric.com), mais par le relayeur (unwilling.intermediary.com). C'est une caractéristique habituelle du relai de messagerie ; çà réflète juste le fait que la machine expéditrice n'a pas renseigné le Message-Id.
Le chapitre sur SMTP, ci-dessus, fait référence à une distinction entre en-tête de "message" et d'"enveloppe". Cette distinction et certaines conséquences sont détaillées ici.
En bref, les en-têtes "envelope" sont véritablement générés par la machine qui reçoit un message, plutôt que par l'expéditeur. Suivant cette définition, les entêtes Received:
sont les en-têtes d'enveloppe ; cependant, le terme fait d'habitude seulement référence à l'"envelope From" et à l'"envelope To".
L'en-tête enveloppe From est l'en-tête issu de l'information de la commande MAIL FROM. Par exemple, si une machine expéditrice dit MAIL FROM:
ginger@turmeric.com, la machine réceptrice génèrera un entête enveloppe From
qui ressemble à ceci :
>From ginger@turmeric.com
Remarquer l'absence de "deux-points" ---"From", et non "From:". Fréquemment, les en-têtes d'enveloppe n'ont pas de "deux-points" ; cette convention n'est pas universelle, mais c'est suffisamment habituel pour le noter.
De manière symétrique, l'enveloppe To est issue d'une commande RCPT TO. Si l'expéditeur dit RCPT TO: tmh@bieberdorf.edu, alors l'enveloppe To est tmh@bieberdorf.edu. Souvent, il n'y a pas de véritable en-tête contenant cette information ; parfois, elle est incluse dans les en-têtes Received:.
Une importante conséquence de l'existence d'une information d'enveloppe est que le message From: et les en-têtes To: sont sans signification. Le contenu cet en-tête From: est fourni par l'expéditeur ; et ainsi, de manière contraire à l'intuition, le contenu de l'en-tête To:. Le message est expédié seulement en fonction de l'enveloppe To, et jamais sur l'en-tête du message To:.
Pour bien voir ceci, considérons une transaction SMTP comme suit :
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 correspondantes (extrait 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
<tmh@bieberdorf.edu>...
From:
another-forged-address@lemongrass.org
To: (your address suppressed for
stealth mailing and annoyance)
Noter que le contenu des enveloppes From, les messages From:, et les messages To: sont tous dictés par l'expéditeur, et n'ont pas le moindre support réel ! L'exemple qui suit illustre pourquoi les en-têtes From, From:, et To: ne peuvent jamais être prises en confiance dans un courrier qui pourrait être falsifié ; ils sont simplement trop faciles à falsifier.
L'Importance des en-têtes Received:
Nous avons déjà vu, dans les exemples ci-dessus, que les en-têtes Received: fournissent un compte-rendu détaillé de l'historique du message, et ainsi rendre possible de tirer des conclusions sur l'origin du message même quand d'autres en-têtes ont été truqués. Ce chapitre examine quelques détails associés à ves en-têtes spécialement importants, et en particulier comment contrer les techniques courantes de trucage.
Indubitablement, la simple protection la plus valable contre la falsification la plus efficace dans les en-têtes Received: est l'information apportée par l'hôte destinataire des messages de l'expéditeur. Rappelons que l'expéditeur peut mentir au sujet de son identité (en mettant des bêtises dans sa commande HELO au destinataire) ; heureusement, les messages récents d'expédition du courrier sont capables de détecter de telles fausses informations et de les corriger.
Si, par exemple, la machine turmeric.com, dont l'adresse IP est 104.128.23.115, envoie un message à mail.bieberdorf.edu, mais dit de manière fausse HELO galangal.org, la ligne résultante Received: pourrait démarrer comme suit :
Received: from galangal.org ([104.128.23.115]) by
mail.bieberdorf.edu (8.8.5)...
(le reste de la ligne est omis pour raison de clarté). Noter que, bien que la machine bieberdorf.edu n'annonce pas explicitement que galangal.org n'est pas réellement la machine de l'expéditeur, elle a enregistré l'adresse IP correcte de l'expéditeur. Si quelqu'un recevant ce courrier pensait avec raison que galangal.org apparaissait dans les en-têtes de par les oeuvres d'un faussaire, il pourrait vérifier l'adresse IP 104.128.23.115 (avec un outil comme le programme UNIX nslookup) et découvrir que cette adresse appartient en fait à turmeric.com (et non à galangal.org). En d'autres mots, l'enregistrement de l'adresse IP de la machine expéditrice fournit suffisamment d'information pour confirmer un trucage suspect.
Beaucoup de programmes de messagerie récents automatisent réellement ce processus, découvrant le nom de la machine espéditrice. (Le processus de contrôle est appelé reverse
DNS (pour Domain Name Service) ---"reverse" parce qu'il inverse le processus habituel de traduction d'un nom en une adresse pour l'expédition). Si mail.bieberdorf.edu utilisait le programme qui a fait çà, la ligne Received: aficherait quelque chose comme çà :
Received: from galangal.org (turmeric.com [104.128.23.115]) by
mail.bieberdorf.edu...
Ici la falsification est parfaitement claire ; cette ligne dit effectivement "turmeric.com, dont l'adresse est 104.128.23.115, a indiqué que son nom est galangal.org". Inutile de dire, une information comme çà est extremement utile pour identifier et pister les messages falsifiés ! (Pour cette bonne raison, les spammers essayent d'éviter d'utiliser les machines relais qui effectuent une information reverse DNS. Parfois, ils trouvent même des machines qui ne font pas le genre d'enregistrement IP décrit dans au paragraphe précédent ---bien qu'il n'y en ait plus beaucoup sur le net) .
Un autre coup utilisé par les faussaires de courrier, celui-là de plus en plus courant, est d'ajouter des en-têtes Received: feintes avant d'envoyer le courrier en cause. Ceci signifie que le courrier hypothétique envoyé de turmeric.com pourrait avoir des lignes Received: ressemblant un peu à :
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!
Evidemment, les deux dernières lignes sont un non-sens complet,
écrites par l'expéditeur et attachées au message avant de l'expédier.
A partir du moment où l'expéditeur n'a pas de contrôle sur le message une fois turmeric.com quitté, et les en-têtes Received: sont toujours ajoutés au début, les lignes truquées doivent apparaître au bas de la liste. Ceci signifie que quelqu'un lisant les lignes de haut en bas, suivant l'historique de ce message, peut assurément voir la chose à le première ligne falsifiée ; même si les lignes Received: après ce point semblent plausibles, elles sont sûres d'être truquées.
Bien sûr, l'expéditeur n'a pas à utiliser de bêtises évidentes ; un faussaire vraiment tortueux pourrait céer une liste plausible de lignes Received: comme ceci :
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, ce qui est révélateur est l'adresse IP non valable de galangal.org dans la toute première ligne Received:. La falsification serait encore plus difficile à détecter si le faussaire avait écrit une adresse IP correcte pour lemongrass.org et graprao.com, mais l'IP dénote dans la première ligne et révèlerait que le message a été faussé et "injecté" dans le réseau pour le site 104.128.23.115 (c'est à dire, turmeric.com). Cependant, la plupart des falsifications d'en-têtes sont considérablement moins sophistiquées, et les lignes Received: supplémentaires sont de toute évidence des bêtises.
Liste des en-têtes courants
- Apparently-To: Les messages avec plusieurs destinataires ont parfois une longue liste d'entêtes de la forme "Apparently-To: rth@bieberdorf.edu" (une ligne par destinataire). Ces en-têtes sont peu courants dans le courrier ordinaire ; ils sont normally le signe d'une mailing list, et récemment, les mailing lists utilisent générallement des logiciels suffisamment sophisticatés pour ne pas générer tout un ensemble d'en-têtess.
- Bcc: (mis pour "Blind Carbon Copy" = "Ccc = Copie conforme cachée) Si vous voyez cet en-tête dans un message entrant, quelque chose ne va pas. C'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 de messages à des personnes qui ne peuvent pas recevoir de réponses ou apparaître dans le sen-têtes. "Blind carbon copies" sont très utilisés par les spammeurs, puisque çà trouble beaucoup d'utilisateurs inexpérimentés de recevoir du courrier qui semble ne pas leur être adressé.
- Cc: (mis pour "Carbon Copy" -"Copie conforme"-, ce qui est tout à fait compréhensible si vous vous souvenez des machines à écrire) Cet en-tête est une sorte d'extension de "To:"; il signifie destinataires supplémentaires. La différence entre "To:" et "Cc:" est essentiellement connotative; certains mailers les traitent aussi différemment vis à vis des réponses.
- Comments: C'est un champ en-tête non standard et de forme libre. Il est la plupart du temps rencontré sous la forme "Comments: Authenticated sender is <rth@bieberdorf.edu>". Un en-tête comme çà est ajouté par certains mailers (notamment le gratuitiel populaire Pegasus) pour identifier l'expéditeur ; cependant, il est aussi bien ajouté "à la main" (avec de fauses informations) par les spammers. A traite avec précaution.
- Content-Transfer-Encoding: = Encodage de transfert de contenu - Cet en-tête est lié à MIME, un moyen standard d'encodage de contenu non textuel dans le courrier. Il n'a pas d'implication directe avec la distribution du courrier, mais il affecte le programme de courrier MIME-conciliant et interprête le contenu du message.
- Content-Type: Un autre en-tête MIME, dit au programme de courrier MIME-conciliant à quel type de contenu il doit s'attendre dans le message.
- Date: Cet en-tête fait exavtement ce que vous attendriez : Il spécifie une date, normalement la date à laquelle le message a été composé et envoyé. Si cet en-tête est omise par l'ordinateur de l'expéditeur, il peut être ajouté par un serveur mail ou même par une autre machine le long du chemin. Il ne doit pas être considéré comme parole biblique ; falsification mise à part, il y a un affreux paquet d'ordinateurs de par le monde dont l'horloge est fausse.
- Errors-To: Spécifie une adresse de branchement pour les erreurs générées par le mailer, comme les messages retournés pour "pas de tel utilisateur" (au lieu de l'adresse de l'expéditeur). Ce n'est pas un en-tête particulièrement répandu, étant donné que l'expéditeur veux habituellement recevoir toutes les erreurs à l'adresse d'expédition, ce qui est ce que la plupart (presque tous) des serveurs de mail font par défaut.
- From (sans les deux points) Ceci est l'"enveloppe From" vue plus haut.
- From: (avec les deux points) Ceci est le "message From:" vu plus haut.
- Message-Id: (aussi Message-id: ou Message-ID:) Le Message-Id est un identifieur plus ou moins unique assigné à chaque message, normalement par le premier serveur mail qu'il rencontre. Par convention, il est de la forme "gibberish@bieberdorf.edu", où la partie "gibberish" peut être absolument n'importe quoi et la seconde partie est le nom de la machine qui a assigné l'ID. Parfois, mais pas souvent, le "gibberish" inclut le nom de l'utilisateur expéditeur. Tout e-mail dans lequel l'identification du message est mal formée (par exemple, une chaine vide ou pas de signe @), ou dans lequel le site dans l'identification du message n'est pas le site réel d'origine, est probablement truqué.
- In-Reply-To: Un en-tête de forum qui apparaît occasionnellement dans un courrier, l'en-tête In-Reply-To: indique l'identification du message de quelques messages précédents auquel il répond. C'est habituel pour cet en-tête d'apparaître sauf dans les e-mails, directement en relation avec les forums ; les spammers sont connus pour fire çà, probablement pour tenter de tromper les programmes de filtrage.
- Mime-Version: (aussi MIME-Version:) Pourtant autre en-tête MIME, celui-là spécifie simplement la version du protocole MIME qui est utilisé par l'expéditeur. Comme les autres en-têtes MIME, celui-ci peut être ignoré ; les programmes de messagerie les plus récents le traiteront comm il se doit.
- Newsgroups: Cet en-tête apparaît seulement dans les e-mails qui sont liés à des forums ---copies e-mail des posts de forums, ou réponses e-mail à des posts. Dans le premier cas, il indique le forum dans lequel le message a été posté ; dans le second, il indique le forum dans lequel le message auquel on répond a été posté. La sémantique de cet en-tête est le sujet d'une guerre sainte de faible intensité, ce qui effectivement assure que les deux bouts de sémantiques seront utilisés sans distinction dans un futur prévisible.
- Organization: Un en-tête de forme libre qui contient normalement le nom de l'organisation par lauelle l'expéditeur a accès au réseau. L'expéditeur peut généralement contrôler cet en-tête, et les saisies toutes bêtes comme "Royal Society for Putting Things on Top of Other Things" sont monnaie courante.
- Priority: Un en-tête essentiellemnt de forme libre qui assigne une priorité au courrier. La plupart des programmes l'ignorent. Il est souvent utilisé par les spammers, d'habitude sous la forme "Priority: urgent" (ou quelque chose de semblable), pour tenter de faire lire leur messages.
- Received: Vu en détails plus haut.
- References: L'en-tête References: est rare dans le courrier excepté pour les copies de posts de forums. Son usage dans les forums est pour identifier les posts "montants" auquel un message répond ; quand il apparaît dans un courrier, il est d'habitude la simple copie d'un en-tête de forum. Il peut aussi apparaître dans les réponses de courrier à des posts de forums, donnant l'identification du message du post auqel il répond ausis bien que les références de ce post.
- Reply-To: Spécifie une adresse pour la réponse. Bien que cet en-tête a beaucoup d'utilisations normales (peut-être votre mutile votre adresse From: et vous voulez que votre réponse soit faite à l'adresse correcte), il est aussi largement utilisé par les spammers pour éviter les critiques. A l'occasion, un spammer naif sollicitera réellement des réponses par e-mail et utilisera l'en-tête Reply-To: pour les collecter, mais plus souvent, l'adresse Reply-To: dans le faux courrier est soit invalide, soit celle d'une innocente victime.
- Sender: Cet en-tête n'est pas habituel dans les e-mails (X-Sender: le remplace souvent), mais apparaît parfois, spéciallement dans les copies de posts de forums. Il devrait identifier l'expéditeur ; dans le cas deposts de forums, c'est une identification plus fiable que l'identification de la ligne From:.
- Subject: Un champ complètement libre spécifié par l'expéditeur, destiné, bien sûr, à décrire l'objet du message.
- To: Le "message To: " décrit ci-dessus. Noter que l'en-tête To: ne nécessite pas l'adresse du destinataire !
- X-headers est le terme générique es en-têtes démarrant par la majuscule X et un tiret. La convention est que les en-têtes X- sont non-standards et fournies pour information seulement, et que, inversement, tout en-tête informative non-standard devrait avoir un nom commençant par "X-". cette convention est fréquemment violée.
- X-Confirm-Reading-To: Cet en-tête nécessite une réponse de confirmation automatique quand le message est reçu ou lu. C'est typiquement ignoré ; certains programmes agissent sûrement sur lui.
- X-Distribution: En réponse à des problèmes avec des spammers utilisant son programme, l'auteur de Pegasus Mail a ajouté cet en-tête. Tout message envoyé avec Pegasus à un nombre suffisemment grand de destinataires a un en-tête supplémentaire qui dit "X-Distribution: bulk". Il est explicitement destiné aux destinataires pour se prémunir.
- X-Errors-To: Comme Errors-To:, cet en-tête spécifie une adresse pour y envoyer les erreurs. C'est probablement moins largement respecté.
- X-Mailer: (aussi X-mailer:) Un en-tête libre destiné au programme de mail utilisé par l'expéditeur pour s'identifier (comme publicité ou n'importe quoi). Etant donné que beaucoup de courrier bidon est envoyé avec des mailers inventés pour l'occasion, ce champ peut fournir beaucoup de matière utile pour les filtres.
- X-PMFLAGS: C'ets un en-tête ajouté par Pegasus Mail ; sa sémantique n'est pas évidente. Il apparaît dans tout message envoyé par Pegasus, aussi il ne transmet évidemment pas d'information au destinataire qui ne soit comprise dans l'en-tête X-Mailer:.
- X-Priority: Un autre champ de priorité, utilisé principalement par Eudora pour assigner une priorité (ce qui apparaît comme une notation graphique dans le message).
- X-Sender: Le pendant analogue à l'en-tête Sender: des forums et news, cet en-tête prétend identifier l'expéditeur avec plus de fiabilité que l'en-tête From:. En fait, il est presque aussi facile à truquer, et devrait donc être regardé avecla même sorte de méfiance que l'en-tête From:.
- X-UIDL: C'est un identifier unique utilisé par le protocole POP pour retrouver le courrier sur le serveur. Il est normalement ajouté entre le serveur mail du destinataire et le vrai programme de courrier du destinataire ; si le mail arrive à un serveur mail avec un en-tête X-UIDL:, il est probablement bidon (il n'y a pas d'utilisation concevable pour un tel en-tête, mais pour certaines raisons inconnues beaucoup de spammers en ajoutent un.
 
|
