Résumé

  • JMAPACCESS engage le serveur sur un ensemble complet de messages accessible par IMAP et JMAP, avec une correspondance des identifiants d’objets.
  • Son annonce dépend de ce que le serveur peut déduire du mode d’authentification utilisé. Elle ne remplace pas une authentification JMAP effective.
  • L’identité ne fige ni la durée de vie d’un message ni tous ses états et représentations. La migration doit vérifier ces dimensions séparément.

La coexistence de deux protocoles est souvent présentée comme une commodité technique. Elle peut aussi masquer deux calendriers de sécurité. Un exploitant conserve les mots de passe sur IMAP pour les anciens clients, mais les désactive sur JMAP. Le même utilisateur réussit sa première connexion sans disposer, par cette voie, de ce qu’il lui faut pour la seconde.

Ce cas figure dans RFC 9698. Il donne à l’extension JMAPACCESS sa véritable unité de décision : pas seulement un serveur ou un compte, mais une authentification précise et ce qu’elle permet de déduire. Le texte de janvier 2025, répertorié comme Proposed Standard, facilite une migration progressive ou l’emploi de fonctions JMAP dans un client IMAP. Il ne certifie aucune migration particulière.

Ce que le serveur engage

Après un LOGIN ou AUTHENTICATE réussi, le serveur examine la méthode utilisée. S’il peut en déduire que les justificatifs suffisent pour JMAP, il doit inclure JMAPACCESS dans les listes de capacités envoyées ensuite. Les exemples citent un mécanisme OAuth commun ou une base de mots de passe commune. Ils décrivent des configurations possibles, pas les déploiements actuels des employeurs des auteurs.

L’extension ne couvre que l’équivalence complète des ensembles de messages. Un accès JMAP limité à certaines boîtes ne devient pas équivalent parce qu’il porte la même marque. Elle affirme également qu’une boîte ou un message portant un identifiant d’objet dans un protocole correspond au même objet, avec le même identifiant, dans l’autre.

Le serveur doit annoncer OBJECTID, défini dans RFC 8474. Un UID ordinaire, lié à une boîte, ne suffit pas à produire cette correspondance. Inversement, un identifiant d’objet n’est pas un passeport universel : RFC 8620 borne l’unicité d’un identifiant JMAP à un type de données dans un compte. Une procédure de rapprochement doit conserver ces deux coordonnées.

Une adresse ne fait pas une connexion

La demande s’appelle GETJMAPACCESS. Si le serveur connaît le service correspondant, il fournit une réponse non étiquetée JMAPACCESS contenant une seule URL de ressource Session, puis une réponse étiquetée OK. Sinon, il renvoie BAD et ne doit pas annoncer la capacité.

Un lecteur copiant l’exemple 2 original pourrait employer le mauvais verbe. L’erratum technique 8635, vérifié le 21 novembre 2025, remplace précisément la commande JMAPACCESS par GETJMAPACCESS. Cette correction documentaire n’atteste ni une vulnérabilité exploitée ni un changement du mécanisme d’authentification.

L’URL conduit à la ressource Session. Le client doit encore effectuer la requête GET authentifiée qui lui donnera les comptes et capacités disponibles avec ses justificatifs. L’extension n’en émet pas de nouveaux. La conclusion « cet accès devrait être possible » et l’observation « cet accès a réussi » ne sont pas le même événement.

La justification de sécurité de RFC 9698 est également circonscrite : le client possède déjà des justificatifs valides et peut découvrir l’adresse par la procédure JMAP existante. Les auteurs estiment donc faible l’intérêt supplémentaire de cette divulgation pour un attaquant. Cela ne dispense pas de vérifier la protection du transport, le destinataire et la politique d’authentification réellement déployés.

Le rapprochement doit survivre au temps

Supposons une lecture IMAP, puis une lecture JMAP une demi-seconde plus tard. La seconde peut échouer parce que le message a été supprimé entre les deux. Le RFC le dit explicitement : l’extension ne modifie pas sa durée de vie. Une absence observée après coup ne tranche donc pas, seule, entre suppression normale et correspondance erronée.

L’égalité des identifiants ne tranche pas davantage toutes les différences visibles. RFC 9698 encourage l’alignement des indicateurs et autres données, sans imposer lui-même des noms de boîtes identiques. RFC 8621 conserve toutefois ses propres règles sur les noms, rôles et appartenances. Son modèle peut garder l’identifiant d’un message lors d’un déplacement et permettre plusieurs appartenances simultanées. Les champs doivent être comparés selon leurs règles, pas comme deux captures d’écran censées être identiques.

EMAILID, dans RFC 8474, identifie le contenu immuable ; des instances portant cet identifiant peuvent avoir des mots-clés différents. Et, dans le cas IMAP ancien décrit par RFC 9698, l’absence d’activation de UTF8=ACCEPT peut produire des adresses dégradées là où JMAP fournit les champs exacts. RFC 6855 explique les limites de ces substituts, notamment pour répondre au message ou vérifier certaines signatures. Un objet commun n’efface pas la différence de représentation.

Les textes de Lu Heng sur la spécification initiale minimale, la primauté du code exécuté et les niveaux de réalité éclairent cette architecture. L’accord commun reste étroit ; sa réalisation appartient aux systèmes qui l’adoptent. C’est une grille éditoriale, distincte de la preuve technique fournie par les RFC.

Aucun fournisseur, incident ou gain de performance n’a été testé ici. La conclusion est opérationnelle : conserver des observations distinctes pour la capacité, l’adresse, l’authentification, l’objet, l’état actuel et l’action finale. Les réunir permet une décision. Les confondre permet seulement une annonce.