Résumé

  • RFC 5232 permet à Sieve de construire un ensemble de drapeaux pour le message qu’il traite, puis de l’associer à la copie remise par keep ou fileinto.
  • Cette demande n’est pas une modification générale du magasin IMAP : un drapeau que la boîte ne peut pas conserver durablement doit être ignoré, sans faire échouer le script à l’exécution.

Le marquage suit la remise du message

Un message entrant traverse plusieurs couches : il est analysé, orienté, puis déposé dans une boîte. Un drapeau IMAP appartient à l’état associé à un message stocké. En janvier 2008, RFC 5232 a relié le langage de filtrage Sieve à cet état, tout en laissant intacte la différence entre décider du sort d’un message courant et réécrire une boîte entière.

L’extension imap4flags impose quatre actions ou tests — setflag, addflag, removeflag et hasflag — ainsi qu’un argument :flags pour keep et fileinto. Les trois premières manipulent un ensemble de drapeaux ; le test vérifie si certains noms y figurent. L’argument accompagne la copie du message en cours lors de son classement.

Cet ensemble vit le temps d’une exécution Sieve. Il est vide au démarrage. setflag le remplace, addflag l’enrichit et removeflag en retire des éléments. hasflag peut examiner l’ensemble courant. Si l’extension distincte Variables est prise en charge, le script peut également nommer plusieurs ensembles ; sinon, un nom de variable explicite provoque une erreur. Les noms de drapeau ne se distinguent pas par la casse et le script ne doit pas compter sur la conservation de leur ordre, de leur graphie ou de doublons.

Le passage décisif intervient à la remise. Pour keep ou fileinto, un :flags explicite fournit les drapeaux de la copie classée. En son absence, l’action reprend la valeur de la variable interne. Cette valeur s’applique aussi au keep implicite, c’est-à-dire au comportement par défaut si aucune action de remise explicite ne l’a remplacé. Un script peut donc accumuler un marqueur dans une branche, puis le transmettre lors du classement — ou fournir une liste différente au moment de l’action.

Le périmètre est volontairement étroit : RFC 5232 porte sur le message traité par cette exécution Sieve. Elle n’autorise pas le script à choisir un autre message dans une boîte et à en modifier les drapeaux. Elle ne modifie pas non plus un message séparé qui serait créé comme effet secondaire d’une autre action. Il s’agit d’un raccord au moment de la remise, pas d’une API générale de mutation IMAP.

La boîte destinataire impose une seconde limite. :flags exprime les drapeaux souhaités pour la copie remise ; il ne peut pas rendre chaque drapeau persistant dans tous les magasins. L’interpréteur doit ignorer ceux que la boîte ne peut pas conserver durablement, sans transformer cette impossibilité en erreur d’exécution Sieve. L’exemple de la RFC indique que fileinto :flags "\\Deleted" équivaut à fileinto si la boîte ne peut pas stocker ce drapeau. En IMAP, \\Deleted marque un message en vue d’une expurgation ultérieure ; ce n’est pas un reçu d’effacement physique.

Dire « la règle a posé le drapeau » fusionne donc plusieurs événements possibles. Une branche a pu être évaluée ; l’interpréteur a pu produire une liste ; l’action de remise a pu la demander ; la boîte a pu n’en conserver qu’une partie durablement ; un client a ensuite pu afficher l’état résultant. Ces observations ne se remplacent pas. RFC 5232 ne précise pas si l’interpréteur se connecte au serveur IMAP comme client ou s’il accède directement au magasin. L’architecture peut varier, tandis que la limite de portée reste la même.

Un dernier détail compte quand plusieurs actions se rejoignent : si l’élimination de doublons fusionne plusieurs keep ou fileinto, la dernière valeur de drapeaux doit l’emporter. La copie qui subsiste n’est pas nécessairement l’union de toutes les intentions intermédiaires. L’ordre des actions et la règle de remise réelle doivent être examinés ; la simple présence de plusieurs addflag dans le script ne permet pas de déduire l’état final.

RFC 5232 côtoie le langage Sieve de base (RFC 5228), les variables (RFC 5229) et les comparaisons relationnelles (RFC 5231). Ces textes éclairent le traitement des tests et des valeurs, sans déplacer la frontière de remise. Plus tard, RFC 9051 distingue les drapeaux permanents des drapeaux de session et déprécie \\Recent : demande de marquage et état durable ne sont pas synonymes. La norme décrit un contrat, pas la conformité d’un serveur nommé, l’arrivée effective d’un message ou la façon dont un client a montré son badge.

Sources