Résumé

  • RFC 3028 a limité le filtrage à un langage d’actions contrôlable et a prévu une conservation implicite lorsqu’aucune action influant sur la remise n’était exécutée.
  • Les verbes keep, fileinto, redirect, discard et le refus exprimaient une décision locale ; ils ne constituaient pas une preuve de stockage, d’acceptation distante ou de résultat final.

Au tournant de 2001, le filtrage côté serveur obligeait à concilier deux besoins opposés. L’utilisateur voulait trier ou renvoyer ses messages avant de les lire. L’opérateur ne pouvait pas lui ouvrir un environnement de programmation général sur la machine chargée de la remise. Une boucle mal bornée ou un programme externe suffisait à transformer un confort personnel en risque partagé.

Sieve a été conçu par soustraction. Le langage de RFC 3028 ne comportait ni boucle, ni fonction, ni appel à un interpréteur de commandes. Les tests observaient sans produire d’effet de bord. Les structures de contrôle choisissaient un bloc. Les actions demandaient une disposition du message. Ce partage rendait une règle lisible, mais surtout permettait au site de borner les effets possibles.

La branche oubliée devait rester sûre

Une règle de courrier vieillit mal. Une liste change d’adresse, un expéditeur modifie son domaine, un utilisateur inverse une condition. Si le fait de ne reconnaître aucun cas entraînait la disparition du message, chaque omission deviendrait une perte silencieuse. La « conservation implicite » répondait à ce risque : faute d’action qui l’annule, le système appliquait sa remise ordinaire, généralement dans la boîte principale.

Cette protection n’ajoutait pas automatiquement une copie après chaque action. keep, fileinto, redirect et discard annulaient la conservation implicite. L’interpréteur devait donc calculer les relations entre actions. Une extension qui produisait un effet secondaire sans décider du sort du message devait déclarer si elle laissait subsister le filet de sécurité.

La sémantique de discard devient alors moins brutale que son nom. L’action annule la conservation implicite en silence ; elle n’efface pas les autres actions compatibles. Un fileinto suivi de discard conserve le dépôt dans le dossier et évite simplement la copie par défaut. Le standard ne donnait pas au mot son sens courant absolu : il définissait précisément ce qu’il retirait de l’ensemble d’actions.

Choisir une destination n’était pas la réaliser

keep demandait le comportement habituel de la plate-forme. Le script n’avait pas à connaître le nom physique de la boîte, le format du magasin ou le mécanisme de transaction. Cette abstraction protégeait la portabilité, mais elle empêchait aussi de prendre le succès de l’évaluation pour une preuve d’écriture durable.

fileinto indiquait un dossier. RFC 3028 recommandait l’action tout en admettant que certains environnements ne pouvaient pas l’offrir. Un dossier nommé dans une règle restait donc une demande adressée à l’agent de remise. L’existence du dossier, les droits et la validation de l’écriture appartenaient à une autre couche.

redirect lançait un renvoi de type MTA : le destinataire d’enveloppe était remplacé et le message repartait. La décision locale pouvait être parfaitement correcte alors que le serveur distant refusait plus tard le courrier. La prévention des boucles relevait elle aussi de l’implémentation. Le renvoi ouvrait un nouvel épisode de transport ; il n’en fournissait pas le récépissé.

discard, enfin, devait rester silencieux. Aucun avis de non-remise ne confirmait l’opération à l’expéditeur. Cette absence de signal pouvait être voulue, mais elle obligeait l’opérateur à distinguer soigneusement la trace de décision de l’absence générale de courrier.

Les combinaisons d’actions formaient une politique

Plusieurs actions sur un même message pouvaient se renforcer, se neutraliser ou se contredire. RFC 3028 imposait aux extensions d’expliquer leurs interactions avec le noyau. Le site pouvait limiter le nombre d’actions et interdire des associations. Une implémentation ne devait pas déposer deux fois le même message dans la même boîte au seul motif que le script l’avait demandé deux fois.

Ces contraintes maîtrisaient l’amplification. Des redirections répétées pouvaient créer une bombe de courrier. Un refus combiné à une livraison pouvait annoncer un échec à l’expéditeur tout en gardant le message. Traiter chaque verbe comme une tâche autonome aurait détruit le sens de la décision globale.

RFC 5228 a remplacé le texte de 2001 sans abandonner cette architecture. Il a précisé le traitement des erreurs et les obligations des extensions. Puis RFC 9122 a créé un registre IANA des actions Sieve qui indique notamment leurs interactions et si elles annulent la conservation implicite. Ce registre documente des contrats d’exécution ; il ne certifie aucun résultat particulier.

Le refus a révélé une frontière mal placée

Dans RFC 3028, l’extension reject jetait le message et envoyait une notification de disposition à l’expéditeur d’enveloppe. Or le système pouvait avoir accepté le courrier avant de produire cette notification. Quand l’adresse source était usurpée, un tiers innocent recevait le retour : le mécanisme contribuait au « backscatter ».

RFC 5429 a corrigé le modèle avec ereject, qui privilégie un refus pendant l’échange SMTP ou LMTP lorsque c’est possible. Le texte a aussi précisé que le refus annule la conservation implicite, interdit plusieurs refus pour un message et déconseille l’association du refus avec des actions de remise. Il s’agissait de cohérence factuelle : on ne doit pas annoncer la non-remise d’un message que l’on a également stocké ou renvoyé.

« Rejeté » pouvait donc recouvrir trois réalités : une règle a choisi l’action ; le composant possédait ou non la capacité de refuser à ce stade ; l’expéditeur a observé une réponse de session, une notification ultérieure ou aucun signal. Sans couche ni preuve, le mot ne suffisait pas.

ManageSieve, normalisé par RFC 5804, a ensuite séparé l’administration des scripts—dépôt, validation, liste, activation—de leur évaluation par message. Cette distinction confirme la chaîne : un script actif n’est pas une action exécutée, et une action choisie n’est pas un résultat constaté.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3028, RFC 5228 ou RFC 5429. Ses essais servent ici de grilles d’analyse déclarées.