Groupe de travail Réseau	J. Degener, Sendmail, Inc.	
Request for Comments : 3894	octobre 2004	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Extension à Sieve : Copie sans effets collatéraux

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

Notice de copyright
Copyright (C) The Internet Society (2004).

Résumé
Le langage de scripts Sieve permet aux utilisateurs de contrôler le traitement  et la destruction de leurs messages électroniques entrants. Par défaut, un message électronique qui est traité par un script Sieve est sauvegardé dans la "boîte aux lettres interne" du propriétaire. Des actions comme "fileinto" et "redirect" annulent ce comportement par défaut.

Le présent document définit un nouveau paramètre de mot clé, ":copy", à utiliser par les actions Sieve "fileinto" et "redirect". L’ajout de ":copy" à une action supprime l’annulation de la sauvegarde par défaut de la "boîte aux lettres interne". Cela permet aux usagers d’ajouter des commandes à un script existant sans changer la signification du reste du script.

1.	Introduction

Le langage de script Sieve [RFC3028] permet aux utilisateurs de contrôler le traitement et la destruction de leurs messages électroniques entrants. Deux commandes Sieve fréquemment utilisées sont "fileinto" (qui sauvegarde dans un dépôt de message local, comme un serveur IMAP) et "redirect" (qui retransmet à une autre adresse de messagerie). Tous deux annulent le comportement Sieve par défaut de sauvegarder dans la "boîte aux lettres interne" de l’utilisateur.

Mais certains utilisateurs souhaitent transmettre une copie supplémentaire d’un message à des fins de sauvegarde à une autre adresse de messagerie, ou pour sauvegarder une copie dans un dossier - en plus de la livraison regulière du message, qui ne devrait pas être affectée par la copie.

Si la sauvegarde d’une copie supplémentaire est tout ce que l’usager veut faire,

fileinto "unfiltered";
keep;

fera le travail. La commande "keep" fait explicitement ce que faisait le comportement par défaut annulé. Mais le "keep" explicite est un pauvre substitut du "keep" implicite lorsque plus de traitement doit suivre :

fileinto "unfiltered";
keep;

Si en-tête "Subject" "FAIRE DE L’ARGENT FACILE!!!"
  {
      discard;
  }

Dans cet exemple, le "discard" est inefficace contre le "keep" explicite ; le message éliminé finit quand même dans la boîte aux lettres de l’usager.

Il est possible de générer un code Sieve qui exprime parfaitement les souhaits d’un usager, mais un tel code s’enfle rapidement de manière incontrôlable parce que il a besoin de garder trace de l’état que le "keep"  implicite aurait eu sans la commande "fileinto" ou "redirect".

La présente extension essaye de rendre la vie plus facile aux concepteurs d’interface d’utilisateur et aux rédacteurs de script en leur permettant d’exprimer directement la sémantique "copy".

2.	Conventions utilisées

Les conventions de notations sont comme dans le paragraphe 1.1 de la [RFC3028], incluant l’utilisation de la [RFC2119] et de l’étiquette "Syntax:" pour la définition de l’action et de la syntaxe des arguments étiquetés.

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

3.	Extension ":copy" aux commandes "fileinto" et "redirect"

Syntaxe :
"fileinto" [":copy"] <folder: string>
"redirect" [":copy"] <address: string>

Si le mot clé facultatif ":copy" est spécifié avec "fileinto" ou "redirect", la commande étiquetée n’annule pas le "keep" implicite. À la place, elle enregistre simplement ou redirige une copie en plus de tout ce qui arrive par ailleurs au message.

Exemple :

require ["copy", "fileinto"];
fileinto :copy "incoming";

# ... plus de traitement suit ...

4.	Considérations pour la sécurité

L’extension "copy" rend plus facile d’espionner le flux de messages d’un utilisateur sans que celui-ci le remarque. Ceci était techniquement possible avant si un attaquant obtenait un accès en lecture/écriture aux scripts Sieve d’un utilisateur, mais maintenant, un attaquant n’a plus besoin d’analyser un script afin de le modifier. L’accès en écriture aux scripts Sieve doit être protégé aussi fortement que l’accès en lecture/écriture à la messagerie électronique, par exemple en utilisant des protocoles de répertoire sûrs comme LDAP correctement paramétré sur TLS [RFC2829].

Les organisations qui souhaitent surveiller le trafic de messagerie électronique de leurs utilisateurs doivent se familiariser avec les lois locales de protection des données avant de créer des dépôts de l’ancien trafic de messagerie électronique sans contrôle, ou peut-être même avoir connaissance de l’envoyeur ou des receveurs prévus.

Les organisations qui utilisent légitimement "redirect :copy" pour espionner la correspondance (par exemple, en conservant un enregistrement pour répondre aux questions ultérieures sur des délits d’initiés) peuvent éviter de futurs problèmes en établissant correctement les attentes de confidentialité de leurs usagers.

5.	Considérations relatives à l’IANA

Le gabarit suivant spécifie l’enregistrement par l’IANA de l’extension "copy" à Sieve spécifiée dans ce document.

To: iana@iana.org
Sujet : Enregistrement d’une nouvelle extension à Sieve
Nom de la capacité : copy
Mot clé de la capacité : copy
Arguments : N/A
Spécification visée : RFC 3894
Adresse de personnelle et de messagerie à contacter pour d’autres  informations :
Jutta Degener
Sendmail, Inc.
6425 Christie Ave, 4th Floor
Emeryville, CA 94608
mél : jutta@sendmail.com 

Ces informations ont été ajoutées à la liste des extensions Sieve données à http://www.iana.org/assignments/sieve-extensions.

6.	Remerciements

Merci à Eric Allman, Ned Freed, Will Lee, Nigel Swinson, et Rand Wacker pour leurs corrections et commentaires.

7.	Références
7.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.

[RFC3028]	T. Showalter, "Sieve : Langage de filtrage de messagerie", janvier 2001. (Obsolète, voir la RFC5228) (P.S.)

7.2	Références pour information

[RFC2829]	M. Wahl et autres, "Méthodes d'authentification pour LDAP", mai 2000. (Obsolète, voir RFC4513, RFC4510) 

Adresse de l’auteur

Jutta Degener
Sendmail, Inc.
6425 Christie Ave, 4th Floor
Emeryville, CA 94608
USA
mél : jutta@sendmail.com 

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004). Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont 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 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 ci encloses ne violent 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 .

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.