Les filtres Sieve permettent de gérer les mails côté serveur¹⁾.

La liste exacte des opérations de gestion (ou «traitements») possibles dépend de chaque serveur. De base, on pourra trier les courriels entrant dans des dossiers, les copier, les réexpédier (forward), les supprimer…

La norme recommande que les serveurs appliquent les filtres Sieve juste avant de procéder au dépôt des mails dans les boîtes mail consultables par les utilisatrices²⁾. Au niveau de l'utilisatrice finale, les filtres Sieve sont définis pour une adresse mail particulière (noues@domain.tld).

Pour décrire les traitements que le serveur doit réaliser, on utilise un langage normalisé, semi-déclaratif. En première approche, on peut dire que la description des traitements souhaités prend la forme d'une liste ordonnée de règles, chaque règle ayant une structure simple : <condition(s)> <action(s)>.

Ces règles s'appliquent à tout courriel parvenant à la boîte mail³⁾ pour laquelle elles ont été définies. Chaque courriel est confronté à la liste des règles, les unes à la suite des autres. S'il répond aux conditions, les actions lui sont appliquées. Elles permettent donc de «filtrer» le mail arrivant à cette adresse. Dans notre cas, «règle» et «filtre» sont des synonymes⁴⁾.

Une liste de filtres est appelée un «script». On parle ainsi de scripts rédigés en langage Sieve ou tout simplement de scripts Sieve.

Les filtres Sieve relevant des traitements côté serveur, les scripts correspondants sont logiquement implantés sur les serveurs. Concrètement, un script Sieve est un fichier texte.

En toute rigueur, il suffirait d'avoir la possibilité de téléverser un fichier (texte) dans lequel on aurait rédigé le script souhaité. Ce serait un peu raide et une source infinie d'insatisfaction pour la cliente, de coût en hotline et en image pour l'entité hébergeante.

C'est pourquoi l'accès aux scripts est proposé à travers des interfaces utilisatrices plus conviviales. Elles masquent une partie de la complexité de la mise à jour des scripts. Mais la richesse des fonctionnalités proposées masque également la simplicité de la chose : on met à jour un fichier texte, point-barre !

Les plus apportés :

• une aide à la rédaction de règles qui dispense d'apprendre le langage de programmation Sieve ; l'interface utilisatrice nous permet de programmer sans le savoir
• l'interface nous permet d'agir à coup sûr sur le bon fichier; on n'a pas à savoir ou il se trouve ni comment il s'appelle
• si on veut programmer “à la main”, l'interface contient un éditeur de texte muni ou pas d'un vérificateur de syntaxe et/ou d'un traducteur de règle en langage humain
• une gestion des versions ; bien pratique pour revenir en arrière en cas d'erreur ou de modification temporaire
• une bibliothèque de règles toutes faites; appréciable si on veut programmer certaines règles complexes ou s'initier à la programmation en Sieve

Bien sûr, la liste des fonctionnalités varie selon les interfaces et les fournisseurs.

La situation la plus courante et la plus simple consiste à accéder aux scripts Sieve à travers la même application webmail ⁵⁾ que celle mise à disposition pour consulter, classer, composer ou envoyer ses mails. Il peut s'agir d'une application propriétaire ou d'un logiciel open source tel que Roundcube, ou SoGo.

Cette fonctionnalité est rarement mise au premier plan de l'interface car elle concerne une minorité d'utilisatrices. On la trouvera souvent dans les fonctionnalités avancées, les paramètres…

Dans ce cas, on accède aux filtres Sieve applicables à nos adresses mail à travers une application installée sur notre ordi ou notre mobile.

Il s'agit d'applications spécialisées dans l'édition et la mise à jour de scripts Sieve (sieveeditor, gsieve,…). Il n'est pas nécessaire que l'ordi soit configuré/équipé pour traiter les mails de la boîte dont on veut gérer les filtres Sieve.

Pour que ces applications soient utilisables, il faut que l'entité qui héberge le mail autorise l'accès aux scripts Sieve de nos boîtes mail via le protocole normalisé ManageSieve.

Certaines applications de gestion de mail permettent de gérer les filtres Sieve (par ex. Kmail). Certaines, comme Thunderbird, peuvent le faire moyennant l'installation d'un plugin.

Cette solution est généralement utilisée pour gérer les filtres Sieve des boîtes dont on gère également le contenu⁶⁾. Si c'est bien fait, cela évite d'avoir à ressaisir les identifiants déjà enregistrés.

Comme dans le cas d'une application dédiée, il faut que l'entité qui héberge le mail autorise l'accès aux scripts Sieve suivant les protocoles standard.

Certains hébergeurs de mail proposent des applications propriétaires permettant d'exploiter plus ou moins pleinement les fonctionnalités disponibles à travers leur webmail : chiffrement, éditions des filtres Sieve, envoi différé…

L'interface simplifiée est propre à chaque application. Toutefois, l'objectif est le même : permettre aux utilisatrices de créer des règles sans écrire de code informatique, sans connaître le langage Sieve. Pour ce faire, pas besoin de réinventer l'eau tiède. Elles reprennent le même type d'interface de tri/classement/traitement que l'on a l'habitude de trouver sur un logiciel de gestion de mail (thunderbird, kmail, evolution…).

À la vue de l'interface suivante, bien maline celle qui pourra dire s'il s'agit de créer une règle Sieve sur le serveur ou une règle locale

Chaque courriel qui est sur le point d'être déposé dans la boîte est confronté aux règles, les unes après les autres, dans l'ordre où elle apparaissent dans l'interface. Ce balayage des règles prend fin lorsque toutes les règles ont été parcourues ou dès qu'une règle dont les conditions sont vérifiées intime de le faire, dans la liste de ses actions.

On en tire deux conclusions. D'une part, plusieurs règles peuvent être appliquées à un même courriel. D'autre part, l'ordre des règles compte. Le grand art dans la rédaction des règles consiste à les formuler de telle sorte que l'ordre dans lequel elles apparaissent soit le moins déterminant possible.

À la différence de l'interface simplifiée, l'interface avancée permet de rédiger des règles en utilisant le langage Sieve. L'intérêt est que l'on a accès à toute la puissance d'expression du langage. Cela permet de produire des règles plus précises, plus complexes, plus générales…

La première difficulté est de connaître le langage Sieve. Par exemple, si je veux que tous les courriel que m'envoie ma copine Julie depuis son adresse Proton mail soient classés dans un sous-dossier à son nom dans ma boîte d'arrivée, je devrai écrire un truc du style :

require "fileinto";
if address :is “From” “JulyS@proton.me” {
  fileinto "INBOX/Julie";
}

À la lecture, on comprends plus ou moins l'idée. L'écrire est une autre paire de manches…

Dans cet autre exemple, je veux “réécrire” le sujet de tous les mails qui arrivent dans un boîte mail qui ne devrait plus en recevoir :

require "editheader";
require "variables";
if header :matches "Subject" "*" {
    set "subject" "${1}";
    deleteheader "Subject";
    addheader :last "Subject" "[Old-Box] ${subject}";
}

C'est déjà moins lisible que l'exemple précédent. On constate cependant que la réécriture/modification du sujet a dû prendre la forme d'une suppression complète suivie d'un ajout.

La deuxième difficulté est qu'il existe de nombreuses variantes du langage Sieve. Certes, la syntaxe et le vocabulaire de base sont normalisés mais le langage est extensible. Heureusement, les extensions les plus utilisées sont normalisées⁷⁾. Malheureusement, toutes les extensions normalisées ne sont pas disponibles sur tous les serveurs. Puisqu'on se donne la peine d'écrire du code informatique afin d'exploiter la puissance d'expression du langage dont on dispose, il faut en connaître les particularités. Seul votre hébergeur de mail peut vous indiquer la liste et la signification des extensions qu'il propose.

Si l'interface “avancée” ne propose rien d'autre qu'un éditeur de texte, elle usurpe le qualificatif : “aride” conviendrait mieux.

Le minimum qu'elle peut faire, à moindre frais, est de mettre à disposition des modèles de règles qu'on n'aura plus qu'à adapter. Mais une interface réellement avancée doit proposer des aides à la rédaction telles qu'on en trouve pour les langages de programmation ou de scripts comme la coloration, la vérification ou un éditeur syntaxique.

Sous l'environnement de bureau KDE, kwrite/kate effectuent la coloration syntaxique du code Sieve. Cela effectue un premier niveau de validation off-line.

• Sieve (mail filtering language) (en) (wikipedia)
• Sieve: An Email Filtering Language (RFC 5228) (en) (ietf)
  • Sieve's Copy Extension (RFC 3894) (en) (ietf)
  • Sieve's Body Extension (RFC-5173) (en) (ietf)
  • Sieve's Reject Extension (RFC-5429) (en) (ietf)
  • Sieve's Variables Extension (RFC-5229) (en) (ietf)
  • Spamtest and VirusTest Extensions (RFC-3685) (en) (ietf)
• ManageSieve (RFC 5804) (en) (ietf)
• Sieve Documents and Specifications (en) (sieve.info)
• Logiciels clients Sieve (en) (sieve.info)
• Creating Sieve Scripts (en) Clair et pédagogique.
• Sieve Language (en) (GNU mailutils.org)
• Sieve Tutorial (en)
• Quelques syntaxes Sieve (en)
• Sieve Syntax and Common Recipes (en)
• Sieve filter (advanced custom filters) (en) (Proton)
• Write Your Own Sieve Filters Tutorial (en) (Gandi)
• Exemples de filtres SIEVE pour les E-mails (fr) (Gandi)
• Using Sieve Editor (kde.org) (en) (kde.org)
• Liste des extensions SIEVE supportée par Gandi (fr) (Gandi)
• SecurityGateway's custom Sieve extensions (en) (MDaemon)