Extension de service SMTP pour l’intubation de commande

Statut de ce mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la 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 une extension du service du protocole simple de transfert de messagerie (SMTP, Simple Mail Transfer Protocol) par laquelle un serveur peut indiquer l’étendue de sa capacité à accepter plusieurs commandes dans une seule opération d’envoi du protocole de commande de transmission (TCP, Transmission Control Protocol). L’utilisation d’une seule opération d’envoi TCP pour plusieurs commandes peut améliorer significativement les performances de SMTP.

1 Introduction

Bien que SMTP soit largement déployé et ait prouvé sa robustesse, certaines extensions peuvent néanmoins se révéler utiles. En particulier, de nombreuse parties de l’Internet font usage de liaisons réseau à forte latence. La structure intrinsèque de SMTP à une commande / une réponse est fortement pénalisée par les liaisons à forte latence, souvent au point que les facteurs qui contribuent au temps de connexion global sont dominés par le temps passé à attendre les réponses aux commandes individuelles (temps de retournement).

Dans un monde idéal, il serait possible de développer simplement un logiciel client SMTP qui utiliserait l’intubation de commande : en groupant plusieurs commandes en une seule opération d’envoi TCP. Malheureusement, la spécification d’origine de SMTP, la [RFC0821] n’établissait pas explicitement que les serveurs SMTP puissent la prendre en charge. Il en résulte qu’un nombre notable de serveurs SMTP Internet ne peuvent pas traiter adéquatement l’intubation de commandes. Les fautes existantes connues dans les serveurs actifs comportent :

(1) Des transferts de connexion et des vidages de mémoire tampon au milieu du dialogue SMTP. La création de traitements de serveur pour les connexions SMTP entrantes est une technique de mise en œuvre utile, évidente, et sans danger. Cependant, certains serveurs SMTP diffèrent le traitement et le transfert de connexion jusqu’à un point intermédiaire du dialogue SMTP. Lorsque cela est fait, du matériel lu sur la connexion TCP et gardé dans des mémoire tampon de traitement peut être perdu.

(2) Le vidage de la mémoire tampon d’entrée de TCP lors de l’échec d’une commande SMTP. Les commandes SMTP échouent souvent mais ce n’est pas une raison pour vider la mémoire tampon d’entrée de TCP lorsque cela arrive. Néanmoins, certains serveurs SMTP le font.

(3) Le traitement incorrect et la signalisation de l’échec de commandes SMTP. Par exemple, certains serveurs SMTP vont refuser d’accepter une commande DATA si la dernière commande RCPT TO échoue, ne prêtant aucune attention à la réussite ou à l’échec des résultats de la précédente commande RCPT TO. D’autres serveurs vont accepter une commande DATA même quand toutes les précédentes commandes RCPT TO ont échoué. Bien qu’il soit possible de s’accommoder de cette sorte de comportement dans un client qui utilise l’intubation de commande, cela complique inutilement la construction du client.

Le présent mémoire utilise le mécanisme décrit dans la [RFC1869] pour définir une extension au service SMTP par laquelle un serveur SMTP peut déclarer qu’il est capable de traiter les commandes intubées. Le client SMTP peut alors vérifier cette déclaration et n’utiliser l’intubation que lorsque le serveur déclare qu’il est lui-même capable de la traiter.

1.1 Exigences de notation

Le présent document utilise occasionnellement des termes qui apparaissent en majuscules. Lorsque les termes "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS", et "PEUT" apparaissent en majuscules, ils sont utilisés pour indiquer les exigences particulières de la présente spécification. Un exposé de la signification des termes "DOIT", "DEVRAIT", et "PEUT" figure dans la [RFC1123] ; les termes "NE DOIT PAS" et "NE DEVRAIT PAS" sont les extensions logiques de cet usage.

2 Cadre de l’extension d’intubation de commande

L’extension d’intubation de commande est définie comme suit :

(1) le nom de l’extension de service SMTP est intubation ;

(2) la valeur de mot clé de EHLO associée à l’extension est PIPELINING ;

(3) aucun paramètre n’est utilisé avec le mot clé de EHLO PIPELINING ;

(4) aucun paramètre supplémentaire n’est ajouté aux commandes MAIL FROM ou RCPT TO ;

(5) aucun verbe SMTP supplémentaire n’est défini par cette extension ;

(6) la prochaine section spécifie comment la prise en charge de l’extension affecte le comportement d’un serveur et d’un client SMTP.

3 Extension de service Intubation

Lorsqu’un client SMTP souhaite employer l’intubation de commande, il produit d’abord la commande EHLO au serveur SMTP. Si le serveur SMTP répond par le code 250 à la commande EHLO, et si la réponse comporte la valeur de mot clé EHLO de PIPELINING, le serveur SMTP a alors indiqué qu’il peut s’accommoder de l’intubation de commande SMTP.

3.1 Utilisation de l’intubation par le client

Une fois que le client SMTP a confirmé qu’il existe un soutien pour l’extension d’intubation, le client SMTP peut alors choisir de transmettre des groupes de commandes SMTP par lots sans attendre une réponse à chaque commande individuelle. En particulier, les commandes RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, et RCPT TO peuvent toutes apparaître à tout endroit d’un groupe de commandes intubées. Les commandes EHLO, DATA, VRFY, EXPN, TURN, QUIT, et NOOP ne peuvent apparaître que comme dernière commande dans un groupe car leur réussite ou leur échec produit un changement d’état dont le client SMTP doit s’accommoder. (NOOP est incluse dans ce groupe de sorte qu’elle peut être utilisée comme point de synchronisation.)

Des commandes supplémentaires ajoutées par d’autres extensions SMTP ne peuvent apparaître que comme dernière commande d’un groupe sauf mention contraire spécifiée par les extensions qui définissent les commandes.

Le transfert réel du contenu du message est explicitement admis comme étant la première "commande" dans un groupe. C’est-à-dire qu’une séquence RSET/MAIL FROM utilisée pour initier une nouvelle transaction de message peut être placée dans le même groupe que le transfert final des en-têtes et du corps du message précédent.

Les mises en œuvre de client SMTP qui emploient l’intubation DOIVENT vérifier tous les états associés à chaque commande dans un groupe. Par exemple, si aucune des adresses de receveur de RCPT TO n’est acceptée, le client doit alors vérifier la réponse à la commande DATA -- le client ne peut pas supposer que la commande DATA sera rejetée seulement parce qu’aucune des commandes RCPT TO ne fonctionne. Si la commande DATA a été rejetée à juste titre, le client SMTP peut juste produire RSET, mais si la commande DATA a été acceptée, le client SMTP devrait envoyer un seul point.

Les états des commandes DOIVENT être coordonnés avec les réponses en comptant chaque réponse séparément et en corrélant ce compte avec le nombre de commandes dont on sait qu’elles ont été produites. Les réponses multilignes DOIVENT être acceptées. La confrontation sur la base des valeurs de code d’erreur ou du texte associé est expressément interdit.

Les mises en œuvre de client SMTP PEUVENT choisir de fonctionner de façon non bloquante, en traitant les réponses du serveur dès réception, même s’il y a encore des données en cours de transmission à partir de l’opération précédente d’envoi TCP du client. Si cependant le fonctionnement non bloquant n’est pas pris en charge, les mises en œuvre de client SMTP DOIVENT aussi vérifier la taille de la fenêtre TCP et s’assurer que chaque groupe de commandes passe entièrement dans la fenêtre. La taille de la fenêtre est habituellement, mais pas toujours, de 4 koctets. Manquer à effectuer cette vérification peut conduire à des conditions de blocage.

Les clients NE DOIVENT PAS confondre les réponses à plusieurs commandes avec des réponses multilignes. Chaque commande exige une ou plusieurs lignes de réponse, la dernière ligne ne contient pas de tiret entre le code de réponse et la chaîne de réponse.

3.2 Prise en charge de l’intubation par le serveur

Une mise en œuvre de serveur SMTP qui offre l’extension d’intubation :

(1) DOIT répondre aux commandes dans l’ordre dans lequel elles sont reçues du client.

(2) DEVRAIT mémoriser les réponses aux commandes RSET, MAIL FROM, SEND FROM, SOML FROM, SAML FROM, et RCPT TO groupées dans une mémoire tampon interne de sorte qu’elles puissent être envoyées comme une entité.

(3) DEVRAIT produire une réponse positive à la commande DATA si et seulement si une ou plusieurs adresses RCPT TO valides ont été reçues précédemment.

(4) NE DOIT PAS, après avoir produit une réponse positive à une commande DATA sans receveurs valides et avoir reçu ensuite un message vide, envoyer quelque message que ce soit à qui que ce soit.

(5) NE DOIT PAS mettre en mémoire tampon les réponses à EHLO, DATA, VRFY, EXPN, TURN, QUIT, et NOOP.

(6) NE DOIT PAS mettre en mémoire tampon les réponses à des commandes non reconnues.

(7) DOIT envoyer toutes les réponses en instance immédiatement chaque fois que la mémoire tampon d’entrée TCP locale est vidée.

(8) NE DOIT PAS faire d’hypothèses sur les commandes qui n’ont pas encore été reçues.

(9) NE DOIT PAS vider ou perdre de quelque autre façon le contenu de la mémoire tampon d’entrée TCP dans aucune circonstances, quelles qu’elles soient.

(10) DEVRAIT produire des réponses textuelles qui indiquent, implicitement ou explicitement, à quelle commande correspond la réponse.

L’intention primordiale de ces exigences pour les serveurs est de leur rendre aussi facile que possible de se conformer à ces extensions d’intubation.

4 Exemples

Considérons le dialogue SMTP suivant qui n’utilise pas l’intubation :

S: <attente de l’ouverture de la connexion>

C: <connexion ouverte avec le serveur>

S: 220 Innosoft.com service SMTP prêt

C: HELO dbc.mtview.ca.us

S: 250 Innosoft.com

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

S: 250 envoyeur <mrose@dbc.mtview.ca.us> OK

C: RCPT TO:<ned@innosoft.com>

S: 250 recipient <ned@innosoft.com> OK

C: RCPT TO:<dan@innosoft.com>

S: 250 receveur <dan@innosoft.com> OK

C: RCPT TO:<kvc@innosoft.com>

S: 250 receveur <kvc@innosoft.com> OK

C: DATA

S: 354 entrer le message, terminer par une ligne contenant seulement "."

...

C: .

S: 250 message envoyé

C: QUIT

S: 221 goodbye

Le client attend une réponse du serveur neuf fois dans ce simple exemple. Mais si on utilise l’intubation, le dialogue suivant est possible :

S: <attente de l’ouverture de la connexion>

C: <connexion ouverte avec le serveur>

S: 220 innosoft.com service SMTP prêt

C: EHLO dbc.mtview.ca.us

S: 250-innosoft.com

S: 250 PIPELINING

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

C: RCPT TO:<ned@innosoft.com>

C: RCPT TO:<dan@innosoft.com>

C: RCPT TO:<kvc@innosoft.com>

C: DATA

S: 250 envoyeur <mrose@dbc.mtview.ca.us> OK

S: 250 receveur <ned@innosoft.com> OK

S: 250 receveur <dan@innosoft.com> OK

S: 250 receveur <kvc@innosoft.com> OK

S: 354 entrer le message, terminer par une ligne contenant seulement "."

...

C: .

C: QUIT

S: 250 message envoyé

S: 221 goodbye

Le nombre total d’allers-retours a été réduit de 9 à 4.

Le prochain exemple illustre une forme de comportement possible lorsque l’intubation est utilisée et que tous les receveurs sont rejetés :

S: <attente de l’ouverture de la connexion>

C: <connexion ouverte avec le serveur>

S: 220 innosoft.com service SMTP prêt

C: EHLO dbc.mtview.ca.us

S: 250-innosoft.com

S: 250 PIPELINING

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

C: RCPT TO:<nsb@thumper.bellcore.com>

C: RCPT TO:<galvin@tis.com>

C: DATA

S: 250 envoyeur <mrose@dbc.mtview.ca.us> OK

S: 550 message distant pour <nsb@thumper.bellore.com> non admis

S: 550 message distant pour <galvin@tis.com> non admis

S: 554 pas de receveur valide

C: QUIT

S: 221 goodbye

Le client SMTP attend ici aussi quatre fois le serveur. Si le serveur SMTP ne vérifie pas qu’il y a au moins un receveur valide avant d’accepter la commande DATA, le dialogue suivant aurait lieu :

S: <attente de l’ouverture de la connexion>

C: <connexion ouverte avec le serveur>

S: 220 innosoft.com service SMTP prêt

C: EHLO dbc.mtview.ca.us

S: 250-innosoft.com

S: 250 PIPELINING

C: MAIL FROM:<mrose@dbc.mtview.ca.us>

C: RCPT TO:<nsb@thumper.bellcore.com>

C: RCPT TO:<galvin@tis.com>

C: DATA

S: 250 envoyeur <mrose@dbc.mtview.ca.us> OK

S: 550 message distant pour <nsb@thumper.bellore.com> non admis

S: 550 message distant pour <galvin@tis.com> non admis

S: 354 entrer le message, terminer par une ligne contenant seulement "."

C: .

C: QUIT

S: 554 pas de receveur valide

S: 221 goodbye

5 Considérations pour la sécurité

La présente RFC ne discute pas de questions de sécurité et ne semble pas soulever de problème de sécurité qui ne soit endémique de la messagerie électronique et présent dans les mises en œuvre pleinement conformes à la [RFC0821].

6 Remerciements

Le présent document se fonde sur le modèle d’extension de service SMTP présenté dans la RFC 1425. La description de l’intubation de commande SMTP de Marshall Rose dans son livre "The Internet Message" a aussi servi de source d’inspiration pour cette extension.

7 Références

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

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

[RFC1854] N. Freed, "Extension de service SMTP pour traitement en parallèle de commande", octobre 1995. (Obsolète, voir RFC2197) (P.S.)

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

[RFC2197] N. Freed, "Extension de service SMTP pour le traitement de commandes en parallèle", septembre 1997. (Obsolète, voir RFC2920) (D.S.)

8 Adresse de l’auteur

Ned Freed

Innosoft International, Inc.

1050 Lakes Drive

West Covina, CA 91790

USA

Tél : +1 626 919 3600

Fax : +1 626 919 361

mél : ned.freed@innosoft.com

Le présent document est le produit du travail du groupe de travail sur les extensions de messagerie de la force d’intervention pour l’ingénierie de l’Internet, présidé par Alan Cargille.

9 Déclaration complète de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis à des tiers, et les travaux dérivés qui le commentent ou l’expliquent ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou en partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction et le présent paragraphe soient inclus dans de telles copies et travaux dérivés. Cependant, le présent document lui-même ne doit être modifié d’aucune façon, ni en retirant la déclaration de droits de reproduction ni les références à la Internet Society ou autres organisations de l’Internet, excepté en tant que de besoin dans le but de développer les normes de l’Internet, auquel cas les procédures de droits de reproduction définies dans le traitement des normes de l’Internet doivent être suivies, ou selon les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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 et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

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