Présentation générale

IMAP Porpriétés proprietes 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.

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 :

• De rapatrier tous ses messages en local et de les effacer du serveur, ce qui permet d'interrompre la connexion et de gérer ses messages localement (mode « hors-ligne »),
• de faire la même chose, mais en rapatriant une copie locale des messages,  laissant les messages « originaux » sur le serveur (mode « déconnecté »).

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.

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 :

• Lecture des objets des messages seulement (sans le corps) ;
• création de dossiers sur le serveur ;
• déplacement de messages sur le serveur d'un dossier à l'autre, sans avoir à rapatrier tout le message en local ;
• effacement de message sans l'avoir lu ;
• lecture des messages en les laissant sur le serveur ;
• marquage des messages sur le serveur. Par exemple, vous lisez un message sur un poste client A, lorsque vous ouvrez votre messagerie sur un poste client B, le message apparaitra comme lu. Il y a d'autres marqueurs que nous verrons plus loin ;
• il est possible, si votre fournisseur de service le permet, de poser sur le serveur des filtres qui classeront vos messages à leur arrivée sur le serveur. Ainsi, en ouvrant une session IMAP, vous trouverez vos messages déjà triés dans les bons dossiers.

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.

• consulter seulement les objets des messages,
• effacer, déplacer des messages sans les lire, éventuellement avec des règles de tri automatiques,
• rapatrier en local certains messages et pas d'autres, en faisant une copie ou un déplacement, éventuellement avec des règles de tri automatiques,
• recopier sur le serveur des messages que vous avez en local,
• et bien d'autres choses encore.

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.

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 :

• tous les fournisseurs de services Internet ne proposent pas encore de serveur IMAP, et ceux qui en proposent, pour des raisons diverses, les amputent parfois de certaines de leurs possibilités,
• rares sont les clients de messagerie (MUA) qui gèrent toutes les possibilités offertes par IMAP4, si l'on se limite à ce que sait faire POP3, alors, autant utiliser POP3,
• garder tous ses messages sur le serveur, même bien classés dans divers dossiers n'a pas que des avantages, l'espace disponible est souvent limité et le stockage sur le serveur va rapidement remplir cet espace, encore que cette situation évolue rapidement. Il faudra donc adopter des stratégies de purge qui restreindront les avantages du système.

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.

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

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

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

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

• testimap@pchris2.maison.mrs pour le serveur Uw-imap,
• testimap@cyrus.nain-t.net pour le serveur Cyrus.

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 :

• Les deux comptes contiennent déjà deux dossiers, « Inbox » et « Trash »,
• sur pchris2 (uw-imap) les deux dossiers sont au même niveau de hiérarchie, alors que sur cyrus, « Trash » est un sous dossier de « Inbox ». Cette subtilité trouvera son explication plus loin dans cet exposé.

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 :

• Sent, pour stocker les messages envoyés,
• Drafts, pour stocker les brouillons,
• Templates, pour stocker les modèles.

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

Encore deux remarques :

• Avec uw-imapd, il n'est pas possible de créer ces dossiers dans « Inbox », tous les dossiers sont obligatoirement au même niveau de hiérarchie,
• avec Cyrus, les dossiers ne peuvent être créés que dans « Inbox » (ou dans un sous dossier de « inbox »). Il est possible de construire une arborescence complexe, même si ce n'est pas forcément souhaitable.

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 :

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.

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. 

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 :

• Dans Inbox, parce que le déplacement n'est en réalité qu'une copie suivie d'un effacement,
• dans demotri,
• dans Trash.

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 :

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

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.