RFC2852 Extension de service SMTP Deliver BY Newman

Groupe de travail Réseau

D. Newman, Sun Microsystems

Request for Comments : 2852

juin 2000

RFC mise à jour : 1894


Catégorie : En cours de normalisation

Traduction Claude Brière de L’Isle



Extension de service SMTP Deliver By



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 (2000). Tous droits réservés


Résumé

Le présent mémoire définit un mécanisme par lequel un client SMTP peut demander, lorsque il transmet un message à un serveur SMTP, que le serveur livre le message dans un délai prescrit. Un client qui fait une telle demande spécifie aussi le traitement de message qui doit être effectué si le message ne peut pas être livré dans le délai spécifié : soit le message est à retourner comme non livrable sans autre traitement, soit une notification d’état de livraison "retardée" (DSN, delivery status notification) [RFC1894] sera produite.


La présente extension ne devrait pas être vue comme un véhicule pour demander un traitement "prioritaire". Un serveur SMTP qui la reçoit peut allouer la priorité de traitement qu’il souhaite à un message transmis avec une demande Deliver By (à livrer avant). Une demande Deliver By sert à exprimer l’urgence d’un message et à fournir un degré supplémentaire de détermination de son traitement. Une indication du statut de message urgent au sein d’une période donnée peut être demandée et sera honorée. De plus, le message peut être retiré si il n’est pas livré dans le délai prévu.


Une utilisation typique de ce mécanisme est pour empêcher la livraison d’un message au delà d’un certain moment futur significatif pour l’envoyeur ou le receveur mais qui n’est pas connu des MTA qui traitent le message. Par exemple, l’envoyeur peut savoir que le message sera livré comme une notification mais ne pas considérer le message comme suffisamment important pour garantir de le notifier au receveur après les heures ouvrées. Dans ce cas, le message pourrait être marqué de telle sorte que les tentatives de livraison ne soient pas faites après 17 h. Une autre utilisation courante apparaît lorsque un envoyeur souhaite être alerté en cas de retard de livraison. Dans ce cas, l’envoyeur peut marquer un message de façon que si il n’est pas livré dans, disons les 30 minutes, une DSN "retardé" soit générée mais que les tentatives de livraison soient néanmoins poursuivies. Dans ce cas, il a été permis à l’envoyeur d’exprimer une préférence sur le moment où il aimerait apprendre les problèmes de livraison.


1. Définitions


Dans le présent document, le terme "livrer" signifie l’acte de transmission d’un message à son destinataire "final" par un agent de transport de message (MTA, message transport agent). La plupart du temps, mais pas toujours, cela signifie de mémoriser ou faire passer d’une certaine manière le message dans la boîte aux lettres du receveur. Donc, un MTA qui accepte un message à livrer dans un délai spécifié est d’accord pour mémoriser ou relayer le message à la boîte aux lettres du receveur dans le délai spécifié. En dehors de la portée du terme "livrer" sont toutes les actions spécifiées par l’utilisateur qui pourraient avoir lieu après que le MTA a mémorisé ou relayé le message ; par exemple, des filtres programmés par l’utilisateur qui, souvent à l’insu du MTA, renvoient le message à quelque autre localisation.


Les mots clés "DOIT", "NE DOIT PAS", "DEVRAIT" et "NE DEVRAIT PAS" dans ce document sont à interpréter comme décrit dans la [RFC2119].


2. Cadre pour l’extension de service Deliver By de SMTP


L’extension de service Deliver By de SMTP utilise le mécanisme d’extension de service SMTP décrit dans la [RFC1869]. L’extension de service SMTP suivante est donc définie :

(1) Le nom de l’extension de service SMTP est "Deliver By".

(2) La valeur du mot clé EHLO associé à cette extension de service est "DELIVERBY".

(3) Un paramètre facultatif est permis avec cette valeur de mot clé EHLO. Le paramètre facultatif, lorsque il est fourni, est une liste d’options dont les éléments sont séparés par une virgule. Une seule option, min-by-time, est spécifiée dans le présent document. D’autres documents peuvent à l’avenir étendre la présente spécification en spécifiant des options supplémentaires. L’option min-by-time est un entier fixé qui indique le délai fixé minimum que le serveur va accepter lorsque un by-mode de "R" est spécifié selon la Section 4.

La syntaxe du paramètre facultatif est la suivante, en utilisant la notation BNF augmenté de la [RFC2234] :


deliverby-param = min-by-time *( ',' jeton-d’extension )

min-by-time = [CHIFFRE 1*9]

jeton-d’extension = 1*<tout CHAR à l’exclusion de SP, COMMA et tous caractères de contrôle (US ASCII 0-31 inclus)>

SP = <caractère espace (code décimal ASCII 32)>

COMMA = <caractère virgule (code décimal ASCII 44)>


Si le paramètre est omis, aucune information n’est convoyée sur le by-time minimum fixé du serveur.


(4) Un paramètre facultatif qui utilise le mot clé "BY" est ajouté à la commande MAIL FROM.


(5) La longueur maximum de la ligne de commande MAIL FROM est augmentée de 17 caractères par l’ajout possible du mot clé et de la valeur BY.


(6) Aucun verbe SMTP supplémentaire n’est défini par cette extension.


3. Extension de service SMTP Deliver By


Un client SMTP qui souhaite utiliser l’extension de service SMTP Deliver By peut produire la commande EHLO pour commencer une session SMTP et pour déterminer si le serveur SMTP prend en charge l’extension de service. Si le serveur répond par le code 250 à la commande EHLO, et si la réponse comporte le mot clé EHLO DELIVERBY, l’extension de service SMTP Deliver By est alors prise en charge par le serveur.


Si un paramètre numérique suit la valeur de mot clé DELIVERBY de la réponse EHLO, le paramètre indique alors la valeur minimum permise pour le by-time lorsque un by-mode de "R" est spécifié avec la commande étendue MAIL FROM, comme décrit à la Section 4. Toute tentative d’un client de spécifier un by-mode de "R" et un by-time strictement inférieur à cette limite de min-by-time sera rejetée avec un code de réponse d’échec permanent (55z).


Un serveur SMTP qui prend en charge l’extension de service Deliver By SMTP va accepter la version étendue de la commande MAIL FROM décrite à la Section 4. Lorsque elle est prise en charge par le serveur, un client SMTP peut utiliser la commande étendue MAIL FROM (au lieu de la commande MAIL FROM décrite dans la [RFC0821]) pour demander que le message soit livré dans le délai spécifié. Le serveur peut alors retourner un code d’erreur approprié si il détermine que la demande ne peut pas être honorée. Noter que ceci peut ne pas être apparent au serveur jusqu’à la présentation des adresses du receveur avec des commandes RCPT TO ou jusqu'à l’achèvement du transfert des données du message avec la commande point (.). À ce titre, le serveur peut envoyer au client une réponse de réussite à la commande MAIL FROM pour retourner ultérieurement une réponse d’erreur à la commande RCPT TO, DATA, ou point.


4. Commande étendue MAIL FROM


La commande MAIL FROM étendue est produite par un client SMTP lorsque il souhaite informer un serveur SMTP qu’un message est à livrer dans un délai spécifié et de quelle action effectuer si le message se révélait indélivrable dans ce délai. La commande MAIL FROM étendue est identique à la commande MAIL FROM définie dans la [RFC0821], sauf qu’un paramètre BY apparaît après l’adresse.


La syntaxe complète de cette commande étendue est définie dans la [RFC1869]. Le mot clé esmtp est "BY" et la syntaxe pour la valeur esmtp est donnée par la syntaxe pour by-value qui figure ci-dessous. Dans le BNF augmenté de la [RFC2234], la syntaxe pour le paramètre BY esmtp est

by-parameter = "BY="by-value

by-value = by-time";"by-mode[by-trace]

by-time = ["-" / "+"]1*9digit ; une valeur négative ou zéro n’est pas permise avec un by-mode de "R"

by-mode = "N" / "R" ; "Notify" ou "Return"

by-trace = "T" ; "Trace"


Noter que le mot clé BY esmtp DOIT avoir une valeur esmtp associée. Le by-time est une représentation décimale du nombre de secondes dans lequel le message devrait être délivré et est dans la gamme -999 999 999 secondes ≤ by-time ≤ +999 999 999 secondes et est donc suffisant pour représenter une durée d’approximativement 31,6 ans dans le passé à 31,6 ans dans le futur.


Comme décrit au paragraphe 4.1, le by-mode indique l’action que doit effectuer le serveur SMTP si il n’était pas possible de transmettre le message dans les by-time secondes.


Noter que by-time est une différence de temps : le nombre de secondes dans lequel livrer le message. Cette différence de temps n’allonge pas la période de rétention normale d’un MTA pour un message non délivrable et n’est pas non plus un temps de "livraison après".


Une différence de temps est utilisée afin d’éviter les problèmes associés à des différences dans les horloges systèmes entre clients et serveurs. À réception d’un by-parameter valide, les serveurs sont supposés convertir le by-time en un temps absolu spécifique local appelé le deliver-by-time. Cela se fait en ajoutant le by-time à réception à l’heure spécifique locale courante et en arrivant ainsi à l’heure absolue spécifique locale qui est by-time secondes dans le futur ou le passé, selon le signe arithmétique du by-time. Le message est alors à livrer au deliver-by-time. Le client qui envoie et le serveur qui reçoit devraient supposer que le temps de transmission de la commande MAIL FROM est instantané. Il est clair que cela ne se passe pas comme cela et la latence du réseau va introduire une erreur dont la nature va être d’allonger légèrement le by-time effectif. Plus le message effectue de bonds, plus l’effet sera prononcé à cause de la nature cumulative de cette erreur induite par la latence.


Dans le cas d’un by-mode de "N", il est possible que le by-time soit zéro ou négatif. Cela n’est pas une erreur et ne devrait pas être rejeté à ce titre. Cela indique un message pour lequel le deliver-by-time s’est produit -(by-time) secondes dans le passé. [Ici, "-(by-time)" représente la négation arithmétique de la valeur de by-time.] Les valeurs zéro et négatives sont permises afin de préserver les informations sur toute information d’heure de livraison demandée – informations que le MTA de livraison peut souhaiter inclure avec le message livré dans l’intérêt du receveur ou pour les montrer dans une notification DSN ou NDN (notification de non livraison).


Dans le cas d’un by-mode de "R", un by-time de zéro ou négatif est une erreur de syntaxe. Dans un tel cas, le serveur SMTP DEVRAIT retourner un code de réponse SMTP de défaillance permanente (501) en réponse à la commande MAIL FROM étendue. Si le serveur SMTP prend aussi en charge les codes d’erreur améliorés de la [RFC2034], un code d’erreur amélioré de 5.5.4 DEVRAIT aussi être retourné.


Si le by-time est une spécification de by-time valide mais si le serveur SMTP ne peut pas l’honorer ou l’accepter pour une raison spécifique du serveur, le serveur SMTP DEVRAIT alors répondre soit par une réponse SMTP 455 si la condition est transitoire, soit par une réponse SMTP 555 si la condition est permanente. De plus, si le serveur SMTP prend aussi en charge la [RFC2034], un code d’erreur amélioré 4.X.X ou 5.X.X convenable DEVRAIT être aussi retourné.


4.1. Comportement du serveur à réception de la commande MAIL FROM étendue

À réception d’une commande MAIL FROM étendue contenant un paramètre BY valide, un serveur SMTP et le MTA associé doivent traiter le message en accord avec les paragraphes qui suivent, 4.1.1 à 4.1.5. Les notifications d’état de livraison générées en réponse au traitement d’un message avec une demande Deliver By devraient inclure à la fois le champs facultatif DSN Arrival-Date et le nouveau champ DSN Deliver-By-Date décrit à la Section 5 du présent mémoire.


Noter que le by-time d’un message n’allonge pas la période normale de rétention de message du MTA : un MTA PEUT retourner un message comme non livrable avant que le deliver-by-time ait été atteint.


4.1.1 Livraison réussie

Si le message est livré avant le deliver-by-time, aucune action particulière n’est nécessaire. Si le serveur SMTP ou le MTA prend aussi en charge l’extension de service de notification d’état de livraison SMTP de la [RFC1891] et si un paramètre NOTIFY incluant "SUCCESS" a été spécifié, une DSN "livré" avec l’état approprié doit être retourné conformément à la [RFC1891].


4.1.2 Échec de livraison, délai de livraison non encore atteint

Si deliver-by-time n’est pas encore passé et si le message se révèle indélivrable pour des raisons temporaires, le serveur SMTP ou le MTA devrait alors continuer les tentatives de livraison ou de relais selon la politique de traitement de message du site. Si la période de rétention de message du MTA est inférieure au by-time, le MTA PEUT retourner le message comme indélivrable avant que le deliver-by-time ait été atteint. Cependant, le message DOIT quand même être traité selon les paragraphes 4.1.1 à 4.1.5.


Si deliver-by-time n’est pas encore passé et si le message ne peut pas être livré pour des raisons permanentes, le serveur SMTP ou le MTA DOIT alors retourner une DSN "échec" avec un état approprié pour chaque adresse de receveur soit sans paramètre NOTIFY spécifié, soit avec le paramètre NOTIFY qui inclut "FAILURE".


4.1.3 Délai expiré ; livraison à temps atteinte ou dépassée

Si le message n’est pas livré ou relayé avant deliver-by-time et si un by-mode de "R" a été spécifié, on peut ne faire aucune autre tentative de livraison du message. Le serveur ou le MTA DOIT produire une DSN "échec" avec l’état 5.4.7, "heure de livraison dépassée", à chaque adresse de receveur soit sans paramètre NOTIFY spécifié, soit avec le paramètre NOTIFY qui inclut "FAILURE".


Si le message n’est pas livré ou relayé avant deliver-by-time et si un by-mode de "N" a été spécifié, le serveur ou le MTA devrait continuer de tenter de livrer ou relayer le message en utilisant la politique de traitement de message du site. De plus, le serveur ou le MTA DOIT produire une DSN "retardé" avec l’état 4.4.7, "heure de livraison dépassée", à chaque adresse de receveur soit sans paramètre NOTIFY spécifié, soit avec le paramètre NOTIFY qui inclut "FAILURE".


4.1.4 Relais vers un autre serveur SMTP

Les paragraphes 4.1.4.1 et 4.1.4.2 décrivent la situation où un message avec une demande Deliver By peut être relayée à un autre serveur SMTP et quelles actions supplémentaires, s’il en est, devraient ou doivent être effectuées. En plus de ce qui est exposé dans ces paragraphes, on doit aussi observer ce qui suit quand le relais est permis.


Si le message est relayé à un serveur SMTP qui prend en charge l’extension Deliver By, un nouveau paramètre BY DOIT être relayé qui spécifie une valeur de by-time indiquant le nombre de secondes restant jusqu’à deliver-by-time. La nouvelle valeur de by-time devrait être calculée aussi près que raisonnablement possible du moment où la commande MAIL FROM est transmise par le client SMTP qui relaie. Noter que si deliver-by-time est passé, le relayed-by-time sera une valeur négative indiquant combien de secondes se sont écoulées depuis delivery-by-time. Un tel cas – relais d’un message pour lequel deliver-by-time est juste arrivé ou passé – ne peut arriver qu’avec un message qui a un by-mode de "N".


Lorsque un message avec un champ by-trace d’une valeur "T" est relayé, une DSN "relayé" DEVRAIT être générée par le client SMTP relayeur pour chaque receveur qui n’a pas spécifié un paramètre NOTIFY ou dont le paramètre NOTIFY n’a pas la valeur "NEVER".


Noter que ces DSN "relayé" sont générées sans considération de si des notifications de réussite étaient demandées avec un paramètre NOTIFY=SUCCESS. Noter de plus que les DSN "relayées" discutées ici ne sont pas les notifications terminales : les serveurs et MTA SMTP peuvent quand même prendre en charge la [RFC1891] et à ce titre des notifications supplémentaires peuvent aussi être faites.


4.1.4.1 Relais d’un message avec un by-mode de "R"

Un message pour lequel un by-mode de "R" a été spécifié NE DOIT PAS être relayé à un serveur SMTP qui ne prend pas en charge l’extension de service SMTP Deliver By. De plus, le serveur auquel il est relayé NE DOIT PAS avoir un by-time minimum fixé qui soit supérieur au temps restant à courir d’ici la livraison du message. Le by-time minimum fixe est exprimé par le paramètre deliverby facultatif discuté à la Section 2.


Si le message requiert un relais afin d’être livré mais ne peut pas être relayé, le message est alors réputé indélivrable pour des raisons permanentes et le paragraphe 4.1.2 devrait être appliqué.


4.1.4.2 Relais d’un message avec un by-mode de "N"

Un message avec un by-mode de "N" peut être relayé à un autre serveur sans considération de si le serveur SMTP auquel il est relayé prend ou non en charge l’extension Deliver By.


Si le message est relayé avant deliver-by-time à un serveur SMTP qui ne prend pas en charge l’extension Deliver By, le client SMTP relayeur DOIT produire une DSN "relayé" pour chaque receveur qui n’a pas spécifié un paramètre NOTIFY ou dont le paramètre NOTIFY n’a pas la valeur "NEVER". De plus, si le serveur SMTP qui fait le relais prend en charge l’extension de service SMTP de notification d’état de livraison de la [RFC1891] alors pour chaque receveur, si aucun paramètre NOTIFY n’a été fourni, "NOTIFY=FAILURE,DELAY" DEVRAIT être demandé ; si un paramètre NOTIFY était spécifié et n’avait pas la valeur "NEVER", "DELAY" DEVRAIT être ajouté à la liste des valeurs de notify-list-element si il n’est pas déjà présent. Noter que ceci se substitue explicitement à la formulation "NE DOIT PAS" du paragraphe 6.2.1(c) de la [RFC1891].


4.1.5 Relais vers un système de messagerie extérieur

Si le système de messagerie étranger accepte une sémantique similaire de celle de l’extension de service SMTP Deliver By décrite dans le présent mémoire, il porte alors la demande Deliver By à ce système. Autrement, il relaie le message comme si il relayait à un serveur SMTP qui ne prend pas en charge l’extension Deliver By.


5. Notifications et extension d’état de livraison


Le format des notifications d’état de livraison (DSN) est spécifié dans la [RFC1894]. Les DSN générées en réponse à une demande Deliver By devraient inclure un champ de DSN Arrival-Date. Le présent mémoire étend aussi les champs par message de la [RFC1894] pour inclure un nouveau champ de la DSN, Deliver-By-Date, qui indique le deliver-by-time tel que calculé par le MTA ou le serveur SMTP qui génère la DSN. Dans le BNF augmenté de la RFC 822 [RFC2234], les champs par message sont donc étendus comme suit :


per-message-fields =

[ original-envelope-id-field CRLF ] reporting-mta-field CRLF

[ dsn-gateway-field CRLF ]

[ received-from-mta-field CRLF ]

[ arrival-date-field CRLF ]

[ deliver-by-date-field CRLF ]

*( extension-field CRLF )

deliver-by-date-field = "Deliver-by-date" ":" date-time où date-time est un champ date-time de la RFC 822 [RFC2234] comme amendé par la [RFC1123].


6. Exemples


Dans l’exemple de dialogue SMTP suivant, le client SMTP demande qu’un message de <eljefe@bigbiz.com> soit livré à <topbanana@other.com> dans les 2 minutes (120 secondes) et retourné autrement. Cette demande prend la forme d’un paramètre BY sur la ligne MAIL FROM de "BY=120;R" comme montré ci-dessous :


S: 220 acme.net SMTP server here

C: EHLO bigbiz.com

S: 250-acme.net

S: 250 DELIVERBY

C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R

S: 250 <eljefe@bigbiz.com> sender ok

C: RCPT TO:<topbanana@other.com>

S: 250 <topbanana@wherever.com> recipient ok


Supposons maintenant que le serveur SMTP receveur dans l’exemple ci-dessus ait besoin de relayer le message à un autre serveur SMTP, mail.other.com. Du fait du by-mode original de "R", le message peut seulement être relayé à un autre serveur SMTP qui prend en charge l’extension Deliver By (paragraphe 4.1.4). De plus, lorsque il relaie le message, la demande Deliver By doit être relayée. En gardant cela en mémoire, considérons le dialogue SMTP suivant :


S: 220 mail.other.com ESMTP server at your service

C: EHLO acme.net

S: 250-mail.other.com

S: 250 DELIVERBY 240

C: QUIT


Dans ce dialogue, le serveur SMTP relayeur, acme.net, se connecte à mail.other.com et produit une commande EHLO. Il apprend alors que l’extension Deliver By est prise en charge mais que le by-time minimum pour un by-mode de "R" est de 4 minutes (240 secondes). Cette valeur excède le by-time original du message et excède donc nécessairement le by-time restant. Le serveur SMTP relayeur termine donc la session SMTP après quoi il doit soit tenter de suivre un autre enregistrement M, soit, si il n’y a plus d’autre enregistrement MX à suivre, retourner le message comme indélivrable. Un comportement similaire résulterait si la commande EHLO était suivie d’une erreur ou ne comportait pas le mot clé DELIVERBY.


Considérons maintenant la session SMTP de relais :


S: 220 mail.other.com ESMTP server at your service

C: EHLO acme.net

S: 250-mail.other.com

S: 250 DELIVERBY 30

C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R

S: 250 <eljefe@bigbiz.com> Sender okay

C: RCPT TO:<topbanana@other.com>

S: 250 <topbanana@wherever.com> Recipient okay


Dans celle-ci, le client SMTP relayeur relaie le paramètre BY avec le by-mode préservé et le by-time calculé comme étant le nombre de secondes restant à l’heure approximative où la commande MAIL FROM a été transmise du client SMTP relayeur (acme.net) au serveur SMTP receveur (mail.other.com). Dans cet exemple, 22 secondes se sont écoulées depuis que acme.net a reçu la ligne MAIL FROM du client envoyeur d’origine et a relayé la demande Deliver By à mail.other.com.


7. Considérations sur le relais fondé sur MX


Les sites qui souhaitent utiliser l’extension de service SMTP Deliver By et qui dirigent leurs messages via des enregistrements MX de la [RFC0974] ont besoin de s’assurer que tous leurs hôtes MX -- hôtes auxquels leurs messages sont dirigés par les enregistrements MX – prennent en charge l’extension Deliver By. Les clients SMTP qui prennent en charge Deliver By NE DEVRAIENT PAS tenter plusieurs hôtes MX en cherchant lesquels prennent en charge Deliver By.


Les hôtes MX devraient faire très attention à la valeur de min-by-time qu’ils présentent en réponse aux commandes EHLO. Il n’est pas pratique pour un hôte MX de présenter une valeur qui (1) est substantiellement différente de ce qui peut être traité par l’hôte de destination auquel il relaye, ou (2) ne reconnaît pas les latences de livraison normales introduites lorsque l’hôte MX relaye la messagerie à l’hôte de destination.


8. Considérations pour la sécurité


La mise en œuvre de Deliver By permet de retracer un système de transport de messagerie. Le champ by-trace "T" demande explicitement que soit générée une trace. De plus, même lorsque le champ by-trace n’est pas utilisé, une trace brute peut être générée en entrant une série de messages dans le système de transport, chacun augmentant successivement la valeur du by-time ; par exemple, "BY=0;R", "BY=1;R", "BY=2;R". La preuve, et dans certains cas, la trace, peut être réalisée par d’autres moyens : en interrogeant les serveurs SMTP visibles, en recherchant les lignes d’en-tête Received: dans les bonds des messages, et en utilisant des utilitaires tels que "traceroute".


9. Autres considérations


Les serveurs SMTP qui prennent en charge l’extension de service SMTP Deliver By ainsi que leurs MTA associés ne sont pas obligés d’affecter une priorité de traitement particulière aux messages qui ont des demandes Deliver By. Bien sûr, certains serveurs et MTA SMTP peuvent le faire si ils le désirent. De plus, les notifications d’état de livraison générées en réponse aux messages qui ont des demandes Deliver By ne sont pas obligées de recevoir de traitement particulier. Par conséquent, les utilisateurs de ce service ne devraient pas, en général, s’attendre à un traitement accéléré de leurs messages. De plus, le simple fait qu’un message soit envoyé avec un paramètre "BY=60;R" ne garantit pas que l’envoyeur va apprendre un échec de livraison dans un délai spécifié car la DSN ne va pas nécessairement être renvoyée à l’envoyeur.


10. Remerciements


L’auteur tient à remercier Keith Moore pour avoir fourni l’élan initial de production de ce document ainsi que les idées de base qui y sont incorporées. Des remerciements sont aussi dus à Ned Freed et Chris Newman pour leur relecture de ce document et leurs suggestions d’améliorations.


11. Références


[RFC0821] J. Postel, "Protocole simple de transfert de messagerie", STD 10, août 1982.


[RFC0974] C. Partridge, "L’acheminement de la messagerie et le système des domaines", janvier 1986. (Obsolète, voir la RFC2821)


[RFC1123] R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.


[RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "Extensions de service à SMTP", novembre 1995. (Obsolète, voir RFC5321, STD0010)


[RFC1891] K. Moore, "Extension de service SMTP pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3461) (P.S.)


[RFC1894] K. Moore, G. Vaudreuil, "Format de message extensible pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3464) (P.S.)


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


[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)


12. Adresse de l’auteur


Dan Newman

Sun Microsystems, Inc.

1050 Lakes Drive, Suite 250

West Covina, CA 91790

USA


téléphone : +1 626 919 3600

Fax : +1 626 919 3614

mél : dan.newman@sun.com


13. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2000). Tous droits réservés.


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

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

page - 7 -