Groupe de travail Réseau	J. Degener, Sendmail, Inc.
Request for Comments : 5293	P. Guenther, Sendmail, Inc.
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	août 2008

Filtrage de messagerie Sieve : Extension Editheader

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le présent document définit deux nouvelles actions pour le langage de filtrage de messagerie "Sieve" qui ajoutent et suppriment des champs d'en-tête de messagerie électronique.
Table des matières
1. Introduction	1
2. Conventions utilisées dans ce document	1
3. Identifiant de capacité	2
4. Action addheader	2
5. Action deleteheader	2
6. Limitations des changements par les mises en œuvre	3
7. Interaction avec les autres extensions Sieve	3
8. Considérations relatives à l’IANA	4
9. Considérations sur la sécurité	4
10. Remerciements	5
11. Références	5
11.1 Références normatives	5
11.2 Références pour information	5
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6

 	1.	Introduction

Les champs d'en-tête de la messagerie électronique sont un moyen souple et facile à comprendre pour la communication entre les processeurs de messagerie. Cette extension permet aux scripts Sieve d’interagir avec les autres composants qui consomment ou produisent des champs d'en-tête en permettant au script de supprimer et ajouter des champs d'en-tête.

 	2.	Conventions utilisées dans ce 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 dans le paragraphe 1.1 de la [RFC5228], incluant l’utilisation de l’étiquette "Usage:" pour la définition de l’action et la syntaxe d’arguments étiquetés.

Le terme "champ d'en-tête" est utilisé ici comme dans la [RFC2822] pour désigner une ligne logique d’un en-tête de message électronique.

 	3.	Identifiant de capacité

La chaîne de capacités associée à l’extension définie dans le présent document est "editheader".

 	4.	Action addheader

Usage : "addheader" [":last"] <nom-de-champ : chaîne> <valeur : chaîne>

L’action addheader ajoute un champ d'en-tête à l’en-tête de message existant. Si le nom du champ n’est pas un nom de champ d'en-tête US-ASCII valide en 7 bits, comme décrit par l’élément de syntaxe non terminal "nom-de-champ" de la [RFC2822], la mise en œuvre DOIT retourner une erreur. L’action addheader n’affecte pas la garde implicite de Sieve.

Si la valeur du champ spécifié ne correspond pas à l’élément de syntaxe "non-structuré" non terminal de la [RFC2822] ou excède une limite de longueur établie par la mise en œuvre, la mise en œuvre DOIT soit marquer une erreur, soit coder le champ en utilisant une espace de saut à la ligne et les codages décrits dans la [RFC2047] ou la [RFC2231] pour être conforme à la [RFC2822].

Une mise en œuvre PEUT imposer une limite de longueur à la taille du champ d'en-tête codé ; une telle limite NE DOIT PAS être de moins de 998 caractères, non inclus le CRLF de terminaison fourni par la mise en œuvre.

Par défaut, le champ d'en-tête est inséré au début de l’en-tête de message existant. Si le fanion facultatif ":last" est spécifié, il est ajouté à la fin.

Exemple :

        /* Ne pas rediriger si on a déjà redirigé */
        si pas d’en-tête :contains "X-Sieve-Filtered"
                ["<kim@job.example.com>", "<kim@home.example.com>"]
        {
                addheader "X-Sieve-Filtered" "<kim@job.example.com>";
                rediriger "kim@home.example.com";
        }

 	5.	Action deleteheader

Usage : "deleteheader" [":index" <fieldno: nombre> [":last"]]
                   [COMPARATOR] [MATCH-TYPE]
                   <nom-de champ : chaîne>
                   [<schémas-de-valeur : liste-de-chaînes>]

Par défaut, l’action deleteheader supprime toutes les occurrences du champ d'en-tête désigné. L’action deleteheader n’affecte pas la garde implicite de Sieve.

Le nom-de-champ est obligatoire et est toujours confronté comme une chaîne US-ASCII insensible à la casse. Si le nom-de-champ n’est pas un nom de champ d'en-tête valide en 7 bits comme décrit par l’élément de syntaxe non terminal "nom-de-champ" de la [RFC2822], la mise en œuvre DOIT marquer une erreur.

Le schémas-de-valeurs, si il est spécifié, restreint les occurrences du champ d'en-tête à supprimer à celles dont les valeurs correspondent à un des schémas-de-valeurs spécifiés, la confrontation étant en accord avec le type de correspondance et le comparateur et effectuée comme par l’essai "header". En particulier, les espaces en tête et en queue dans les valeurs de champ sont ignorées. Si aucun schémas-de-valeurs n’est spécifié, alors les options de comparateur et de type de correspondance sont ignorées en silence.

Si :index <fieldno> est spécifié, les tentatives de confronter une valeur sont limitées à l’occurrence de <fieldno> du champ d'en-tête désigné, en commençant à 1, le premier champ d'en-tête désigné. Si :last est spécifié, le compte est inversé ; 1 note le dernier champ d'en-tête désigné, 2 le second avant la fin, et ainsi de suite. Le compte se fait avant la confrontation des <schémas-de-valeurs>, si il en est. Par exemple :

deleteheader :index 1 :contains "Delivered-To"  "bob@example.com";

supprime le premier champ d'en-tête "Delivered-To" si il contient la chaîne "bob@example.com" (pas le premier champ "Delivered-To" qui contient "bob@example.com").

Il n’y a pas d’erreur si aucun champ d'en-tête ne satisfait les conditions dans l’action deleteheader ou si l’argument :index est supérieur au nombre de champs d'en-tête désignés.

La mise en œuvre DOIT marquer une erreur si :last est spécifié sans aussi spécifier :index.

 	6.	Limitations des changements par les mises en œuvre

En matière de politique locale, les mises en œuvre PEUVENT limiter les champs d'en-tête qui peuvent être supprimés et ceux qui peuvent être ajoutés. Cependant, les mises en œuvre NE DOIVENT PAS permettre des tentatives de suppression des champs d'en-tête "Received" et "Auto-Submitted" et DOIVENT permettre l’ajout et la suppression du champ d'en-tête "Subject".

Si un script essaye de faire un changement qui n’est pas permis, la tentative DOIT être ignorée en silence.

 	7.	Interaction avec les autres extensions Sieve

Les actions qui génèrent ([RFC3798], [RFC3464]) ou les messages de disposition similaires DOIVENT le faire en utilisant l’en-tête de message original, non modifié. De même, si une erreur termine le traitement du script, l’en-tête original du message DOIT être utilisé quand on fait la garde implicite exigée par le paragraphe 2.10.6 de la [RFC5228].

Toutes les autres actions qui mémorisent, envoient, ou altèrent le message DOIVENT le faire avec l’ensemble actuel de champs d'en-tête. Cela inclut les actions addheader et deleteheader elles-mêmes. Par exemple, ce qui suit laisse le message inchangé :

addheader "X-Hello" "World";
deleteheader :index 1 "X-Hello";

De même, avec un message de trois champs d'en-tête "X-Hello" ou plus, l’exemple suivant supprime le premier et le troisième  ; mais pas le premier et le second :

deleteheader :index 1 "X-Hello";
deleteheader :index 2 "X-Hello";

Des essais et actions comme "exists", "header", ou "vacation" [RFC5230] qui examinent les champs d'en-tête DOIVENT examiner l’état actuel d’un en-tête tel que modifié par toutes les actions qui ont eu lieu jusqu’alors.

Par exemple, l’essai "header" dans le fragment suivant va toujours s’évaluer à vrai, sans considération de si le message entrant contenait ou non un champ d'en-tête "X-Hello" :

addheader "X-Hello" "World";
si header :contains "X-Hello" "World"
{
      fileinto "international";
}

Cependant, si la présence ou la valeur d’un champ d'en-tête affecte la façon dont la mise en œuvre analyse ou décode les autres parties du message, alors, pour les besoins de cette analyse ou décodage, la mise en œuvre PEUT ignorer certains ou tous les changements faits à ces champs d'en-tête. Par exemple, dans une mise en œuvre qui prend en charge l’extension de la [RFC5173], les essais "body" peuvent n’être pas affectés par la suppression ou l’ajout de champs d'en-tête "Content-Type" ou "Content-Transfer-Encoding". Cela n’annule pas l’exigence que les changements à ces champs d'en-tête affectent le essais directs ; seul les effets collatéraux de sémantique des changements des champs peuvent être ignorés.

Afin d’éliminer les dupliqués, un message modifié par addheader ou deleteheader DOIT être considéré comme le même que le message original. Par exemple, dans une mise en œuvre qui obéit à la contrainte du paragraphe 2.10.3 de la [RFC5228] et ne livre pas plus d’une fois le même message à un dossier, le fragment de code suivant

keep;
addheader "X-Flavor" "vanilla";
keep;

DOIT seulement mettre un message dans le dossier. Il appartient à la mise en œuvre de prendre une des actions redondantes "fileinto" ou "keep" pour l’exécuter, et de décider de celles qui sont ignorées.

La "garde implicite" est vue pour être exécutée à la fin du script, après que les en-têtes ont été modifiés. (Cependant, une "garde implicite" annulée reste annulée.)

 	8.	Considérations relatives à l’IANA

Le gabarit suivant spécifie l’enregistrement par l’IANA de l’extension Sieve spécifiée dans le présent document :

Pour : iana@iana.org
Sujet : enregistrement d’une nouvelle extension Sieve
Nom de capacité : editheader
Description : ajoute les actions "addheader" et "deleteheader" qui modifient l’en-tête du message en cours de traitement.
Numéro de RFC : RFC 5293
Adresse de contact : liste de diffusion Sieve à <ietf-mta-filters&imc.org>

 	9.	Considérations sur la sécurité

Quelqu’un qui a l’accès en écriture à la mémorisation du script d’un utilisateur peut utiliser cette extension pour générer des en-têtes qu’un utilisateur aurait dissimulés autrement (par exemple, par un agent de transport de messagerie (MTA, Mail Transport Agent) de passerelle qui les supprime).

Ceci est la première extension Sieve à être normalisée qui permet l’altération de messages traités par les moteurs Sieve. Un script Sieve qui utilise les essais Sieve définis dans la [RFC5228], l’extension editheader, et l’action redirect en retour au même utilisateur peut conserver de l’état entre les différentes invocations du même script pour le même message. Mais on notera qu’il ne sera pas possible d’introduire une boucle infinie en utilisant un tel script, parce que chaque itération ajoute un nouveau champ d'en-tête Received, de sorte que la prévention de boucle de messagerie décrite dans la [RFC2821] va finalement bloquer la livraison du message, et parce que il est explicitement interdit à l’extension editheader d’altérer ou supprimer les champs d'en-tête Received (c'est-à-dire, elle ne peut pas interférer avec la prévention de boucle).

Un filtre Sieve qui supprime des champs d'en-tête peut à tort détruire les preuves sur le chemin qu’a pris un message.

Tout changement du contenu de message peut interférer avec les mécanismes de signature numérique qui incluent l’en-tête dans le matériel signé. Par exemple, des changements (ou la suppression/ajout) aux champs d'en-tête inclus dans la liste de "DEVRAIT être inclus dans la signature" du paragraphe 5.5 de la [RFC4871] peuvent invalider les signatures DKIM. Cela inclut aussi les signatures DKIM qui garantissent l’absence d’un champ d'en-tête.

L’extension editheader n’affecte pas directement les signatures de champ d'en-tête [RFC2822] générées en utilisant la [RFC3851] ou la [RFC3156], parce que ces schémas de signature incluent une copie séparée des champs d'en-tête à l’intérieur de la partie de corps signée du message/rfc822. Cependant, les logiciels écrits pour détecter les différences entre la copie interne (signée) des champs d'en-tête et les champs d'en-tête externes (modifiés par editheader) pourraient être affectés par les changements faits par editheader.

Comme la livraison normale de message ajoute des champs d'en-tête "Received" et d’autres champs de trace au début d’un message, beaucoup de ces mécanismes de signature numérique sont imperméables aux en-têtes ajoutés devant un message, et vont fonctionner avec "addheader" sauf si :last est utilisé.

Tout mécanisme de décision dans un filtre d’utilisateur qui est fondé sur les en-têtes est vulnérable à l’usurpation d’en-tête. Par exemple, si l’utilisateur ajoute un en-tête ou une étiquette APPROUVÉ, un envoyeur malveillant peut ajouter lui-même cette étiquette ou en-tête. Une façon de se garder contre cela est de supprimer ou renommer tous ces en-têtes ou étiquettes avant de traiter le message.

 	10.	Remerciements

Merci à Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson, et Rand Wacker de leurs nombreuses corrections et suggestions.

 	11.	Références
 	11.1	Références normatives
[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

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

[RFC2231]	N. Freed, K. Moore, "Extensions MIME Valeur de paramètre et Mot codé : jeux de caractères, langages, et continuations", novembre 1997. (P.S.)

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

[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)

 	11.2	Références pour information
[RFC2821]	J. Klensin, éditeur, "Protocole simple de transfert de messagerie", STD 10, avril 2001. (Obsolète, voir RFC5321)

[RFC3156]	M. Elkins et autres, "Sécurité MIME avec OpenPGP", août 2001.(P.S.)

[RFC3464]	K. Moore, G. Vaudreuil, "Format extensible de message pour les notifications d'état de livraison", janvier 2003. (MàJ par RFC4865, RFC5337, RFC6533) (D.S.)

[RFC3798]	T. Hansen et G. Vaudreuil, éd., "Notification de disposition de message", mai 2004. (MàJ par RFC5337, RFC6533) (D.S.; Rendue obsolète par RFC8098)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC4871]	E. Allman et autres, "Signatures de messagerie identifiées par DomainKeys (DKIM)", mai 2007. (Remplace RFC4870 Màj par RFC5672 ; Remplacée par RFC6376) (P.S.)

[RFC5173]	J. Degener, P. Guenther, "Filtrage Sieve de messagerie électronique : extension "body"", avril 2008. (MàJ RFC5229) (P.S.)

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

 	Adresse des auteurs
Jutta Degener	Philip Guenther	
5245 College Ave, Suite #127	Sendmail, Inc.	
Oakland, CA 94618	6475 Christie Ave., Ste 350	
	Emeryville, CA 94608	
USA	USA	
mél : jutta@pobox.com	mél : guenther@sendmail.com	

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est fourni par l'activité de soutien administratif de l'IETF (IASA).