Résumé

  • RFC 5293 impose aux actions ordinaires de consulter l’en-tête courant, mais réserve l’en-tête original aux notifications de disposition et à la conservation implicite déclenchée par une erreur.
  • Les représentations modifiée et initiale comptent pourtant comme un seul message pour éliminer les doublons ; un journal probant doit donc nommer la vue, l’action et le résultat observé.

Le désaccord venait de l’archive, pas du protocole

Lors d’un contentieux, une équipe a produit la copie classée dans la boîte du salarié. Une autre a produit le DSN associé. La première comportait un sujet requalifié et une balise interne ; le second citait les champs initiaux. Chacun en a déduit que l’autre pièce avait été altérée.

RFC 5293 explique pourquoi cette conclusion est trop rapide. addheader et deleteheader modifient un état courant. Les tests exécutés ensuite voient cet état. Les actions de classement, d’envoi ou de transformation l’utilisent elles aussi. En revanche, un MDN, un DSN ou une notification comparable doit être construit depuis l’en-tête original non modifié. Si une erreur arrête le script, la conservation implicite exigée par Sieve repart également de l’original.

Il ne s’agit donc pas d’une copie maîtresse accompagnée d’erreurs. Deux vues différentes sont prévues par la norme pour des fonctions différentes.

L’ordre fait partie de la preuve

Par défaut, addheader insère le champ au début ; :last le place à la fin. deleteheader peut viser toutes les occurrences ou une position :index. Avec :last, le comptage part de la fin. La position est déterminée avant de tester le motif de valeur.

Surtout, la liste change à mesure que le script avance. Après la suppression de la première occurrence, la deuxième instruction ne travaille plus sur la liste initiale. Ajouter puis supprimer le premier X-Hello peut ne laisser aucune trace dans le résultat final, alors que ce champ a existé assez longtemps pour influencer une étape intermédiaire.

Un simple hachage final ne permet pas de rejouer cette histoire. Il faut l’ordre des actions et un hachage de l’état courant à chaque frontière.

Une identité commune ne veut pas dire des octets communs

Pour éviter les doublons, le message modifié reste le même que l’original. Deux demandes redondantes de conservation ne doivent produire qu’une copie, mais l’implémentation peut choisir laquelle elle exécute. La norme sépare ainsi identité de livraison et représentation binaire.

Cette distinction protège les boîtes contre les duplications, mais elle complique l’audit. Dire « une seule copie » ne révèle ni les en-têtes de cette copie ni l’action retenue. La déduplication répond à une question de multiplicité, pas à une question de provenance.

Les limites silencieuses sont aussi des décisions

Une politique locale peut interdire certaines modifications. La tentative est alors ignorée sans erreur. La suppression de Received et d’Auto-Submitted doit toujours être interdite, tandis que Subject doit pouvoir être ajouté ou supprimé. Cette protection empêche notamment le filtre d’effacer le mécanisme de trace utilisé contre les boucles SMTP.

Une exécution verte ne prouve donc pas que chaque ordre a pris effet. La télémétrie doit distinguer demande, autorisation locale et mutation réelle.

La signature révèle la pluralité

Une modification peut invalider DKIM, y compris lorsqu’une signature garantit l’absence d’un champ que le filtre ajoute ensuite. Pour S/MIME ou OpenPGP/MIME, une copie interne signée peut rester intacte alors que l’en-tête externe évolue. L’écart n’est pas forcément une fraude ; il faut savoir quelle couche le vérificateur a examinée.

La grammaire ne protège pas davantage contre l’usurpation. Un expéditeur peut placer sa propre balise X-Approved. Le système de confiance doit conserver la forme reçue, neutraliser les marques non fiables, puis émettre une assertion locale identifiable. Détruire l’original avant vérification revient à supprimer la possibilité d’expliquer la décision.

Un reçu en trois colonnes

Pour chaque action importante, il faut conserver l’identité du message, la représentation consultée et l’issue observée. Le reçu comprendra le hachage de l’en-tête original, l’inventaire ordonné des occurrences, la version du script, les comparateurs et motifs, les changements demandés et effectifs, ainsi que les hachages courant avant et après.

Il enregistrera aussi les vérifications cryptographiques, la règle de déduplication, le choix d’une action redondante, l’accusé de classement ou de soumission et l’observation indépendante de la destination. Un redirect sélectionné n’est pas encore une remise accomplie.

Sources