Groupe de travail Réseau	A. Melnikov, Isode Limited
Request for Comments: 5490	mars 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Langage de filtrage de messagerie Sieve - extensions pour vérifier l'état de boîtes aux lettres et les métadonnées d'acccès aux boîtes aux lettres

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent mémoire définit une extension au langage de filtrage de messagerie Sieve (RFC 5228) pour l'accès aux boîtes aux lettres et aux annotations de serveur, la vérification de l'existence d'une boîte aux lettres, et contrôler la création de boîte aux lettres sur une action "fileinto".
Table des matières
1. Introduction	2
2. Conventions utilisées dans le document	2
3. Extensions "mailbox" et "mboxmetadata"	2
3.1 Essai "mailboxexists"	2
3.2 Argument ":create" à la commande "fileinto"	2
3.3 Essai "metadata"	3
3.4 Essai "metadataexists"	3
4. Extension "servermetadata"	3
4.1 Essai "servermetadata"	3
4.2 Essai "servermetadataexists"	4
5. Considérations sur la sécurité	4
6. Considérations relatives à l'IANA	4
7. Remerciements	5
8. Références	5
8.1 Références normatives	5
8.2 Références pour information	6
Adresse de l'auteur	6

 	1.	Introduction

Le présent mémoire définit une extension au langage de filtrage de messagerie Sieve [RFC5228] pour l'accès aux annotations de boîte aux lettres et de serveur. Cela permet la personnalisation du comportement du moteur Sieve sur la base de l'ensemble de variables en utilisant la [RFC5464].

Le présent document définit aussi une extension pour vérifier l'existence de la boîte aux lettres et pour contrôler la création de la boîte aux lettres sur une action "fileinto".

 	2.	Conventions utilisées dans le document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119],.

Les conventions de notation sont comme au paragraphe 1.1 de la [RFC5228], incluant l'utilisation de la [RFC5234].

Le présent document est écrit avec l'hypothèse que le lecteur est familiarisé avec le modèle de données et les termes définis à la Section 3 de la [RFC5464].

 	3.	Extensions "mailbox" et "mboxmetadata"
 	3.1	Essai "mailboxexists"
Usage :  mailboxexists <mailbox-names: string-list>

L'essai "mailboxexists" est vrai si toutes les boîtes aux lettres mentionnées dans l'argument "mailbox-names" existent dans le magasin de messagerie, et que chacune permet à l'utilisateur dont le contexte de script Sieve fonctionne pour lui "livrer" les messages. Quand le magasin de messagerie est un serveur IMAP, la "livraison" des messages est possible si :
a.	le code de réponse READ-WRITE est présent pour la boîte aux lettres (voir le paragraphe 7.1 de la [RFC3501]) si la liste de contrôle d'accès (ACL, Access Control List) [RFC4314] IMAP n'est pas prise en charge par le serveur, ou
b.	l'utilisateur a les droits "p" ou "i" pour la boîte aux lettres (voir le paragraphe 5.2 de la [RFC4314]).

Noter qu'un essai "mailboxexists" réussi pour une boîte aux lettres ne signifie pas nécessairement que l'action "fileinto" sur cette boîte aux lettres va réussir. Par exemple, l'action "fileinto" pourrait mettre des quotas à l'utilisateur. L'essai "mailboxexists" vérifie seulement l'existence de la boîte aux lettres et si l'utilisateur dans le contexte duquel fonctionne le script Sieve a la permission d'exécuter "fileinto" sur lui.

La chaîne de capacités à utiliser avec la commande "require" est "mailbox".

Exemple : on suppose que le moteur Sieve prend aussi en charge "reject" [RFC5429] et "fileinto" [RFC5228]. Cependant, ces extensions ne sont pas exigées pour mettre en œuvre l'extension "mailbox".

        require ["fileinto", "reject", "mailbox"];
        if mailboxexists "Partners" {
           fileinto "Partners";
        } else {
           reject "Ce message n'a pas été accepté par le magain de messagerie";
        }

 	3.2	Argument ":create" à la commande "fileinto"
Usage :  fileinto [:create] <mailbox: string>

Si l'argument facultatif ":create" est spécifié avec "fileinto", il ordonne à l'interpréteur Sieve de créer la boîte aux lettres spécifiée, si nécessaire, avant de tenter de livrer le message dans la boîte aux lettres spécifiée. Si la boîte aux lettres existe déjà, cet argument est ignoré. L'échec de la création de la boîte aux lettres spécifiée est considérée comme une erreur.

La chaîne de capacités à utiliser avec le paramètre ":create" est "mailbox".

 	3.3	Essai "metadata"
Usage : métadonnées [MATCH-TYPE] [COMPARATOR]
           <mailbox: string>
           <annotation-name: string> <key-list: string-list>

Cet essai restitue la valeur de l'annotation de la boîte aux lettres "annotation-name" pour la boîte aux lettres "mailbox" [RFC5464]. La valeur restituée est comparée à la "key-list". L'essai retourne vrai si l'annotation existe et si sa valeur correspond à une des clés.

Le type de correspondance par défaut est ":is" [RFC5228]. Le comparateur par défaut est "i;ascii-casemap" [RFC5228].

La chaîne de capacités à utiliser avec la commande "require" est "mboxmetadata".

Les annotations DOIVENT être accédées avec la permission de l'utilisateur dans lequel fonctionne le contexte du script Sieve, et les annotations qui commencent par le préfixe "/private" DOIVENT être celles de l'utilisateur dans lequel fonctionne le contexte du script Sieve.

Exemple : l'exemple suivant suppose que le moteur Sieve prend aussi en charge l'extension "vacation" [RFC5230]. Cependant, cette extension n'est pas exigée pour mettre en œuvre l'extension "mboxmetadata".

       require ["mboxmetadata", "vacation"];
       if metadata :is "INBOX"
          "/private/vendor/vendor.isode/auto-replies" "on" {
           vacation text:
       Je suis en vacances jusqu'à mars 2009.
       S'attendre à un délai.
       .
       }

 	3.4	Essai "metadataexists"
Usage : metadataexists <mailbox: string> <annotation-names: string-list>

L'essai "metadataexists" est vrai si toutes les annotations mentionnées dans l'argument "annotation-names" existent (c'est-à-dire, ont des valeurs non NULLES) pour la boîte aux lettres spécifiée.

La chaîne de capacités à utiliser avec la commande "require" est "mboxmetadata".

 	4.	Extension "servermetadata"
 	4.1	Essai "servermetadata"
Usage :  servermetadata [MATCH-TYPE] [COMPARATOR] <annotation-name: string> <key-list: string-list>

Cet essai restitue la valeur de l'annotation de serveur "annotation-name" [RFC5464]. La valeur restituée est comparée à la "key-list". L'essai retourne vrai si l'annotation existe et si sa valeur correspond à une des clés.

Le type de correspondance par défaut est ":is". Le comparateur par défaut est "i;ascii-casemap".

La chaîne de capacités à utiliser avec la commande "require" est "servermetadata".

Les annotations DOIVENT être accédées avec la permission de l'utilisateur dans lequel fonctionne le contexte du script Sieve, et les annotations qui commencent par le préfixe "/private" DOIVENT être celles de l'utilisateur dans lequel fonctionne le contexte du script Sieve.

Exemple : l'exemple suivant suppose que le moteur Sieve prend aussi en charge les extensions "variables" [RFC5229], "enotify" [RFC5435], et "envelope" [RFC5228]. Cependant, ces extensions ne sont pas exigées pour mettre en œuvre l'extension "servermetadata".

require ["enotify", "servermetadata", "variables", "envelope"];

       if servermetadata :matches
          "/private/vendor/vendor.isode/notification-uri" "*" {
           set "notif_uri" "${0}";
       }

       if not string :is "${notif_uri}" "none" {
# :matches est utilisé pour obtenir l'adresse MAIL FROM
           if envelope :all :matches "from" "*" {
               set "env_from" " [really: ${1}]";
           }

# :matches est utilisé pour obtenir la valeur de l'en-tête Subject
           if header :matches "Subject" "*" {
               set "subject" "${1}";
           }

# :matches est utilisé pour obtenir l'adresse de l'en-tête From
           if address :matches :all "from" "*" {
               set "from_addr" "${1}";
           }

           notify :message "${from_addr}${env_from}: ${subject}"
                  "${notif_uri}";
       }

 	4.2	Essai "servermetadataexists"
Usage :  servermetadataexists <annotation-names: string-list>

L'essai "servermetadataexists" est vrai si toutes les annotations du serveur mentionnées dans l'argument "annotation-names" existent (c'est-à-dire, ont des valeurs non NULLES).

La chaîne de capacités à utiliser avec la commande "require" est "servermetadata".

 	5.	Considérations sur la sécurité

Les extensions définies dans le présent document ne fournissent délibérément pas de moyen de modifier les annotations.

Un échec de restitution de données du fait de la défaillance du serveur qui mémorise les annotations ou parce qu'il est autrement inaccessible, peut altérer le résultat du traitement de Sieve. Donc les mises en œuvre DEVRAIENT traiter une défaillance temporaire de restitution des annotations de la même manière qu'une défaillance temporaire de restitution d'un script Sieve. Par exemple, si le script Sieve est mémorisé dans le protocole léger d'accès à un répertoire (LDAP, Lightweight Directory Access Protocol) et si le script ne peut pas être restitué quand un message est traité, alors l'agent qui effectue le traitement Sieve peut, par exemple, supposer que le script n'existe pas ou retarder la livraison du message jusqu'à ce que le script puisse être bien restitué. Les annotations devraient être traitées comme si elles faisaient partie du script lui-même, de sorte qu'un échec temporaire de leur restitution devrait être traité de la même façon qu'un échec temporaire à restituer le script Sieve lui-même.

Les protocoles/API utilisés pour restituer les annotations DOIVENT fournir au moins le même niveau de confidentialité que les protocoles/API utilisés pour restituer les scripts Sieve. Par exemple, si les scripts Sieve sont restitués en utilisant LDAP sécurisé avec le chiffrement de la sécurité de la couche de transport (TLS, Transport Layer Security) alors le protocole utilisé pour restituer les annotations doit utiliser un mécanisme comparable pour fournir la confidentialité de la connexion. En particulier, le protocole utilisé pour restituer les annotations ne doit pas manquer d'être chiffré.

 	6.	Considérations relatives à l'IANA

L'IANA a ajouté les enregistrements suivants à la liste des extensions à Sieve :

Pour : iana@iana.org
Sujet : enregistrement d'une nouvelle extension Sieve
Nom de capacité : mailbox
Description : ajoute des essais pour vérifier l'existence d'une boîte aux lettres et un nouvel argument facultatif à fileinto pour créer une boîte aux lettres avant de tenter la livraison de message.
RFC publiée : RFC 5490
Adresse de contact : liste de diffusion Sieve à <ietf-mta-filters@imc.org>

Nom de capacité : mboxmetadata
Description : ajoute des essais pour vérifier l'existence de l'élément de métadonnées de boîte aux lettres et pour restituer une valeur des métadonnées de boîte aux lettres.
RFC publiée : RFC 5490
Adresse de contact : liste de diffusion Sieve à <ietf-mta-filters@imc.org>

Nom de capacité : servermetadata
Description : ajoute des essais pour vérifier l'existence de l'élément de métadonnées de serveur et pour restituer une valeur des métadonnées de serveur.
RFC publiée : RFC 5490
Adresse de contact : liste de diffusion Sieve à <ietf-mta-filters@imc.org>

 	7.	Remerciements

Merci à Cyrus Daboo pour la motivation initiale de ce document.

Merci à Barry Leiba, Randall Gellens, et Aaron Stone poir leurs commentaires utiles sur ce document.

L'auteur remercie aussi le groupe de travail Mobile Email de Open Mobile Alliance pour sa fourniture de l'ensemble d'exigences pour les appareils mobiles, qui ont servi de guide pour certaines extensions de ce document.

 	8.	Références
 	8.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474 ; remplacée par la 9051

[RFC4314]	A. Melnikov, "Extension IMAP4 de liste de contrôle d'accès (ACL)", décembre 2005. (Remplace RFC2086) (P.S.)

[RFC5228]	P. Guenther et autres, "Sieve : un langage de filtrage de messagerie électronique", janvier 2008. (P.S. ; Remplace RFC3028, MàJ par RFC5229, 5429 9042)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5464]	C. Daboo, "Extension IMAP METADATA", février 2009. (P.S.)

 	8.2	Références pour information

[RFC5229]	K. Homme, "Filtrage de messagerie Sieve : extension Variables", janvier 2008. (MàJ par RFC5173) (P.S.)

[RFC5230]	T. Showalter, N. Freed, éd., "Filtrage de messagerie Sieve : extension Vacation", janvier 2008. (P.S. ; MàJ par RFC8580.)

[RFC5429]	A. Stone, éd., "Filtrage de messagerie électronique Sieve : Extensions Reject et Extended Reject", mars 2009. (Remplace RFC3028, MàJ RFC5228) (P.S.)

[RFC5435]	A. Melnikov et autres, "Filtrage de messagerie Sieve : extension pour les notifications", janvier 2009. (P.S. ; MàJ par RFC8580)

 	Adresse de l'auteur

Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex  TW12 2BX
UK
mél : Alexey.Melnikov@isode.com