BONY Simon IR1. Services Réseaux TP3. BONY Simon

Transcription

1 Services Réseaux TP3 BONY Simon 2 décembre

2 Table des matières Introduction... 3 A Installation de Postfix... 4 A.1 Installation du paquetage... 4 A.2 Etude de la configuration... 5 B Test de la configuration du serveur SMTP... 7 B.1 Préparations... 7 B.2 Etude du fonctionnement... 8 B.3 Les logs C Etude du protocole SMTP D Installation du serveur POP E Etude du protocole POP E.1 La gestion des mails E.2 Les commandes F Etude du protocole IMAP F.1 Installation F.2 Les commandes G Analyse des messages G.1 SMTP G.2 POP G.3 IMAP G.4 Avantages d IMAP sur POP G.5 SMTP-AUTH Conclusion

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. 3

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 4

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 « /8 [::ffff: ]/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. 5

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. 6

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 [email protected]. 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). 7

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 8

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 [email protected] Fri Dec 2 09:13: Return-Path: <[email protected]> 3.X-Original-To: [email protected] 4.Delivered-To: [email protected] 5.Received: by pccop0b002b-15.tpreseau.umlv (Postfix, from userid 1001) id 891FB45A57; Fri, 2 Dec :13: (CET) 6.To: [email protected] 7.Subject: Test SMTP 8.Message-Id: < [email protected]> 9.Date: Fri, 2 Dec :13: (CET) 10.From: [email protected] 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 9

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: messageid=< [email protected]> Dec 2 09:13:52 pccop0b002b-15 postfix/qmgr[9310]: 891FB45A57: from=<[email protected]>, size=413, nrcpt=1 (queue active) Dec 2 09:13:52 pccop0b002b-15 postfix/local[9493]: 891FB45A57: to=<[email protected]>, 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. 10

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. 11

12 Nous demandons alors à créer un mail en notre nom par la commande MAIL from : <[email protected]>. Ici aussi le serveur nous donne son accord. Nous précisons alors le destinataire avec la commande RCPT to : <[email protected]>. 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. 12

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 13

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épertoire Maildir Nous sommes désormais en possession d un serveur POP3 opérationnel. 14

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 15

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 16

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. 17

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 18

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. 19

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. 20

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 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 ] 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 21

22 id4 UID FETCH 3 BODY[HEADER] * 3 FETCH (UID 3 BODY[HEADER] {462} Return-Path: <[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: by pccop0b002b-15.tpreseau.umlv (Postfix, from userid 1001) id 68F ; Fri, 2 Dec :31: (CET) To: [email protected] Subject: Test IMAP Message-Id: < F @pccop0b002b-15.tpreseau.umlv> Date: Fri, 2 Dec :31: (CET) From: [email protected] ) id4 OK FETCH completed. id5 UID FETCH 3 BODY[] * 3 FETCH (UID 3 BODY[] {518} Return-Path: <[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: by pccop0b002b-15.tpreseau.umlv (Postfix, from userid 1001) id 68F ; Fri, 2 Dec :31: (CET) To: [email protected] Subject: Test IMAP Message-Id: < F @pccop0b002b-15.tpreseau.umlv> Date: Fri, 2 Dec :31: (CET) From: [email protected] 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. 22

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. 23

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. 24

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 à [email protected] depuis [email protected], 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 à [email protected] 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. 25

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 : 26

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 27

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. 28

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. 29

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é. 30

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. 31