Résumé

  • Le RFC 9661 distingue le dépôt des octets, leur validation, l’enregistrement de l’objet SieveScript et l’activation d’un script unique par compte.
  • Une réponse positive à SieveScript/set prouve une transition administrative ; elle ne prouve ni le chargement du blob par tous les moteurs de livraison ni le traitement attendu d’un message précis.
  • Le reçu solide relie empreinte du blob, capacités de validation, état conditionnel, activation, relecture croisée, génération du worker, trace du message et résultat final.

Le basculement paraît irréprochable. Le nouveau script est téléversé, validé, créé puis activé avec onSuccessActivateScript. La réponse place l’ancien à false et le nouveau à true. Pourtant, le premier message de contrôle arrive encore dans le dossier prévu par l’ancienne règle.

Il n’y a pas nécessairement contradiction. Il y a deux périmètres de vérité.

Le RFC 9661 décrit la gestion des scripts Sieve par JMAP. L’objet expose un identifiant, un nom unique, un blobId et l’indicateur serveur isActive. Ce modèle rend l’administration observable et automatisable. Il ne normalise pas la topologie interne qui transporte cet état jusqu’aux processus chargés de la livraison finale.

Une commande, plusieurs frontières

Le blob reçu n’est encore qu’un contenu conservé. SieveScript/validate vérifie ce contenu sans le stocker comme script. Cette validation porte sur la syntaxe et sur les extensions annoncées par le serveur. Le RFC 5228 rappelle qu’une erreur d’exécution peut n’apparaître qu’au passage d’un vrai message : validité et réussite opérationnelle ne sont donc pas synonymes.

La mutation de l’objet vient ensuite. Le mécanisme ifInState du RFC 8620 permet de refuser une écriture si la collection a changé depuis sa lecture. C’est une protection essentielle contre les modifications concurrentes. Le jeton reste toutefois un marqueur opaque d’état JMAP, pas une attestation cryptographique du code chargé en mémoire dans chaque worker.

L’activation est enfin liée au succès global des créations, mises à jour et suppressions demandées. Cette atomicité évite un demi-basculement dans la transaction JMAP. Mais la transaction s’arrête à son propre bord. Un cache de script compilé, une file d’invalidation retardée, une réplique en retard ou un pool non redémarré peuvent prolonger l’ancienne réalité d’exécution.

La cohérence JMAP–ManageSieve est nécessaire, pas suffisante

Le RFC 9661 vise un accès cohérent aux mêmes scripts par JMAP et par ManageSieve. Une relecture depuis les deux interfaces est donc un contrôle naturel : nom actif, contenu et identité doivent converger. Un désaccord révèle immédiatement un problème de stockage ou de projection.

Mais deux interfaces peuvent lire la même base alors qu’un moteur de livraison utilise encore une version compilée plus ancienne. Le bon objet de preuve n’est pas « le compte a Sieve ». C’est l’ensemble formé par le compte, l’id du script, l’empreinte du blob, la génération active, l’identité du worker, le message témoin et la décision observée.

Sieve s’exécute lors de la livraison finale. Un message absent ne démontre pas automatiquement discard : rejet en amont, retard, filtrage antispam, défaut de routage et panne de stockage produisent des symptômes voisins. Pour prouver l’action, il faut injecter un message marqué de façon unique par le véritable chemin d’entrée, conserver son acceptation, identifier le worker, puis observer le classement, la redirection ou la décision d’abandon.

La provenance compte autant que l’état

Le cas VacationResponse du RFC 8621 rend cette discipline visible. Un serveur peut matérialiser la réponse d’absence sous forme de script Sieve. JMAP Sieve peut alors la lire et l’activer, mais ne doit ni modifier son contenu ni la détruire par SieveScript/set. L’autorité d’écriture reste attachée à VacationResponse/set.

Cette séparation empêche deux interfaces légitimes de devenir, par commodité, deux auteurs concurrents. Chaque script devrait donc porter une provenance : éditeur Sieve, génération depuis une réponse d’absence, restauration, ManageSieve ou automatisation. Une activation correcte d’un objet de provenance inconnue peut être techniquement valide et organisationnellement dangereuse.

Le RFC 9404 apporte la gestion des blobs et le RFC 9425 la visibilité sur les quotas. Le registre JMAP de l’IANA fixe le vocabulaire public. Ces couches bornent les possibilités ; elles n’observent pas l’exécution d’un message.

Construire la preuve à rebours

Partir du résultat évite de confondre intention et effet. Pour un message témoin, enregistrer l’action attendue, le worker de livraison et la génération Sieve chargée. Rattacher cette génération à l’id actif et à l’empreinte exacte du blob. Conserver ensuite la réponse d’activation, l’ancien et le nouvel état, la précondition ifInState, le résultat de validation et l’instantané des capacités.

Les essais négatifs sont indispensables : id inexistant qui ne modifie pas l’actif courant, suppression du script actif refusée avec sieveIsActive, erreur d’exécution contrôlée malgré une syntaxe valide, modification d’un script d’absence refusée depuis la mauvaise interface, quota saturé et redémarrage d’un worker. Une preuve qui ne garde que le chemin heureux est un tableau de bord, pas un dossier d’incident.

La spécification initiale minimale de Heng Lu fournit la bonne limite institutionnelle : normaliser ce qui doit être partagé, puis soumettre les choix locaux à la preuve. Les couches de réalité empêchent le mot « actif » d’emprunter l’autorité du résultat. La primauté du code en fonctionnement donne le dernier mot au moteur qui a réellement traité le message.

Le RFC 9661 ferme proprement la transaction de contrôle. L’organisation doit encore fermer la boucle d’exécution.

Sources