Groupe de travail Réseau	A. Stone, éditeur, Serendipity
Request for Comments : 5429	mars 2009
RFC rendue obsolète : 3028
RFC mise à jour : 5228
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Filtrage de messagerie Sieve : Extensions Rejet et Rejet étendu

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.

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 met à jour la définition de l'extension "reject" du langage de filtrage de messagerie Sieve, définie à l'origine dans la RFC 3028.

Un "Joe-job" est un pourriel arrangé pour paraître provenir d'une partie innocente, qui est ensuite généralement arrosé par des dispositifs automatiques, des notifications de disposition de message (MDN, Message Disposition Notification) et des messages personnels avec des plaintes. L'action Sieve "reject" originale définie dans la RFC 3028 exigeait l'utilisation de MDN pour rejeter les messages, contribuant donc à l'arrosage de pourriels déguisés aux victimes de ces pourriels.

Le présent mémoire met à jour la définition de l'action "reject" pour permettre que les messages soient refusés durant la transaction SMTP, et définit l'action "ereject" pour exiger que les messages soient refusés durant la transaction SMTP, si possible.

L'action "ereject" est destinée à remplacer l'action "reject" chaque fois que possible. L'action "ereject" est similaire à "reject", mais va toujours favoriser le rejet du message au niveau du protocole.
Table des matières
1. Introduction	2
1.1. Conventions utilisées dans ce document	2
2. Extensions Sieve "reject" et "ereject" 	2
2.1 Action ereject	2
2.2 Action reject	4
2.3 Mise à niveau en silence de "reject" à "ereject"	5
2.4 Compatibilité avec d'autres actions	5
2.5 Détails de refus au niveau du protocole	6
3. Changements par rapport à la RFC 3028	6
4. Considérations sur la sécurité	7
5. Considérations relatives à l’IANA	7
5.1 Enregistrement de l'extension "reject" 	7
5.2 Enregistrement de l'extension "ereject"	7
6. Références	7
6.1 Références normatives	7
6.2 Références pour information	8
Appendice A. Remerciements	8
Appendice B. Contributeurs	8
Adresse de l'éditeur	9

 	1.	Introduction

Le langage de filtrage de messagerie Sieve, défini à l'origine dans la [RFC3028], spécifiait que l'action "reject" doit éliminer un message et envoyer une notification de disposition de message [RFC3798] à l'envoyeur de l'enveloppe avec un message d'explication. Le langage de filtrage de messagerie Sieve, mis à jour dans la [RFC5228], ne définit aucune action "reject", c'est donc l'objet du présent document.

Ce document met à jour la définition de l'action "reject" pour permettre le refus du message durant la transaction SMTP, si possible, et définir une nouvelle action "ereject" pour exiger le refus du message durant la transaction SMTP, si possible.

Un but important de ce document est de réduire le risque que des scripts Sieve soient utilisés pour perpétrer des envois de pourriels déguisés (Joe-job) où la MDN envoyée pour notifier à l'envoyeur d'un message qu'il n'a pas été livré est en fait envoyée à un tiers innocent. L'action "reject" originale de Sieve définie dans la RFC 3028 exigeait l'utilisation de MDN pour rejeter les messages, contribuant donc à l'arrosage de pourriels déguisés aux victimes des pourriels déguisés. En rejetant le message au niveau du protocole, il est moins probable qu'une MDN soit nécessaire, et donc moins probable qu'une MDN soit dirigée sur un tiers innocent.

Les mises en œuvre sont de plus encouragées à utiliser des systèmes de détection de pourriels pour déterminer le niveau de risque associé à l'envoi d'une MDN, et le présent document permet aux mises en œuvre d'éliminer en silence la MDN si le message rejeté est réputé être probablement un pourriel.

Le présent document décrit aussi comment utiliser "reject"/"ereject" à divers points dans la pile de messagerie : agent de transfert de messagerie (MTA, Mail Transfer Agent), agent de livraison de message (MDA, Mail Delivery Agent), et agent d'utilisateur de messagerie (MUA, Mail User Agent). Voir dans la [RFC5598] une discussion a complète de ces environnements.

En général, une MDN est générée par un MUA, et peut être utilisée pour indiquer l'état d'un message par rapport à son receveur, tandis qu'une notification d'état de livraison (DSN, Delivery Status Notification) [RFC3464] est générée par un MTA, et peut être utilisée pour indiquer si un message a ou non été reçu et livré par le système de messagerie.

On trouvera une discussion soulignant les risques résultant de la génération de MDN et les avantages d'un refus au niveau du protocole dans [Joe-DoS].

 	1.1.	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 sur les notations sont comme au paragraphe 1.1 de la [RFC5228].

Le présent document ne tente pas de définir le pourriel ni comment il devrait être identifié, er ne tente pas de définir un virus de messagerie ni comment il devrait être détecté. Il est conseillé aux mises en œuvre de suivre les bonnes pratiques courantes et de se tenir au courant des recherches en cours dans ces domaines.

 	2.	Extensions Sieve "reject" et "ereject" 
 	2.1	Action ereject
Usage : ereject <raison: chaîne>

Les mises en œuvre de Sieve qui utilisent l'action "ereject" doivent utiliser la chaîne de capacités "ereject".

L'action "ereject" annule la conservation implicite et refuse la livraison d'un message. La chaîne "raison" est une chaîne UTF-8 [RFC3629] qui spécifie la raison du refus. Comment un message est refusé dépend des capacités du composant de messagerie (MDA ou MTA) qui exécute le script Sieve. L'interpréteur Sieve DOIT exécuter une des actions suivantes (rangées dans l'ordre décroissant de préférence) DOIT exécuter l'action préférée, et DOIT revenir aux actions moins préférées si une action préférée échoue.

1.	Refuser la livraison du message en envoyant un code de réponse 5XX sur SMTP [RFC5321] ou du protocole de transfert de messagerie locale (LMTP, Local Mail Transfer Protocol) [RFC2033]. Voir les détails au paragraphe 2.1.1.

2.	Envoyer un rapport de non livraison à l'envoyeur de l'enveloppe [RFC3462], [RFC3464], sauf si l'adresse de l'envoyeur de l'enveloppe est déterminée comme étant falsifiée ou autrement invalide.

Noter que la détermination de si un envoyeur d'enveloppe est ou non une falsification peut être effectuée par des techniques d'heuristique spécifiques du site et de la mise en œuvre, comme une "vérification du chemin de retour", dont les détails sortent du domaine d'application de ce document. Les mises en œuvre DEVRAIENT enregistrer les instances où un rapport de non livraison n'est pas envoyé et la raison du non envoi du rapport (par exemple, le contenu était un pourriel, le chemin de retour est invalide, etc.).

L'action "ereject" NE DOIT PAS être disponible dans les environnements qui ne prennent pas en charge le rejet au niveau du protocole, par exemple, un MUA, et DOIT être disponible dans tous les autres environnements qui prennent en charge l'action "reject".

Exemple :
               require ["ereject"];
               if address "from" "someone@example.com" {
                   ereject "Je n'accepte plus les messages venant de cette adresse";
               }

 	2.1.1	Rejet d'un message au niveau du protocole SMTP/LMTP
Les mises en œuvre de Sieve qui sont capables de rejeter des messages au niveau de SMTP/LMTP DOIVENT le faire et DEVRAIENT utiliser le code de réponse 550. Noter que si un message arrive sur SMTP et a plusieurs receveurs, dont certains ont accepté le message, le paragraphe 2.1.2 définit comment rejeter un tel message.

Le risque que ces actions génèrent des pourriels en retour est minimisé mais ne peut pas être éliminé complètement même dans le cas de "ereject", donc la prudence est conseillée quand on utilise ces actions pour traiter des messages déterminés comme étant des pourriels.

Noter que SMTP [RFC5321] ne permet pas de caractères non US-ACSII dans le texte de la réponse SMTP. Si des caractères non US-ACSII apparaisent dans la chaîne "reason", ils peuvent être envoyés au niveau du protocole si et seulement si le client et le serveur utilisent une extension SMTP qui permet la transmission de texte de réponse non US-ACSII. (Un exemple de cette extension SMTP est décrit dans [UTF8-RESP]). En l'absence de cette extension SMTP, le moteur Sieve DOIT remplacer toute chaîne "reason" envoyée au niveau du protocole et contenant des caractères non US-ACSII par une chaîne US-ACSII seulement définie par la mise en œuvre.

Les utilisateurs qui n'aiment pas ce comportement devrait envisager d'utiliser l'action "reject" décrite au paragraphe 2.2, si elle est disponible.

Voir au paragraphe 2.5 les instructions détaillées sur la réalisation du rejet au niveau du protocole.

 	2.1.2	Rejet d'un message par l'envoi d'un DSN
Une mise en œuvre peut recevoir un message via SMTP qui a plus d'un RCPT TO qui a été accepté par le serveur, et au moins un, mais pas tous, a refusé la livraison (que le refus soit causé par une action Sieve "ereject" ou pour une autre raison). Dans ce cas, le serveur DOIT accepter le message et générer des DSN pour tous les receveurs qui le refusent. Noter que cette exception ne s'applique pas à LMTP, car LMTP est capable de rejeter des messages receveur par receveur. (Cependant, le client LMTP peut alors n'avoir pas le choix mais générer une DSN pour rapporter l'erreur, ce qui peut résulter en un retour de pourriels.)

Noter que selon la [RFC3464], des notifications d'état de livraison NE DOIVENT PAS être générées si le MAIL FROM (ou Return-Path) est vide.

Le message DSN DOIT suivre les exigences des [RFC3464] et [RFC3462]. Le champ Valeur d'action défini au paragraphe 2.3.3 de la [RFC3464] DOIT contenir la valeur "échec". La portion lisible par l'homme du rapport de non livraison DOIT contenir la chaîne "reason" provenant de l'action "ereject" et DEVRAIT contenir du texte supplémentaire alertant l'envoyeur original apparent de ce que le message a été refusé par un filtre de messagerie. Cette partie du rapport pourrait apparaître comme suit :

------------------------------------------------------------
Votre message a été refusé par le programme de filtrage de messagerie du receveur.
La raison donnée est la suivante :
Je ne prend pas les messages venant de vous, et je ne veux pas non plus vos aliments pour oiseaux !
------------------------------------------------------------
 	2.2	Action reject
Ce paragraphe met à jour la définition de l'action "reject" du paragraphe 4.1 de la [RFC3028] et est une extension facultative à la [RFC5228].

Usage : reject <raison : chaîne>

Les mises en œuvre de Sieve qui utilisent l'action "reject" doivent utiliser la chaîne de capacité "reject".

L'action "reject" annule la conservation implicite et refuse la livraison d'un message. La chaîne "reason" est une chaîne UTF-8 [RFC3629] qui spécifie la raison du refus. À la différence de l'action "ereject" décrite ci-dessus, cette action va toujours favoriser la préservation du texte exact de la raison du refus. Normalement, l'action "reject" refuse la livraison d'un message en renvoyant une MDN à l'envoyeur (voir le paragraphe 2.2.1). Cependant, les mises en œuvre PEUVENT refuser la livraison sur le protocole SMTP/LMTP (comme précisé au paragraphe 2.5) si et seulement si toutes les conditions suivantes sont vraies :

1.	La chaîne "reason" comporte seulement des caractères US-ASCII ou la chaîne "reason" contient des caractères non US-ASCII et le client et le serveur prennent tous deux en charge et négocient l'utilisation d'une extension SMTP/LMTP pour l'envoi des réponses UTF-8.

2.	Le protocole LMTP est utilisé, ou le protocole SMTP est utilisé et le message a un seul receveur, ou le protocole SMTP est utilisé, le message a plusieurs receveurs, et tous ont refusé la livraison du message (que Sieve soit ou non utilisé).

Exemple :
              require ["reject"];
              si taille : plus de 100 k {
                  rejeter le texte :
     Message trop gros. Si vous voulez m'envoyer une grosse pièce jointe, mettez la sur un site public de la Toile et envoyez moi un URL.
      .
                  ;
              }

(Faire comme si la chaîne "reason" ci-dessus contenait du texte non US-ACSII.)

Les mises en œuvre peuvent utiliser les techniques décrites au paragraphe 2.1 pour déterminer si un rapport de non livraison ne devrait pas être envoyé à un envoyeur falsifié. Les mises en œuvre DEVRAIT enregistrer les instances où un rapport de non livraison n'est pas envoyé et la raison du non envoi du rapport.

 	2.2.1	Rejet d'un message par l'envoi d'un MDN
L'action "reject" renvoie le message reçu à l'envoyeur d'enveloppe spécifié par l'adresse MAIL FROM (ou Return-Path) en l'enveloppant dans un formulaire "reject" qui explique qu'il a été rejeté par le receveur.

Noter que conformément à la [RFC3798], les notifications de disposition de message NE DOIVENT PAS être générées si le MAIL FROM (ou Return-Path) est vide.

Un message "reject" DOIT prendre la forme d'une MDN d'échec comme spécifié dans la [RFC3798]. La portion lisible par l'homme du message, le premier composant de la MDN, contient le message lisible par l'homme qui décrit l'erreur, et il DEVRAIT contenir du texte supplémentaire alertant l'envoyeur original apparent de ce que le message a été refusé par un filtre de messagerie.

Le champ disposition de MDN comme défini dans la spécification de MDN DOIT être "deleted" (supprimé) et DOIT avoir les modes "MDN-sent-automatically" et "automatic-action" établis (voir le paragraphe 3.2.6 de la [RFC3798]). Dans le script suivant, un message est rejeté et retourné à l'envoyeur.

Exemple :
               require ["reject"];
               si l'en-tête :contient "from" "coyote@desert.exemple.org" {
                   rejeter le texte :
       Je ne prend pas les messages venant de vous, et je ne veux pas non plus vos aliments pour oiseaux !
       .
                   ;
               }

Pour ce script, la première partie de la MDN pourrait apparaître comme suit :

------------------------------------------------------------
Le message a été refusé par le programme de filtrage de messagerie du receveur.
La raison donnée est la suivante :
Je ne prend pas les messages venant de vous, et je ne veux pas non plus vos aliments pour oiseaux !
   ------------------------------------------------------------

 	2.3	Mise à niveau en silence de "reject" à "ereject"
Les mises en œuvre NE DOIVENT PAS mettre à niveau en silence les actions "reject" en actions "ereject" dans un script Sieve parce que cela pourrait conduire à des changements de comportement déplaisants non prévus par le propriétaire.

Les interfaces d'utilisateur qui présentent une option générique de rejet, et génèrent le résultat du script Sieve, PEUVENT passer de changer de générer des actions "reject" en actions "ereject" pour autant que le faire ne crée pas un changement  confus pour le propriétaire du script.

Les générateurs de script DEVRAIENT s'assurer qu'une action de rejet exécutée par suite d'un essai anti-pourriel/anti-virus positif soit faite en utilisant l'action "ereject", car elle est plus convenable pour de tels rejets.

Les générateurs de script PEUVENT automatiquement mettre à niveau les scripts qui étaient précédemment utilisés avec l'action "reject" pour des rejets relatifs à l'anti-pourriel/anti-virus. Noter que de tels générateurs DOIVENT s'assurer que l'environnement cible peut supporter l'action "ereject".

 	2.4	Compatibilité avec d'autres actions
Ce paragraphe s'applique également aux actions "reject" et "ereject". Toutes les références à l'action "reject" dans ce paragraphe peuvent être remplacées par l'action "ereject".

Une action "reject" annule la garde implicite.

Les mises en œuvre DOIVENT interdire l'exécution de plus d'un "reject" dans un script Sieve.

"reject" DOIT être incompatible avec l'action "vacation" [RFC5230]. Il n'est PAS RECOMMANDÉ que les mises en œuvre permettent l'utilisation de "reject" avec des actions qui causent la livraison des messages, comme "keep", "fileinto", et "redirect".

Rendre "reject" compatible avec des actions qui causent la livraison des messages viole le principe de la [RFC5321] qu'un message est soit livré, soit renvoyé à l'expéditeur. Donc renvoyer (rejeter) un message et le livrer va faire croire à l'envoyeur que le message n'a pas été livré.

Cependant, il existe des lois qui exigent de certaines organisations qu'elles archivent tous les messages reçus, même ceux qui sont rejetés. Aussi, il peut être assez utile de sauvegarder des copies des messages rejetés pour une analyse ultérieure.

Toute action qui modifierait le corps de message n'aura pas d'effet sur le corps de tout message refusé par "reject" en utilisant un code de réponse SMTP et NE DOIT PAS avoir d'effet sur le contenu des DSN/MDN générées.

 	2.5	Détails de refus au niveau du protocole
Si la chaîne "reason" consiste en plusieurs lignes séparées par des CRLF, alors le texte de la raison DOIT être retourné comme une réponse SMTP/LMTP multi lignes, conformément au paragraphe 4.2.1 de la [RFC5321]. Aucune ligne NE DOIT excéder la limite SMTP sur la longueur maximale de ligne. Pour rendre la chaîne "reason" conforme à de telles limites, le serveur PEUT insérer des CRLF et transformer la réponse en une réponse multi lignes.

Dans le script suivant (qui suppose la prise en charge des extensions "spamtest" [RFC5235] et "fileinto") les messages qui vérifient l'essai positif de pourriel sont refusés.

Exemple :
               require ["ereject", "spamtest", "fileinto", "comparator-i;ascii-numeric"];
               if spamtest :value "ge"
                           :comparator "i;ascii-numeric" "6" {
                   ereject text:
       Le moteur antiSpam pense que ce message est un pourriel.
       Il est donc refusé.
       Appelez le 1-900-PAY-US si vous voulez nous contacter.
       .
                   ;
               } elsif spamtest :value "ge"
                                :comparator "i;ascii-numeric" "4" {
                   fileinto "Suspect";
               }

L'extrait suivant d'une session SMTP le montre en action.

         ...
         C: DATA
         S: 354 Send message, ending in CRLF.CRLF.
          ...
         C: .
         S: 550-Le moteur antiSpam pense que ce message est un pourriel.
         S: 550-Il est donc refusé.
         S: 550 Appelez le 1-900-PAY-US si vous voulez nous contacter.

Si le serveur SMTP/LMTP pend en charge la [RFC2034], il DOIT ajouter un code d'erreur amélioré approprié au texte de "reason". Le code  d'erreur amélioré 5.7.1 ou un 5.7.0 plus générique est RECOMMANDÉ. Avec un code d'erreur amélioré, la réponse à une commande DATA dans l'exemple SMTP ci-dessous ressemblerait à :

         S: 550-5.7.1 Le moteur antiSpam pense que ce message est un pourriel.
         S: 550-5.7.1 Il est donc refusé.
         S: 550 5.7.1 Appelez le 1-900-PAY-US si vous voulez nous contacter.

si le serveur a choisi "5.7.1" comme approprié.

Si une mise en œuvre de Sieve qui prend en charge "ereject" ne souhaite pas divulguer immédiatement la raison du rejet (par exemple, qu'elle a détecté un pourriel) elle peut différer d'envoyer immédiatement le code d'erreur 550 en envoyant un code d'erreur 4XX sur la première tentative de réception du message.

 	3.	Changements par rapport à la RFC 3028

On a précisé que l'action "reject" annule la garde implicite. On a étendu la liste des actions permises sur "reject" pour inclure le rejet de messages au niveau du protocole.

Ajout de l'action "ereject" qui est similaire à "reject", mais va toujours favoriser le rejet du message au niveau du protocole.

 	4.	Considérations sur la sécurité

L'introduction de ce document discute pourquoi rejeter des messages avant la livraison est meilleur que de les accepter et les renvoyer.

Bien que les détails des techniques qui peuvent être utilisées pour déterminer quand éliminer en silence un rapport de non livraison sortent du domaine d'application de ce document, la permission explicite que donne ce document d'effectuer une telle action peut permettre des situations de déni de service. Des techniques comme la vérification de pourriel, la vérification du chemin de retour, et d'autres, peuvent avoir, et ont des faux positifs. On devrait faire attention à empêcher la perte de messages légitimes par l'omission de la notification de la non livraison à l'envoyeur.

Les questions de sécurité associées aux auto-répondeurs de messagerie électronique sont discutées en profondeur dans la section des Considérations sur la sécurité de la [RFC3834]. Le présent document n'est pas supposé introduire de nouvelles considérations de sécurité supplémentaires dans ce domaine général.

L'extension "ereject" ne soulève pas d'autres considérations de sécurité qui ne soient déjà présentes dans la  spécification de base [RFC5228], et ces questions sont discutées dans la [RFC5228].

 	5.	Considérations relatives à l’IANA

Les paragraphes qui suivent montrent les enregistrements de l'IANA pour les extensions à Sieve spécifiées dans ce document.

 	5.1	Enregistrement de l'extension "reject" 
Il est demandé à l'IANA de mettre à jour l'enregistrement de l'extension Sieve "reject" comme précisé ci-dessous :

Nom de capacité : reject
Description : ajoute l'action "reject" pour refuser la livraison d'un message. La raison exacte du refus est renvoyée au client.
Numéro de RFC : RFC 5429
Adresse de contact : liste de diffusion Sieve à <ietf-mta-filters@imc.org>

 	5.2	Enregistrement de l'extension "ereject"
Il est demandé à l'IANA de remplacer l'enregistrement préliminaire de l'extension de refus Sieve par l'enregistrement suivant :

Nom de capacité : ereject
Description : ajoute l'action "ereject" pour refuser la livraison d'un message. Le refus devrait se produire aussitôt que possible (par exemple, au niveau du protocole) et pourrait ne pas préserver la raison exacte du refus si elle contient du texte non US-ASCII.
Numéro de RFC : RFC 5429
Adresse de contact : liste de diffusion Sieve à <ietf-mta-filters@imc.org>

 	6.	Références
 	6.1	Références normatives

[RFC2033]	J. Myers; "Protocole de transfert de messagerie locale", octobre 1996. (Information)

[RFC2034]	N. Freed, "Extension de service SMTP pour le retour de codes d'erreur améliorés", octobre 1996. (P.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)

[RFC3462]	G. Vaudreuil, "Type de contenu Multipart/Report pour les rapports des messages administratifs du système de messagerie", janvier 2003. (Remplacée par RFC6522, STD 73)

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

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003, DOI 10.17487/RFC3629.

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

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

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

[RFC5321]	J. Klensin, "Protocole simple de transfert de messagerie(SMTP)", octobre 2008. (Remplace RFC2821) (MàJ RFC1123) (D.S.)

 	6.2	Références pour information

[Joe-DoS]	Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery Notice Attacks", avril 2004, <http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf>.

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

[RFC3834]	K. Moore, "Recommandations sur les réponses automatiques à la messagerie électronique", août 2004. (MàJ par RFC5436) (P.S.)

[RFC5235]	C. Daboo, "Filtrage de messagerie Sieve : extensions Spamtest et Virustest", janvier 2008. (Remplace RFC3685) (P.S.)

[RFC5598]	D. Crocker, "Architecture de la messagerie Internet", juillet 2009. (Information) 

[UTF8-RESP]	Melnikov, A., "SMTP Language Extension", Travail en cours, juin 2007.

 	Appendice A.	Remerciements

Merci à Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, Mark E. Mallett, Philip Guenther, Michael Haardt, et Randy Gellens de leurs commentaires et corrections.

Les auteurs remercient de son immense travail Tim Showalter comme auteur de la RFC 3028, qui a à l'origine défini l'action "reject".

 	Appendice B.	Contributeurs

Matthew Elvey	Alexey Melnikov	
The Elvey Partnership, LLC	Isode Limited	
1819 Polk Street, Suite 133	5 Castle Business Village	
San Francisco, CA  94109	36 Station Road	
USA	Hampton, Middlesex  TW12 2BX	
mél : matthew@elvey.com	UK	
	mél : Alexey.Melnikov@isode.com	

 	Adresse de l'éditeur

Aaron Stone
Serendipity
260 El Verano Ave
Palo Alto, CA  94306
USA
mél : aaron@serendipity.palo-alto.ca.us