Résumé

  • La RFC 6154, publiée en mars 2011, a défini des attributs facultatifs dans les réponses IMAP LIST. Un client peut chercher \Sent, \Drafts ou \Trash au lieu d’inférer la fonction d’un dossier à partir du nom que voit l’utilisateur.
  • \Sent peut décrire un rangement automatique du serveur ou simplement indiquer où le client doit enregistrer les copies. Un dossier peut porter plusieurs fonctions, et plusieurs dossiers peuvent afficher la même fonction.
  • La commande LIST étendue peut annoncer SPECIAL-USE. Les fonctions facultatives de CREATE et METADATA permettent de demander ou modifier un rôle, sous réserve de l’accord du serveur. Le registre de l’IANA conserve les noms d’attributs et leurs références.

Deviner le nom, c’était confier une décision au hasard

Deux logiciels ouvrent le même compte de messagerie. Le premier dépose les copies envoyées dans un dossier qu’il croit être le bon ; le second en crée un autre. Le propriétaire du compte voit alors deux historiques. Il peut aussi n’en voir aucun si chaque logiciel attend que l’autre, ou que le serveur, sauvegarde la copie. L’erreur se présente comme un petit défaut de réglage. Elle touche pourtant le dossier qui permet à une personne de retrouver ce qu’elle a écrit.

Un guide de mise en œuvre IMAP de 1999 parlait déjà de noms usuels tels que « Sent Mail » et « Trash ». Les usages aident un administrateur et un lecteur. Ils ne donnent pas à un programme un contrat fiable. Le dossier peut porter un autre nom, être renommé ou changer de rôle sans changer de nom. Le client devait reconstituer une règle de stockage à partir d’une étiquette destinée aux humains.

La RFC 6154 a placé cette indication dans la réponse LIST du serveur. Elle a introduit sept attributs : \All, \Archive, \Drafts, \Flagged, \Junk, \Sent et \Trash. Un serveur peut les retourner avec les autres attributs de chaque boîte. Les noms visibles peuvent rester SentMail, MyDrafts ou ceux que l’utilisateur préfère ; le client interroge la fonction déclarée.

Le changement transfère la question au participant le mieux placé pour y répondre. Un logiciel fraîchement connecté ignore le plan de rangement du serveur. Le serveur connaît les boîtes qu’il expose et les usages qu’il leur attribue. Il peut donc fournir une carte machine lisible. Il ne retire pas à l’utilisateur le choix de ses dossiers, mais évite au client de prendre leur orthographe pour un protocole.

Une fonction annoncée ne range aucune lettre

Le point le plus intéressant est une ambiguïté assumée. La RFC dit que certains serveurs déposent automatiquement les copies de messages envoyés dans \Sent. Ailleurs, l’attribut conseille au client de les y déposer. Si le client attend une action du serveur qui n’a pas lieu, le dossier reste vide. S’il enregistre lui-même une copie alors que le serveur l’a déjà fait, il peut en créer deux. L’attribut permet de trouver le lieu prévu ; seule l’observation du message montre qui exécute le classement.

Les autres marques ont leur propre mécanique. \All peut être une vue virtuelle sur les messages et omettre ceux de \Trash ou \Junk. La portée de \Archive dépend du serveur. \Drafts peut être une boîte virtuelle ou la destination conseillée aux brouillons du client. \Trash peut refléter un modèle de suppression du serveur ou servir au client qui n’utilise pas directement le drapeau IMAP \Deleted. Un vocabulaire commun ne transforme pas ces modèles en un seul système de rangement.

Un même dossier peut n’avoir aucun attribut, en avoir un ou plusieurs. Plusieurs dossiers peuvent aussi porter \Sent. Le rôle est souvent propre à l’utilisateur : deux personnes peuvent partager une boîte physique sans considérer toutes les deux que c’est leur boîte d’envoi. Le client qui suppose une réponse unique et universelle répète l’ancienne erreur, cette fois à partir d’une chaîne normalisée.

Le registre IANA des attributs de boîtes IMAP stabilise les noms et les références de cette grammaire. Sa ligne pour Sent ne révèle ni les messages effectivement stockés, ni le programme qui les y a mis. Le registre coordonne les mots ; le magasin de courrier et ses clients produisent les faits.

Le serveur pouvait répondre oui, non ou autrement

La norme s’appuie sur le cadre LIST étendu. Dans ce cadre, le serveur annonce SPECIAL-USE dans CAPABILITY. Le client peut demander uniquement les boîtes marquées ou demander que leurs attributs spéciaux soient retournés. La sélection implique le retour des attributs. Un serveur peut aussi inclure ces marques dans une réponse LIST ordinaire ; cette forme n’a pas de chaîne CAPABILITY séparée. Pour lire une trace, il faut distinguer l’absence d’annonce dans un mode de l’absence de toute information possible.

Le client peut aller plus loin que la découverte. La RFC 6154 prévoit un paramètre USE facultatif sur CREATE pour demander qu’une nouvelle boîte ait un rôle donné. Le serveur annonce séparément cette faculté avec CREATE-SPECIAL-USE. Il peut refuser un conflit, déplacer un rôle existant ou permettre plusieurs boîtes avec la même fonction. S’il ne peut pas créer la boîte avec le rôle demandé, il doit rejeter toute l’opération : le client ne doit pas hériter d’une boîte créée à moitié configurée.

Pour les serveurs qui prennent en charge IMAP METADATA, l’entrée /private/specialuse peut décrire ou modifier les rôles d’une boîte existante. Les modifications doivent être validées selon les règles du serveur. Changer un nom visible, demander un rôle et déplacer un message sont trois actes distincts. Chacun a sa propre réponse et sa propre preuve.

L’enjeu de sécurité est concret. Si le serveur dépose automatiquement le courrier indésirable dans une boîte \Junk, permettre à un client de donner ce rôle à une boîte partagée peut exposer à d’autres personnes des messages légitimes classés à tort. La RFC 6154 cite précisément ce cas. Une marque devient un levier d’action dès que le serveur agit sur elle ; il lui revient d’accepter ou de refuser la demande en connaissance de cause.

La norme établit les façons de déclarer, demander et modifier un rôle. Pour savoir où un compte déterminé a rangé un message envoyé, il faut la réponse CAPABILITY/LIST datée, les éventuels échanges CREATE ou METADATA, et la place où la copie a réellement atterri. Le nom peint sur le dossier est le renseignement le moins sûr.