L'Internet Rapide et Permanent

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. Étant 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.

Ça, c'est 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…

Ça voudrait dire que petit à petit, l'espace alloué va s'encombrer de déchets et finalement, 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 octet, 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 :

Ça 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 à 28 800 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é.

C'est une commande importante, elle permet au client de savoir ce dont le serveur est capable. Tous les serveurs IMAP n'ont pas les mêmes possibilités. Cette commande peut être envoyée au serveur avant l'authentification. Il est même recommandé de le faire, de manière à choisir le moyen d'authentification le plus approprié. Exemples :

un serveur uw-imapd

10 capability
* CAPABILITY IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY
UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND
SASL-IR LOGIN-REFERRALS STARTTLS LOGINDISABLED
10 OK CAPABILITY completed

un serveur Dovecot

10 capability
* CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+
IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS AUTH=PLAIN
10 OK CAPABILITY completed

un autre serveur Dovecot, configuré différemment

10 capability
* CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+
IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN
10 OK CAPABILITY completed

un serveur Courier-imapd

10 capability
* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES
SORT QUOTA IDLE ACL ACL2=UNION STARTTLS LOGINDISABLED
10 OK CAPABILITY completed

un serveur Cyrus-imapd

10 capability
* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID
NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT
THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS LOGINDISABLED
10 OK Completed

Notez STARTTLS et LOGINDISABLED. L'une permet de passer en mode chiffré, l'autre indique que la commande LOGIN qui passe le nom d'utilisateur et le mot de passe en clair n'est pas acceptée par le serveur.

Ces deux commandes permettent de savoir quels sont les répertoires souscrits et existants. Exemple :

* OK Dovecot ready.
10 login chris@maison.mrs epikoi
10 OK Logged in.
20 lsub "*" "*"
* LSUB () "." "Trash"
20 OK Lsub completed.
30 list "*" "*"
* LIST (\HasNoChildren) "." "Trash"
* LIST (\HasNoChildren) "." "INBOX"
30 OK List completed.
40 unsubscribe "Trash"
40 OK Unsubscribe completed.
50 lsub "*" "*"
50 OK Lsub completed.
60 list "*" "*"
* LIST (\HasNoChildren) "." "Trash"
* LIST (\HasNoChildren) "." "INBOX"
60 OK List completed.
70 logout
* BYE Logging out
70 OK Logout completed.
Connection closed by foreign host.

Au début de la session, LSUB dit que chris@maison.mrs est abonné au dossier Trash. La commande LIST indique qu'il y a un autre dossier : INBOX. Mais à celui-ci l'utilisateur est obligatoirement abonné.

La commande UNSUBSCRIBE permet de se désabonner à Trash. En effet la commande LSUB n'indique plus rien, ce qui ne veut pas dire que le dossier n'existe plus, puisque la commande LIST l'affiche toujours.

Permet de sélectionner un dossier et d'avoir un compte rendu de son contenu. Pour les besoins, envoyons un message à chris@maison.mrs et manipulons un peu :

20 select INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 6 EXISTS
* 1 RECENT
* OK [UNSEEN 5] First unseen.
* OK [UIDVALIDITY 1216295789] UIDs valid
* OK [UIDNEXT 7] Predicted next UID
20 OK [READ-WRITE] Select completed.

Le fait de sélectionner INBOX nous apprend principalement que dedans il y a :

• six messages ;
• un est RECENT ;
• le premier message non lu a l'index 5.

Pour en savoir plus, il faut utiliser ce couple infernal, avec la bonne syntaxe. Ici, nous voulons juste avoir le détail des FLAGS pour tous les messages présents dans INBOX :

30 uid fetch 1:* (FLAGS)
* 1 FETCH (FLAGS (\Seen) UID 1)
* 2 FETCH (FLAGS (\Seen) UID 2)
* 3 FETCH (FLAGS (\Seen) UID 3)
* 4 FETCH (FLAGS (\Seen) UID 4)
* 5 FETCH (FLAGS () UID 5)
* 6 FETCH (FLAGS (\Recent) UID 6)
30 OK Fetch completed.

Ce qui nous apprend que :

• les messages 1 à 4 ont été lus ;
• le message 5 était déjà présent lors de la dernière consultation, mais n'a pas été lu ;
• le message 6 est Recent. Il n'était pas présent lors de la dernière consultation.

Est-ce à dire que le seul fait d'ouvrir une session IMAP peut changer des flags ? Absolument. La preuve :

40 logout
40 OK Logout completed.
Connection closed by foreign host.
chris@pchris2:~$ telnet janus.maison.mrs 143
Trying 192.168.0.18...
Connected to janus.maison.mrs.
Escape character is '^]'.
* OK Dovecot ready.
10 login chris@maison.mrs epikoi
10 OK Logged in.
20 select "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 6 EXISTS
* 0 RECENT
* OK [UNSEEN 5] First unseen.
* OK [UIDVALIDITY 1216295789] UIDs valid
* OK [UIDNEXT 7] Predicted next UID
20 OK [READ-WRITE] Select completed.
30 uid fetch 1:* (FLAGS)
* 1 FETCH (FLAGS (\Seen) UID 1)
* 2 FETCH (FLAGS (\Seen) UID 2)
* 3 FETCH (FLAGS (\Seen) UID 3)
* 4 FETCH (FLAGS (\Seen) UID 4)
* 5 FETCH (FLAGS () UID 5)
* 6 FETCH (FLAGS () UID 6)
30 OK Fetch completed.

Le seul fait d'avoir fermé la session IMAP puis d'en avoir ouvert une autre fait que le message 6 n'est plus Recent. Soyons clairs. Ceci ne veut pas dire qu'il a été lu. Un message lu a le flag Seen. La preuve :

40 uid FETCH 6 BODY[HEADER]
* 6 FETCH (UID 6 FLAGS (\Seen) BODY[HEADER] {811}
Return-Path: <root@janus.nain-t.net>
Delivered-To: chris@maison.mrs
Received: from localhost (localhost [127.0.0.1])
    by janus.nain-t.net (Postfix) with ESMTP id C47C64000B3
    for <chris@maison.mrs>; Sun, 20 Jul 2008 17:58:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at janus.nain-t.net
Received: from janus.nain-t.net ([127.0.0.1])
    by localhost (janus.nain-t.net [127.0.0.1]) (amavisd-new, port 0024)
    with ESMTP id UPxwk-p3hN85 for <chris@maison.mrs>;
    Sun, 20 Jul 2008 17:58:17 +0200 (CEST)
Received: by janus.nain-t.net (Postfix, from userid 0)
    id C886740009C; Sun, 20 Jul 2008 17:58:17 +0200 (CEST)
To: chris@maison.mrs
Subject: test IMAP
Message-Id: <20080720155817.C886740009C@janus.nain-t.net>
Date: Sun, 20 Jul 2008 17:58:17 +0200 (CEST)
From: root@janus.nain-t.net (root)

)
40 OK Fetch completed.
40 uid fetch 1:* (FLAGS)
* 1 FETCH (FLAGS (\Seen) UID 1)
* 2 FETCH (FLAGS (\Seen) UID 2)
* 3 FETCH (FLAGS (\Seen) UID 3)
* 4 FETCH (FLAGS (\Seen) UID 4)
* 5 FETCH (FLAGS () UID 5)
* 6 FETCH (FLAGS (\Seen) UID 6)
40 OK Fetch completed.

uid FETCH 6 BODY[HEADER] signifie que l'on souhaite lire le texte du message d'index 6, mais seulement son en-tête. Cette demande fait que par la suite, le message 6 est marqué comme Seen.

Cette commande permet de négocier entre le client et le serveur une méthode de chiffrement des données échangées. Le serveur doit présenter un certificat (avec sa clé publique) et le client doit accepter ce certificat. Soit automatiquement parce qu'il est signé par une autorité de confiance connue, soit manuellement. STARTTLS employé avant AUTHANTICATE permet de chiffrer aussi la procédure de login. Il n'est que trop conseillé d'utiliser cette méthode si le serveur le permet.

Il faut utiliser la commande STORE pour placer sur le message visé le flag \Deleted :

50 store 6 +FLAGS (\Deleted)
* 6 FETCH (FLAGS (\Deleted \Seen))
50 OK Store completed.
60 uid fetch 1:* (FLAGS)
* 1 FETCH (FLAGS (\Seen) UID 1)
* 2 FETCH (FLAGS (\Seen) UID 2)
* 3 FETCH (FLAGS (\Seen) UID 3)
* 4 FETCH (FLAGS (\Seen) UID 4)
* 5 FETCH (FLAGS () UID 5)
* 6 FETCH (FLAGS (\Deleted \Seen) UID 6)
60 OK Fetch completed.

Vous l'avez compris, ceci n'a rien effacé du tout. Nous avons juste ajouté le flag \Deleted au message d'index 6. Dans les MUA graphiques, cette opération peut être diversement visualisée :

• le message semble avoir disparu, ce qui est une très mauvaise approche, car l'utilisateur non averti peut penser légitimement que le message est détruit ;
• le message apparait barré, mais est toujours visible. C'est probablement la meilleure approche.

Devinez laquelle choisissent la plupart des MUA ? La première bien sûr. Non contents de ça, ils créent automatiquement un répertoire Trash dans lequel ils copient les messages marqués comme effacés. Moralité, l'utilisateur (non averti) croit faire du ménage, en fait, il ajoute des copies de messages en plus dans son espace, en attendant de vider la poubelle.

Ce détail a son importance lorsque l'on a atteint le quota fixé par le fournisseur du service. Refaire un peu de place peut s'avérer impossible si l'on n'a pas compris ce fonctionnement.

EXPUNGE a pour mission de détruire physiquement tous les messages marqués \Deleted dans le dossier courant. CLOSE fait la même chose en refermant le dossier courant. Exemple :

70 close
70 OK Close completed.
80 select "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 5 EXISTS
* 0 RECENT
* OK [UNSEEN 5] First unseen.
* OK [UIDVALIDITY 1216295789] UIDs valid
* OK [UIDNEXT 7] Predicted next UID
80 OK [READ-WRITE] Select completed.
90 uid fetch 1:* (FLAGS)
* 1 FETCH (FLAGS (\Seen) UID 1)
* 2 FETCH (FLAGS (\Seen) UID 2)
* 3 FETCH (FLAGS (\Seen) UID 3)
* 4 FETCH (FLAGS (\Seen) UID 4)
* 5 FETCH (FLAGS () UID 5)
90 OK Fetch completed.

Le message d'index 6, qui était marqué \Deleted a bien disparu de INBOX. EXPUNGE et CLOSE sont de vrais effaceurs.

Malheureusement, les MUA communs n'emploient pas par défaut ni l'un ni l'autre de ces effaceurs. Thunderbird peut le faire si on le lui demande, mais il faut passer par la configuration avancée et ce n'est pas trivial pour l'utilisateur (non averti).