IMAP : garder ton courrier sur le serveur, ou pourquoi ton client mail n'est qu'une fenêtre

L'idée de base tient en une phrase : tes messages restent sur le serveur, ton client ne fait que regarder dedans.

C'est l'inverse de POP3, l'ancêtre, qui téléchargeait les messages en local et les retirait souvent du serveur. Avec POP3, ton courrier vivait sur une seule machine. Tu la perdais, tu perdais tout. Avec IMAP, le serveur garde la vérité : dossiers, labels, statut lu/non lu, tout est centralisé.

Le protocole date de 1986, développé par Mark R. Crispin à Stanford sous le nom d'Interim Mail Access Protocol. Le mot « interim » trahissait son caractère expérimental. Trente-huit ans plus tard, on l'utilise toujours. C'est le genre de pari provisoire qui dure plus longtemps que la plupart des certitudes.

Ce que « stateful » change pour toi

IMAP est un protocole stateful. Le serveur garde en mémoire l'état de ta session.

HTTP, à côté, est stateless : chaque requête repart de zéro. IMAP non. Il sait que tu as ouvert la boîte « Factures », que tu as marqué le message 412 comme lu, que tu es en train de déplacer trois messages vers « Archives ». Cette mémoire permet des interactions compliquées — et c'est précisément ce qui rend le protocole plus lourd à implémenter qu'un simple GET.

Plusieurs appareils peuvent se connecter en même temps à la même boîte. Ton téléphone, ton portable, ta webmail. Tant que les clients sont bien écrits, ils ne se marchent pas dessus. Le serveur arbitre.

La contrepartie, tu la sens quand ta connexion tombe. POP3 supporte mal la coupure, mais il a déjà tout téléchargé. IMAP, lui, dépend du serveur à chaque instant. Pas de réseau, pas de courrier. C'est le prix de la synchronisation.

La spécification, et pourquoi elle a changé

En 2003, l'IETF publie la RFC 3501, qui définit IMAP4rev1. Pendant près de vingt ans, c'est la référence. Le document décrit tout : comment un client se connecte, ouvre une boîte, demande des messages, les marque, les déplace, les supprime.

Entre-temps, des dizaines d'extensions apparaissent. Meilleure sécurité, synchronisation plus efficace, gestion de grosses boîtes, meilleure remontée d'erreurs. Ces extensions vivent d'abord en dehors de la norme, puis finissent par y entrer.

Le 23 août 2021, l'IETF publie la RFC 9051, qui définit IMAP4rev2. Elle remplace la RFC 3501 et intègre les extensions devenues indispensables. C'est la norme actuelle.

En pratique, tu ne choisis pas ta version d'IMAP. Ton serveur et ton client négocient. Mais savoir que rev2 existe t'évite de t'étonner quand une option n'apparaît pas sur une vieille installation.

Côté client : ce que tu installes décide de ton confort

Alpine est un client en mode texte, héritier de Pine, sorti en 1991 à la University of Washington. Il gère IMAP, il est léger, il tourne dans un terminal. Sur Arch, tu l'installes via le paquet `alpine`, avec `alpine-dbg` si tu veux déboguer. Tu y saisis le domaine du serveur et ton identifiant, et tu travailles.

Ce que ça coûte : Alpine ne te tiendra pas la main. Pas de wizard, pas de détection automatique. Tu dois connaître les ports, les options TLS, le nom exact de ton serveur. Si tu es à l'aise en ligne de commande, c'est un excellent outil. Sinon, tu vas souffrir.

Evolution est l'autre bout du spectre. C'est le client par défaut de GNOME, et il fait bien plus que du mail : calendrier, contacts, tâches. Il parle IMAP, mais aussi Microsoft Exchange, CalDAV, LDAP. Sa configuration passe par un assistant qui te guide champ par champ. Tu remplis le serveur entrant, le serveur sortant, ton mot de passe, et ça marche.

Le coût, ici, c'est le poids. Evolution embarque une base de données locale, un démon d'indexation, un moteur de calendrier. Sur une machine modeste, tu le sens. Et si tu n'utilises que le mail, tu traînes trois modules dont tu ne te sers pas.

Entre les deux, il y a Mutt, Thunderbird, Claws Mail, et une bonne dizaine d'autres. Le choix dépend surtout de ta tolérance à la configuration manuelle.

Côté serveur : Dovecot, et la question des versions

Dovecot est l'implémentation IMAP et POP3 open source la plus répandue sur Linux et les systèmes UNIX. Sécurité, rapidité, configuration lisible. Il sert aussi bien une boîte personnelle qu'une infrastructure d'entreprise.

Un détail compte si tu administres : la version 2.4 a introduit des ruptures dans le format de configuration. Arch Linux propose donc les deux branches — la 2.4 récente et l'ancienne 2.3 — parce que migrer une configuration existante n'a rien d'automatique. Si tu pars de zéro, prends la 2.4. Si tu reprends une install en 2.3, ne saute pas l'étape de relecture du fichier de conf.

Dovecot gère l'authentification de plusieurs façons : comptes système, base SQL, LDAP, PAM. Il gère le chiffrement, les boîtes virtuelles, les quotas. Tout est configurable, et donc tout est à configurer.

C'est le point qu'on oublie souvent : un serveur IMAP n'est pas un logiciel qu'on installe et qu'on oublie. C'est un service exposé à Internet, qui détient tes mots de passe et tes messages. La moindre erreur de configuration se paie en fuite de données.

Ce que ça implique quand tu héberges toi-même

Monter Dovecot sur un VPS, c'est une soirée de travail. Le rendre fiable, c'est une autre affaire. Sauvegardes, certificats qui expirent, mises à jour de sécurité, filtrage du spam en amont, reverse DNS propre pour ne pas finir en liste noire.

Rien de tout cela n'est insurmontable. Mais il faut le vouloir.

Si tu prends un hébergement mail chez un fournisseur, tu délègues tout ça. Tu perds la main sur les détails — versions, extensions, politique de rétention — et tu gagnes des soirées tranquilles.

Aucune des deux options n'est meilleure dans l'absolu. Tout dépend de ce que tu veux pouvoir réparer toi-même à onze heures du soir.

Le vrai partage, ce n'est pas IMAP contre POP3

POP3 a encore du sens dans un cas précis : tu veux une copie locale, tu ne fais pas confiance au serveur, tu consultes depuis une seule machine. C'est rare aujourd'hui, mais ça existe.

IMAP a du sens dès que tu touches à ta boîte depuis plus d'un appareil. C'est-à-dire presque toujours.

Le reste — quel client, quel serveur, hébergé ou pas — dépend de ta patience, de ton budget et du nombre de choses que tu acceptes de ne pas contrôler. Il n'y a pas de bonne réponse universelle. Il y a celle qui tient quand quelque chose casse, et celle qui ne tient pas.

C'est souvent la seule différence qui compte.