Résumé

  • Le RFC 9979 enregistre $istrusted comme mot-clé IMAP/JMAP partagé et consultatif, appliqué par le serveur à la livraison lorsque le nom et l’adresse de l’expéditeur ont été vérifiés avec un haut degré de confiance. Un simple succès SPF, DKIM ou DMARC ne suffit expressément pas.
  • Plusieurs clients peuvent transformer cet état en indicateur de vérification. Le jeton ne prouve pourtant ni l’innocuité du contenu, ni la justesse de l’interface, ni l’autorisation d’agir, ni la validité durable du verdict.
  • Daniel Kade propose une trace de correction sobre en données : elle relie la base et la version de politique du serveur, l’état synchronisé, la présentation au lecteur, les effets matériels et la rectification, sans copier le message ni les secrets.

La confiance visible a une histoire que le bit ne raconte pas

Un fournisseur de messagerie reconnaît l’un de ses propres avis adressés à un client. Le service de réception possède des éléments suffisamment solides sur le nom affiché et l’adresse pour poser $istrusted. L’application de bureau montre une coche ; le téléphone parle d’un « expéditeur vérifié ». Le lecteur ne voit pas la règle qui a produit le verdict, mais il comprend que son fournisseur se porte garant de l’identité affichée.

Quelques jours plus tard, l’enquête établit que le marquage était injustifié. La source de preuve avait été classée trop largement, une ancienne règle était restée active, ou le serveur avait été compromis. Effacer le mot-clé corrige l’état courant. Cela ne répond pas aux questions rétrospectives : quelles copies ont reçu l’indication, quels clients l’ont rendue visible, quelle formule ont-ils employée et quelles mesures faut-il prendre auprès de ceux qui s’y sont fiés ?

Publié en mai 2026 dans la série IETF comme document d’information, le RFC 9979 définit dix-sept mots-clés de message et trois attributs de nom de boîte déjà utilisés dans différents logiciels. L’enregistrement évite les collisions et fixe un usage attendu. Il s’agit d’une œuvre de coordination : serveurs et clients peuvent partager un vocabulaire sans supposer que le même nom désigne partout la même chose.

Pour $istrusted, la formulation est exigeante. Le serveur doit avoir vérifié avec un haut degré de confiance l’authenticité du nom et de l’adresse de l’expéditeur. Le cas typique est celui d’un fournisseur qui reconnaît ses propres messages envoyés à sa clientèle. Un client compatible peut alors afficher un indice permettant de différencier une communication authentique d’une usurpation.

Le texte refuse le raccourci le plus tentant. Le serveur doit être prudent, car le mot-clé transmet de la confiance et son attribution erronée peut convaincre l’utilisateur de croire un fraudeur. Il ne doit pas le poser uniquement parce que SPF, DKIM ou DMARC a réussi. Ces mécanismes produisent des faits utiles dans leurs domaines respectifs ; ils ne constituent pas, à eux seuls, la conclusion renforcée que représente $istrusted.

Le registre coordonne une assertion, pas toute sa responsabilité

Dans le registre IANA des mots-clés IMAP et JMAP, $istrusted est partagé, d’usage courant et utilisable dans les deux protocoles. Sa fiche le qualifie de consultatif et attribue sa mise en place au serveur lors de la livraison. Ces champs distribuent déjà des rôles importants : l’assertion vient du serveur, circule comme état partagé et informe le client sans commander automatiquement une action.

Ils ne contiennent cependant ni dossier de preuve, ni identifiant de règle, ni date d’observation des éléments, ni procédure d’appel. Le client reçoit une conclusion, pas le raisonnement complet. Inversement, le serveur ne sait pas nécessairement comment chaque interface l’a exprimée. Une petite coche, un bandeau solennel, une annonce vocale ou l’absence totale d’indicateur transmettent des intensités très différentes.

Les autres entrées du RFC illustrent cette variété. $new attire l’attention et peut être retiré après interaction. $notify peut déclencher une notification. $muted, posé par un client, peut conduire le serveur à réduire la visibilité des futures réponses d’un fil. $unsubscribed signifie qu’une tentative de désabonnement a eu lieu, et non qu’elle a abouti. Chaque mot-clé délimite un fait ou une demande ; aucun ne remplace toutes les étapes du processus.

Le cas des attributs de boîte est encore plus clair. Snoozed permet de reconnaître l’emplacement où résident les messages reportés, mais le RFC précise qu’il ne définit pas à lui seul le mécanisme ni l’interface de report. Le registre IANA des attributs de boîte rend un rôle découvrable ; il ne devient pas l’ordonnanceur. De même, $istrusted transporte un jugement sans devenir son système d’audit et de correction.

Authentifier un nom n’approuve pas ce que le message demande

La portée sémantique doit rester visible. Le RFC parle de l’authenticité du nom dans From et de l’adresse associée. Il ne garantit pas que chaque phrase soit exacte, qu’un lien conduise vers un site inoffensif, qu’une pièce jointe soit sans danger ou qu’un paiement soit dû. Un expéditeur authentique peut se tromper, être mal conseillé ou envoyer une demande qui ne devrait pas être exécutée par ce destinataire.

L’interface peut pourtant élargir silencieusement le sens. « Identité reconnue par votre fournisseur » respecte la frontière. « Courriel sûr » certifie bien davantage. Placer la coche contre un bouton de transfert de fonds peut aussi transformer une information d’identité en quasi-autorisation. Le mot-clé partagé ne mémorise aucune de ces décisions de conception.

Il serait inefficace de demander à tous les clients de répéter les contrôles du serveur. L’intérêt d’un état posé en amont tient justement à sa cohérence et à son coût mutualisé. La discipline consiste plutôt à distinguer les propriétaires : le serveur décide de l’authenticité de l’expéditeur ; le client décide de la manière de l’expliquer ; le destinataire décide d’une action ultérieure. Aucun verdict ne doit se faire passer pour le suivant.

Why BTW Media Exists fournit ici une règle éditoriale utile : rapporter ce qui peut être observé avant de raconter ce que l’on aimerait en déduire. L’observation exacte est qu’un serveur déterminé, sous une politique déterminée, a appliqué un mot-clé à un message. L’innocuité générale du courriel est une affirmation supplémentaire.

La fiabilité du serveur fait partie de la preuve

La section de sécurité du RFC 9979 place le problème au bon endroit. L’usage et l’interprétation de ces mots-clés dépendent de la capacité du client et de l’utilisateur à faire confiance au serveur IMAP. Un serveur compromis ou malveillant peut manipuler les états afin de les tromper. Le badge ne témoigne donc pas indépendamment de l’infrastructure qui l’a émis.

Une capture d’écran prouve au mieux qu’une interface a montré un indice à un instant donné. Pour reconstituer la décision, il faut relier cet affichage à l’état synchronisé, au serveur émetteur, à la version de son moteur de décision et à la catégorie de preuve admise. Si l’intégrité du serveur est contestée, $istrusted devient une pièce du dossier à vérifier, non l’arbitre du dossier.

Le caractère partagé introduit en outre une temporalité. Le serveur peut retirer le mot-clé, le portable connecté peut se mettre à jour immédiatement, l’ordinateur hors ligne peut garder une copie ancienne et une notification déjà affichée peut subsister dans la mémoire du lecteur. Le RFC ne promet pas un comportement uniforme des caches et interfaces. Dire « nous avons effacé le bit, donc la confiance a été retirée partout » dépasserait les faits.

The Policy Mirror invite à faire correspondre la politique aux contrôles réels. Ici, la décision appartient au serveur, la propagation au mécanisme de synchronisation, l’expression au produit et l’action finale à la personne ou au système en aval. Une politique valable doit nommer ces plans séparément pour savoir qui peut corriger quoi.

Une trace minimale peut suivre la correction sans surveiller la lecture

Il ne faut pas répondre par l’archivage massif du courrier. Le corps du message, les identifiants secrets, les clés, les traces cryptographiques détaillées et toute l’activité de lecture créeraient un gisement de données disproportionné. La question est plus étroite : comment une conclusion du serveur a-t-elle voyagé jusqu’à une surface humaine, et comment sa modification a-t-elle été propagée ?

Une trace de correction peut préserver six plans. Le premier identifie le message par un identifiant limité à la boîte ou un condensat salé, avec l’heure de livraison et le périmètre du compte, sans recopier le contenu. Le deuxième nomme le service de décision, les catégories de preuves, l’époque de politique, l’heure et une bande de confiance, sans secrets bruts.

Le troisième enregistre l’événement d’état : origine de $istrusted, version, portée de synchronisation, retrait ou remplacement et classe de motif. Le quatrième décrit grossièrement mais utilement le rendu : famille et version du client, libellé, équivalent d’accessibilité, première et dernière visibilité connues, possibilité d’obtenir une explication.

Le cinquième n’enregistre que les conséquences matérielles que l’organisation est légitime à observer, par exemple l’ouverture d’un parcours à risque pendant que l’indicateur était présent. Il exclut le contenu et les comportements sans rapport. Le sixième conserve la correction : autorité d’enquête, nouvelle conclusion, intervalle touché, clients ou comptes informés, réparation, voie de recours et responsable de clôture.

La trace doit accepter l’incertitude. Le serveur ne doit pas affirmer que l’icône a disparu simplement parce qu’il a modifié son état. Le client ne doit pas reconstruire une preuve d’authenticité à partir d’une image locale. L’équipe d’incident ne doit pas imputer une action au badge si elle ignore ce qui était visible. Le rôle de la trace est d’empêcher ces sauts, pas de les lisser.

Cette proposition est celle de Daniel Kade, non une obligation du RFC 9979. Elle ne change pas la sémantique du protocole. Elle rend révisable la vie opérationnelle de l’assertion.

Sources