Groupe de travail Réseau	B. Leiba, IBM T.J. Watson Research Center
Request for Comments : 5436	M. Haardt, freenet.de GmbH
RFC mise à jour : 3834	janvier 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Mécanisme mailto de notification Sieve

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.

Résumé
Le présent document décrit un profil d'extension Sieve pour les notifications, pour permettre d'envoyer des notifications par message électronique.
Table des matières
1. Introduction	1
1.1 Vue d'ensemble	1
1.2. Conventions utilisées dans ce document	2
2. Définition	2
2.1 Paramètre Notify "method"	2
2.2 Essai notify_method_capability	2
2.3 Étiquette Notify ":from"	2
2.4 Étiquette Notify ":importance"	2
2.5 Étiquette Notify ":options"	2
2.6 Étiquette Notify ":message"	2
2.7 Autres définitions	2
3. Exemples	4
4. Considérations d'internationalisation	5
5. Considérations sur la sécurité	5
6. Considérations relatives à l’IANA	6
6.1 Enregistrement de mécanisme de notification	6
6.2 Nouveau registre pour les mots clés de champ d'en-tête Auto-Submitted	6
6.3 Enregistrement initial de mots clés de champ d'en-tête Auto-Submitted	6
7. Références	7
7.1 Références normatives	7
7.2 Références pour information	7
Adresse des auteurs	8

 	1.	Introduction
 	1.1	Vue d'ensemble
L'extension "notify" de la [RFC5435] au langage de filtrage de messagerie Sieve [RFC5228] est un cadre pour fournir des notifications en employant des URI pour spécifier le mécanisme de notification. Le présent document définit comment les URI de la [RFC2368] sont utilisés pour générer des notifications par messagerie électronique.

 	1.2.	Conventions utilisées dans ce document
Les conventions de notation sont celles du paragraphe 1.1 de la [RFC5228], y compris celle de la [RFC2119].

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

 	2.	Définition

Le mécanisme mailto résulte en l'envoi d'un nouveau message (un "message de notification") pour notifier à un receveur un "message déclencheur".

 	2.1	Paramètre Notify "method"
Le mécanisme de notification mailto utilise les URI mailto standard comme spécifié dans la [RFC2368]. Les URI mailto peuvent contenir des champs d'en-tête consistant en un nom et une valeur d'en-tête. Ces champs d'en-tête sont appelés des "en-têtes d'URI" pour les distinguer des "en-têtes de message".

 	2.2	Essai notify_method_capability
L'essai notify_method_capability pour "online" peut retourner "oui" ou "non" seulement si le processeur Sieve peut déterminer avec certitude si les receveurs du message de notification sont ou non en ligne et enregistrés. Autrement, l'essai retourne "peut-être" pour cette méthode de notification.

 	2.3	Étiquette Notify ":from"
L'étiquette ":from" outrepasse l'envoyeur par défaut du message de notification. "Envoyeur" se réfère ici à la valeur utilisée dans l'en-tête "From" [RFC5322]. Les mises en œuvre PEUVENT aussi utiliser cette valeur dans la commande "MAIL FROM" de la [RFC5321] ("l'envoyeur d'enveloppe") ou elles peuvent préférer établir une boîte aux lettres qui reçoit les rebonds des messages de notification.

 	2.4	Étiquette Notify ":importance"
L'étiquette ":importance" n'a pas de signification particulière pour ce mécanisme de notification, et la présente spécification ne met pas de restriction à son utilisation. Les mises en œuvre PEUVENT utiliser la valeur de ":importance" pour établir une priorité ou une indication d'importance sur le message de notification (peut-être une indication visuelle, ou peut-être utiliser un des en-têtes de message non standard mais couramment utilisés).

 	2.5	Étiquette Notify ":options"
Cette étiquette n'est pas utilisée par la méthode mailto.

 	2.6	Étiquette Notify ":message"
La valeur de cette étiquette, si elle est présente, est utilisée comme le sujet du message de notification, et outrepasse tous les autres mécanismes pour déterminer le sujet (comme décrit ci-dessous). Sa valeur  NE DEVRAIT normalement PAS être tronquée, bien qu'il pourrait être raisonnable de tronquer une valeur excessivement longue.

 	2.7	Autres définitions
Parce que la réception d'un message électronique génère un autre message électronique, les mises en œuvre DOIVENT prendre des mesures pour éviter des boucles de messages. L'inclusion EXIGÉE d'un champ "Auto-Submitted:", comme décrite dans les lignes directrices sur la composition de messages, va aussi aider à la détection et l'évitement de boucles.

Les mises en œuvre NE DEVRAIENT PAS déclencher de notifications pour les messages qui contiennent des champs d'en-tête "Auto-Submitted:" avec toute valeur autre que "Non".

Les mises en œuvre DOIVENT permettre que des messages avec des envoyeurs d'enveloppe vide déclenchent des notifications.

Parce que cette méthode de notification utilise un système de mémorisation et livraison différée pour la livraison du message de notification, le processeur Sieve ne devrait pas avoir besoin de réessayer les notifications. Donc, les mises en œuvre de cette méthode DEVRAIENT utiliser les mécanismes normaux pour soumettre les messages SMTP et pour réessayer la soumission initiale. Une fois le message de notification soumis, les mises en œuvre NE DOIVENT PAS le resoumettre, car cela résulterait probablement en plusieurs notifications, et augmenterait le danger de boucle de message.

Les mises en œuvre DEVRAIENT envisager de limiter les messages de notification. En particulier, elles NE DEVRAIENT PAS envoyer des notifications dupliquées à la même adresse provenant de la même invocation de script. La mise en lots de notifications dans un court intervalle de temps à la même adresse pourrait aussi être utile. Différentes mises en œuvre, différents domaines administratifs, et différents utilisateurs peuvent avoir des besoins différents ; les options de configuration sont ici une bonne idée.

Le message de notification global est composé en utilisant les lignes directrices suivantes (voir la [RFC5322] pour les références aux champs d'en-tête de message) :

o	Si l'envoyeur d'enveloppe du message déclencheur est vide, l'envoyeur d'enveloppe du message de notification DOIT aussi être vide, pour éviter des boucles de message. Autrement, l'envoyeur d'enveloppe du message de notification DEVRAIT être réglé à la valeur de l'étiquette ":from" dans l'action notify, si une est spécifiée, il a la syntaxe d'une adresse de message électronique, et est valide selon les vérifications de sécurité spécifiques de la mise en œuvre (voir le paragraphe 3.3 de la [RFC5435]). Si ":from" n'est pas spécifié ou n'est pas valide, l'envoyeur d'enveloppe du message de notification DEVRAIT être réglé soit au champ "to" d'enveloppe provenant du message déclencheur, comme utilisé par Sieve, soit à une adresse de messagerie associée au système de notification, à la discrétion de la mise en œuvre. Ceci NE DOIT PAS être outrepassé par un en-tête d'URI "from", et un tel en-tête d'URI DOIT être ignoré.

o	Le ou les receveurs d'enveloppe du message de notification DEVRAIENT être réglés à la ou aux adresses spécifiées dans l'URI (y compris tous les en-têtes d'URI où le hname est "to" ou "cc").

o	Le champ d'en-tête "Auto-Submitted: auto-notified" DOIT être inclus dans le message de notification (voir le paragraphe 2.7.1). C'est pour réduire la probabilité de boucles de message, en étiquetant cela comme un message généré automatiquement. Entre autres résultats, cela va informer les autres systèmes de notification de ne pas générer d'autres notifications. Les en-têtes d'URI mailto avec un hname "auto-submitted" sont considérés comme non sûrs et DOIVENT être ignorés.

o	Le champ d'en-tête "From:" du message de notification DEVRAIT être réglé à la valeur de l'étiquette ":from" à l'action notify, si une est spécifiée, il a la syntaxe d'une adresse de messagerie, et est valide selon les vérifications de sécurité spécifiques de la mise en œuvre (voir le paragraphe 3.3 de la [RFC5435]). Si ":from" n'est pas spécifié ou n'est pas valide, le champ d'en-tête "From:" du message de notification DEVRAIT être réglé soit au champ "to" d'enveloppe provenant du message déclencheur, comme utilisé par Sieve, soit à une adresse de messagerie associée au système de notification, à la discrétion de la mise en œuvre. Ceci NE DOIT PAS être outrepassé par un en-tête d'URI "from", et un tel en-tête d'URI DOIT être ignoré.

o	Le champ d'en-tête "To:" du message de notification DEVRAIT être réglé à la ou aux adresses spécifiées dans l'URI (y compris tout en-tête d'URI où le hname est "to").

o	Le champ "Subject:" du message de notification DEVRAIT contenir la valeur définie par l'étiquette ":message", comme décrit dans la [RFC5435]. Si il n'y a pas d'étiquette ":message" et si il y a un en-tête "subject" sur l'URI, alors cette valeur DEVRAIT être utilisée. Si l'en-tête "subject" est aussi absent, le "subject" DEVRAIT être pris du message déclencheur. Noter que Sieve [RFC5229] peut être utilisé avantageusement ici, comme le montre l'exemple de la Section 3.

o	Le champ "References:" du message de notification PEUT être réglé à se référer au message déclencheur, et PEUT inclure des références provenant du message déclencheur.

o	Si l'URI mailto contient un en-tête "body", la valeur de cet en-tête DEVRAIT être utilisée comme corps du message de notification. Si il n'y a pas d'en-tête "body", il appartient à la mise en œuvre de décider si elle laisse le corps vide ou si elle utilise un extrait du message original.

o	Les champs "Received:" provenant du message déclencheur PEUVENT être conservés dans le message de notification, car ils pourraient fournir d'utiles informations de trace/historique/diagnostic. Le champ d'en-tête "Auto-Submitted" DOIT être placé au-dessus d'eux (voir le paragraphe 2.7.1). Les en-têtes d'URI avec le hname "received" sont considérés comme non sûrs, et DOIVENT être ignorés.

o	Les autres champs d'en-tête du message de notification qui se rapportent normalement à un nouveau message individuel (comme "Message-ID" et "Date") sont générés de la façon normale pour le message de notification, et NE DOIVENT PAS être copiés du message déclencheur. Tous les en-têtes d'URI avec ces noms DOIVENT être ignorés. De plus, l'en-tête "Date" sert d'horodatage de notification défini dans la [RFC5435].

o	Tous les autres champs d'en-tête du message de notification sont comme spécifié par les en-têtes d'URI, ou ont des valeurs spécifiques de la mise en œuvre ; leurs valeurs ne sont pas définies ici. Il est suggéré que la mise en œuvre mette en majuscule la première lettre des en-têtes d'URI et ajoute un caractère espace après les deux points entre le nom d'en-tête de message et la valeur quand elle ajoute des en-têtes d'URI au message, pour être cohérente avec la pratique courante des en-têtes de messagerie.

 	2.7.1	Champ d'en-tête Auto-Submitted
Le champ d'en-tête "Auto-Submitted: auto-notified" DOIT être inclus dans le message de notification (voir la [RFC3834]). Le champ d'en-tête "Auto-Submitted" est considéré comme un "champ de trace", similaire aux champs d'en-tête "Received" (voir la [RFC5321]). Si la mise en œuvre conserve les champs "Received" provenant du message déclencheur (voir ci-dessus) le champ "Auto-Submitted" DOIT être placé au-dessus de ces champs "Received", servant de frontière entre ceux provenant du message déclencheur et ceux qui vont faire partie du message de notification.

Le champ d'en-tête "Auto-Submitted: auto-notified" DOIT inclure un des paramètres suivants, ou les deux :

o	owner-email - spécifie une adresse de messagerie, déterminée par la mise en œuvre, du propriétaire du script Sieve qui a généré cette notification. Si il est spécifié, il pourrait être utilisé pour identifier ou contacter le propriétaire du script. L'attribut du paramètre est "owner-email", et la valeur du paramètre est une chaîne entre guillemets contenant une adresse de messagerie, comme définie par "addr-spec" dans la [RFC5322]. Exemple : Auto-Submitted: auto-notified; owner-email="moi@exemple.com"

o	owner-token - spécifie un jeton opaque, déterminé par la mise en œuvre, que le domaine administratif du propriétaire du script Sieve qui a généré cette notification peut utiliser pour identifier le propriétaire. Cela pourrait être utilisé pour permettre l'identification du propriétaire tout en protégeant l'intimité du propriétaire. L'attribut de paramètre est "owner-token", et la valeur du paramètre esr comme défini par "token" dans la [RFC3834]. Exemple : Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W

Voir à la Section 5 la discussion des utilisations possibles de ces paramètres.

 	3.	Exemples

Message déclencheur (reçu par receveur@exemple.org):

      Return-Path: <nouvelles-du-tricot@exemple.com>
      Received: from mail.exemple.com by mail.exemple.org
        for <receveur@exemple.org>; Wed, 7 Dec 2005 05:08:02 -0500
      Received: from hobbies.exemple.com by mail.exemple.com
        for <tricot@exemple.com>; Wed, 7 Dec 2005 02:00:26 -0800
      Message-ID: <1234567.89ABCDEF@exemple.com>
      Date: Wed, 07 Dec 2005 10:59:19 +0100
      Precedence: list
      List-Id: Liste de diffusion Tricotage <tricot.exemple.com>
      Sender: nouvelles-du-tricot@exemple.com
      Errors-To: nouvelles-du-tricot@exemple.com
      From: "Jeff Smith" <jeff@hobbies.exemple.com>
      To: "Liste de diffusion Tricotage" <tricot@exemple.com>
      Subject: [Tricotage] Un nouveau tricot

      Je viens juste de finir un nouveau grand tricot !

   script Sieve (au nom de receveur@exemple.org):

      require ["enotify", "variables"];

      if header :contains "list-id" "tricot.exemple.com" {
        if header :matches "Subject" "[*] *" {
          notify :message "From ${1} list: ${2}"
              :importance "3"
              "mailto:0123456789@sms.exemple.net?to=backup@exemple.com";
        }
      }

Message de notification :

      Auto-Submitted: auto-notified; owner-email="receveur@exemple.org"
      Received: from mail.exemple.com by mail.exemple.org
        for <receveur@exemple.org>; Wed, 7 Dec 2005 05:08:02 -0500
      Received: from hobbies.exemple.com by mail.exemple.com
        for <tricot@exemple.com>; Wed, 7 Dec 2005 02:00:26 -0800
      Date: Wed, 7 Dec 2005 05:08:55 -0500
      Message-ID: <A2299BB.FF7788@exemple.org>
      From: receveur@exemple.org
      To: 0123456789@sms.exemple.net, backup@exemple.com
      Subject: From Liste Tricotage : Un nouveau tricot

Noter que :

o	Les champs comme "Message-ID:" et "Date:" ont été fraîchement générés pour le message de notification, et ne se rapportent pas au message déclencheur.

o	Des champs "Received:" supplémentaires vont être ajoutés au message de notification en transit ; ceux montrés ont été copiés du message déclencheur. De nouveaux vont être ajoutés au dessus du champ d'en-tête Auto-Submitted:.

o	Si ce message devait apparaître à nouveau au serveur mail.exemple.org, le serveur pourrait utiliser la présence d'une ligne "mail.exemple.org" reçue pour le reconnaître. Le champ d'en-tête Auto-Submitted est aussi présent pour dire au serveur d'éviter d'envoyer une autre notification, et il inclut un paramètre facultatif owner-email pour l'identification.

 	4.	Considérations d'internationalisation

La présente spécification n'introduit pas de problème spécifique d'internationalisation qui ne soit déjà traité dans les [RFC5228] et [RFC5435].

 	5.	Considérations sur la sécurité

L'envoi d'une notification est comparable à la transmission d'un message au receveur de notification. On doit faire attention, quand on transmet automatiquement un message, de s'assurer que des informations confidentielles ne sont pas envoyées dans un environnement non sûr.

L'envoi automatique de messages électroniques expose le système à des boucles de messages, qui peuvent causer des problèmes de fonctionnement. Les mises en œuvre de la présente spécification DOIVENT se protéger contre les boucles de messages ; voir au paragraphe 2.7 la discussion sur ce point et quelques suggestions. D'autres atténuations possibles pour les boucles de messages impliquent des limitations de types de service. Par exemple, le nombre de notifications générées pour un seul utilisateur pourrait être limité à pas plus de, disons, 30 dans une période de 60 minutes. Bien sûr, cette technique présente ses propres problèmes, en ce que la limite de taux réelle doit être choisie avec soin, pour permettre la plupart des situations légitimes dans l'environnement donné. Même avec un choix attentif, il est inévitable qu'il y ait des faux positifs -- et des faux négatifs.

En fin de compte, une intervention humaine peut être nécessaire pour réactiver les notifications qui ont été désactivées parce qu'une boucle avait été détectée, ou pour terminer une boucle très lente qui est sous le radar de la détection automatique. Des mécanismes administratifs DOIVENT être disponibles pour traiter ces sortes de situations.

Les adresses de messagerie spécifiées comme les receveuses de notifications pourraient n'être pas possédées par l'entité qui possède le script Sieve. Par suite, un receveur de notification pourrait finir comme cible de notifications non désirées, soit intentionnellement (en utilisant des scripts pour monter une attaque de bombardement de messages) soit par accident (une adresse mal rédigée ou réallouée). La situation n'est peut-être pas pire que celle où un receveur reçoit de la messagerie non désirée, et certains des mêmes mécanismes peuvent être utilisés dans ce cas. Mais ceux qui vont déployer la présente extension doivent être avertis ici des problèmes supplémentaires potentiels, où des scripts pourraient être créés par des moyens qui ne valident pas les adresses de messagerie de façon adéquate, et de tels scripts pourraient alors être oubliés et laissés indéfiniment en fonctionnement.

En particulier, noter qu'il est exigé que le champ d'en-tête Auto-Submitted inclue une valeur qu'un receveur puisse utiliser quand il contacte le domaine de source du message de notification (voir le paragraphe 2.7.1). Cette valeur va permettre au domaine de retracer le propriétaire du script et de faire corriger ou désactiver le script. Les domaines qui permettent cette extension DOIVENT être prêts à répondre à de telles plaintes, afin de limiter les dommages causés par un script fautif.

Des problèmes peuvent aussi apparaître si des messages de notification sont envoyés à une passerelle dans un autre service, comme un SMS. Les informations provenant du message électronique sont souvent perdues dans la traduction de la passerelle ; et dans ce cas, des informations critiques nécessaires pour éviter des boucles, pour contacter le propriétaire du script, et pour résoudre d'autres problèmes, pourraient être perdues. Les développeurs de passerelles de messagerie devraient considérer ces questions, et essayer de préserver autant d'informations que possible, y compris ce qui apparaît dans les en-têtes de trace de messages et le champ d'en-tête Auto-Submitted.

Des considérations de sécurité supplémentaires sont discutées dans les [RFC5228] et [RFC5435].

 	6.	Considérations relatives à l’IANA
 	6.1	Enregistrement de mécanisme de notification
Le gabarit suivant spécifie l'enregistrement par l'IANA du mécanisme de notification Sieve spécifié dans le présent document :

To: iana@iana.org
Subject : enregistrement d'un nouveau mécanisme de notification Sieve
Nom de mécanisme : mailto
URI de mécanisme : RFC2368
Options spécifiques du mécanisme : aucune
Référence permanente et directement disponible : RFC 5436
Personne et adresse de messagerie à contacter pour plus d'informations : Michael Haardt <michael.haardt@freenet.ag>

Ces informations devraient être ajoutées à la liste des mécanismes de notification Sieve disponibles à http://www.iana.org.

 	6.2	Nouveau registre pour les mots clés de champ d'en-tête Auto-Submitted
Parce que la [RFC3834] ne définit pas de registre pour les nouveaux mots clés utilisés dans le champ d'en-tête Auto-Submitted, on en définit un ici, qui a été créé et est disponible à http://www.iana.org. Les mots clés sont enregistrés en utilisant la politique de "spécification exigée" de la [RFC5226].

On définit ci-après le gabarit à utiliser pour enregistrer de nouveaux mots-clés. Les entrées initiales de ce registre sont au paragraphe 6.3.

To: iana@iana.org
Subject : enregistrement d'un nouveau mot clé de champ d'en-tête auto-soumis
Valeur de mot-clé : [valeur de texte du champ]
Description : [brève explication de l'objet de cette valeur]
Paramètres : [liste de tous paramètres spécifiques de mot clé, spécification de leur signification, de si ils sont exigés ou facultatifs ; utiliser "aucun" si il n'y en a aucun]
Référence permanente et directement disponible : [identifie la spécification qui définie la valeur à enregistrer]
Contact : [nom et adresse de messagerie à contacter pour plus d'informations :]

 	6.3	Enregistrement initial de mots clés de champ d'en-tête Auto-Submitted
Les mots-clés initiaux suivants ont été enregistrés dans le registre "Mots clés de champ d'en-tête Auto-Submitted", disponible à http://www.iana.org.

Valeur de mot-clé : no
Description : indique qu'un message N'A PAS été généré automatiquement, mais a été créé par un humain. C'est l'équivalent de l'absence d'un en-tête Auto-Submitted.
Paramètres : aucun
Référence permanente et directement disponible : RFC3834
Contact : Keith Moore <moore@network-heretics.com>

Valeur de mot-clé : auto-generated
Description : indique qu'un message a été généré par un processus automatique, et n'est pas une réponse directe à un autre message.
Paramètres : aucun
Référence permanente et directement disponible : RFC3834
Contact : Keith Moore <moore@network-heretics.com>

Valeur de mot-clé : auto-replied
Description : indique qu'un message a été généré automatiquement comme réponse directe à un autre message.
Paramètres : aucun
Référence permanente et directement disponible : RFC3834
Contact : Keith Moore <moore@network-heretics.com>

Valeur de mot-clé : auto-notified
Description : indique qu'un message a été généré par un système de notification Sieve.
Paramètres : owner-email, owner-token. Au moins un est exigé ; tous deux se réfèrent au propriétaire du script Sieve qui a généré ce message. Voir la RFC pertinente pour les détails.
Référence permanente et directement disponible : RFC 5436
Contact : Michael Haardt <michael.haardt@freenet.ag>

 	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. (MàJ par RFC8174)

[RFC2368]	P. Hoffman, L. Masinter, J. Zawinski, "Le schéma d'URL mailto", juillet 1998. (P.S.) (Obsolète, voir la RFC6068)

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

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

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

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008. (Remplace RFC2822) (MàJ RFC4021) (D.S.)

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

 	7.2	Références pour information

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

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

 	Adresse des auteurs

Barry Leiba	Michael Haardt	
IBM T.J. Watson Research Center	freenet.de GmbH	
19 Skyline Drive	Willstaetter Str. 13	
Hawthorne, NY  10532	Duesseldorf, NRW  40549	
US	Germany	
téléphone : +1 914 784 7941	téléphone : +49 241 53087 520	
mél : leiba@watson.ibm.com	mél : michael.haardt@freenet.ag