Mon blog

Le langage de filtrage du courrier Sieve se voit désormais doté d'une nouvelle fonction, la possibilité de prévenir lors de l'arrivée de certains messages. Cette notification pourra se faire via plusieurs protocoles, spécifiés dans d'autres RFC.

Certains utilisateurs du courrier veulent être prévenus tout de suite lorsqu'un message a certaines caractéristiques (par exemple un message du chef comportant « URGENT » dans le sujet). Cette demande va même parfois au delà du raisonnable, lorsqu'ils rejettent, par exemple, des méthodes anti-spam très efficaces comme le greylisting (RFC 6647) parce qu'ils ne supportent pas l'idée que leur courrier soit retardé de quelques minutes. La méthode classique pour être prévenu est de type pull : interroger le serveur de messagerie regulièrement, ce qui le fait travailler, la plupart du temps pour rien. Notre RFC 5435 propose donc une méthode de type push où l'utilisateur est notifié lorsqu'un message obéit à certaines caractéristiques.

Voyons tout de suite un exemple :

if allof (header :contains "from" "chef@example.com",
          header :contains "subject" "URGENT")
 {
           notify 
                 :importance "1"
                 :message "This is probably very important"
              "tel:123456";
 }

Cette règle appelera le numéro de téléphone 123456 dès qu'un message du chef comportant le mot-clé arrivera.

D'autres RFC décriront les mécanismes de notification. Le RFC 5436 décrit mailto: (envoi de la notification par courrier), le seul mécanisme obligatoire. Le RFC 5437 décrit, lui, la notification par le protocole de messagerie instantanée XMPP. La section 3.8 détaille les limites que doivent suivre ces mécanismes (par exemple sur la taille des messages de notification). La liste complète des mécanismes figure dans le registre IANA.

Le RFC est court, le gros de la définition se trouvant dans la section 3, qui précise la syntaxe de la nouvelle action notify, syntaxe illustrée dans l'exemple ci-dessus. Les options les plus importantes sont :

• La méthode de notification, un URI (par exemple xmpp:bortzmeyer@gmail.com ou bien mailto:stephane+alert@bortzmeyer.org, le support de cette dernière méthode étant obligatoire).
• L'expéditeur à utiliser pour la notification (:from),
• L'importance du message de notification, utilisée par certaines méthodes pour le prioritiser,
• Et bien sûr le message de notification lui-même, :message.

Voici un exemple plus élaboré que le précédent, utilisant les variables Sieve du RFC 5229 :

 require ["enotify", "fileinto", "variables"];

 if header :contains "to" "sievemailinglist@example.org" {
     # :matches is used to get the value of the Subject header
     if header :matches "Subject" "*" {
          set "subject" "${1}";
     }

     # :matches is used to get the value of the From header
     if header :matches "From" "*" {
          set "from" "${1}";
     }
           
     notify :importance "3"
               :message "[SIEVE] ${from}: ${subject}"
               "mailto:alm@example.com";
     fileinto "INBOX.sieve";
 }

Les sections 4 et 5 décrivent des tests Sieve permettant à un script de savoir quelles méthodes de notification sont disponibles sur le site.

La section 8, très détaillée, est consacrée aux questions de sécurité. En effet, comme le note le RFC, la notification est potentiellement très dangereuse. Elle peut entraîner des boucles (si un courrier de notification déclenche à son tour une notification), « spammer » des destinataires, aboutir à la sortie involontaire d'informations confidentielles, etc. Combinée avec des extensions comme les variables (qui permettent de fabriquer dynamiquement des composants de la notification, comme le message ou le destinataire), l'action notify peut mener à des résultats très surprenants. Les programmeurs sont donc invités à la prudence, notamment pour éviter les boucles.

Je ne connais pas encore d'implémentation de Sieve qui mette en œuvre ce mécanisme de notification.