Résumé

  • NAMESPACE normalisait la découverte des conventions de nommage pour trois classes de boîtes aux lettres.
  • LIST, l’existence, SELECT, les droits, la récupération du message, son affichage et sa lecture restaient des faits distincts.

Le client recevait un mode d’emploi

Avant RFC 2342, un client IMAP demandait souvent à l’utilisateur le préfixe de ses dossiers personnels ou partagés. Le serveur pouvait employer une racine vide, INBOX., #shared/ ou une autre convention locale. NAMESPACE a permis de découvrir cette convention.

La réponse place dans un ordre fixe l’espace personnel, celui des autres utilisateurs et l’espace partagé. Chaque classe vaut NIL ou contient un ou plusieurs couples préfixe-délimiteur. Les espaces peuvent employer des séparateurs différents, et le serveur peut n’exposer qu’une partie de ceux qu’il prend en charge.

Le résultat est donc une grammaire liée à cette connexion. NIL signifie que la classe n’est pas disponible dans cette réponse ; il ne démontre pas une absence universelle. Un préfixe ~ permet de construire ~mark/INBOX ; il ne démontre ni Mark, ni INBOX, ni un droit accordé au demandeur.

Le silence de LIST pouvait être intentionnel

Pour l’espace des autres utilisateurs, RFC 2342 propose d’ajouter % au préfixe puis d’envoyer LIST. Mais le serveur ne devrait pas dévoiler les utilisateurs n’ayant pas accordé le droit de listage. Il peut ne renvoyer que les noms autorisés, ou refuser une requête large et exiger un nom d’utilisateur précis.

L’un des exemples rejette #Users/%, puis accepte #Users/Mike/%. La carte n’a pas changé. La politique d’énumération et la précision de la question ont changé. La retenue protège aussi la confidentialité : une liste de comptes est déjà une information utile à un attaquant.

RFC 9051 renforce cette limite. LIST renvoie un sous-ensemble de tous les noms disponibles au client, éventuellement aucun. Un nom peut porter \Noselect ou \NonExistent. Une sélection SUBSCRIBED peut même conserver le nom d’une boîte qui n’existe plus.

Une branche annoncée, un nom listé, un abonnement et une boîte sélectionnable ne décrivent donc pas le même état.

Le droit de voir n’était pas le droit de lire

RFC 4314 sépare les droits : l rend la boîte visible à LIST/LSUB ; r autorise SELECT et STATUS ; s gouverne la persistance de Seen/Unseen. D’autres droits couvrent insertion, création, suppression, expunge ou administration.

Une boîte peut ainsi être visible mais illisible. RFC 9051 décrit le cas d’un utilisateur qui possède l sans r : LIST voit le nom, STATUS échoue et la réponse doit signaler que la boîte n’est pas sélectionnable. RFC 8440 peut joindre MYRIGHTS à un LIST étendu, mais un droit reste une possibilité, pas la preuve qu’une opération a eu lieu.

SELECT apporte un reçu plus fort : une réussite place cette connexion dans l’état selected et retourne notamment FLAGS, EXISTS, UIDNEXT et UIDVALIDITY. Elle ne répond toujours pas aux questions suivantes : FETCH a-t-il livré le corps, le client l’a-t-il décodé, la fenêtre était-elle visible, quelqu’un a-t-il lu ?

Même \Seen ne tranche pas la dernière question. Un fetch, un moteur d’indexation ou une synchronisation peut le modifier. Le protocole observe l’état du message, pas l’attention humaine.

Une norme précise n’avait pas besoin de prétendre davantage

RFC 2342 a réussi parce qu’elle a limité sa compétence. Elle a rendu déterministe la construction de la prochaine commande sans présumer son résultat. C’est la différence entre un artefact de coordination et la réalité exécutée : la publication d’une convention ne crée pas les objets auxquels elle permet de faire référence.

Cette discipline reste utile bien au-delà d’IMAP. Un schéma peut définir un identifiant sans garantir son objet. Une capacité peut annoncer une commande sans garantir son succès. Un contrôle vert peut autoriser l’étape suivante sans certifier l’issue finale.

NAMESPACE indiquait où commencer à chercher. Il ne pouvait pas signer à la place de LIST, SELECT, FETCH, du client et du lecteur.