I. Introduction▲
Le protocole POP3 (Post Office Protocol) a un objectif très spécifique : permettre à l'utilisateur de relever son courrier depuis un hôte qui ne contient pas sa boîte aux lettres. Entendez par là  : depuis un hôte qui n'est pas celui où le SMTP stocke les messages entrants pour son compte, ce qui est le cas de la très large majorité des internautes.
Autant dire que la plus grosse partie du travail est réalisée par SMTP, vu plus en détail dans les articles « SMTP » et « SMTP/IMAP en pratique ».
POP3 et également IMAP4 sont donc des protocoles dont l'unique fonction est de gérer à distance cette file d'attente, présente sur le serveur SMTP qui réceptionne vos messages. IMAP est plus performant, mais aussi plus complexe.
Dans ce chapitre, nous allons voir :
- comment fonctionne POP3Â ;
- comment exploiter ce protocole avec un outil aussi rudimentaire que Telnet.
II. La philosophie du courrier électronique sur un réseau▲
Les utilisateurs qui ne connaissent que les O.S. Microsoft ont souvent du mal à assimiler les principes de la messagerie, parce que cette notion n'existe pas nativement dans les réseaux Microsoft. Windows 95/98 n'étaient pas des systèmes multiutilisateurs, même s'ils ont fait parfois semblant. Windows NT/2000/XP/Vista sont des systèmes multiutilisateurs (NT 4 disposait d'ailleurs d'un vague système de messagerie, complètement propriétaire et qui n'est, sauf erreur de ma part, plus supporté par MS).
Sur un hôte Linux, même isolé, un utilisateur a la possibilité de laisser un e-mail à un autre utilisateur.
II-A. Un cas simple▲
Imaginons le cas fort simple de deux hôtes Linux connectés en réseau :
Il y a trois utilisateurs sur ce réseau : Jim, Jules et Alfred. Jules et Alfred travaillent toujours sur la même machine, Jim travaille tantôt sur l'une, tantôt sur l'autre; il dispose donc d'un compte d'utilisateur sur chacune des deux machines.
Chaque utilisateur dispose d'au moins une adresse électronique, sauf Jim qui en a deux.
Jim |
Jules |
Alfred |
jim@jules.maison.mrs |
jules@jules.maison.mrs |
alfred@alfred.maison.mrs |
Ça n'est peut-être pas la meilleure façon de fonctionner, mais c'est comme ça que les choses se passent par défaut : tout utilisateur disposant d'un compte sur un hôte dispose par la même occasion d'une boîte aux lettres sur cet hôte.
Chaque utilisateur pourra envoyer un message à un autre utilisateur, Jim pourra en recevoir sur l'un ou l'autre des deux hôtes (ce qui n'est pas forcément le plus simple pour lui). Jusque-là , c'est SMTP qui se charge des acheminements.
S'il n'y a rien de plus, Jim devra aller sur jules.maison.mrs pour lire ses courriers adressés à jim@jules.maison.mrset aller sur alfred.maison.mrs pour lire ses courriers adressés à jim@alfred.maison.mrs.
On aimerait (surtout lui) pouvoir relever le courrier dans les deux boîtes depuis l'un quelconque des hôtes. C'est là qu'intervient POP3. Si le service POP3 est installé sur les deux hôtes, Jim pourra relever son courrier depuis n'importe quel hôte dans l'une ou l'autre de ses boîtes aux lettres.
II-B. Un cas un peu moins simple▲
Jim s'est offert un portable sous Windows™. Ce genre de dispositif, par défaut, ne dispose pas d'autre chose que d'Outlook Express qui n'est rien de plus qu'un MUA. Il n'y a pas de système de messagerie sous Windows™. Il peut tout de même se connecter au réseau.
Et il peut, non seulement envoyer des messages à Jules, à Alfred et à lui-même en employant jules.maison.mrs ou jim.maison.mrs comme serveur SMTP (si les systèmes GNU/Linux sont correctement configurés pour ce mode de fonctionnement), mais il peut aussi relever ses messages aussi bien sur jules.maison.mrs que sur jim.maison.mrs grâce toujours à POP3, à la condition bien entendu qu'un serveur POP3 soit installé sur chacune de ces machines. Ses deux adresses électroniques resteront utilisables tant que Jim sera un utilisateur connu sur les hôtes Linux.
II-C. Conclusion▲
Si nous reportons ce principe sur l'Internet, nous nous trouvons avec quelque chose de similaire :
Lorsque vous vous inscrivez chez votre FAI, vous disposez d'un compte sur leur serveur (la situation peut être un peu plus compliquée, mais elle revient au même en ce qui nous concerne). Bien évidemment, vous disposez de droits très limités, mais suffisants pour utiliser au moins le système de messagerie.
Dans un cas simple, ce serveur vous servira de relais SMTP et abritera également votre messagerie, c'est normal, vous avez un compte dessus. Le service POP3 vous permettra de relever votre courrier à distance. Vous êtes dans la situation de Jim, avec son portable.
II-D. Description simplifiée du fonctionnement▲
Post Office Protocol est très simple, même rudimentaire ; il est toutefois largement suffisant pour des cas classiques de gestion de boîtes aux lettres.
Le principe consiste à ouvrir entre le client et le serveur une connexion TCP. Par la suite, le serveur POP3 est capable de répondre à un certain nombre de commandes. Nous verrons le détail de ces commandes plus loin.
Vos messages sont contenus sur le serveur dans une file, un fichier unique pour tous les messages, si le stockage est de type Mailbox. On ne peut pas faire plus simple. POP3 est capable de les délimiter, de les compter, de calculer leur taille, d'extraire tout ou partie de chaque message, de supprimer un message et c'est à peu près tout. Tout le reste de la gestion de vos messages, celle que vous voyez dans votre client : messages isolés dans des fichiers indépendants, répertoires de stockage personnalisés pour le tri et l'archivage, s'effectuent sur votre poste et non pas sur le serveur (ce qui n'est pas le cas d'IMAP, comme nous le verrons plus loin).
POP3 n'assure donc qu'un service minimum :
- permettre au client d'extraire une copie complète ou partielle de chaque message présent dans la file d'attente ;
- supprimer tel ou tel message dans la file ;
- remettre la file d'attente en ordre en supprimant les trous créés par la destruction des messages ;
- la page suivante va nous aider à mieux comprendre le principe, en détaillant les commandes de POP3.
POP3 tourne sous la forme d'un démon qui écoute par défaut sur le port 110.
II-E. Dans le cambouis▲
Voici un exemple de file d'attente de messages. La machine est dans un placard. Elle tourne 24/7 et fait office de serveur et de passerelle Internet sur un réseau local. chris est l'utilisateur qui reçoit tous les messages de notification du système. Nous regardons ici la file d'attente de ses messages avant qu'il ne soit allé les lire. La file d'attente se trouve dans le fichier /var/spool/mail/chris, il s'agit d'un système très basique, les messages sont stockés dans un seul fichier, c'est le format mbox, le plus ancien, du temps où IMAP n'existait pas encore :
~# cat /var/spool/mail/chris
From MAILER_DAEMON Thu Apr 12 18:09:09 2007
Date: Thu, 12 Apr 2007 18:09:09 +0200
From: Mail System Internal Data <MAILER-DAEMON@betelgeuse>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
Message-ID: <1176394149@betelgeuse>
X-IMAP: 1101374946 0000018214 NonJunk
Status: RO
This text is part of the internal format of your mail folder, and is not
a real message. It is created automatically by the mail system software.
If deleted, important folder data will be lost, and it will be re-created
with the data reset to initial values.
From logcheck@lair.nain-t.net Sat Jul 19 06:02:38 2008
Return-Path: <logcheck@lair.nain-t.net>
X-Original-To: root
Delivered-To: root@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 110)
id 0278628B8; Sat, 19 Jul 2008 06:02:34 +0200 (CEST)
To: root@lair.nain-t.net
Subject: betelgeuse.maison.mrs 2008-07-19 06:02 System Events
Message-Id: <20080719040235.0278628B8@lair.nain-t.net>
Date: Sat, 19 Jul 2008 06:02:34 +0200 (CEST)
From: logcheck@lair.nain-t.net (logcheck system account)
This email is sent by logcheck. If you wish to no-longer receive it,
you can either deinstall the logcheck package or modify its
configuration file (/etc/logcheck/logcheck.conf).
System Events
=-=-=-=-=-=-=
etc. etc. etc.
From prof@nain-t.net Sat Jul 19 13:54:10 2008
Return-Path: <prof@nain-t.net>
X-Original-To: root
Delivered-To: root@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 0)
id CCD3D10169; Sat, 19 Jul 2008 13:54:05 +0200 (CEST)
To: root@lair.nain-t.net
Subject: [Fail2Ban] ssh: banned 82.17.104.168
Message-Id: <20080719115406.CCD3D10169@lair.nain-t.net>
Date: Sat, 19 Jul 2008 13:54:05 +0200 (CEST)
From: prof@nain-t.net (root)
Hi,
The IP 82.17.104.168 has just been banned by Fail2Ban after
6 attempts against ssh.
Here are more information about 82.17.104.168:
Lines containing IP:82.17.104.168 in /var/log/auth.log
Jul 19 13:40:48 betelgeuse sshd[27763]: Did not receive identification string from 82.17.104.168
Jul 19 13:52:33 betelgeuse sshd[27801]: Invalid user admin from 82.17.104.168
Jul 19 13:52:35 betelgeuse sshd[27803]: Invalid user test from 82.17.104.168
Jul 19 13:52:42 betelgeuse sshd[27807]: Invalid user ghost from 82.17.104.168
Jul 19 13:53:00 betelgeuse sshd[27815]: Invalid user guest from 82.17.104.168
Jul 19 13:53:01 betelgeuse sshd[27817]: Invalid user ghost from 82.17.104.168
Jul 19 13:53:03 betelgeuse sshd[27819]: Invalid user magnos from 82.17.104.168
Regards,
Fail2Ban
From prof@nain-t.net Sat Jul 19 15:29:34 2008
Return-Path: <prof@nain-t.net>
X-Original-To: chris
Delivered-To: chris@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 0)
id D908F10169; Sat, 19 Jul 2008 15:29:33 +0200 (CEST)
To: chris@lair.nain-t.net
Subject: Message test
Message-Id: <20080719132933.D908F10169@lair.nain-t.net>
Date: Sat, 19 Jul 2008 15:29:33 +0200 (CEST)
From: prof@nain-t.net (root)
Juste pour montrer comment les messages sont rangés
dans la file d'attente de type "mbox"
Il s'agit bien d'un unique fichier qui contient quatre messages, surlignés chacun d'une couleur différente. Nous sommes bien dans le cas d'un système mbox :
- le premier message n'en est pas un. C'est juste un avertissement pour rappeler que ce fichier ne doit pas être détruit ;
- le second est un compte-rendu des événements de la journée précédente. Il est ici volontairement tronqué, pour simplifier la lecture ;
- le troisième est une alerte envoyée par le service fail2ban qui est chargé de repérer les tentatives de connexion à distance qui échouent. Ici, Monsieur 82.17.104.168 a tenté une attaque par dictionnaire et s'est fait repérer et bloquer à la cinquième tentative ;
- le dernier message est juste un exemple, envoyé par prof à chris pour étoffer un peu la file d'attente.
Nous verrons avec le protocole IMAP qu'il existe une autre façon de stocker les messages, chacun dans un fichier séparé. C'est le format Maildir, plus utilisé dans le cas de serveurs IMAP, mais aussi utilisable avec les serveurs POP3 actuels.
II-F. Les commandes de POP3▲
Commande |
Fonction |
USER |
Il s'agit de l'identifiant du titulaire du compte. En règle générale la partie à gauche du @ dans l'adresse électronique. |
PASS |
Le mot de passe fourni par le FAI |
STAT |
Donne le nombre de messages présents dans la file d'attente, ainsi que le volume total des messages en octets. |
LIST |
Donne la liste des messages en attente, avec pour chaque message : |
UIDL |
Analogue à LIST, mis à part qu'elle retourne non pas la taille du message, mais un identificateur unique |
RETR n |
Permet de récupérer la totalité du message « n » dans la file d'attente. |
DELE n |
Détruit le message « n » dans la file d'attente. Le numéro d'ordre des messages suivants demeure inchangé jusqu'à la fin de la session. |
TOP n x |
Permet de récupérer les x premières lignes du message « n ». Les lignes d'en-tête ne sont pas comptabilisées. Cette commande est le plus souvent utilisée pour récupérer l'en-tête complet et la première ligne du message, x ne pouvant être égal à 0. |
LAST |
Permet de connaître le numéro d'ordre du dernier message auquel on a accédé. (utile avec une session TELNET). |
RSET |
Cette commande permet d'annuler toutes les commandes de destruction de messages envoyées pendant la session. En fait, les commandes DELE ne sont rendues effectives que si la session a proprement été fermée (commande QUIT acceptée). Cette méthode permet donc d'annuler les opérations d'effacement dans la session en cours. |
NOOP |
Cette commande sert à ne rien faire. |
QUIT |
Clôture la session en cours. Le serveur ferme alors la session TCP et « fait le ménage » dans la file d'attente, en fonction des ordres DELE qui ont été donnés. |
Pour plus de détails sur les commandes POP3, consultez la rfc1939
Il y a très peu de commandes, mais elles sont suffisantes pour relever sa boîte aux lettres. La plupart des MUA (clients de messagerie) ne les utilisent même pas toutes.
II-G. Expérience avec TELNET▲
Il est donc tout à fait possible, si l'on connaît le jeu de commandes ci-dessus, d'ausculter sa boîte aux lettres avec un terminal TELNET. Voici des extraits d'une trace enregistrée avec un terminal TELNET, connecté sur le port 110 du serveur pop installé sur notre passerelle :
~# telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK Dovecot ready.
user chris
+OK
pass epikoi
+OK Logged in.
Nous avons utilisé les commandes user et pass pour nous identifier, le serveur nous a reconnus et accepte la connexion.
stat
+OK 3 6694
list
+OK 3 messages:
1 4997
2 1217
3 480
.
Nous avons utilisé la commande stat, ce qui nous apprend qu'il y a trois messages (rappelez-vous, le premier n'est pas un vrai message), puis la commande list qui ne fait que nous donner les numéros d'ordre et la taille en octets de chaque message.
top 1 1
+OK
Return-Path: <logcheck@lair.nain-t.net>
X-Original-To: root
Delivered-To: root@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 110)
id 0278628B8; Sat, 19 Jul 2008 06:02:34 +0200 (CEST)
To: root@lair.nain-t.net
Subject: betelgeuse.maison.mrs 2008-07-19 06:02 System Events
Message-Id: <20080719040235.0278628B8@lair.nain-t.net>
Date: Sat, 19 Jul 2008 06:02:34 +0200 (CEST)
From: logcheck@lair.nain-t.net (logcheck system account)
This email is sent by logcheck. If you wish to no-longer receive it,
.
top 2 1
+OK
Return-Path: <prof@nain-t.net>
X-Original-To: root
Delivered-To: root@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 0)
id CCD3D10169; Sat, 19 Jul 2008 13:54:05 +0200 (CEST)
To: root@lair.nain-t.net
Subject: [Fail2Ban] ssh: banned 82.17.104.168
Message-Id: <20080719115406.CCD3D10169@lair.nain-t.net>
Date: Sat, 19 Jul 2008 13:54:05 +0200 (CEST)
From: prof@nain-t.net (root)
Hi,
.
top 3 1
+OK
Return-Path: <prof@nain-t.net>
X-Original-To: chris
Delivered-To: chris@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 0)
id D908F10169; Sat, 19 Jul 2008 15:29:33 +0200 (CEST)
To: chris@lair.nain-t.net
Subject: Message test
Message-Id: <20080719132933.D908F10169@lair.nain-t.net>
Date: Sat, 19 Jul 2008 15:29:33 +0200 (CEST)
From: prof@nain-t.net (root)
Juste pour montrer comment les messages sont rangés
.
Nous utilisons trois fois la commande top en ne demandant qu'une seule ligne du message, et récupérons ainsi les en-têtes de chacun des trois messages.
dele 3
+OK Marked to be deleted.
list
+OK 2 messages:
1 4997
2 1217
.
Nous avons utilisé la commande dele pour supprimer le 3e message, puis la commande list qui n'indique plus que les deux premiers messages.
rset
+OK
list
+OK 3 messages:
1 4997
2 1217
3 480
.
Nous nous ravisons et utilisons la commande rset pour annuler toutes les commandes d'effacement que nous aurions pu envoyer précédemment. La commande list réaffiche trois messages.
retr 3
+OK 480 octets
Return-Path: <prof@nain-t.net>
X-Original-To: chris
Delivered-To: chris@lair.nain-t.net
Received: by lair.nain-t.net (Postfix, from userid 0)
id D908F10169; Sat, 19 Jul 2008 15:29:33 +0200 (CEST)
To: chris@lair.nain-t.net
Subject: Message test
Message-Id: <20080719132933.D908F10169@lair.nain-t.net>
Date: Sat, 19 Jul 2008 15:29:33 +0200 (CEST)
From: prof@nain-t.net (root)
Juste pour montrer comment les messages sont rangés
dans la file d'attente de type "mbox"
.
quit
+OK Logging out.
Connection closed by foreign host.
La commande retr permet ici d'afficher la totalité du 3e message et la commande quit met fin à la session.
Notez que lorsque POP3 renvoie des données, par exemple avec la commande list, la dernière ligne envoyée est toujours une ligne commençant par un point. C'est la convention du protocole pour indiquer au client que le serveur a fini d'envoyer des données et que le client peut passer à la commande suivante.
Que retrouverions-nous sur le serveur, si nous ouvrons une nouvelle connexion ?
:~# telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK Dovecot ready.
user chris
+OK
pass epikoi
+OK Logged in.
list
+OK 3 messages:
1 4997
2 1217
3 480
.
quit
+OK Logging out.
Exactement, la même chose. Autrement dit, si nous n'effaçons pas explicitement les messages sur le serveur, ils y restent, même si nous les lisons.
II-H. POP3 et les MUA▲
POP3 est un protocole simple. Pourtant la plupart des clients de messagerie (Thunderbird, Outlook, etc.) ne l'exploitent pas pleinement.
Généralement, notre client de messagerie effectue par défaut, la suite des opérations suivante :
- ouverture de la session POP3Â ;
- identification du client (user et pass)Â ;
- récupération en local puis effacement de tous les messages présents sur le serveur (list, retr, dele).
Généralement, il est au moins possible de demander au MUA de laisser une copie sur le serveur (la commande dele n'est plus envoyée). Dans ce cas, le MUA tient à jour (en principe) une liste des index de messages déjà lus, de manière à ne pas les récupérer à nouveau à chaque session.
Il faut bien noter que dans tous les cas, les messages lus sont copiés en local, même s'ils ne sont pas détruits sur le serveur.
Utiliser POP3 lorsque l'on est amené à lire sa messagerie depuis plusieurs postes n'est pas bien pratique. Il faut en effet prévoir une stratégie qui permet d'effacer les messages sur le serveur une fois que l'on est assuré de les avoir récupérés sur chaque poste.
De plus, les messages sont dupliqués sur chaque poste client utilisé, il faut les retrier sur chaque poste, etc. IMAP va beaucoup nous aider dans ce cas.
III. 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 à zoom61 pour la relecture orthographique de cet article.
N'hésitez pas à commenter cet article ! Commentez