Table des matières

Présentation générale

Initialement, IMAP représentait un acronyme de  : « Interactive Message Access Protocol ». Le nom a été modifié en « Internet Message Access Protocol » Pour tenir compte des derniers ajouts au protocole (actuellement en version 4 révision 1).

Il est défini par le RFC 2060, remplacé par le RFC 3501.

Pourquoi IMAP4 ?

Puisqu'on a POP3 ...

POP3 remplit tout à fait son rôle de relève de courrier, nous l'avons vu. Alors pourquoi changer ?

POP3 permet de travailler en modes « hors-ligne » et « déconnecté », autrement dit, il est possible :

Le mode « hors-ligne » est tout à fait utilisable si l'on ne gère sa messagerie que depuis un seul poste de travail, ce qui n'est pas toujours le cas.

Le mode « déconnecté » permet quant à lui une gestion depuis plusieurs postes, mais pose tout de même le problème de la purge du serveur. En effet, il faudra bien faire de la place de temps en temps si l'on ne veut pas voir sa boîte exploser. Et les messages une fois détruits sur le serveur ne pourront plus y être remis autrement qu'en se les renvoyant.

Lorsque l'on est dans des conditions de connexion difficiles, POP3 se révèle peu puissant pour se tirer d'embarras si un message volumineux se trouve dans la file. Il est possible, en exploitant toutes les finesses de POP3, d'éliminer ce message ou du moins de ne pas le rapatrier, mais peu de MUA savent gérer ces possibilités et le message non lu représentera toujours un écueil, à chaque consultation.

Mais avec IMAP4 ...

Ici, le protocole autorise des manipulations infiniment plus souples. De plus, et c'est probablement là le point le plus décisif, les messages peuvent être entièrement gérés en restant sur le serveur. IMAP propose en effet les possibilités suivantes :

Cette notion de dossiers de stockage sur le serveur n'est absolument pas exploitable en POP3, qui ne sait lire que le contenu de INBOX, le point d'entrée des nouveaux messages.

Toutes ces possibilités nécessitent bien entendu d'être connecté en permanence, donc en mode interactif, d'où le nom initial du protocole.

Mais IMAP fait encore plus, dans la mesure où les modes « hors-ligne » et « déconnecté » sont également possibles.

Ce qu'IMAP4 sait faire

Vous le voyez, il semble n'y avoir aucune bonne raison de ne pas passer à IMAP, même si tous les MUA n'exploitent pas pleinement les possibilités de ce protocole.

Alors pourquoi POP3 encore ?

S'il ne semble y avoir que de bonnes raisons de passer à IMAP, il y en a aussi (mais sont-elles bonnes ?) pour rester sur POP3.

IMAP4 est un protocole beaucoup plus compliqué que POP3 et pour cause, il est plus puissant. Cette complexité relative amène plusieurs effets négatifs :

Mais nous sommes ici pour parler d'IMAP4. Pas moins de 25 commandes alors que POP3 n'en propose que 12. Nous ne les verrons pas toutes en détail, le but étant d'avantage de comprendre l'intérêt du protocole que de le manipuler avec telnet.

Démonstration

Les configurations utilisées

Pour cette démonstration, nous disposons de deux serveurs IMAP différents. Nous nous contenterons de les utiliser pour une première approche des possibilités de ce protocole.

Note : Cette démonstration date un peu, mais elle reste d'actualité.

UW-IMAP

Un serveur développé à l'université de Washington, installé pour l'occasion sur mon poste de travail. Le serveur SMTP utilisé est Postfix. La machine s'appelle poétiquement pchris2.maison.mrs.

Ce serveur utilise le format « MAILBOX ».

Cyrus

Un serveur développé à l'université de Carnegie Mellon, installé sur une Debian « Etch ». Le SMTP employé ici est également Postfix. La machine s'appelle cyrus.nain-t.net.

Ce serveur utilise le format « MAILDIR ».

Les tests

Configuration du client (MUA)

Sur chacune de ces machines, un compte de messagerie est créé :

Un client de messagerie, « Thunderbird », est installé sur la machine : pchris2.maison.mrs, qui fonctionne sous Ubuntu.

Nous allons créer ces deux comptes sur Thunderbird :

Deux remarques immédiates :

Création de répertoires

Ceci n'est pas un cours sur l'emploi de Thunderbird. Nous nous dispenserons donc de développer le mode opératoire.

Thunderbird aime bien disposer de répertoires supplémentaires :

Nous allons les créer pour chaque compte, sur les serveurs respectifs.

Encore deux remarques :

Réception d'un premier mail

Nous avons plus de moyens que vous ne pensez. Depuis une quatrième machine (Windows, celle là, mais qui utilise aussi Thunderbird), nous envoyons un message sur ces deux comptes :

Bien entendu, ça fonctionne et nous retrouvons sur pchris2 ce message dans chaque BAL :

Manipulations diverses

Voyons un peu la configuration de notre Thunderbird :

Par défaut, Thunderbird place une copie des messages envoyés dans le dossier « Sent », sur le serveur IMAP du compte employé. Vérifions ça en répondant à ce premier message depuis le compte sur gw2 :

Il y est.

Le dossier « Sent » est bien sur le serveur IMAP de gw2.maison.mrs et le message envoyé s'y trouve bien. Nous allons le vérifier tout de suite, puisque nous avons le serveur sous la main :

/home/testimap# ls -la
total 28
drwxr-xr-x    2 testimap nogroup      4096 Dec 20 10:53 .
drwxrwsr-x    6 root     staff        4096 Nov 30 16:42 ..
-rw-r--r--    1 testimap nogroup        28 Dec 20 10:20 .mailboxlist
-rw-------    1 testimap nogroup       513 Dec 20 10:19 Drafts
-rw-------    1 testimap nogroup      1190 Dec 20 10:53 Sent
-rw-------    1 testimap nogroup       513 Dec 20 10:20 Templates
-rw-------    1 testimap nogroup       513 Dec 20 10:03 Trash

Nous avons bien quatre fichiers qui correspondent aux quatre dossiers créés et un cinquième, caché, qui s'appelle .mailboxlist. Etant d'un naturel curieux, impossible de résister à l'envie de regarder son contenu :

/home/testimap# cat .mailboxlist
Trash
Drafts
Sent
Templates

Un peu décevant… Il ne contient que la liste des noms des répertoires.

Voyons maintenant le contenu du fichier « Sent » :

sysop:/home/testimap# cat Sent
From MAILER-DAEMON Sat Dec 20 10:20:02 2003
Date: 20 Dec 2003 10:20:02 +0100
From: Mail System Internal Data <MAILER-DAEMON@sysop.eme-enseignement.fr>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
X-IMAP: 1071912002 0000000000
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 testimap@sysop.eme-enseignement.fr Sat Dec 20 10:53:12 2003 +0100
Status: R
X-Status:
X-Keywords:
Message-ID: <3FE41C07.1030504@gw2.maison.mrs>
Date: Sat, 20 Dec 2003 10:53:11 +0100
From: testimap-gw2 <testimap@gw2.maison.mrs>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Caleca <christian.caleca@free.fr>
Subject: Re: un premier test IMAP
References: <3FE4192C.7040107@free.fr>
In-Reply-To: <3FE4192C.7040107@free.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Christian Caleca wrote:

> Coucou.

Bien reçu :)

Intéressons nous pour l'instant à ce qui est surligné : c'est bien le texte de la réponse faite.

Il n'a bien entendu pas échappé à votre sagacité que le dossier « Inbox » n'est pas ici. C'est tout simplement qu'il est ailleurs. Il est dans le spool de messagerie, directement alimenté par le SMTP, via l'agent de distribution local (MDA). Avec EXIM vous le trouverez dans /var/spool/mail

sysop:/var/spool/mail# ls
chris  testimap

Profitons-en pour voir ce qu'il y a dedans :

sysop:/var/spool/mail# cat testimap
From christian.caleca@free.fr Sat Dec 20 10:40:53 2003
Return-path: <christian.caleca@free.fr>
Envelope-to: testimap@gw2.maison.mrs
Received: from pchris.maison.mrs ([192.168.0.10] helo=free.fr)
        by sysop.eme-enseignement.fr with esmtp (Exim 3.35 #1 (Debian))
        id 1AXdbQ-0000u2-00; Sat, 20 Dec 2003 10:40:52 +0100
Message-ID: <3FE4192C.7040107@free.fr>
Date: Sat, 20 Dec 2003 10:41:00 +0100
From: Christian Caleca <christian.caleca@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  testimap@gw2.maison.mrs,  testimap@cyclope.maison.mrs
Subject: un premier test IMAP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-IMAPbase: 1071913280 2
Status: RO
X-Status: DA
X-Keywords:
X-UID: 1

Coucou.

Le message que l'on a reçu. C'est réconfortant.

Suppression d'un message dans « Inbox »

Le message initial n'ayant pas d'intérêt, nous allons le détruire. Nous devrions théoriquement le retrouver dans la poubelle (Trash):

Tout va bien, tout se passe comme prévu.

Comme ce message n'a toujours pas d'intérêt, même dans la poubelle, nous vidons aussi la poubelle.

Bien. Vous êtes bien assis ? Alors, allons vérifier tout ça sur le serveur :

/home/testimap# cat Trash

From MAILER-DAEMON Sat Dec 20 11:07:13 2003
Date: 20 Dec 2003 11:07:13 +0100
From: Mail System Internal Data <MAILER-DAEMON@sysop.eme-enseignement.fr>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
Message-ID: <1071914833@sysop.eme-enseignement.fr>
X-IMAP: 1071911016 0000000001
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 christian.caleca@free.fr Sat Dec 20 10:40:53 2003
Return-path: <christian.caleca@free.fr>
Envelope-to: testimap@gw2.maison.mrs
Received: from pchris.maison.mrs ([192.168.0.10] helo=free.fr)
        by sysop.eme-enseignement.fr with esmtp (Exim 3.35 #1 (Debian))
        id 1AXdbQ-0000u2-00; Sat, 20 Dec 2003 10:40:52 +0100
Message-ID: <3FE4192C.7040107@free.fr>
Date: Sat, 20 Dec 2003 10:41:00 +0100
From: Christian Caleca <christian.caleca@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  testimap@gw2.maison.mrs,  testimap@cyclope.maison.mrs
Subject: un premier test IMAP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Status: RO
X-Status: A
X-Keywords:

Coucou.

Ca c'est c.. ennuyeux. Bien qu'effacé, le message y est toujours !

Et dans le spool, le premier message reçu, puis effacé, y est-il toujours lui aussi ?

sysop:/var/spool/mail# cat testimap

From christian.caleca@free.fr Sat Dec 20 10:40:53 2003
Return-path: <christian.caleca@free.fr>
Envelope-to: testimap@gw2.maison.mrs
Received: from pchris.maison.mrs ([192.168.0.10] helo=free.fr)
        by sysop.eme-enseignement.fr with esmtp (Exim 3.35 #1 (Debian))
        id 1AXdbQ-0000u2-00; Sat, 20 Dec 2003 10:40:52 +0100
Message-ID: <3FE4192C.7040107@free.fr>
Date: Sat, 20 Dec 2003 10:41:00 +0100
From: Christian Caleca <christian.caleca@free.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  testimap@gw2.maison.mrs,  testimap@cyclope.maison.mrs
Subject: un premier test IMAP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-IMAPbase: 1071913280 2
Status: RO
X-Status: DA
X-Keywords:
X-UID: 1

Coucou.

Oui…

Ca voudrait dire que petit à petit, l'espace alloué va s'encombrer de déchets et au final, la BAL va exploser alors même qu'elle sera considérée comme vide ?

La réponse est oui, si l'on ne prend pas une précaution supplémentaire : le compactage des dossiers.

En cliquant sur Inbox du bouton droit et en faisant « Compact This Folder » et en répétant la même opération sur « Trash », nous allons remédier au problème :

/var/spool/mail# ls -l
total 48
-rw-rw----    1 testimap mail            0 Dec 20 11:33 testimap

Le fichier existe toujours, mais fait 0 octets, ce qui prouve qu'il est vide.

Il est donc primordial, avec IMAP, de penser à compacter régulièrement les dossiers de la messagerie. 

Déplacement de messages

Nous allons créer pour le compte sur gw2.maison.mrs une règle de filtrage qui va déplacer tout message contenant le mot « trier » dans un dossier spécial intitulé « demotri » et créé à cet effet.

et nous envoyons un message  :

Et chez le destinataire :

Ca fonctionne. Le seul fait de lire sa messagerie va faire que le message sera déplacé dans le dossier « demotri » sans qu'il ait été au préalable rapatrié chez le client.

On efface ce message sans intérêt, on vide la poubelle et au bout du compte, notre BAL contiendra toujours trois exemplaires de ce message, invisibles, mais bien présents :

Pensez donc à compacter les dossiers souvent…

Plus fort encore, nous allons créer une règle de tri qui fera que, lorsqu'un message à destination de testimap@cyclope.maison.mrs contient le mot « distant » dans son objet, il faudra le déplacer dans le répertoire « demotri » du compte testimap@gw2.maison.mrs.

Autrement dit, nous allons déplacer un message d'un serveur à l'autre.

Répétons-le, cette règle est écrite pour le compte [testimap@cyclope.maison.mrs !

Envoi du message :

Et réception :

Le cas d'un gros message encombrant.

Vous êtes perdu quelque part de l'autre côté de la fracture numérique et ne disposez que d'une méchante connexion RTC qui plafonne à 28800 bps et qui se déconnecte toutes les cinq minutes, à cause de la mauvaise qualité de votre ligne téléphonique. Je peux vous indiquer des endroits en France où c'est comme ça que ça se passe.

Comme dans ce cas, vous avez pris la précaution de faire afficher la taille des messages, vous constatez que celui-ci fait 805 Ko, qu'avec votre connexion pourrie, vous n'arriverez jamais à le télécharger, IMAP vous sauve.

En effet, à ce stade, le message n'est pas téléchargé en local. Aussi longtemps que vous ne cliquerez pas dessus du bouton gauche, il ne se téléchargera pas.

Cliquez donc dessus du bouton droit, demandez de le déplacer dans le dossier « Lire_plus_tard », que vous avez créé à cet effet. Le déplacement aura lieu sans que le message ne soit téléchargé localement. Vous pourrez alors aller le lire plus tard, lorsque vous aurez retrouvé une connexion de bonne qualité.

Premières conclusions

Si cette démonstration ne vous a pas convaincu de l'intérêt d'IMAP, c'est que vous n'avez pas besoin de consulter votre messagerie depuis des machines différentes, que vous êtes suffisamment sûr de la fiabilité de votre machine locale pour ne pas souhaiter conserver vos messages importants sur le serveur de votre fournisseur, que vous n'avez jamais été confronté au blocage de votre messagerie  parce que vous avez une connexion tellement minable qu'un gros message ne peut jamais être rapatrié à cause des déconnexions.

IMAP propose beaucoup de fonctionnalités, c'est une autre affaire que d'en disposer avec son MUA. Thunderbird gère bien mieux l'IMAP que ne le fait Outlook Express, par exemple, qui ne sait pas appliquer de règles de filtrage sur les dossiers IMAP. Cependant, il n'est pas parfait non plus. Il n'est pas possible par exemple de définir simplement une règle de tri en fonction de la taille des messages.

Pourquoi avons-nous fait ces manipulations surtout avec UW-imap ? Parce que c'est le serveur dont la structure est la plus simple. Mais rassurez-vous, nous aurons l'occasion de voir Cyrus plus en détails dans tard.

De ce que nous avons vu pour l'instant, retenons que Cyrus offre plus de souplesse dans l'organisation des répertoires que ne le fait UW-imap. Nous verrons plus loin que ce n'est pas son seul avantage. Mais en ce qui concerne le protocole IMAP lui-même, les deux serveurs se comportent de la même manière.