Résumé
- IMAP définit
\Seencomme « message lu », mais l’événement observable reste un état modifiable de boîte aux lettres : un FETCH du corps peut l’activer,BODY.PEEKpeut récupérer le contenu sans l’activer, et un client autorisé peut l’ajouter ou l’effacer. - Pour affirmer qu’une personne a lu, il faut relier identité, client, incarnation de boîte, UID, commande, état avant/après, réponse du serveur et événement d’affichage. Le drapeau seul ne prouve ni attention, ni compréhension, ni consentement, ni réponse.
Un verbe humain porté par un état de protocole
Mark Crispin a conçu IMAP pour que le courrier demeure sur un serveur tout en restant accessible depuis plusieurs clients et plusieurs lieux. Le mémorial de Stanford rappelle qu’il a inventé ce protocole lorsqu’il y travaillait comme programmeur système entre 1977 et 1988. Son profil IETF recense 25 RFC, dont la RFC 3501, référence durable d’IMAP4rev1. Le Consortium Unicode, auquel il contribua longtemps, le présente comme un expert du courrier électronique et le père d’IMAP.
La RFC 3501 donne à \Seen une définition directe : le message a été lu. La RFC 9051, qui décrit IMAP4rev2, conserve cette sémantique. Ce vocabulaire fournit aux clients un état commun très utile. Il ne transforme pourtant pas le serveur en observateur de l’attention.
Les spécifications distinguent expressément l’« utilisateur », humain, du « client », logiciel. Le serveur reçoit des commandes, renvoie des octets et conserve des attributs. Il ne voit ni le regard, ni la compréhension. La conclusion la plus solide est donc la plus étroite : à l’instant observé, la boîte porte le drapeau normalisé de lecture. Toute conclusion sur une personne exige de connaître la cause du bit.
FETCH peut écrire ; PEEK peut ne rien changer
La frontière apparaît clairement dans la commande FETCH. Lorsqu’un client demande une section du corps par BODY[...], les RFC 3501 et 9051 prévoient l’activation implicite de \Seen. Si l’état change, le serveur doit rendre ce changement visible dans sa réponse. La lecture de données et la mutation du drapeau sont couplées par la commande.
BODY.PEEK[...] offre l’alternative qui récupère les mêmes données sans activer implicitement \Seen. Il existe dès lors plusieurs faits possibles : le corps a été récupéré avec mutation ; il a été récupéré sans mutation ; un STORE a activé le drapeau sans récupération ; une opération ultérieure l’a supprimé.
Ces possibilités ne rendent pas IMAP incohérent. Elles permettent les aperçus, les files « à relire » et la synchronisation. Elles empêchent seulement de confondre un état de protocole avec un capteur humain. Un indexeur, un filtre, un cache ou un générateur d’aperçu peut, selon sa commande, provoquer une mutation. À l’inverse, un client peut afficher des données obtenues par PEEK tout en laissant le drapeau absent. Ce sont des scénarios permis par le protocole, pas des accusations contre un produit donné.
Un message peut entrer déjà marqué
APPEND accepte des drapeaux initiaux. Les RFC donnent même des exemples où une copie arrive avec \Seen. Le bit décrit alors l’état choisi au moment de l’admission ; il ne prouve pas qu’une personne a lu cette nouvelle copie après son stockage.
STORE permet ensuite d’ajouter ou d’enlever le drapeau. « Marquer comme lu » peut modifier une liste entière sans afficher les corps. « Marquer comme non lu » peut effacer le bit après une lecture attentive. Dans une boîte déléguée, un autre client ou une autre personne autorisée peut créer l’état vu plus tard.
Ainsi, « non lu » ne signifie pas logiquement « jamais lu par un humain ». Il signifie que \Seen est absent maintenant. L’historique peut contenir un FETCH, une remise à zéro volontaire, une course de synchronisation ou un état importé que la valeur courante ne raconte plus.
L’autorisation modifie la trace durable
La RFC 4314 attribue à \Seen un droit propre, s. Un FETCH qui devrait activer le drapeau ne doit pas le faire si l’utilisateur courant ne possède pas ce droit. STORE vérifie le même droit pour modifier ce bit.
Deux identités peuvent donc récupérer le même corps et laisser des traces différentes. Pour l’une, le drapeau change ; pour l’autre, l’autorisation interdit cette écriture. L’absence du bit peut témoigner d’une politique d’accès et non d’une absence d’affichage.
Les implémentations peuvent aussi distinguer drapeaux partagés et non partagés. Il faut conserver la question complète : état de qui, dans quel modèle de boîte, écrit sous quel droit ? Une boîte personnelle, une boîte d’assistance partagée et une délégation de direction ne produisent pas une preuve équivalente parce qu’elles exposent le même nom de drapeau.
L’ordre des changements n’en révèle pas l’auteur
La RFC 7162 ajoute CONDSTORE et QRESYNC. Les séquences de modification aident un client à reconnaître une métadonnée plus récente, à mettre son cache à jour et à conditionner un STORE par UNCHANGEDSINCE. Elles évitent qu’une écriture obsolète efface silencieusement un changement concurrent.
Mais une séquence est un reçu d’ordre, pas une déposition. Elle ne dit pas seule si la cause fut un FETCH implicite, un STORE, un agent externe ou une action présentée à l’écran. Elle ne montre ni les pixels affichés ni l’attention accordée.
La RFC 8621 transporte la même idée dans JMAP avec le mot-clé $seen, que l’utilisateur autorisé peut ajouter ou enlever. Une synchronisation cohérente augmente la confiance dans l’état répliqué, pas dans les conclusions humaines qu’on lui prête.
Composer une preuve avec des reçus distincts
Un registre défendable commence par le principal authentifié, la délégation, l’instance cliente et la session. Il conserve ensuite l’incarnation de la boîte, notamment UIDVALIDITY, ainsi que l’UID du message. Puis il nomme la cause : FETCH du corps, PEEK, STORE, APPEND, synchronisation ou agent externe. Il joint sections demandées, drapeaux avant/après, réponse, heure et séquence de modification lorsqu’elle existe.
L’affichage dans l’interface est un événement séparé. L’accusé de réception humain en est encore un autre. Un journal honnête peut écrire : « corps récupéré, Seen activé implicitement, affichage inconnu, aucun accusé ». Cette phrase est moins séduisante que « lu ». Elle est beaucoup plus utile lorsqu’une décision est contestée.
IMAP a rendu l’état de la boîte interopérable. Il revient aux institutions de ne pas lui faire témoigner au-delà de ce qu’il a observé.
Sources
- Mark Crispin — IETF Datatracker
- Mark Crispin dans le mémorial 2012 de Stanford
- RFC 3501 — IMAP4rev1
- RFC 4314 — Droits de contrôle d’accès IMAP4
- RFC 7162 — IMAP CONDSTORE et QRESYNC
- RFC 8621 — JMAP Mail
- RFC 9051 — IMAP4rev2
- Portrait public de Mark Crispin — Consortium Unicode
- Mémorial de Mark Crispin — Consortium Unicode
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
