Groupe de travail Réseau	G. White, indépendant
Request for Comments : 4865	G. Vaudreuil, Alcatel-Lucent
RFC mises à jour : 3463, 3464	mai 2007
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Extension de service de soumission SMTP pour 
livraison future du message 

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de 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 copyright
Copyright (C) The IETF Trust (2007).

Résumé
Le présent mémoire définit une extension au protocole de soumission SMTP pour qu'un client indique un moment à l'avenir pour la livraison du message. Cette extension permet à un client d'utiliser une mémorisation sur le serveur pour un message qui devrait être conservé en file d'attente jusqu'à l'heure précisée. Ceci est utile pour les clients qui n'ont pas de mémorisation locale ou sont pour une autre taison dans l'incapacité de livrer un message à une heure prévue.
Table des matières
1. Introduction	1
2. Terminologie	1
3. Cadre	2
4. Comportement	3
4.1 Client SMTP 	3
4.2 MSA	3
5. Interactions de protocole	4
5.1 Interaction avec les extensions de service DSN SMTP	4
5.2 Interaction avec l'extension de service DELIVERBY de SMTP	4
5.3 Interaction avec la fonction MDN	5
6. Considérations sur la sécurité	5
7. Considérations relatives à l'IANA	6
8. Remerciements	6
9. Références normatives	6
10. Références pour information	6
Adresse des auteurs	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

Une caractéristique largement utilisée dans la communauté de la messagerie vocale est de composer et envoyer un message à livrer ultérieurement. C'est utile pour envoyer des annonces à écouter au début d'une journée de travail, pour envoyer des félicitations un jour d'anniversaire, et ainsi de suite, ou pour utiliser une facilité légère pour construire un service de pense-bête personnel.

La présente extension utilise le protocole de soumission SMTP [RFC4409] pour permettre à un client, quand il soumet un message, d'ndiquer une heure future pour la libération du message à livrer.

 	2.	Terminologie

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

 	3.	Cadre

L'extension de service Livraison future de message pour la soumission SMTP utilise le mécanisme d'extension de service SMTP [RFC2821] pour étendre le protocole de soumission SMTP [RFC4409]. L'extension de service de soumission SMTP suivante est définie de la façon suivante :

Le nom de l'extension de service de soumission SMTP est "Livraison future du message".

1)	Le mot clé étendu Hello (EHLO) associé à cette extension de service est "FUTURERELEASE".

2)	Deux paramètres exigés, max-future-release-interval (intervalle maximum de livraison future) et max-future-release-date-time (date et heure maximum de livraison future) sont combinés avec le mot clé EHLO de la manière spécifiée dans la [RFC2821].

L'intervalle maximum de livraison future est un entier positif qui indique la durée maximum pendant laquelle le serveur de soumission de message (MSA, Message Submission Server) va conserver les messages pour une livraison future.

En utilisant l'ABNF [RFC4234], la syntaxe de ce paramètre est :
future-release-integer = %x31-39 *8DIGIT	; entier dans la gamme 1 à 999999999 mesuré en secondes

max-future-release-interval = future-release-integer

max-future-release-date-time est un horodatage, normalisé sur le temps universel coordonné (UTC, Universal Coordinated Time) indiquant la date et heure futures les plus lointaines jusqu'à laquelle le MSA va conserver les messages pour livraison future.

En utilisant l'ABNF [RFC4234], la syntaxe de ce paramètre est :

max-future-release-date-time = date-time

où le format de date-time est défini dans la [RFC3339].

3)	Quand on forme la portion de la réponse EHLO contenant le mot clé FUTURERELEASE, le mot clé est suivi par max-future-release-interval, et ensuite max-future-release-date-time. Le mot clé et les deux valeurs sont délimités par des espaces (SP).

Par exemple, l'ABNF pour une ligne de continuation dans la réponse EHLO qui contient le mot clé FUTURERELEASE est :

ligne = "250-FUTURERELEASE" SP max-future-release-interval SP max-future-release-date-time

4)	Un paramètre exigé, hold-param, est ajouté à la commande MAIL en utilisant le mot clé "HOLDFOR" ou le mot clé "HOLDUNTIL".

La valeur du paramètre HOLDFOR est un intervalle de livraison future, qui est un entier positif indiquant la durée pendant laquelle le message va être détenu par le MSA avant livraison.

La valeur du paramètre HOLDUNTIL est une date et heure future de livraison, qui est un horodatage, normalisé en UTC, qui indique la date et heure future jusqu'à laquelle le message va être détenu par le MSA avant libération.

En utilisant l'ABNF [RFC4234], la syntaxe de ce paramètre est :

future-release-interval = future-release-integer	(intervalle de livraison future = entier de liv. future)
future-release-date-time = Internet-style-date-time-UTC	(date-heure de liv. fut. = date-heure UTC style Internet)
hold-for-param = "HOLDFOR=" future-release-interval	(paramètre garder pendant)
hold-until-param = "HOLDUNTIL=" future-release-date-time	(paramètre garder jusqu'à)
hold-param = hold-for-param / hold-until-param	(paramètre de garde)

L'absence de ce paramètre dans la commande MAIL n'implique pas une valeur par défaut pour ce paramètre.

5) 	La longueur maximum d'une commande MAIL est augmentée de 34 caractères par le possible ajout de hold-param.

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

7)	Cette extension de service n'est appropriée que pour le protocole de soumission SMTP [RFC4409]. Cette extension de service n'est pas appropriée pour le SMTP standard [RFC2821].

 	4.	Comportement

Il est très difficile de définir deux façons identiques pour indiquer une heure future de livraison de message. Quand le client a à la fois une heure précise et des informations précises de zone horaire, l'intervalle ou la date et l'heure peuvent être calculés d'une façon triviale par l'autre. Cependant, dans le monde réel des clients, il y a des clients avec une heure locale précise, mais pas d'indication de leur zone horaire, et des clients dépourvus d'une horloge d'une précision convenable. Sur la base des facilités limitees disponibles à ces clients auxquels le temps pose un défi, il est probable que seulement un ou l'autre de ces mécanismes va être utile.

On estime que les serveurs vont avoir une heure précise, et peuvent facilement convertir ces mécanismes. Il est aussi accepté que les frais généraux de protocole et de mise en œuvre de l'offre de ces deux mécanismes sont faibles, et peu de défis d'intéropérabilité sont envisagés.

 	4.1	Client SMTP 
1)	Un client SMTP qui se prépare à utiliser la livraison future de message DOIT d'abord vérifier que le MSA prend en charge cette extension.

2)	Un client SMTP qui utilise la livraison future de message DOIT inclure un et un seul hold-param dans la commande MAIL.

3)	Un client SMTP qui utilise la livraison future de message avec l'option "for" du hold-param DOIT s'assurer que l'intervalle de livraison future est inférieur ou égal à l'intervalle maximum de livraison future annoncé par le MSA.

4)	Un client SMTP qui utilise la livraison future de message avec l'option "until" du hold-param DOIT s'assurer que la date et heure de livraison future est antérieure ou égale à la date et heure maximale de livraison future annoncée par le MSA.

 	4.2	MSA
1)	Un MSA qui prend en charge la livraison future de message DOIT se conformer au protocole de soumission SMTP comme décrit dans la [RFC4409].

2)	Un MSA qui prend en charge la livraison future de message NE DOIT PAS annoncer cette prise en charge (c'est-à-dire, inclure le mot clé FUTURERELEASE dans sa réponse EHLO) sur tout accès autre que l'accès de soumission.

3)	Un MSA qui prend en charge la livraison future de message DOIT inclure le mot clé FUTURERELEASE, et les paramètres associés max-future-release-interval et max-future-release-date-time, dans sa réponse à la commande EHLO.

4)	Un MSA qui prend en charge la livraison future de message DOIT accepter une commande MAIL contenant un hold-param valide, étant entendu que la commande MAIL ne contient pas d'autres erreurs.

5)	Un MSA qui accepte un message avec une demande de livraison future de message indiquant l'option "for" NE DOIT PAS livrer le message avant l'écoulement de la durée spécifiée dans l'intervalle de livraison future.

6)	Un MSA qui accepte un message avec une demande de livraison future de message indiquant l'option "until" NE DOIT PAS livrer le message avant la date et l'heure indiquée par la date et heure de livraison future.

7)	Un MSA qui prend en charge la livraison future de message DOIT rejeter une commande MAIL contenant l'option "for" spécifiant une valeur supérieure à celle annoncée dans l'intervalle maximum de future livraison, ou par ailleurs invalide.

8)	Un MSA qui prend en charge la livraison future de message DOIT rejeter une commande MAIL contenanr l'option "until" spécifiant une valeur qui est postérieure à la date et heure maximum de livraison future annoncée, ou par ailleurs invalide.

9)	Un MSA qui prend en charge la livraison future de message DOIT rejeter une commande MAIL contenant plus d'un hold-param.

10)	Un MSA qui prend en charge la livraison future de message, quand il rejette une commande MAIL selon les points 7, 8, ou 9, ci-dessus, DEVRAIT fournir le code de réponse 501 (erreur de syntaxe dans les paramètres ou arguments [RFC2821]) dans la réponse.

11)	Un MSA qui prend en charge la livraison future de message, quand il rejette une commande MAIL selon les points 7, 8, ou 9, ci-dessus, DEVRAIT fournir le code d'état de système de messagerie améliorée 5.5.4 (arguments de commande invalides [RFC3463]) dans la réponse.

 	5.	Interactions de protocole
 	5.1	Interaction avec les extensions de service DSN SMTP
L'extension de service Notification d'état de livraison (DSN, Delivery Status Notification) est décrite dans la [RFC3461], et le format de message DSN est décrit dans la [RFC3464].

 	5.1.1	Interaction du client SMTP avec DSN
Un client SMTP NE DOIT PAS demander la livraison future de message quand il envoie une DSN au MSA.

 	5.1.2	Interaction du MSA avec DSN
1) Si un MSA génère une DSN pour un message qui inclut une demande de livraison future de message, le MSA DOIT inclure un champ Date d'arrivée dans la partie de corps lisible par la machine de la DSN.

2) Si un MSA génère une DSN pour un message qui inclut une demande de livraison future de message, le MSA DOIT inclure un champ Demande de livraison future dans la partie de corps lisible par la machine de la DSN. La valeur de ce champ est la valeur du paramètre HOLD contenu dans la commande MAIL du message d'origine.

Le champ Future-Release-Request est une extension de l'ensemble de champs de DSN par message décrit dans la [RFC3464]. En utilisant l'ABNF de la [RFC4234], la syntaxe de ce nouveau champ est :

orig-hold-param-value = ("for;" future-release-interval) / ("until;" future-release-date-time)
; c'est la valeur du paramètre HOLD provenant de la commande MAIL du message d'origine

future-release-request-field = "Future-Release-Request:" orig-hold-param-value

 	5.2	Interaction avec l'extension de service DELIVERBY de SMTP
Si un MSA prend en charge les extensions de service Livraison future de message et Livraison par, il est possible qu'un client SMTP fasse des demandes simultanées pour la livraison future de message et Livraison par quand il soumet un message. Un problème va se produire si le moment de livraison future du message est plus loin dans le futur que le moment du Livraison par. Afin d'honorer la demande Livraison par, la demande de livraison future de message doit être ignorée. Afin d'honorer la demande de livraison future de message, la demande Livraison par doit être ignorée. On examine ici ce problème. L'extension Livraison par est décrite dans la [RFC2852].

 	5.2.1	Interaction du client SMTP avec DELIVERBY
Quand un client SMTP souhaite utiliser les extensions Livraison future de message et Livraison par avec le même message, le client DOIT s'assurer que le moment du Livraison par spécifié est plus loin dans le futur que le moment de livraison future de message spécifié (option "until") ou impliqué (option "for").

 	5.2.2	Interaction du MSA avec DELIVERBY
1)	Si un MSA prend en charge les extensions Livraison future de message et Livraison par, et reçoit un message demandant l'utilisation des deux extensions, le MSA DOIT rejeter la commande MAIL si il détermine que le moment de livraison future de message est plus tard que le moment du Livraison par.

2)	Quand un MSA rejette une commande MAIL selon le point 1 ci-dessus, il DEVRAIT fournir le code de réponse 501 (erreur de syntaxe dans les paramètres ou arguments) [RFC2821] dans la réponse.

3)	Quand un MSA rejette une commande MAIL selon le point 1 ci-dessus, il DEVRAIT fournir le code d'état de système de messagerie améliorée de 5.5.4 (arguments de commande invalides) [RFC3463] dans la réponse.

 	5.3	Interaction avec la fonction MDN
La fonction de notification de disposition de message (MDN, Message Disposition Notification) est décrite dans la [RFC3798].

 	5.3.1	Interaction du client SMTP avec MDN
Un client SMTP NE DOIT PAS demander la livraison future de message quand il envoie une MDN au MSA.

 	6.	Considérations sur la sécurité

L'extension de service de livraison future de message pose un certain nombre problèmes de sécurité :

1)	Des messages non autorisés de livraison future donnent le moyen de submerger la mémorisation d'un MSA. Les mécanismes d'autorisation requis pour le protocole de base de soumission de message [RFC4409] sont supposés fournir une défense appropriée contre de telles attaques.

2)	La livraison future de message autorisée sans un quota par utilisateur peut aussi fournir un moyen de submerger la mémoire d'un MSA. La mémorisation de messages à livraison future d'un MSA DEVRAIT être soumise à un quota par utilisateur.

3)	Si un MSA impose un quota par utilisateur sur la mémorisation des messages à livraison future, et détecte qu'un message entrant à livraison future va excéder le quota de mémorisation de messages à livraison future de l'utilisateur, le MSA DOIT rejeter la commande MAIL.

4)	Quand un MSA rejette une commande MAIL selon le paragraphe 5.3, il DEVRAIT fournir le code de réponse 552 (action de messagerie demandée interrompue : allocation de mémoire dépassée) [RFC2821] dans la réponse.

5)	Quand un MSA rejette une commande MAIL selon le paragraphe 5.3, il DEVRAIT fournir le nouveau code d'état de système de messagerie améliorée défini dans ce but. Ce nouveau code d'état met à jour la [RFC3463].

X.7.16 : Quota de messages à livraison future par utilisateur dépassé

Il y a un quota par utilisateur insuffisant pour mettre le message à livraison future en file d'attente. Ce code suggère que le client ne peut soumettre à nouveau qu'après que la file d'attente par utilisateur a diminué.

X.7.17 : Quota de messages à livraison future du système excédé

Le quota du système est insuffisant pour mettre en file d'attente le message pour livraison future. Ce code suggère que le client peut soumettre à nouveau après la diminution de la file d'attente du système.

6)	Une heure inappropriée au MSA peut résulter en une livraison prématurée ou retardée des messages. Les deux mécanismes de demande HOLDUNTIL et HOLDFOR sont sensibles aux horloges imprécises ou instables sur le MSA.

7)	Le concept de livraison future de message est par nature un peu trompeur. L'heure de livraison du message est intentionnellement retardée après le moment où il aurait été autrement livré. Cette extension ne fournit aucun mécanisme pour cacher cela au receveur du message. L'en-tête de message de la [RFC2822], et spécifiquement le champ Date, reste inchangé après la soumission. Alors qu'un client envoyeur PEUT choisir de placer l'heure de la livraison future du message comme date dans le champ Date, il n'y a pas d'exigence ni d'attente que les champs de réception et autres informations de trace soient modifiés par le système de transport pour appuyer cette "tromperie".

 	7.	Considérations relatives à l'IANA

Cette extension a été ajoutée à la liste des extensions de service SMTP sur la page de la Toile des paramètres de messagerie.

 	8.	Remerciements

Une grande partie du présent document est due au groupe de travail LEMONADE. Par de nombreuses révisions, les discussions ont résulté en une compréhension fondamentalement nouvelle de ce protocole et des précisions correspondantes des exigences et du protocole impliqués. Des remerciements tout particuliers sont dus à ceux qui avec patience ont conduit le groupe de travail à comprendre que traiter à la fois l'intervalle et la date-heure était l'approche pragmatiquement correcte pour les besoins des divers clients.

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

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

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

[RFC2852]	D. Newman, "Extension de service SMTP Livraison par", juin 2000. (P.S.)

[RFC3339]	G. Klyne, C. Newman, "La date et l'heure sur l'Internet : horodatages", juillet 2002. (P.S.)

[RFC3461]	K. Moore, "Extension de service du protocole simple de transfert de messagerie (SMTP) pour les notifications d'état de livraison (DSN)", janvier 2003. (MàJ par RFC3798, RFC3885, RFC5337, RFC6533, RFC8098) (D.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)

[RFC4234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplace RFC2234, remplacée par RFC5234)

[RFC4409]	R. Gellens, J. Klensin, "Soumission du message de messagerie électronique", avril 2006. (Remplacé par la RFC6409 STD072)

 	10.	Références pour information

[RFC3463]	G. Vaudreuil, "Codes d'état améliorés du système de messagerie", janvier 2003. (MàJ par RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (D.S.)

 	Adresse des auteurs

Gregory A. White	Gregory M. Vaudreuil	
6519 Camille Ave.	Alcatel-Lucent	
Dallas, TX  75252	9489 Bartgis Ct	
USA	Frederick, MD 21702	
mél : g.a.white@tx.rr.com 	USA	
	mél : GregV@ieee.org 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

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 actuellement fourni par la Internet Society.