1
Services Réseaux – TP3
BONY Simon
2 décembre 2011
2
Table des matières
Introduction ... 3
A Installation de Postfix ... 4
A.1Installation du paquetage ... 4
A.2Etude de la configuration ... 5
B Test de la configuration du serveur SMTP ... 7
B.1Préparations ... 7
B.2Etude du fonctionnement ... 8
B.3Les logs ... 10
C Etude du protocole SMTP ... 11
D Installation du serveur POP3 ... 13
E Etude du protocole POP ... 15
E.1La gestion des mails ... 15
E.2Les commandes ... 16
F Etude du protocole IMAP ... 20
F.1 Installation ... 20
F.2 Les commandes ... 21
G Analyse des messages ... 25
G.1SMTP ... 25
G.2POP ... 26
G.3IMAP ... 27
G.4Avantages d’IMAP sur POP3 ... 28
G.5SMTP-AUTH ... 29
Conclusion ... 31
3
Introduction
L’objectif de ce TP est d’obtenir les connaissances ainsi que l’expérience de la mise en service d’un serveur Mail. Nous utiliserons notamment Postfix dans ce rôle.
Nous étudierons plus en profondeur l’utilité et le fonctionnement des trois protocoles SMTP, POP3 et IMAP qui jouent des rôles clés dans la gestion des mails.
4
A Installation de Postfix
Postfix est un gestionnaire de messagerie présentant plusieurs avantages : c’est un logiciel libre ne nécessitant donc pas d’investissement, il est simple à configurer et peu gourmand en ressource et il a été conçu pour une sécurité optimale. C’est une messagerie au standard SMTP ce qui nous permettra d’étudier ce protocole.
A.1 Installation du paquetage
Commençons par installer Postfix sur notre machine. Nous utilisons pour cela la commande aptitude install postfix. Lors de l’installation, nous précisons l’installation « site internet » et nous gardons les configurations par défaut.
Installation du paquetage postfix
5
A.2 Etude de la configuration
Etudions les dernières lignes de l’installation du paquetage postfix.
Extrait des lignes d’installation de postfix
Nous apprenons donc que /etc/postfix/main.cf est le fichier de configuration du programme, postconf est la commande permettant de consulter les configurations actuelles et /etc/init.d/postfix reload est la commande permettant de relancer Postfix.
De plus, nous pouvons voir l’initialisation de certaines variables que nous retrouvons lors de l’utilisation de postconf ou en ouvrant main.cf.
mydestination a pour valeurs « localhost.localdomain », « pccop0b002b- 15.tpreseau.umlv », « localhost.tpreseau.umlv » et « localhost ». C’est la liste des domaines desservis par Postfix.
mynetworks a pour valeur « 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 ».
C’est la liste des clients SMTP de confiance. C’est donc via ces clients que nous enverrons nos mails.
inet_interfaces a pour valeur « all ». C’est la liste des adresses des interfaces réseaux desservis. Ce sont donc les serveurs par lesquels nous attendons des mails. Préciser all indique qu’elles sont toutes desservis.
relayhost n’a pas de valeur. Sachant qu’elle est la destination suivante dans le transfert des mails non locaux, on en déduit que ce service n’est pas configuré par défaut.
6
Nous observons aussi la création de deux variables, alias maps et alias database, ainsi que du fichier /etc/aliases.
En regardant le contenu du fichier main.cf, nous trouvons les valeurs des deux variables : « alias_maps = hash:/etc/aliases » et « alias_database = hash:/etc/aliases ».
alias database contient les emplacements des bases de données des alias locaux tandis que alias maps contient la base de donnée par défaut.
Les alias sont donc contenus dans le fichier /etc/aliases. Celui-ci se présente de cette façon :
# /etc/aliases
mailer-daemon: postmaster postmaster: root
nobody: root hostmaster: root usenet: root news: root webmaster: root www: root
ftp: root abuse: root noc: root security: root
Contenu du fichier /etc/aliases
Nous remarquons des liens entre un utilisateur (root) et des noms. On en déduit donc qu’un alias est un moyen de rediriger les mails entrant pour un utilisateur vers un autre utilisateur. Ils peuvent aussi permettre de donner plusieurs noms à une seule adresse.
Nous pouvons maintenant lancer le serveur Postfix avec la commande /etc/init.d/postfix load et vérifier son lancement avec la commande ps.
Commandes /etc/init.d/postfix load et ps –ax|grep postfix
Avec ces manipulations, nous possédons un serveur Postfix opérationnel et nous en comprenons les grandes lignes de configuration.
7
B Test de la configuration du serveur SMTP
Nous allons ici étudier la gestion des mails par Postfix utilisant le protocole SMTP (Simple Mail Transfer Protocol).
Nous installons donc le paquetage mail avec la commande aptitude install mailx.
B.1 Préparations
Nous allons tester l’envoi et la réception de mail entre un utilisateur 1 et un utilisateur 2. Pour cela, nous devons commencer par les créer avec useradd –m puis leur attribuer un mot de passe avec passwd.
Création d’user1 et d’user2 avec mot de passe
Nous pouvons désormais tester l’envoi d’un mail. A l’aide de la commande mail, nous allons envoyer un mail à user2 depuis user1.
Nous ouvrons donc un terminal au nom d’user1 et nous lançons la commande mail user2@localhost.localdomain. Il nous suffit alors de renseigner le sujet puis le corps du mail. On arrête la saisie avec ctrl+d ou un retour à la ligne, un point et un retour à la ligne.
Envoi d’un mail à user2 par user1
Ouvrons maintenant un terminal au nom d’user2 et ouvrons notre boite mail avec la commande mail. On nous indique alors la présence d’un nouveau mail avec quelques données. On précise alors que l’on souhaite l’ouvrir en entrant simplement son numéro (ici 1).
8
Réception du mail par user2
Nous pouvons donc bel et bien envoyer et recevoir des mails.
B.2 Etude du fonctionnement
Nous nous concentrerons ici sur la réception par user2 et pour commencer en nous demandant comment le serveur a t’il su que le mail était nouveau et qu’en a-t-il fait ?
En vérifiant les différents répertoires de Postfix et de user2, nous avons pu comprendre le fonctionnement. La gestion de ces mails se fait par deux fichiers : /var/mail/user2 et /home/user2/mbox.
Capture d’écran : les fichiers user2 et mbox
9
Nous remarquons qu’avant de lire le mail reçu, le fichier user2 n’est pas vide. D’ailleurs, en l’ouvrant, nous y constatons la présence du mail.
Cependant, après l’avoir lu, le fichier user2 est vide. Nous en déduisons donc que le serveur enregistre dans un fichier au nom de l’utilisateur concerné tous les nouveaux mails qui lui sont destinés. Il sait donc s’il existe des nouveaux mails pour user2 en étudiant le contenu du fichier user2.
De plus, le fichier user2 étant vidé, on en déduit que le mail a été effacé du serveur.
Pourtant, le mail peut toujours être consulté. On remarque alors que le fichier mbox du répertoire utilisateur d’user2 n’est plus vide comme à l’origine : il contient le mail.
Etudions maintenant l’en-tête du mail :
1.From user1@localhost.localdomain Fri Dec 2 09:13:52 2011 2.Return-Path: <user1@localhost.localdomain>
3.X-Original-To: user2@localhost.localdomain 4.Delivered-To: user2@localhost.localdomain
5.Received: by pccop0b002b-15.tpreseau.umlv (Postfix, from userid 1001) id 891FB45A57; Fri, 2 Dec 2011 09:13:52 +0100 (CET)
6.To: user2@localhost.localdomain 7.Subject: Test SMTP
8.Message-Id: <20111202081352.891FB45A57@pccop0b002b-15.tpreseau.umlv>
9.Date: Fri, 2 Dec 2011 09:13:52 +0100 (CET) 10.From: user1@localhost.localdomain
11.Status: RO
En-tête du mail Expliquons chacun de ces champs :
1. Emetteur du mail et la date et l’heure d’envoi 2. Adresse à utiliser pour répondre au mail 3. Récepteur du mail
4. Récepteur réel du mail si alias
5. Informations sur le récepteur : FQDN, type de serveur, ID, date…
6. Destinataire du mail indiqué par l’émetteur 7. Sujet du mail
8. Id du mail : numéro unique + machine de l’émetteur 9. Date d’envoi
10. Emetteur du mail indiqué par l’émetteur.
11. Statut du mail
10
Nous remarquons donc la présence d’un grand nombre d’information.
Pourtant, le protocole utilisé ici pour relever le courrier est le protocole SMTP sachant que nous n’avons pas eu à nous identifier. Ce protocole sans authentification ne protège en rien toutes ces données.
B.3 Les logs
Toutes les actions du serveur sont consignées dans des fichiers de log situés dans le dossier /var/log. Trois fichiers enregistrent les informations liées au serveur : mail.err qui enregistre les erreurs, mail.warn qui enregistre les avertissements et mail.info qui enregistre les informations.
Ici, mail.err et mail warn sont vides.
Informations sur les fichiers mail.err et mail.warn
Quant à lui, mail.info contient les lignes suivantes :
Dec 2 08:43:02 pccop0b002b-15 postfix/master[9303]: daemon started -- version 2.5.5, configuration /etc/postfix
Dec 2 09:13:52 pccop0b002b-15 postfix/pickup[9309]: 891FB45A57: uid=1001 from=<user1>
Dec 2 09:13:52 pccop0b002b-15 postfix/cleanup[9491]: 891FB45A57: message- id=<20111202081352.891FB45A57@pccop0b002b-15.tpreseau.umlv>
Dec 2 09:13:52 pccop0b002b-15 postfix/qmgr[9310]: 891FB45A57:
from=<user1@localhost.localdomain>, size=413, nrcpt=1 (queue active) Dec 2 09:13:52 pccop0b002b-15 postfix/local[9493]: 891FB45A57:
to=<user2@localhost.localdomain>, relay=local, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Dec 2 09:13:52 pccop0b002b-15 postfix/qmgr[9310]: 891FB45A57: removed Contenu de mail.info
On peut ainsi retracer toutes les étapes de l’envoi du mail : la création du message d’ID 891FB45A57, sa préparation, sa finalisation, son envoi et sa suppression du serveur de l’émetteur.
Nous avons pu comprendre grâce à ces manipulations les actions effectuées par le serveur pour gérer l’envoi et la réception de mail à l’aide du protocole SMTP.
Etudions maintenant le dît protocole.
11
C Etude du protocole SMTP
La gestion du protocole SMTP était réalisée automatiquement par Postfix.
Afin de mieux étudier le protocole, nous utiliserons donc netcat afin de générer nos propres requêtes.
Comme nous l’avons vu, le protocole SMTP n’est pas adapté à la relève de courrier. Par contre, elle est tout indiquée dans l’émission de ceux-ci.
Nous allons donc étudier ce protocole lors de l’envoi d’un mail d’user1 à user2.
Depuis un terminal au nom d’user1, nous nous connectons au serveur local sur son port SMTP (le port 25) avec la commande nc localhost 25.
Nous effectuons ensuite l’envoi d’un mail avec les commandes suivantes :
Envoi d’un mail via netcat
Nous commençons par identifier notre machine avec la requête EHLO localhost.localdomain.
Par cette commande, nous demandons l’attention du serveur ce à quoi le serveur répond par le code 250 signifiant l’accord de celui-ci.
12
Nous demandons alors à créer un mail en notre nom par la commande MAIL from : <user1@localhost.localdomain>. Ici aussi le serveur nous donne son accord.
Nous précisons alors le destinataire avec la commande RCPT to :
<user2@localhost.localdomain>. Le serveur continue de confirmer.
Nous précisons alors le corps du message avec DATA. Nous précisons avec subject : que cette ligne est le sujet du message. Nous renseignons le corps du message et nous quittons de la même manière que sous Postfix. Le serveur nous confirme alors la réception ainsi que l’envoi du message.
Dès lors, nous fermons la connexion avec la commande QUIT, le serveur nous retournant le code 221 signifiant que le serveur ferme la
transmission.
Depuis un terminal sous user2, nous vérifions que le mail a bel et bien été envoyé. Par la commande mail, nous confirmons ainsi l’arrivée du mail et donc le succès de l’envoi.
Réception du mail par user2
Nous avons donc pu envoyer par lignes de commandes un mail à destination d’user2 tout en observant la communication entre le MUA (bash + netcat) et le MTA (Postfix), ce dernier étant renseigné lors du lancement de netcat.
Toutes ces manipulations nous ont donc permis de mieux comprendre le fonctionnement du protocole SMTP.
13
D Installation du serveur POP3
Nous avons précédemment étudié le protocole SMTP, particulièrement adapté à l’envoi de mail mais peu indiqué dans la relève de courrier. C’est donc dans l’optique d’étudier un protocole adapté à la relève de courrier que nous nous intéressons au protocole POP3 (Post Office Protocol Version 3).
Nous allons donc nous concentrer sur l’installation d’un serveur POP3, ce qui nous permettra d’en apprendre plus sur son fonctionnement général.
Nous commençons par l’installation du paquetage courier-pop.
Installation du paquetage courier-pop
L’installation de ce paquetage entraine le lancement du serveur. Nous pouvons donc confirmer la bonne installation en vérifiant le lancement du deamon POP3.
Pour cela, nous utilisons la commande netstat –at qui permet de visualiser les ports ouverts.
Extrait de la commande netstat -at
14
Nous pouvons donc affirmer la bonne installation du paquetage.
L’utilisation de POP3 nécessite d’enregistrer ses mails sur la machine.
Nous étudierons cela dans la prochaine partie. Néanmoins, l’installation du serveur nécessite donc la mise en place d’un répertoire de stockage.
Nous ajoutons donc la variable home_mailbox= Maildir/ dans le fichier de configuration de Postfix main.cf.
Cette ligne indique au serveur la présence d’un répertoire nommé Maildir dans les répertoires utilisateurs où les mails doivent être stockés.
Nous créons donc ce répertoire dans les répertoires utilisateurs d’user1 et d’user2 avec la commande maildirmake Maildir.
RépertoireMaildir
Nous sommes désormais en possession d’un serveur POP3 opérationnel.
15
E Etude du protocole POP
Nous allons maintenant étudier le protocole POP3 pour la relève de courrier. Nous envoyons donc pour commencer un mail d’user1 à user2.
Envoi d’un mail d’user1 à user2
E.1 La gestion des mails
Nous pouvons alors retrouver le mail dans le répertoire new du répertoire Maildir d’user2.
Le serveur l’a immédiatement placé dans ce répertoire sans passer par le répertoire /var/mail car nous avons placé la variable home_mailbox dans le fichier de configuration, indiquant ainsi où transférer les mails entrants pour un utilisateur.
Commande ls sur Maildir/new et affichage du message avec la commande cat
16
E.2 Les commandes
Connectons-nous maintenant au serveur POP à l’aide de netcat avec la commande nc localhost 110 (110 étant le port destiné au protocole POP).
Nous allons consulter nos mails, notamment le mail précédemment envoyé.
Consultation des mails d’user2 via netcat en POP3
17
La première étape consiste à s’authentifier. Nous rappelons que le
protocole POP3 est un système de relève de courrier sécurisé nécessitant une authentification.
Nous précisons donc qui nous somme avec la commande USER user2. Le serveur nous précise alors qu’il nous connaît mais que nous devons lui fournir un mot de passe.
Nous lui transmettons celui-ci avec la commande PASS user2 (ici, user2 est le mot de passe). Le serveur nous indique alors qu’il est correct et que nous somme logué.
Nous demandons alors au serveur de lister les mails présents avec la commande STAT. Le serveur nous indique qu’il y a un mail d’identifiant 1 et de 516 octets.
Nous demandons alors les informations que nous possédons sur le mail 1 avec la commande LIST 1. Le serveur nous donne alors les mêmes informations, nous n’avons donc pas plus d’information.
Nous allons donc en obtenir plus avec la commande TOP 1 0 qui nous retourne l’en-tête du mail 1 suivit de 0 ligne du corps.
Le serveur nous précise alors qu’il nous retourne l’en-tête suivit de celui-ci contenant des informations qui nous intéressent tels que l’émetteur du mail ou la date.
Nous consultons finalement le mail avec la commande RETR 1. Le serveur nous le fournit donc en précisant qu’il nous retourne 516 octets.
Une fois lu, le mail est alors transféré du répertoire Maildir/new au répertoire Maildir/cur.
18
Présence du mail dans Maildir/cur
Il n’est donc pas supprimé du serveur et peut toujours être consulté.
Sa suppression peut être cependant demandée avec la commande DELE.
Suppression du mail 1
Nous pouvons d’ailleurs vérifier le contenu du répertoire Maildir/cur pour constater qu’il est vide.
Contenu du répertoire Maildir/cur
Lorsque notre boite possède un important nombre de mail, la gestion par le numéro du message devient complexe, surtout lorsqu’un mail est supprimé et que tous les numéros changent.
Il est donc utile d’utiliser l’UID du mail (Unique IDentifier) qui est un
identifiant unique et permanent. Nous pouvons l’obtenir avec la commande
19
UIDL. Celle-ci liste tous les UIDs des messages présents. Préciser UIDL 1 nous fournira l’UID du mail 1.
Commande UIDL
Nous savons maintenant comment gérer nos mails à l’aide du protocole POP3. Cela nous à permis de mieux comprendre le fonctionnement de ce protocole et d’en dégager l’intérêt pour la relève de courrier. Cependant, l’enregistrement des mails sur la machine, au-delà du problème de place, entraine un transfert de toutes les données du serveur à la machine.
Nous allons donc étudier un autre protocole, le protocole IMAP.
20
F Etude du protocole IMAP
Le protocole IMAP (Internet Message Access Protocol) est un autre protocole de relève de courrier qui cependant laisse les messages sur le serveur de courrier, ne faisant que les gérer et les consulter à distance.
Cela évite donc d’avoir à charger les mails sur sa machine.
F.1 Installation
Pour étudier ce protocole, nous devons installer le paquetage associé à IMAP. Ce paquetage est courier-imap. Nous l’installons donc avec la commande aptitude install courrier-imap.
Une fois l’installation terminée, tout comme pour le protocole POP3, le serveur est immédiatement lancé. Nous pouvons donc vérifier la bonne installation en recherchant le daemon IMAP avec la commande netstat –at.
Extrait de la commande netstat -at
Nous sommes donc en possession d’un serveur IMAP opérationnel.
21
F.2 Les commandes
Nous allons maintenant effectuer les équivalents des commandes POP3 de la partie E sur le serveur IMAP par l’intermédiaire de netcat. Il nous faut donc commencer par envoyer un mail d’user1 à user2.
Envoi d’un mail d’user1 à user2
Nous nous connectons alors au serveur IMAP à l’aide de la commande netcat localhost 143 (143 étant le port du protocole IMAP).
Nous effectuons alors les commandes suivantes : user2@pccop0b002b-15:~/Maildir/new$ nc localhost 143
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2008 Double
Precision, Inc. See COPYING for distribution information.
id1 LOGIN user2 user2 id1 OK LOGIN Ok.
id2 SELECT INBOX
* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)]
Limited
* 3 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1322822006] Ok
* OK [MYRIGHTS "acdilrsw"] ACL id2 OK [READ-WRITE] Ok
id3 FETCH 3:* RFC822.SIZE
* 3 FETCH (RFC822.SIZE 518) id3 OK FETCH completed.
Consultation des mails d’user2 via netcat en IMAP- Partie 1
22 id4 UID FETCH 3 BODY[HEADER]
* 3 FETCH (UID 3 BODY[HEADER] {462}
Return-Path: <user1@localhost.localdomain>
X-Original-To: user2@localhost.localdomain Delivered-To: user2@localhost.localdomain
Received: by pccop0b002b-15.tpreseau.umlv (Postfix, from userid 1001) id 68F7645802; Fri, 2 Dec 2011 11:31:16 +0100 (CET)
To: user2@localhost.localdomain Subject: Test IMAP
Message-Id: <20111202103116.68F7645802@pccop0b002b-15.tpreseau.umlv>
Date: Fri, 2 Dec 2011 11:31:16 +0100 (CET) From: user1@localhost.localdomain
)
id4 OK FETCH completed.
id5 UID FETCH 3 BODY[]
* 3 FETCH (UID 3 BODY[] {518}
Return-Path: <user1@localhost.localdomain>
X-Original-To: user2@localhost.localdomain Delivered-To: user2@localhost.localdomain
Received: by pccop0b002b-15.tpreseau.umlv (Postfix, from userid 1001) id 68F7645802; Fri, 2 Dec 2011 11:31:16 +0100 (CET)
To: user2@localhost.localdomain Subject: Test IMAP
Message-Id: <20111202103116.68F7645802@pccop0b002b-15.tpreseau.umlv>
Date: Fri, 2 Dec 2011 11:31:16 +0100 (CET) From: user1@localhost.localdomain
Ce message a pour objectif de tester le protocole IMAP )
id5 OK FETCH completed.
id6 LOGOUT
* BYE Courier-IMAP server shutting down id6 OK LOGOUT completed
Consultation des mails d’user2 via netcat en POP3 – Partie 2
Pour commencer, toute requête doit être précédée d’un identifiant (ici id1 – id2) afin que le serveur ne se perde pas lors du traitement de plusieurs commandes simultanées.
Nous commençons donc par nous loguer. Nous utilisons donc la commande id1 LOGIN user2 user2 qui prend comme arguments le login et le mot de passe.
Le serveur nous confirme alors que nous avons l’accès.
23
Nous demandons alors au serveur de lister le contenu de la boite mail principale (INBOX) avec la commande id2 SELECT INBOX.
Le serveur nous précise alors la présence de 3 mails dont aucun nouveau (pour les tests du TP, nous avions déjà consulté le nouveau mail). Il finit par nous indiquer que la requête d’identifiant id2 c’est bien passé.
Nous demandons alors des précisions sur le mail 3 avec la commande id3 FETCH 3:* RFC822.SIZE. Ici, « 3 :* » indique que nous souhaitons traiter les mails en partant du numéro 3. « RFC822.SIZE » indique que nous souhaitons connaitre la taille des mails. De façon générale, FETCH sert à demander des informations sur les mails et s’écrit FETCH <id(s) mail(s)>
<action>.
Le serveur nous indique que le message 3 fait 518 octets.
Nous souhaitons donc obtenir l’en-tête du mail 3. Nous utilisons donc la commande id4 UID FETCH 3 BODY[HEADER]. L’action BODY sert à consulter le message mais spécifier HEADER permet de restreindre la consultation à l’en-tête.
Le serveur nous donne alors l’en-tête du mail 3 précisant qu’il fait 462 octets.
Nous voulons donc consulter le mail. Nous utilisons donc la même commande sans la restriction HEADER : id5 UID FETCH 3 BODY[]. Le serveur nous retourne alors le message entier.
Nous fermons donc la connexion avec la commande id6 LOGOUT.
Le protocole IMAP permet de gérer des boites.
Nous pouvons donc créer des boites avec la commande CREATE suivit du nom de la boite. Pour créer une boite dans une boite, nous indiquons comme nom <nom de la boite contenant>.<nom de la boite contenu>. Par exemple, créer une boite test dans INBOX donnera CREATE INBOX.test.
24
Pour lister les boites présentes sur le serveur, nous utilisons la commande LIST «» *. Nous pouvons ensuite vider les nouveaux messages d’une boite avec la commande EXPUNGE.
Voici un exemple d’utilisation : nous nous connectons, nous créons la boite Bony dans la boite INBOX puis nous listons les boites. Nous vérifions ensuite le contenu d’INBOX puis nous supprimons les nouveaux messages qu’elle contient avant de vérifier si la suppression a eu lieu.
Exemple de gestion des boites avec IMAP
L’avantage du protocole IMAP est d’éviter la transmission du mail entier, diminuant ainsi le coût en trames généré par la consultation de sa boite mail. Il est donc beaucoup utilisé dans les systèmes de gestion des mails.
25
G Analyse des messages
Précédemment, nous avons étudié le moyen de gérer chaque protocole.
Nous allons maintenant capturer les trames à l’aide de Wireshark pour les étudier.
G.1 SMTP
Observer les trames du protocole SMTP peut se faire en envoyant un mail à une adresse non locale. Nous avons donc envoyé un mail à
simon.bony77@laposte.net depuis simon.bony77@laposte.net, les serveurs de laposte.net gérant les 3 protocoles.
Nous pouvons alors capturer les trames suivantes :
Capture Wireshark : utilisation de SMTP
On peut alors y observer tout le dialogue : les trames DNS correspondent à la recherche du serveur de messagerie sortant. S’ensuit-la connexion au serveur smtp1-g21.free.fr. On précise alors qui nous sommes avec EHLO, puis la commande MAIL nous précisons qui l’envoi. On demande alors à envoyer à simon.bony77@laposte.net avec RCPT puis avec la commande DATA, on transmet les données. Enfin on quitte avec QUIT.
Nous pouvons donc confirmer l’efficacité des commandes manuelles de la partie C.
26
En étudiant une trame, nous pouvons y retrouver toutes les encapsulations effectuées, que nous pouvons mettre en rapport avec le modèle OSI et les étapes de gestion d’une trame.
On commence par SMTP (niveau 7) dont les données sont mises en forme (niveau 6) et les applications entre en contact dans le cadre d’une session (niveau 5). Le niveau 4 segmente les données en paquets qui sont
encapsulé avec les adresses IP (niveau 3). On assure la liaison (niveau 2) et on envoi les données sur l’interface physique (niveau 1).
Nous remarquons aussi la présence de trames TCP entre chaque trame SMTP. Ce sont les messages de contrôle. Pour le protocole SMTP, ils font 74 octets.
G.2 POP
Nous réceptionnons alors notre mail avec le protocole POP. Nous obtenons alors les trames suivantes.
Capture Wireshark : utilisation de POP
Nous remarquons alors l’utilisation des mêmes requêtes et des mêmes réponses que dans la consultation manuelle de la partie E :
27
- Nous nous loguons avec USER et PASS (le mot de passe est en clair : inutile d’essayer de se connecter, ce mot de passe a été choisit pour être temporaire)
- Nous demandons les informations disponibles avec STAT, LIST et UIDL - Nous rapatrions le nouveau mail 4
Ici, l’encapsulation reste globalement la même, la gestion des trames étant relativement identique : le protocole POP (niveau 7), TCP (niveau 4), IP (niveau 3), Ethernet (niveau 2) et couche physique (niveau 1).
De plus, les messages de contrôle font 54 octets pour ce protocole.
G.3 IMAP
Nous envoyons un autre mail et nous le réceptionnons alors avec le protocole IMAP. Nous capturons alors les trames suivantes.
Capture Wireshark : utilisation d’IMAP
28
Nous remarquons alors l’utilisation des commandes utilisées dans la partie F ainsi que de nouvelles commandes :
- Après la connexion, nous émettons la commande capability qui demande quelles sont les commandes supportées.
- Nous nous loguons avec la commande login.
- Puis la commande namespace qui demande le nom des dossiers accessibles.
- Et la commande lsub qui demande quels dossiers sont visibles depuis un point de référence.
- Nous demandons ensuite les informations sur INBOX avec LIST.
- Nous listons alors le contenu de la boite INBOX avec SELECT et précisons les mails présents avec FETCH
- Puis enfin nous demandons les mails avec la commande FETCH aussi.
L’encapsulation est là encore identique, à l’exception de l’utilisation d’IMAP à la couche 7.
Les messages de contrôles sont quant à eux de 54 octets.
G.4 Avantages d’IMAP sur POP3
IMAP est un protocole présentant de nombreux avantages sur POP3.
La seule différence majeure est la gestion à distance d’IMAP. Mais cette différence entraine de nombreuses conséquences.
Tout d’abord, la gestion à distance évite d’enregistrer sur notre machine les mails reçus, ce qui peut être très long avec POP3 si le mail est trop
volumineux.
De plus, seul l’en-tête est transféré par IMAP. Ceci permet de supprimer le mail sans même le consulter ce qui réduit là encore l’utilisation de la bande.
29
Autre avantage : un serveur POP3 ne garde que les nouveaux mails, les supprimant après leur lecture pour les enregistrer sur la machine utilisée lors de la lecture. Cela signifie que l’utilisation d’une autre machine ne permet pas de consulter les mails déjà lus.
Un serveur IMAP ne supprimant pas les mails, ceux-ci restent consultables depuis n’importe quelle machine.
Cette gestion protège aussi contre la panne. Effectivement, si une machine utilisant le protocole POP3 tombe en panne, les mails seront perdus.
Dans le cas d’IMAP, les serveurs ayant des systèmes de sauvegardes et de délégations, les mails seront toujours accessibles en cas de panne d’un serveur.
IMAP permet aussi une gestion des dossiers que n’offre pas POP3 et un système de « flags » permettant de désigner un mail non lu comme lu et inversement, savoir si on y a répondu ou s’il faudra le supprimer, etc.
G.5 SMTP-AUTH
Nous avons pu étudier le protocole SMTP qui sert à l’envoi des mails.
Cependant, tout comme pour la relève de courrier, il ne nécessite aucune authentification.
Si ce n’est pas un problème pour l’expéditeur, rien ne garantit la
provenance du mail pour le destinataire. C’est un problème notamment dans la lutte contre le spam.
Le protocole SMTP-AUTH (SMTP authentifié) est une extension du protocole SMTP.
S’il ne contrôle par le contenu du mail et donc la valeur du champ « From » (permettant donc de se faire passer pour un autre), il assure que le mail provient d’un serveur autorisé.
En effet, chaque serveur relai doit s’authentifier auprès du serveur suivant précisant qu’il a lui-même authentifié le précédent.
30
Cependant, ce protocole possède une faille de taille : il faut « croire » le premier serveur.
Effectivement, ce serveur est celui qui authentifie l’émetteur. S’il fait passer l’émetteur pour un client de confiance alors qu’il ne l’est pas, un spam envoyé par cet émetteur ne sera pas bloqué par le SMTP-AUTH.
Le protocole nécessite donc de déclarer le premier serveur comme serveur de confiance, ce qui est soit très restrictif, soit trop évasif.
Nous connaissons désormais le fonctionnement des trois protocoles SMTP, POP3 et IMAP ainsi que l’existence d’une sécurité pour le protocole SMTP, souffrant à l’origine d’un manque de fiabilité.
31
Conclusion
Après avoir installé notre serveur Postfix, nous avons pu tester les trois protocoles SMTP, POP3 et IMAP. Nous avons pu remarquer le manque de sécurité dans l’utilisation de SMTP pour la relève de courrier mais son efficacité dans l’envoi de mail. Nous avons aussi pu voir l’efficacité des protocoles POP3 et IMAP pour la relève de courrier, bien que le protocole IMAP est plus avantageux.
Effectuer ce TP nous a permis de mieux comprendre la gestion des mails et de pouvoir configurer plus efficacement un gestionnaire.
