Fonctionnement

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 multi utilisateurs, même s'ils ont fait parfois semblant. Windows NT/2000/XP/Vista sont des systèmes multi utilisateurs (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.

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.

Ca 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 boite 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.mrs et 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 boites 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 boites aux lettres.

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.

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.

Post Office Protocol est très simple, même rudimentaire; il est toutefois largement suffisant pour des cas classiques de gestion de boites 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'effectue 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.

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.

1. le premier message n'en est pas un. C'est juste un avertissement pour rappeler que ce fichier ne doit pas être détruit.
2. 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.
3. 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.
4. 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.