Résumé

  • RFC 9979 harmonise 17 mots-clés IMAP/JMAP et trois attributs de boîte. Il distingue soigneusement une assertion du serveur, une action du client, un conseil d’affichage et un état susceptible de déclencher une action.
  • $istrusted ne vaut pas preuve autonome d’authenticité, $unsubscribed constate une tentative et non son succès, $new règle l’attention plutôt que l’âge, et Scheduled nomme un lieu de stockage plutôt qu’un envoi.

Le badge était encore visible sur le téléphone, l’ordinateur portable et le webmail. Partout, le message apparaissait comme « digne de confiance ». Le classement était donc parfaitement synchronisé. Lorsqu’un analyste demanda quel contrôle avait vérifié le nom affiché et l’adresse, personne ne retrouva la version de règle. La migration avait copié le mot-clé, pas son dossier de preuve.

Ce scénario est construit ; il n’accuse aucun service réel. Il montre la limite précise de RFC 9979, document IETF informatif publié en mai 2026. Le texte donne un sens partagé à 17 mots-clés de message et trois attributs de boîte déjà employés par plusieurs implémentations. Cette normalisation réduit les collisions de noms. Elle ne transforme pas chaque occurrence en constat certifié.

Le registre IANA des mots-clés IMAP/JMAP conserve le nom, le type privé ou partagé, l’usage, le périmètre et la référence normative. Le registre des attributs de boîte inscrit notamment Memos, Scheduled et Snoozed. Le registre coordonne le vocabulaire mondial ; il n’exécute ni analyse de message, ni désabonnement, ni remise SMTP.

La provenance est d’autant plus importante que les étiquettes n’ont pas toutes le même auteur. Certaines sont posées par le serveur lors de la livraison. D’autres sont ajoutées ou retirées par le client à la suite d’un geste de l’utilisateur. Certaines restent consultatives ; $followed ou $muted peuvent modifier le traitement automatique. Copier le jeton sans son acteur efface une part de sa signification.

RFC 5788 a créé le registre des mots-clés. RFC 8457 avait déjà organisé le partage de l’importance. RFC 9051 définit IMAP4rev2 et RFC 8621 JMAP Mail. L’accord entre protocoles permet à plusieurs clients de voir le même état. Il ne prouve pas que la décision locale qui l’a produit était juste.

La paire pièce jointe l’illustre sans enjeu de confiance. $hasattachment et $hasnoattachment s’excluent mutuellement. L’absence du premier n’est pourtant pas le second : le serveur ou le client n’a peut-être jamais analysé la structure MIME. Il faut donc préserver trois valeurs — oui, non vérifié, inconnu — là où une interface binaire ne montre qu’un trombone ou du vide.

JMAP doit faire correspondre sa propriété hasAttachment à cet état. Une égalité entre IMAP et JMAP atteste la cohérence des projections. Elle n’indique pas quel parseur a travaillé, sur quelle version du message, à quelle heure ni avec quelle règle. Une même erreur peut être reproduite sans divergence sur tous les écrans.

Les mémos introduisent un problème de transaction. $memo marque le message qui contient la note personnelle ; $hasmemo marque le message annoté. Création et suppression imposent de mettre à jour les deux extrémités. RFC 8474 fournit les identifiants d’objet utilisés pour stabiliser ce type de relation. Une interruption entre deux écritures peut laisser un état syntaxiquement licite mais causalement faux.

$istrusted porte un risque plus direct. RFC 9979 en fait une assertion consultative du serveur : le nom de l’expéditeur et son adresse auraient été vérifiés avec un degré de confiance élevé. Le texte avertit qu’une mauvaise application peut conduire l’utilisateur à croire un message frauduleux. Il interdit surtout de poser ce mot-clé sur la seule base d’un passage SPF, DKIM ou DMARC.

Cette restriction respecte ces mécanismes au lieu de les dévaloriser. RFC 7208 traite de l’autorisation d’un hôte pour une identité d’enveloppe. RFC 6376 lie une signature de domaine à certaines parties du message. RFC 9989 évalue l’alignement avec le domaine d’auteur visible et une politique demandée au destinataire. Ces preuves ne certifient automatiquement ni le nom humain affiché, ni l’autorité professionnelle, ni l’innocuité du contenu.

Le « degré élevé » reste une décision locale. RFC 9979 ne fixe ni algorithme universel, ni seuil. Cette liberté rend nécessaire un reçu parallèle : serveur assertant, classes de preuves, version du classificateur, score ou bande de confiance, date, durée, cause de révocation et responsable. L’interface peut résumer, mais elle ne devrait pas donner au badge une portée plus large que le dossier.

Le chapitre de sécurité désigne aussi le maillon de confiance. Client et utilisateur doivent pouvoir se fier au serveur IMAP ; un serveur compromis ou malveillant peut manipuler les mots-clés afin de tromper. Une synchronisation impeccable propage alors fidèlement une assertion fausse. Le consensus des écrans n’est pas une source indépendante.

Le désabonnement sépare capacité, tentative et résultat. $canunsubscribe signifie qu’un mécanisme List-Unsubscribe conforme a passé les contrôles de réputation propres au serveur. RFC 8058 décrit le signal « one-click ». Cela autorise raisonnablement l’affichage d’une commande ; cela ne constate pas son exécution.

$unsubscribed signifie que l’utilisateur a tenté l’action, même si aucune confirmation de succès n’est arrivée. Il ne doit pas être posé quand l’échec est certain. Le mot courant paraît achevé, mais la machine d’état ne l’est pas : offre, tentative, échec certain, résultat inconnu et succès confirmé doivent rester distincts. Quand les courriels continuent, le support a besoin du reçu externe, pas d’un participe passé.

Les états d’attention ne sont pas des horloges. $new peut faire ressortir un vieux message qui revient après une période de snooze. $notify demande une notification à un client compatible, sous réserve des préférences de l’utilisateur. Ni l’un ni l’autre ne prouve une date d’arrivée, un affichage, une lecture ou une réaction.

Les attributs de boîte ont la même modestie. Snoozed désigne l’emplacement des messages différés et ne définit pas le mécanisme de réveil. Scheduled désigne l’endroit où sont conservés des messages destinés à partir plus tard. Leur présence ne vaut ni déclenchement, ni acceptation par le relais, ni livraison. Il faut relier planification, essai d’envoi, réponse de transport et résultat final.

La paire $followed/$muted expose enfin le prix d’un historique perdu. Les états sont incompatibles ; s’ils coexistent, followed l’emporte. La règle évite des comportements divergents, mais n’explique pas si le conflit vient d’un ancien client, d’une course, d’une restauration ou d’une intrusion. RFC 9979 conseille de contrôler et éventuellement d’annuler les mises en sourdine après récupération d’un compte compromis.

Le silence peut alors devenir une action de sécurité. Un attaquant ayant accès à la boîte peut masquer une conversation de récupération, une alerte de paiement ou une réponse critique. Changer le mot de passe sans revoir les états synchronisés restaure l’accès au compte, pas l’intégrité de l’attention.

La notice RFC Editor et la recherche d’errata fixent la version documentaire à lire. Elles ne démontrent aucune implémentation, aucun seuil de confiance, aucun message classé ni résultat de livraison. L’employeur d’un auteur ne constitue pas une preuve de déploiement.

Les couches de réalité de Heng Lu ordonnent le problème : registre, règle locale, assertion serveur, état synchronisé, présentation, croyance humaine, action et résultat extérieur sont huit objets. Running-Code Primacy place l’exécution observable avant le symbole. Minimum Initial Specification justifie un langage commun mince sans absorber le jugement des opérateurs.

Le reçu utile conserve donc identité du message, du fil ou de la boîte, mot-clé exact, acteur autorisé, serveur et client, protocole, état antérieur et nouveau, règle ou geste, référence de preuve, confiance, heure, expiration, événement de synchronisation, présentation, préférence, action, résultat et correction. Les éléments sensibles peuvent rester protégés. Leur existence et leur propriétaire ne doivent pas disparaître.

RFC 9979 transporte des significations pratiques. La discipline consiste à ne jamais leur faire transporter, en plus, une preuve qu’elles ne contiennent pas.

Sources