IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

L'Internet Rapide et Permanent

Le protocole de messagerie SMTP

Vous disposez d'une connexion permanente et rapide… et maintenant, vous êtes perdu dans la technique…

Cette série « L'Internet Rapide et Permanent », que Christian Caleca nous a aimablement autorisés à reproduire, est là pour répondre à quelques-unes de ces questions. Cet article parlera du protocole de messagerie SMTP.

N'hésitez pas à commenter cet article ! Commentez Donner une note à l´article (5)

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

1. Introduction

1-1. Simple Mail Transfert Protocol

C'est un des protocoles les plus fondamentaux de l'Internet. Nous l'utilisons tous les jours et nous sommes loin d'en connaître toutes les finesses…

Lorsque j'ai décidé de construire cet exposé, je n'avais pas une idée exacte de la galère dans laquelle je me mettais. C'est exactement la même que celle dans laquelle vous allez vous mettre si vous poursuivez sa lecture… (On ne pourra pas dire que je soigne ma publicité.)

Vous continuez ? Je vous aurai prévenu …

1-2. Qu'allons-nous voir au juste ?

L'objectif initial de ce chapitre était double :

  • détailler un peu ce qu'il se passe lorsqu'on envoie un message, comment l'information voyage et arrive chez le destinataire et comment s'y prendre pour que le destinataire dispose d'une information lisible. Tout le monde n'utilise pas les mêmes outils de messagerie, les mêmes systèmes d'exploitation, le but étant tout de même d'arriver à communiquer entre « mondes » différents.
    Cette partie de l'exposé, je la voulais simple et relativement complète. J'ai vite constaté que c'était une gageure (prononcer [gazyr] Action, projet, opinion si étrange, si difficile, qu'on dirait un pari impossible à tenir). 
    Cette partie-là a donc explosé en deux morceaux :
    • l'un qui reste simple et traite « en gros » du transport SMTP et en détail des divers moyens de coder un message pour qu'il puisse passer par les tuyaux de SMTP. Cette partie contient ce qui, à mon sens, devrait être connu de tout internaute responsable, parce que c'est le fondement d'une « tour de Babel » moderne. Autant vous dire que vous avez intérêt à lire au moins cette partie… ;
    • l'autre morceau reprend en détail le transport SMTP, en s'appuyant sur une analyse de trames lors d'un envoi de message et sur une méthode d'envoi de message à la Robinson Crusoe, avec TELNET, pour manipuler soi-même les commandes reconnues par le protocole SMTP.
  • Un troisième volet intéressant consistait à montrer comment construire un système autonome qui permette de poster des messages sans avoir à utiliser le serveur proposé par votre fournisseur d'accès. C'est une opération a priori très simple à réaliser, mais qui nécessite de connaître un minimum les outils que l'on emploie, si l'on ne veut pas courir le risque de jouer aux apprentis sorciers. L'expérience apprenant des choses, dans cette version remise à jour, j'ai choisi d'exposer la mise en Å“uvre de systèmes de messagerie (Postfix, Qmail), dans des chapitres séparés.

2. Les bases

Dans cette partie de l'exposé, nous allons voir en détail ce que tout internaute gagnerait à savoir, concernant la façon dont les e-mails voyagent, quel est leur contenu exact, comment les informations sont codées…

Cette partie est donc divisée en trois paragraphes :

  • la façon dont le message voyage, depuis l'émetteur jusqu'au destinataire ;
  • une analyse détaillée de tout le contenu du message, y compris l'en-tête qui n'est pas visible par défaut dans les outils de messagerie courants ;
  • une explication de la façon dont le contenu du message est codé pour pouvoir être transporté par SMTP.

2-1. Itinéraire d'un message électronique

Supposons un cas simple (et cependant courant).

  • Soit un utilisateur abonné chez « truc » et ayant pour adresse électronique : fred@truc.fr.
  • Soit un autre utilisateur abonné chez « machin » et ayant pour adresse électronique marc@machin.com.
  • truc dispose des serveurs :
    • smtp.truc.fr ;
    • pop.truc.fr.
  • machin dispose des serveurs :
    • smtp.machin.com ;
    • pop.machin.com.
  • Fred doit envoyer un message à Marc.
  • Fred compose le message avec son outil de messagerie préféré, disons outlook express. Il a des avantages : Il est gratuit et il est fait par Microsoft.
    Une fois le message composé, Fred clique sur le bouton « envoyer » de son MUA (comme Mail User Agent). Comme il a correctement configuré son outil, le message est envoyé sur le serveur smtp.truc.fr (MTA, comme Mail Transfert Agent).
  • Le serveur smtp.truc.fr reçoit le message, constate que le destinataire n'est pas dans son domaine (sa destination). Il cherche alors un MTA dans le domaine machin.com et le trouve (DNS est là pour ça, entre autres choses). Il envoie le message à smtp.machin.com.
  • Le serveur smtp.machin.com reçoit le message, constate que le destinataire est bien dans son domaine (ses destinations). Il range alors le message dans la boite aux lettres de Marc, par l'intermédiaire d'un composant appelé MDA, comme Mail Delivery Agent. Il y restera aussi longtemps qu'il le faudra, sans rien dire à personne.
  • Un jour, Marc décide de regarder s'il n'a pas de messages. Il envoie donc une requête à son serveur pop.machin.com, au moyen de son outil de messagerie préféré, par exemple « Thunderbird » (un autre MUA). Il a des avantages : il est libre, gratuit et n'est pas fait par Microsoft.
  • Le serveur pop consulte la boite aux lettres de Marc, constate qu'il y a un message dedans.
  • Il l'envoie alors à l'outil de messagerie de Marc qui, par défaut, demandera à pop.machin.com de le supprimer de la boite aux lettres. Nous supposons ici que Marc, ou plutôt son MDA, utilise le protocole POP3. Mais c'est un comportement par défaut, il est possible de demander à ne pas effacer les messages (même avec POP3). Cette fonction est utile lorsque l'on désire consulter sa messagerie de divers endroits sans avoir à se renvoyer un message si on veut le relire ailleurs.

POP3 est un protocole de relève de courrier. Sans entrer ici dans les détails, il en existe un autre appelé IMAP. D'ailleurs, tout ceci est étudié dans d'autres chapitres de ce site.

2-2. Mécanismes mis en jeu

2-2-1. SMTP (Simple Message Transfert Protocol)

C'est le protocole applicatif qui permet de transporter les messages sur l'Internet. Il sait acheminer un message jusqu'à une boîte aux lettres, mais ne va pas plus loin.

Pour y arriver, il analyse dans un premier temps la partie de l'adresse située à droite du @ (à prononcer dans ce cas « at »), pour trouver le domaine du destinataire. Si ce domaine le concerne, il cherche alors la boîte aux lettres du destinataire en regardant la partie de l'adresse située à gauche du @. Si le domaine du destinataire ne le concerne pas, il va chercher le serveur SMTP qui gère ce domaine, au moyen des champs MX du DNS du domaine destinataire et transmet le message à ce serveur.

2-2-2. POP3 (Post Office Protocol 3)

Ce protocole est exclusivement utilisé pour le dialogue entre le client de messagerie et la boîte aux lettres. Il ne fait pas de transport sur l'Internet, il permet juste à l'utilisateur de gérer son courrier. IMAP4 (Internet (ou Interactive ?) Mail (ou Message ?) Access Protocol version 4) en est une alternative.

2-2-3. MUA, MTA, MDA et cetera

Un peu de jargon :

  • le MUA (Mail User Agent), c'est le client de messagerie (Thunderbird, Outlook Express, Eudora, Pegasus, etc.) ;
  • le MTA (Mail Transfert Agent) est à prendre au sens large. Le courrier peut être acheminé d'un point à un autre par l'intermédiaire d'agents de transfert qui ne gèrent pas de boites aux lettres, mais savent relayer le courrier d'un point à un autre pour atteindre le serveur supportant les boites aux lettres. En effet, l'exemple vu plus haut est le plus simple que l'on puisse imaginer. Dans la pratique, le courrier peut transiter par plusieurs MTA. Nous le verrons plus loin ;
  • le MDA (Mail Delivery Agent) aussi appelé LDA (Local Delivery Agent) est le service de remise du courrier dans les boites aux lettres des destinataires, une fois que le courrier est arrivé sur le MTA de destination. Le MTA transmet alors au MDA les messages destinés aux clients du domaine ;
  • le MX (Mail eXchanger), n'est rien de plus qu'un MTA référencé sur les DNS, comme nous le verrons plus loin.
2-2-3-1. Récapitulons

Lorsque l'on rédige un courrier et qu'on le poste, on le fait avec le MUA qui le transmet au MTA qu'on lui a signalé dans la configuration (pour un abonné Free, c'est normalement smtp.free.fr). C'est l'étape 1 du petit schéma vu plus haut.

De MTA en MTA, le message voyage jusque sur le MTA qui a en charge la messagerie du domaine du destinataire (étape 2). Il le passe alors (avec tous les autres messages entrants pour ce domaine) au MDA qui distribue ce courrier entrant dans les boites aux lettres concernées (étape 3).

Les étapes 4, 5 et 6 concernent le serveur POP (ou IMAP).

2-3. Dans les entrailles de l'e-mail

D'abord, en français on ne dit pas « e-mail », ni « mail »; on dit « mèl » (je t'envoie un mèl, tu m'envoies un mèl, on s'envoie des mèls), on peut dire également « courriel ». Mais, pour la bonne compréhension du texte, je continuerai à écrire « e-mail ».

Lorsque vous recevez un e-mail, votre MUA (maintenant qu'on sait ce que c'est) vous montre :

  • l'expéditeur ;
  • l'objet (qu'il ne faut jamais oublier de remplir, c'est utile pour trier son courrier) ;
  • le texte (ou corps) du message.

Mais votre e-mail contient toute une partie « cachée » qui nous permet de savoir quel chemin cet e-mail a suivi pour arriver dans votre boîte aux lettres.

Cette partie, appelée l'en-tête, n'est pas « top secret », bien que non visible par défaut. Vous pouvez toujours la consulter avec votre MUA. Pour Thunderbird, menu « Affichage/code source du message ». Pour Outlook Express, il y a longtemps que j'ai oublié.

2-3-1. Prenons un exemple

 
Sélectionnez
Return-Path: <christian.caleca@wxnxdoo.fr>
Received: from alisier.wxnxdoo.fr (smtp-rt-9.wxnxdoo.fr [193.252.19.55])
          by mail.monaco.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA07439
for <eme13@enprovence.com>; Thu, 11 May 2000 18:20:10 +0200
Received: from mahonia.wxnxdoo.fr (193.252.19.58)
          by alisier.wxnxdoo.fr; 11 May 2000 18:20:08 +0200
Received: from CHRIS (62.161.101.240)
          by mahonia.wxnxdoo.fr; 11 May 2000 18:19:51 +0200
Message-ID: <000501bfbb64$afc796c0$0a00a8c0@maison.mrs>
From: "Christian CALECA" <christian.caleca@wxnxdoo.fr>
To: <eme13@enprovence.com>
Subject: test itineraire
Date: Thu, 11 May 2000 18:19:24 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset= "iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Status:

Juste pour analyser l'en-tête

Toute la partie en gras constitue ce que l'on appelle l'en-tête, alors que la dernière ligne, le message lui-même, s'appelle le corps.

Note : Pour éviter de faire la partie trop belle aux robots renifleurs d'adresses e-mail, certains noms de domaines ont été volontairement dégradés.

2-4. Détail de l'en-tête

Tous les mots finis par « : » sont des champs qui ont une signification particulière, soit pour les MTA, soit pour les MUA. Nous allons détailler leur signification.

Return-Path: C'est l'adresse qui sera utilisée :
* pour la réponse (la fonction répondre à l'expéditeur) ;
* le renvoi du message s'il ne peut arriver au destinataire.
Received: Cette ligne est un peu particulière. Chaque MTA qui reçoit le message y inscrit le nom du MTA qui le lui a envoyé, ainsi que le sien. Il est ainsi possible de retracer complètement la route qu'a suivie le message de l'expéditeur jusqu'au destinataire.
Message-ID: C'est un identifiant unique du message. Il est attribué par le premier MTA qui reçoit le message (Protocole ESMTP : Extended SMTP).
From: C'est l'adresse de l'expéditeur. Elle est par défaut recopiée dans le « return path », sauf configuration différente du MUA de l'expéditeur.
To: C'est l'adresse du (ou des) destinataire(s).
Subject: L'objet du message.
Date: La date d'émission écrite par le MUA de l'émetteur.
MIME-Version: Version du mode de codage des données. Cette information a tellement d'importance que nous allons y consacrer toute une page.
Content-Type: Type de codage utilisé.
charset= Jeu de caractères utilisé.
Content-Transfer-Encoding: Codage sur 7 ou 8 bits.
X-… Tous les champs commençant par X ne sont pas des champs « officiels ». Chaque MUA est libre d'en ajouter autant qu'il veut. Leur contenu n'est pas pris en compte par les MTA. Ainsi, il est illusoire de croire que le champ X-Priority ait une quelconque importance dans la vitesse de transport du message.

Cette liste de champs n'est pas complète. Il y en aurait pour trois pages à les énoncer tous… 

2-4-1. Utilité de l'en-tête

L'en-tête contient donc toutes les informations nécessaires pour :

  • identifier l'auteur du message ;
  • identifier le destinataire ;
  • savoir à qui il faut répondre ;
  • retrouver le chemin suivi par le message ;
  • savoir comment a été codé ce message ;
  • des informations « subsidiaires » (champs X…) qui ne sont pas utilisées par SMTP ni ESMPT, mais qui permettent de donner des informations qui peuvent être utiles, comme le MUA qui a généré le message.

2-5. Vertus et défauts de SMTP

Ce protocole a la vertu d'être particulièrement « solide », mais il est un peu ancien et il lui manque quelques fonctionnalités qui seraient bien utiles aujourd'hui :

  • la sécurisation de la transmission. Encore qu'une extension « STARTTLS » ait été créée dans ce but (voir à ce propos le site « Sécurisation des courriers électroniques ») ;
  • les possibilités de transmettre autre chose que du texte brut.

Ces deux limites peuvent être contournées :

  • en chiffrant son message ;
  • en utilisant un artifice pour encoder tout type de document de telle manière que SMTP croie que c'est du texte. Étudier ce système ici nous mènerait trop loin. Si le sujet vous intéresse, consultez le chapitre sur le codage des caractères.

Nous allons tout de même faire deux où trois observations utiles, pour comprendre mieux comment il faut configurer son MUA pour être lu correctement.

2-5-1. Les divers codages utilisant MIME

Bien que le codage des données soit traité plus en détail ailleurs sur ce site, voyons tout de même rapidement quelques points importants.

Pour illustrer ceci, nous allons envoyer des messages avec Outlook Express et nous allons les lire avec un outil rustique sous Linux : l'outil « mail ». Cet outil fonctionne en mode texte. Plus rustique, vous n'aurez que Telnet.

Nota : les captures ne datent pas d'hier et elles utilisent Outlook Express qui n'est pas recommandable, mais qui permet de mener à bien la manip.

2-5-2. Codage « Aucun » ou « plain/text »

C'est-à-dire pas de codage particulier pour le texte. On envoie ce message :

Image non disponible

Et l'on récupère ceci (à la condition que votre console utilise ISO-8859-1) :

Image non disponible

C'est correct. L'en-tête indique que le contenu est du texte de type « plain text » encodé sur 8 bits, avec un jeu de caractères « ISO-8859-1 ». Comme vous pouvez le constater, le texte est parfaitement lisible. Il y a cependant un problème potentiel en voie de disparition : la plupart des MTA utilisent un protocole ESMTP qui gère l'ASCII sur 8 bits, mais il peut encore exister çà et là des vieux MTA qui mettront systématiquement le bit7 à 0. Le problème devrait aujourd'hui être rarissime. Dans ce cas, la seule solution est d'utiliser des caractères du code ASCII US, sans aucune lettre accentuée.

2-5-3. Codage « quoted printable »

Outlook express propose ce mode en « texte brut ». Essayons pour voir…

Image non disponible

Ben c'est pas terrible ; les lettres accentuées sont curieusement codées…

Image non disponible

En fait, dans ce mode de codage,  les caractères qui peuvent être codés sur 7 bits sont transmis normalement, ceux qui ne le peuvent pas (bit 7 à 1) sont remplacés par « = » et la valeur du code ASCII sur 8 bits exprimée en hexadécimal.

À ne pas utiliser donc, si le destinataire ne dispose pas d'outil sachant décoder du « quoted printable ». Aujourd'hui, (20 juin 2008) cette façon de faire semble être à la mode sur la configuration par défaut de nombreux MUA. J'avoue ne pas en connaitre ni en comprendre la raison.

2-5-4. Codage « base 64 »

Outlook Express propose également ce mode de codage, lorsque l'on choisit le « texte brut ». On essaye…

Image non disponible

C'est catastrophique. Mail ne sait pas du tout décoder le message…

Image non disponible

Aucun caractère n'est lisible.

2-5-5. Le codage HTML

Enfin, le meilleur pour la fin, le message en HTML.

Je ne voudrais pas ici déclencher une polémique inextinguible sur ce sujet brûlant… Mais rappelons les faits.

Le texte pur, c'est bien, mais c'est de la génération de « edit », « notepad » et autres « vi ». Autrement dit, aucun enrichissement possible du texte. Il peut pourtant être utile de rédiger ses messages avec quelques possibilités des traitements de texte, comme les notions de gras, italique, souligné, mise en surbrillance, etc. D'où l'idée d'écrire ses messages en HTML qui sait faire tout cela.

Mais voyons le résultat :

Image non disponible

Ici, pas de copie d'écran, tellement le résultat est long :

  • ce qui est en gras constitue les morceaux de l'en-tête ;
  • ce qui est surligné représente les spécificités du codage en HTML « multipart » ;
  • ce qui est en bleu, c'est l'explication de ce qu'il se passe. (Ça ne fait pas partie du message.)
 
Sélectionnez
From christian.caleca@w-n-doo.fr  Thu May 11 09:00:46 2000
Return-Path: <christian.caleca@w-n-doo.fr>
Delivered-To: chris@gateway2.maison.mrs
Received: from chris (chris.maison.mrs [192.168.0.10])
        by gateway2.maison.mrs (Postfix) with SMTP id DB2D51BAAF
        for <chris@gateway2.maison.mrs>; Thu, 11 May 2000 09:00:46 +0200 (CEST)
Message-ID: <003501bfbb16$8a226dd0$0a00a8c0@maison.mrs>
From: "Christian CALECA" <christian.caleca@w-n-doo.fr>
To: <chris@gateway2.maison.mrs>
Subject: codage HTML
Date: Thu, 11 May 2000 09:00:06 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;

# L'extension MIME indique ici que le message va être codé en deux parties,
# de manière différente pour les deux parties...

        boundary="----=_NextPart_000_0031_01BFBB27.4D9A74F0"

# Avec une balise que l'on aura du mal à confondre
# avec le texte du message, quel qu'il soit.

X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

# C'est un message de format MIME en plusieurs parties.

------=_NextPart_000_0031_01BFBB27.4D9A74F0  # Première balise
Content-Type: text/plain;
        charset= »iso-8859-1 »
Content-Transfer-Encoding: 8bit

Ici, c'est ce qu'on fait de mieux:
éèàçùî

# Cette première partie a été codée  de façon basique,
# celle qui, normalement, doit fonctionner avec n'importe quel MUA, nous l'avons vu.

------=_NextPart_000_0031_01BFBB27.4D9A74F0  # Deuxième balise
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

# Mais "quoted-printable", ce n'est pas forcément un bon choix...
# Le « plain text » peut être utilisé dans le codage HTML

<!DOCTYPE HTML PUBLIC « -//W3C//DTD HTML 4.0 Transitional//EN »>
<HTML><HEAD>
<META content=3D »text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D »MSHTML 5.00.2919.6307 » name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ici, c'est ce qu'on fait de =
mieux:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>=E9=E8=E0=E7=F9=EE</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>


# Tout ceci est du jargon HTML. Simple ici, parce qu'il n'y a aucune fioriture !
# Ce paragraphe aurait été beaucoup plus long, si l'on avait mis des couleurs,
# des tailles de polices différentes, et surtout un fond de papier.
# Notez que la seule partie signifiante de tout ceci est ce qui est surligné en blanc


------=_NextPart_000_0031_01BFBB27.4D9A74F0--   # Dernière balise.

Notez qu'Outlook Express, malgré tout le mal que l'on peut en dire ici où là, a la politesse de créer un paragraphe en « plain text » qui sera lisible par tout MUA. D'autres MUA n'ont même pas cette politesse.

Alors, pourquoi le HTML est-il proscrit par la netiquette ?

  • En tout premier lieu, hélas, un problème de sécurité. Un document HTML peut véhiculer des scripts malicieux ayant des comportements de virus.
  • L'extrême longueur des messages générés, surtout si l'on s'amuse un peu trop avec les gadgets. Ce gonflement de la taille du message est souvent pénalisant :
    • pour l'espace disque de celui qui conserve les messages qu'il reçoit ;
    • la durée de chargement (pensez qu'il existe encore des internautes qui ne disposent que d'un très faible débit).
  • La lisibilité aussi. La taille des polices étant fixée, un texte lisible sur un écran 800×600 deviendra très pénible à lire sur un 1280×1024.
  • La plus élémentaire des politesses qui consiste à s'assurer que l'on ne dérange pas celui à qui l'on envoie ce message. Les dérangements les plus évidents étant :
    • l'impossibilité pour le destinataire de lire correctement le message, n'étant pas outillé pour çà (mais là, à la rigueur, il peut éventuellement faire l'effort d'utiliser des outils qui savent le faire, la politesse passe aussi par là…) ;
    • le temps de chargement des messages et l'encombrement de la boite aux lettres. C'est un argument qui me parait plus convaincant. Si vous êtes en déplacement, que vous vous connectez avec un portable sur une ligne RTC de qualité douteuse, vous préférerez assurément que les messages soient le plus court possible ;
    • certaines personnes reçoivent plusieurs dizaines (centaines) de messages par jour. Même avec une bonne connexion, c'est mieux de faire court ;
    • le dernier argument est une synthèse des autres, les boites aux lettres sont souvent limitées en taille par les fournisseurs d'accès, même si cette taille augmente périodiquement. Plus les messages sont longs, moins on peut en mettre dedans. Les pièces jointes sont d'ailleurs aussi pénalisantes, mais elles sont parfois indispensables. Là encore, c'est une question de discernement.

2-6. Conclusions

  • Par défaut, postez en texte brut, « plain text » ou « aucun codage » avec Outlook Express. En pratique, codez en ISO-8859-1 (ou en UTF-8, éventuellement, bien que ce soit l'avenir, tous les MUA ne savent pas forcément gérer correctement cet encodage) ;
  • ne postez en HTML qu'aux personnes qui vous l'ont permis, c'est plus poli ;
  • ne postez en HTML que si c'est vraiment utile, (faire simplement « joli » n'est pas utile. Pour faire joli, faites une Å“uvre d'art et envoyez-la par la poste).

Voilà. Vous ne pourrez plus dire maintenant que vous ne saviez pas pourquoi il fallait  faire attention au codage de vos messages

3. Les profondeurs

3-1. Les mécanismes de SMTP

Dans cette partie de l'exposé, nous allons regarder ce qu'il se passe dans les profondeurs du protocole SMTP.

3-1-1. L'analyse de trames

Comme d'habitude, rien ne vaut l'analyse des trames pour voir exactement ce qu'il se passe. Si l'on arrive à tout interpréter, on est certain de ne rien laisser passer du protocole. Ici, l'analyse est un peu longue, elle comporte deux parties :

  • la recherche de l'adresse du MTA du destinataire (recherche DNS « classique ») ;
  • la transmission du message selon le protocole SMTP, qui s'appuie sur TCP. Les échanges sont un peu plus compliqués qu'en UDP, employé pour la résolution des noms.

3-1-2. Envoyer un message « à la main »

Il existe un petit outil appelé « Telnet » qui n'est rien d'autre qu'un terminal trivial en mode texte. Il est cependant possible de faire beaucoup de choses avec Telnet, pas toujours très simplement, je vous l'accorde. Avec « Telnet », il est possible de lire son courrier, d'en envoyer, de lire les news et bien d'autres choses encore.

Nous allons envoyer un message avec Telnet, ce qui nous obligera à connaitre toutes les commandes (du moins les plus importantes) du protocole SMTP.

3-2. Espionnage d'un envoi

Comme d'habitude, nous allons espionner l'envoi d'un e-mail avec notre « sniffer » préféré. Rien de tel pour bien comprendre comment les choses se passent.

3-2-1. Énoncé du problème

Depuis un poste du réseau privé, nous allons envoyer un message à l'adresse « eme13@enprovence.com » en employant notre serveur SMTP « gateway1.maison.mrs ».

3-2-2. Objectif de la manip

Si nous arrivons à tracer toute la transaction, plus aucun détail du protocole SMTP ne nous échappera. Essayons pour voir.

Attention ! C'est du TCP, ça va être long… (mais ça va être bon)

3-2-3. Les trames récupérées

  • Ce qui est surligné en jaune est ce qui est le plus important.
  • Ce qui est en bleu est un commentaire.
3-2-3-1. Recherche de l'adresse du serveur SMTP du destinataire
 
Sélectionnez
Frame 3 (74 on wire, 74 captured)
...
    Protocol: UDP (0x11)
    Header checksum: 0x0a83 (correct)
    Source: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
    Destination: ns0.mrs.ftci.oleane.com (62.161.120.11)  # Notre DNS régional
User Datagram Protocol
    Source port: 1038 (1038)
    Destination port: domain (53)
    Length: 40
    Checksum: 0xb005
Domain Name System (query)
    Transaction ID: 0xea25
    Flags: 0x0100 (Standard query)
        0... .... .... .... = Query
        .000 0... .... .... = Standard query
        .... ..0. .... .... = Message is not truncated
        .... ...1 .... .... = Do query recursively
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        enprovence.com: type MX, class inet   # Notez la nature de la requête:
            Name: enprovence.com              # On demande un enregistrement de type MX
            Type: Mail exchange               # (Mail Exchanger)
            Class: inet

La trame 3 constitue donc une requête DNS pour trouver un Mail Exchanger valide pour le domaine « enprovence.com »

 
Sélectionnez
Frame 4 (207 on wire, 207 captured)
...
    Protocol: UDP (0x11)
    Header checksum: 0x7fd6 (correct)
    Source: ns0.mrs.ftci.oleane.com (62.161.120.11)
    Destination: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
User Datagram Protocol
    Source port: domain (53)
    Destination port: 1038 (1038)
    Length: 173
    Checksum: 0xbffd
Domain Name System (response)
    Transaction ID: 0xea25
    Flags: 0x8180 (Standard query response, No error)
        1... .... .... .... = Response
        .000 0... .... .... = Standard query
        .... .0.. .... .... = Server isn't an authority for domain
        .... ..0. .... .... = Message is not truncated
        .... ...1 .... .... = Do query recursively
        .... .... 1... .... = Server can do recursive queries
        .... .... .... 0000 = No error
    Questions: 1
    Answer RRs: 2
    Authority RRs: 2
    Additional RRs: 3
    Queries
        enprovence.com: type MX, class inet
            Name: enprovence.com
            Type: Mail exchange
            Class: inet
    Answers  # La réponse de notre DNS concernant les MX
        enprovence.com: type MX, class inet, preference 0, mx mail.monaco.net
            Name: enprovence.com
            Type: Mail exchange
            Class: inet
            Time to live: 22 hours, 30 minutes, 40 seconds
            Data length: 19
            Preference: 0
            Mail exchange: mail.monaco.net
        enprovence.com: type MX, class inet, preference 1, mx dns2.monaco.net
            Name: enprovence.com
            Type: Mail exchange
            Class: inet
            Time to live: 22 hours, 30 minutes, 40 seconds
            Data length: 9
            Preference: 1
            Mail exchange: dns2.monaco.net

# Notez qu'il y en a deux, avec des niveaux de préférence différents...
# Notez également que les adresses IP n'ont pas été fournies...

    Authoritative nameservers
        enprovence.com: type NS, class inet, ns DNS1.monaco.net
            Name: enprovence.com
            Type: Authoritative name server
            Class: inet
            Time to live: 14 hours, 39 minutes, 58 seconds
            Data length: 7
            Name server: DNS1.monaco.net
        enprovence.com: type NS, class inet, ns dns2.monaco.net
            Name: enprovence.com
            Type: Authoritative name server




            Class: inet
            Time to live: 14 hours, 39 minutes, 58 seconds
            Data length: 2
            Name server: dns2.monaco.net

# Mais tout de même, la réponse intègre les noms des DNS impliqués dans l'affaire.

    Additional records
        mail.monaco.net: type A, class inet, addr 194.79.150.9
            Name: mail.monaco.net
            Type: Host address
            Class: inet
            Time to live: 1 hour, 51 minutes, 41 seconds
            Data length: 4
            Addr: 194.79.150.9
        dns2.monaco.net: type A, class inet, addr 194.79.150.2
            Name: dns2.monaco.net
            Type: Host address
            Class: inet
            Time to live: 13 hours, 11 minutes, 15 seconds
            Data length: 4
            Addr: 194.79.150.2
        DNS1.monaco.net: type A, class inet, addr 194.79.150.9
            Name: DNS1.monaco.net
            Type: Host address
            Class: inet
            Time to live: 14 hours, 9 minutes, 50 seconds
            Data length: 4
            Addr: 194.79.150.9

Les « Additional records », tout le monde semble s'en moquer. Pourtant, l'avenir va nous montrer qu'ils nous feraient gagner en efficacité…

Nous avons ici toutes les IP nécessaires… Et pourtant… Notez également au passage la diversité des fonctions de l'hôte dns2.monaco.net, il est second MX et second NS.

 
Sélectionnez
Frame 5 (75 on wire, 75 captured)
...
    Protocol: UDP (0x11)
    Header checksum: 0x0a81 (correct)
    Source: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
    Destination: ns0.mrs.ftci.oleane.com (62.161.120.11)
User Datagram Protocol
    Source port: 1038 (1038)
    Destination port: domain (53)
    Length: 41
    Checksum: 0x3994
Domain Name System (query)
    Transaction ID: 0xea26
    Flags: 0x0100 (Standard query)
        0... .... .... .... = Query
        .000 0... .... .... = Standard query
        .... ..0. .... .... = Message is not truncated
        .... ...1 .... .... = Do query recursively
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        mail.monaco.net: type A, class inet
            Name: mail.monaco.net
            Type: Host address
            Class: inet

Et voilà… Si le système avait tenu compte des « additional records », la question n'aurait pas été posée.

 
Sélectionnez
Frame 6 (171 on wire, 171 captured)
...
    Protocol: UDP (0x11)
    Header checksum: 0x7fed (correct)
    Source: ns0.mrs.ftci.oleane.com (62.161.120.11)
    Destination: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
User Datagram Protocol
    Source port: domain (53)
    Destination port: 1038 (1038)
    Length: 137
    Checksum: 0xab21
Domain Name System (response)
    Transaction ID: 0xea26
    Flags: 0x8180 (Standard query response, No error)
        1... .... .... .... = Response
        .000 0... .... .... = Standard query
        .... .0.. .... .... = Server isn't an authority for domain
        .... ..0. .... .... = Message is not truncated
        .... ...1 .... .... = Do query recursively
        .... .... 1... .... = Server can do recursive queries
        .... .... .... 0000 = No error
    Questions: 1
    Answer RRs: 1
    Authority RRs: 2
    Additional RRs: 2
    Queries
        mail.monaco.net: type A, class inet
            Name: mail.monaco.net
            Type: Host address
            Class: inet
    Answers
        mail.monaco.net: type A, class inet, addr 194.79.150.9
...

Authoritative nameservers   # Plus la liste des DNS ayant autorité
        MONACO.NET: type NS, class inet, ns DNS1.MONACO.NET
...
        MONACO.NET: type NS, class inet, ns DNS2.MONACO.NET
...
    Additional records
        DNS1.MONACO.NET: type A, class inet, addr 194.79.150.9
...
        DNS2.MONACO.NET: type A, class inet, addr 194.79.150.2
...

Nous avons l'adresse de mail.monaco.net, mais nous la connaissions déjà…

 
Sélectionnez
Frame 7 (75 on wire, 75 captured)
...
    Protocol: UDP (0x11)
    Header checksum: 0x0a80 (correct)
    Source: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
    Destination: ns0.mrs.ftci.oleane.com (62.161.120.11)
User Datagram Protocol
    Source port: 1038 (1038)
    Destination port: domain (53)
    Length: 41
    Checksum: 0x6692
Domain Name System (query)
    Transaction ID: 0xea27
    Flags: 0x0100 (Standard query)
        0... .... .... .... = Query
        .000 0... .... .... = Standard query
        .... ..0. .... .... = Message is not truncated
        .... ...1 .... .... = Do query recursively
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        dns2.monaco.net: type A, class inet
            Name: dns2.monaco.net
            Type: Host address
            Class: inet

Encore une question futile…

 
Sélectionnez
Frame 8 (166 on wire, 166 captured)
...
    Protocol: UDP (0x11)
    Header checksum: 0x7fec (correct)
    Source: ns0.mrs.ftci.oleane.com (62.161.120.11)
    Destination: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
User Datagram Protocol
    Source port: domain (53)
    Destination port: 1038 (1038)
    Length: 132
    Checksum: 0xd9dd
Domain Name System (response)
    Transaction ID: 0xea27
    Flags: 0x8180 (Standard query response, No error)
        1... .... .... .... = Response
        .000 0... .... .... = Standard query
        .... .0.. .... .... = Server isn't an authority for domain
        .... ..0. .... .... = Message is not truncated
        .... ...1 .... .... = Do query recursively
        .... .... 1... .... = Server can do recursive queries
        .... .... .... 0000 = No error
    Questions: 1
    Answer RRs: 1
    Authority RRs: 2
    Additional RRs: 2
    Queries
        dns2.monaco.net: type A, class inet
            Name: dns2.monaco.net
            Type: Host address
            Class: inet
    Answers
        dns2.monaco.net: type A, class inet, addr 194.79.150.2
...
    Authoritative nameservers
        MONACO.NET: type NS, class inet, ns DNS1.MONACO.NET
...
        MONACO.NET: type NS, class inet, ns dns2.monaco.net
...
    Additional records
        DNS1.MONACO.NET: type A, class inet, addr 194.79.150.9
...
        dns2.monaco.net: type A, class inet, addr 194.79.150.2
...

Avec sa réponse pertinente, certes, mais qui ne nous apprend rien de nouveau.

À ce niveau, nous disposons :

  • des adresses des deux échangeurs de courrier pour le domaine « enprovence.com » (dont nous avons appris au passage qu'il était hébergé à Monaco) ;
  • des adresses des serveurs de noms pour ce domaine.

Normalement, nous devrions attaquer le transfert du message, en commençant par le MX qui a la meilleure préférence. S'il ne répond pas, nous passerons à l'autre.

3-2-3-2. La négociation SMTP
 
Sélectionnez
Frame 9 (74 on wire, 74 captured)
...
    Protocol: TCP (0x06)

# Notez que l'on est maintenant en mode connecté...

    Header checksum: 0x28de (correct)
    Source: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
    Destination: dns1.monaco.net (194.79.150.9)

# Ça ne vous choque pas ?
# On aurait pu s'attendre à ce que ce soit avec mail.monaco.net que le dialogue
# s'initie (c'est lui qui a la meilleure préférence)...
# Mais regardez attentivement les adresses IP, et vous verrez que, surprise:
# mail.monaco.net n'est autre que dns1.monaco.net

Transmission Control Protocol, Src Port: 1027, Dst Port: smtp(25), Seq:2161513038, Ack: 0
    Source port: 1027 (1027)
    Destination port: smtp (25)
    Sequence number: 2161513038
    Header length: 40 bytes
    Flags: 0x0002 (SYN)
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 32120
    Checksum: 0x8248
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        SACK permitted
        Time stamp: tsval 5420137, tsecr 0
        NOP
        Window scale: 0 bytes

Nous allons faire maintenant un petit bond en avant. L'analyse détaillée de ce qui suit s'apparente plus à une étude du protocole TCP, ce qui sort de notre sujet et qui est traité dans un autre article.

Juste pour constater que les e-mails circulent en clair sur le réseau et que n'importe quel « sniffer » peut les interpréter, je vous suggère d'aller directement voir la trame 45…

 
Sélectionnez
  Frame 45 (706 on wire, 706 captured)
  ...

      Protocol: TCP (0x06)
      Header checksum: 0x2654 (correct)
      Source: ca-ol-marseille-6-80.abo.w-n-doo.fr (62.161.101.80)
      Destination: dns1.monaco.net (194.79.150.9)
  Transmission Control Protocol, Src Port:1027, Dst Port:smtp(25, Seq:2161513153, Ack:2324999158
      Source port: 1027 (1027)
      Destination port: smtp (25)
      Sequence number: 2161513153
      Acknowledgement number: 2324999158
      Header length: 20 bytes
      Flags: 0x0018 (PSH, ACK)
          ..0. .... = Urgent: Not set
          ...1 .... = Acknowledgment: Set
          .... 1... = Push: Set
          .... .0.. = Reset: Not set
          .... ..0. = Syn: Not set
          .... ...0 = Fin: Not set
      Window size: 32120
      Checksum: 0xfb10
  Data (652 bytes)

     0  00d0 7972 5c00 0020 af07 1a3d 0800 4500   ..yr\.. ...=..E.
    10  02b4 15a6 4000 4006 2654 3ea1 6550 c24f   ....@.@.&T>.eP.O
    20  9609 0403 0019 80d6 12c1 8a94 abf6 5018   ..............P.
    30  7d78 fb10 0000 5265 6365 6976 6564 3a20   }x....Received:
    40  6672 6f6d 2063 6872 6973 2028 6368 7269   from chris (chri
    50  732e 6d61 6973 6f6e 2e6d 7273 205b 3139   s.maison.mrs [19
    60  322e 3136 382e 302e 3130 5d29 0d0a 0962   2.168.0.10])...b
    70  7920 6761 7465 7761 7931 2e6d 6169 736f   y gateway1.maiso
    80  6e2e 6d72 7320 2850 6f73 7466 6978 2920   n.mrs (Postfix)
    90  7769 7468 2053 4d54 5020 6964 2032 4131   with SMTP id 2A1
    a0  3832 3130 3239 410d 0a09 666f 7220 3c65   821029A...for <e
    b0  6d65 3133 4065 6e70 726f 7665 6e63 652e   me13@enprovence.
    c0  636f 6d3e 3b20 4d6f 6e2c 2032 3220 4d61   com>; Mon, 22 Ma
    d0  7920 3230 3030 2032 303a 3238 3a30 3520   y 2000 20:28:05
    e0  2b30 3230 3020 2843 4553 5429 0d0a 4d65   +0200 (CEST)..Me
    f0  7373 6167 652d 4944 3a20 3c30 3035 3430   ssage-ID: <00540
   100  3162 6663 3431 6224 3735 3132 6361 3330   1bfc41b$7512ca30
   110  2430 6130 3061 3863 3040 6d61 6973 6f6e   $0a00a8c0@maison
   120  2e6d 7273 3e0d 0a46 726f 6d3a 2022 4368   .mrs>..From: "Ch
   130  7269 7374 6961 6e20 4341 4c45 4341 2220   ristian CALECA"
   140  3c63 6872 6973 7469 616e 2e63 616c 6563   <christian.calec
   150  6140 7761 6e61 646f 6f2e 6672 3e0d 0a54   a@w-n-doo.fr>..T
   160  6f3a 203c 656d 6531 3340 656e 7072 6f76   o: <eme13@enprov
   170  656e 6365 2e63 6f6d 3e0d 0a53 7562 6a65   ence.com>..Subje
   180  6374 3a20 7465 7374 2053 4d54 500d 0a44   ct: test SMTP..D
   190  6174 653a 204d 6f6e 2c20 3232 204d 6179   ate: Mon, 22 May
   1a0  2032 3030 3020 3230 3a32 373a 3539 202b    2000 20:27:59 +
   1b0  3032 3030 0d0a 4d49 4d45 2d56 6572 7369   0200..MIME-Versi
   1c0  6f6e 3a20 312e 300d 0a43 6f6e 7465 6e74   on: 1.0..Content
   1d0  2d54 7970 653a 2074 6578 742f 706c 6169   -Type: text/plai
   1e0  6e3b 0d0a 0963 6861 7273 6574 3d22 6973   n;...charset="is
   1f0  6f2d 3838 3539 2d31 220d 0a43 6f6e 7465   o-8859-1"..Conte
   200  6e74 2d54 7261 6e73 6665 722d 456e 636f   nt-Transfer-Enco
   210  6469 6e67 3a20 3762 6974 0d0a 582d 5072   ding: 7bit..X-Pr
   220  696f 7269 7479 3a20 330d 0a58 2d4d 534d   iority: 3..X-MSM
   230  6169 6c2d 5072 696f 7269 7479 3a20 4e6f   ail-Priority: No
   240  726d 616c 0d0a 582d 4d61 696c 6572 3a20   rmal..X-Mailer:
   250  4d69 6372 6f73 6f66 7420 4f75 746c 6f6f   Microsoft Outloo
   260  6b20 4578 7072 6573 7320 352e 3030 2e32   k Express 5.00.2
   270  3931 392e 3636 3030 0d0a 582d 4d69 6d65   919.6600..X-Mime
   280  4f4c 453a 2050 726f 6475 6365 6420 4279   OLE: Produced By
   290  204d 6963 726f 736f 6674 204d 696d 654f    Microsoft MimeO
   2a0  4c45 2056 352e 3030 2e32 3931 392e 3636   LE V5.00.2919.66
   2b0  3030 0d0a 0d0a 736e 6966 660d 0a0d 0a2e   00....sniff.....
   2c0  0d0a                                      ..

Et voilà… Sans précautions particulières, les messages circulent en clair sur le réseau au moment de leur émission vers leur(s) destinataire(s). Il vaut mieux le savoir. Nous verrons également dans le protocole POP3 que le message circule également en clair, avec en plus, le mot de passe du client, au moment de sa lecture.

Pour finir, voici l'en-tête du message tel qu'il est déposé dans la boîte aux lettres eme13@enprovence.com. Vous pouvez clairement y voir le chemin emprunté par le message. Comme chaque MTA complète l'en-tête en y insérant des lignes à son début, il faudra lire de bas en haut.

 
Sélectionnez
Return-Path: <christian.caleca@w-n-doo.fr>

# 2°/ Mon SMTP, côté Internet, envoie le message au SMTP du destinataire

Received: from gateway1.maison.mrs
          (IDENT:postfix@ca-ol-marseille-6-80.abo.w-n-doo.fr [62.161.101.80])
        by mail.monaco.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id UAA24841
        for <eme13@enprovence.com>; Mon, 22 May 2000 20:28:13 +0200

# 1°/ Mon poste de travail envoie le message sur mon SMTP, côté réseau local

Received: from chris (chris.maison.mrs [192.168.0.10])
        by gateway1.maison.mrs (Postfix) with SMTP id 2A1821029A
        for <eme13@enprovence.com>; Mon, 22 May 2000 20:28:05 +0200 (CEST)

Message-ID: <005401bfc41b$7512ca30$0a00a8c0@maison.mrs>
From: "Christian CALECA" <christian.caleca@w-n-doo.fr>
To: <eme13@enprovence.com>
Subject: test SMTP
Date: Mon, 22 May 2000 20:27:59 +0200
MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Status:
sniff

3-3. Pour les plus démunis… Telnet

3-3-1. Envoi du message

Pour ceux qui aiment bien comprendre, envoyons maintenant un message avec TELNET. La manip est faite à partir du poste Linux, parce que le client Telnet est tout de même plus efficace que celui fourni par Windows, mais c'est possible aussi depuis un poste Windows. Comme nous savons maintenant que le MX de enprovence.com n'est autre que dns1.monaco.net, nous allons nous adresser directement à lui.

Image non disponible
  • La ligne 1 démarre le client Telnet sur le serveur de messagerie dont on a trouvé le nom grâce au « sniff », sur le port 25 (port « officiel » d'écoute des MTA). On aurait pu le trouver également avec NSLOOKUP.
  • Les lignes 2, 3 et 4 indiquent que la connexion Telnet est correcte.
  • La ligne 5 (220 mail.monaco.net) est un message de bienvenue du serveur.
  • La ligne 6 (MAIL FROM) est la première commande que nous entrons. Elle donne l'adresse de l'émetteur du message. Suivant les règles de sécurité du MTA, cette adresse pourra ne pas être acceptée.
  • La ligne 7 (250 …) indique que l'émetteur est accepté.
  • La ligne 8 (RCPT TO:) est la deuxième commande. Elle donne l'adresse du destinataire du message.
  • La ligne 9 (250…) indique que le destinataire est accepté.
  • La ligne 10 (DATA) est encore une commande, elle indique que nous allons transmettre le message proprement dit.
  • La ligne 11 (354…) est une réponse indiquant comment il faut envoyer le texte du message.
  • La ligne 12 constitue le texte du message envoyé.
  • La ligne 13 (.) indique la fin du message.
  • La ligne 14 (250…) indique que le message est accepté.
  • La ligne 15 (QUIT) est une commande pour indiquer au MTA que l'on a fini.
  • La ligne 16 (221) nous indique que le MTA a fermé la connexion.

Notez que nous n'avons pas ici respecté totalement le protocole, principalement en omettant la commande HELO ou mieux : EHLO. Certains MTA n'aiment pas la grossièreté.

3-3-2. Analyse du résultat

Voici le texte complet (en-tête compris) du message tel que le destinataire le reçoit :

 
Sélectionnez
Return-Path: <christian.caleca@w-n-doo.fr>

# C'est l'adresse de l'émetteur envoyée avec la commande MAIL FROM:

Received: from ca-ol-marseille-15-205.abo.w-n-doo.fr
          (IDENT:root@ca-ol-marseille-15-205.abo.w-n-doo.fr [213.56.62.205])

# C'est la machine avec laquelle le message a été envoyé

by mail.monaco.net (Pro-8.9.3/Pro-8.9.3) with SMTP id TAA08106
for eme13@enprovence.com; Thu, 25 May 2000 19:43:56 +0200

# C'est l'adresse du destinataire envoyée avec la commande RCPT TO:

Date: Thu, 25 May 2000 19:43:56 +0200
From: christian.caleca@w-n-doo.fr
Message-Id: <200005251743.TAA08106@mail.monaco.net>
X-Authentication-Warning: mail.monaco.net:
IDENT:root@ca-ol-marseille-15-205.abo.w-n-doo.fr [213.56.62.205]
      didn't use HELO protocol

# Ici, c'est une info ajoutée par le MTA mail.monaco.net: Il prévient qu'il y a
# quelqu'un de grossier dans la chaîne
# d'envoi du message, il n'a pas utilisé le protocole HELO.

Status:

le texte du message

3-3-3. Quelques remarques

  • HELO, la commande manquante qui a généré le « X-Authentification-Warning », est prévue dans le protocole. Nous aurions pu l'envoyer au début du dialogue. L'administrateur de mail.monaco.net aurait pu se vexer et rejeter le message.
  • L'en-tête est très incomplet. À titre de comparaison, vous avez plus bas le même message envoyé « normalement » avec Outlook Express, par l'intermédiaire du MTA de Wanadoo (smtp.wanadoo.fr). C'est tout simplement parce que l'en-tête est construit au cours du voyage par :le MDA peut aussi ajouter ses commentaires.
    1. le MUA émetteur ;
    2. les MTA qui font transiter le message ;
    3. le MTA destinataire ;
    4. le MDA peut aussi ajouter ses commentaires.

Nous aurions pu les introduire nous-même dans la petite manip vue plus haut. Certains MTA essayent plus ou moins de reconstruire les champs manquants, d'autres non.

Au passage, il faut noter que l'en-tête n'est donc pas un élément nécessaire au transport. Seuls les contenus de MAIL FROM: et RCPT TO: sont indispensables au transport. Seul le contenu de EHLO est requis par le protocole, même si certains MTA ne le considèrent pas comme indispensable.

Autrement dit, le contenu de l'en-tête, vis-à-vis de SMTP n'est que du contenu, d'ailleurs transmis dans la commande DATA au même titre que le « contenu » du message. La conséquence est qu'il est parfaitement possible de forger complètement une partie de l'en-tête, de la façon la plus fantaisiste qui soit. Qui n'a jamais reçu de message envoyé par lui-même « à l'insu de son plein gré » ?

3-4. Conclusions

Le processus d'envoi d'un e-mail  par SMTP peut donc se découper en deux phases bien distinctes :

  • une recherche DNS sur les MX (Mail Exchanger) concernés par le domaine du destinataire (enprovence.com dans l'exemple) ;
  • un dialogue entre le MTA trouvé et le client, suivant le protocole SMTP pour transférer le message.
    Il n'est pas obligatoire que le message transite directement de votre serveur SMTP à celui du destinataire. Dans notre manipulation avec Telnet, nous avons contacté directement le MX du destinataire, lorsque nous envoyons le même message avec un MUA, il sera plus long, comme le montrent les exemples suivants.

3-4-1. Envoyé par smtp.wanadoo.fr

 
Sélectionnez
      Return-Path: <christian.caleca@w-n-doo.fr>

#     Dernier MTA, celui qui gère la BAL du destinataire.

      Received: from camelia.wanadoo.fr (smtp-rt-10.wanadoo.fr [193.252.19.59])
                by mail.monaco.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA16616
                for <eme13@enprovence.com>; Sat, 27 May 2000 14:35:27 +0200


#     Second MTA, toujours chez Wanadoo. Le premier n'est donc qu'un agent de relais

      Received: from amyris.wanadoo.fr (193.252.19.150)
                by camelia.wanadoo.fr; 27 May 2000 14:08:11 +0200

#     Premier MTA, celui sur lequel le MUA poste le message

      Received: from chris (62.161.101.80)
                by amyris.wanadoo.fr; 27 May 2000 14:07:57 +0200
      Message-ID: <00a001bfc7d4$2cf01930$0a00a8c0@maison.mrs>
      From: "Christian CALECA" <christian.caleca@w-n-doo.fr>
      To: <eme13@enprovence.com>
      Subject:
      Date: Sat, 27 May 2000 14:07:48 +0200
      MIME-Version: 1.0
      Content-Type: text/plain;
        charset="iso-8859-1"
      Content-Transfer-Encoding: 7bit
      X-Priority: 3
      X-MSMail-Priority: Normal
      X-Mailer: Microsoft Outlook Express 5.00.2919.6600
      X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
      Status:  O
     
      Le texte du message

Le chemin ici est le suivant :

  • amyris.wanadoo.fr ;
  • camelia.wanadoo.fr ;
  • mail.monaco.net.

Notez que n'apparait pas smtp.wanadoo.fr, du moins sous ce nom-là.

3-4-2. Envoyé maintenant avec notre MTA personnel sur Gateway1

 
Sélectionnez
      Return-Path: <christian.caleca@w-n-doo.fr>
      Received: from gateway1.maison.mrs
                (IDENT:postfix@ca-ol-marseille-6-80.abo.wanadoo.fr [62.161.101.80])
                by mail.monaco.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA17676
                for <eme13@enprovence.com>; Sat, 27 May 2000 15:29:23 +0200
      Received: from chris (chris.maison.mrs [192.168.0.10])
                by gateway1.maison.mrs (Postfix) with SMTP id A38181105F
                for <eme13@enprovence.com>; Sat, 27 May 2000 15:29:15 +0200 (CEST)
      Message-ID: <000901bfc7df$884e4ad0$0a00a8c0@maison.mrs>
      From: "Christian CALECA" <christian.caleca@w-n-doo.fr>
      To: <eme13@enprovence.com>
      Subject:
      Date: Sat, 27 May 2000 15:29:06 +0200
      MIME-Version: 1.0
      Content-Type: text/plain;
        charset="iso-8859-1"
      Content-Transfer-Encoding: 7bit
      X-Priority: 3
      X-MSMail-Priority: Normal
      X-Mailer: Microsoft Outlook Express 5.00.2919.6600
      X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
      Status: RO
     
      Texte du message.

Le chemin ici est le suivant :

  • gateway1.maison.mrs (notre MTA Postfix) ;
  • mail.monaco.net.

Ici, le message a directement été transmis depuis notre MTA vers celui du destinataire.

Ceci veut dire qu'il est parfaitement possible sur de grosses architectures, de créer des MTA qui ne font que relayer du courrier d'un point à un autre, sans gérer de destinataires locaux (pas de MDA).

4. Fiabilité, sécurité

SMTP est un très vieux protocole. C'est le RFC 821 qui en définit les bases, en 1982. À cette date, les connexions étaient rares, peu fiables et le souci premier était d'assurer un transport sans pertes. Depuis, les conditions ont bien changé et la sécurité, qui n'avait pas été prise en compte, devient un souci majeur.

ESMTP a ajouté quelques fonctionnalités importantes, comme le support du codage sur 8 bits, les types MIME et aussi la possibilité de chiffrer la connexion.

4-1. Extended SMTP

Aujourd'hui, tous les serveurs SMTP sont en réalité des serveurs ESMTP. Pour le vérifier, utilisons la commande EHLO plutôt que HELO :

 
Sélectionnez
$ telnet cyrus.bts.eme 25
Trying 192.168.10.7...
Connected to cyrus.bts.eme.
Escape character is '^]'.
220 cyrus.nain-t.net ESMTP Experimental
HELO machin.nain-t.net
250 cyrus.nain-t.net
quit
221 2.0.0 Bye

Pas grand-chose comme informations, si ce n'est que nous disposons d'un serveur ESMTP (et encore, cette information étant dans la bannière, elle n'est pas d'une grande fiabilité).

 
Sélectionnez
~$ telnet cyrus.bts.eme 25
Trying 192.168.10.7...
Connected to cyrus.bts.eme.
Escape character is '^]'.
220 cyrus.nain-t.net ESMTP Experimental
EHLO machin.nain-t.net
250-cyrus.nain-t.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye

La commande EHLO nous permet d'obtenir quelques informations sur la capacité du serveur. Parmi les plus intéressantes, nous constatons que Postfix sait gérer le « 8 bits MIME » (le contraire serait fâcheux, mais ici, nous en avons la confirmation) et accepte la commande starttls.

4-2. Chiffrement

Les évolutions du protocole SMTP permettent de chiffrer la connexion de deux manières légèrement différentes. SMTPS se contente de passer le dialogue SMTP dans une connexion SSL. L'autre méthode, plus actuelle, consiste à invoquer la commande STARTTLS.

Si la mise en œuvre d'une commande STARTTLS entre un MUA et un serveur SMTP est assez simple, elle devient plus compliquée entre deux serveurs SMTP, du fait que les certificats des serveurs doivent être signés par une racine de confiance acceptée par le partenaire. Aussi, il est rare qu'un chiffrement ait lieu entre deux MTA. Ce qui veut dire que votre message circule en clair sur l'Internet.

STARTTLS comme SSL offrent tout de même l'avantage pour le client de masquer son login, lorsqu'il a besoin de le transmettre (accès IMAP, POP3 ou même SMTP si le MTA requiert une authentification du client).

5. Remerciements Developpez

Vous pouvez retrouver l'article original ici : L'Internet Rapide et Permanent. Christian Caleca a aimablement autorisé l'équipe « Réseaux » de Developpez.com à reprendre son article. Retrouvez tous les articles de Christian Caleca sur cette page.

Nos remerciements à Claude LELOUP pour la relecture orthographique de cet article.

N'hésitez pas à commenter cet article ! Commentez Donner une note à l´article (5)

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2009 Christian Caleca. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.