Groupe de travail Réseau

J. De Winter, Wildbear Consulting, Inc.

Request for Comments : 1985

août 1996

Catégorie : En cours de normalisation

Traduction Claude Brière de L’Isle

 

Extension de service SMTP pour début de mise en file d’attente de message à distance

 

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émo n'est soumise à aucune restriction.

 

Résumé

Le présent mémo définit une extension au service SMTP par laquelle un client et un serveur SMTP peuvent interagir pour donner au serveur une opportunité de débuter le traitement de ses files d’attente pour les messages destinés à un hôte donné. Cette extension est prévue pour une utilisation dans des conditions de démarrage aussi bien que pour les nœuds qui ont des connexions provisoires avec leurs fournisseurs de service.

 

1 Introduction

La commande TURN était une bonne tentative pour régler le problème d’avoir à commencer le traitement d’une file d’attente de message sur une machine distante. Cependant, la commande TURN présente une grande faiblesse pour la sécurité. Comme il n’y a aucune vérification du nom de l’hôte distant, la commande TURN pourrait être utilisée par un système hostile pour télécharger de la messagerie destinée à un autre site.

Le présent mémo introduit donc la commande ETRN. Cette commande utilise le mécanisme exposé dans [2] pour définir des extensions au service SMTP par lesquelles un client ("envoyeur-SMTP") peut demander que le serveur ("receveur-SMTP") commence le traitement de ses files d’attente de messagerie pour les messages qui attendent la machine client chez le serveur. Si des messages sont en attente chez le serveur pour le client, le serveur peut alors créer une nouvelle session SMTP et envoyer les messages à ce moment.

 

2 Cadres de l’extension ETRN

L’extension de service suivante est donc définie :

(1) le nom de l’extension de service SMTP est "Déclaration de traitement de file d’attente à distance" ;

(2) la valeur de mot clé EHLO associée à cette extension est "ETRN", sans paramètre associé ;

(3) un verbe additionnel, ETRN, avec un seul paramètre spécifiant le nom du ou des clients pour qui le processus est fait ;

(4) aucun verbe SMTP additionnel n’est défini par cette extension.

Le reste de ce mémo spécifie comment l’extension affecte le comportement d’un client et d’un serveur SMTP.

 

3 Extension de service Déclaration de traitement de file d’attente à distance

Pour des raisons d’économies, les petites compagnies n’entretiennent que des connexions provisoires avec leurs fournisseurs de service. De plus, il y a des situations où le site client dépend de l’arrivée rapide du courrier, aussi, forcer les files d’attentes sur le serveur qui appartient à leur fournisseur de service peut être préférable à l’attente de la fin de temporisation de réessai.

Ces deux situations pourraient actuellement être réglées en utilisant la commande TURN définie en [1], si elle ne présentait pas un grave danger pour la sécurité. Telle qu’elle se trouve, la commande TURN va inverser la direction de la connexion SMTP et supposer que l’hôte distant est honnête dans sa désignation. Le danger pour la sécurité est l’absence de stipulation documentée pour vérifier l’authenticité du nom de l’hôte distant, tel que donné par la commande HELO ou EHLO. Aussi, la plupart des mises en œuvre SMTP et ESMTP n’utilisent pas la commande TURN pour éviter cette faille dans la sécurité.

C’est ce problème qui est visé par le concept de la commande ETRN. Cette extension de la commande TURN a été rédigée en visant les points du premier paragraphe, et en faisant attention aux problèmes qui existent actuellement avec la commande TURN. Le danger pour la sécurité est évité en demandant au serveur de commencer une nouvelle connexion avec le client spécifié.

De cette façon, le serveur a bien plus de certitude qu’il dialogue avec le client SMTP correct. Ce mécanisme peut être juste vu comme une version plus immédiate du réessai de file d’attente qui apparaît dans la plupart des mises en œuvre SMTP. De plus, comme cette commande va prendre un seul paramètre, le nom du ou des hôtes distants pour lesquels commencer les files d’attente, le serveur peut décider si il souhaite respecter la demande ou la refuser pour des raisons administratives locales.

 

4 Définitions

Le traitement de file d’attente à distance signifie qu’en utilisant une connexion SMTP ou ESMTP, le client peut demander que le serveur commence le traitement d’une partie de ses files d’attente de messagerie. Ce traitement est effectué en utilisant l’infrastructure SMTP existante et va survenir à un moment quelconque après l’initialisation du traitement.

L’hôte serveur est le nœud qui répond à la commande ETRN.

L’hôte client est le nœud qui prend l’initiative de la commande ETRN.

Le nom de l’hôte distant est défini comme un champ de texte en clair qui spécifie un nom pour le ou les hôtes distants). Ce nom d’hôte distant peut aussi inclure un alias pour l’hôte distant spécifié ou des commandes particulières pour identifier d’autres types de files d’attente.

 

5 Commande ETRN étendue

La commande ETRN étendue est produite par l’hôte client lorsqu’il souhaite faire commencer le traitement de la file d’attente SMTP d’un hôte serveur donné. La syntaxe de cette commande est la suivante :

ETRN [<caractère d’option>]<nom de nœud><CR><LF>

Cette commande peut être produite à tout moment une fois qu’une session est établie, tant qu’il n’y a pas de transaction en cours. Et donc, cette commande est illégale entre une commande MAIL FROM: et la fin des commandes et réponses DATA.

Le nom de nœud spécifié doit être un nom de domaine pleinement qualifié pour le nœud, qui peut se référer à un pointeur CNAME ou MX dans le DNS. Si un alias est utilisé pour le nœud, plusieurs commandes ETRN peuvent être nécessaires pour débuter le traitement pour le nœud car il peut figurer au site distant sous plusieurs noms. Ceci peut aussi se régler en utilisant les options exposées au paragraphe 5.3.

Dans les circonstances normales, le caractère d’option n’est pas utilisé.

 

5.1 Action du serveur à réception de la commande ETRN étendue

Lorsque l’hôte serveur reçoit la commande ETRN, il devrait regarder le nom d’hôte spécifié dans la commande et prendre une décision locale pour savoir s’il devrait ou non honorer la demande. Sinon, les codes d’erreur appropriés devraient être retournés au client.

Autrement, l’hôte serveur devrait forcer ses files d’attente de réessai à commencer l’envoi de messages à ce site distant, en utilisant une autre connexion SMTP. À ce moment, il n’y a pas d’exigence qu’une connexion se fasse, ou que la connexion doive se faire dans un délai donné. Ceci devrait être noté pour le cas où il n’y aurait pas de message destiné à l’hôte client chez l’hôte serveur et où seule la réponse 250 serait utilisée.

Comme le traitement des files d’attente peut prendre un temps indéterminé, cette commande devrait retourner immédiatement une réponse à l’hôte client. Les codes de retour valides pour cette commande sont :

250 OK, file d’attente pour le nœud <x> commencée
251 OK, pas de message en attente pour le nœud <x>
252 OK, messages en instance pour le nœud <x> commencé
253 OK, <n> messages en instance pour le nœud <x> commencé
458 Incapable de mettre en file d’attente les messages pour le nœud <x>
459 Nœud <x> non admis: <raison>
500 Erreur de syntaxe
501 Erreur de syntaxe dans les paramètres

Le code de réponse 250 n’indique pas que les messages seront envoyés au système en question, mais juste que la file d’attente a été entreprise et qu’une action va survenir. Si le serveur est capable d’accepter cela, les codes de réponse 251, 252 ou 253 devraient être utilisés pour donner plus d’informations du côté client. Dans ce cas, si il y a des messages en attente pour le nœud côte client, une vérification peut être faite en utilisant ces codes de réponse comme indication du moment où il n’y a plus de messages en instance dans la file d’attente pour ce nœud.

Les codes de résultat 458 et 459 devraient être utilisés pour donner plus d’informations en retour à l’hôte client sur les raisons pour lesquelles l’action n’a pas été effectuée. Si la syntaxe de la demande n’est pas correcte, les codes de résultat 500 et 501 devraient alors être utilisés.

 

5.2 Action du client à réception de la réponse à la commande ETRN étendue

Si un des codes d’erreur de niveau 500 (550 ou 551) est envoyé, le client devrait supposer que le protocole n’est pas pris en charge à l’hôte distant ou que le protocole n’a pas été correctement mis en œuvre chez l’hôte client ou serveur. Dans ce cas, on ne devrait pas envoyer plusieurs commandes ETRN (visant les alias du système).

Si la réponse 250 est reçue, l’hôte client peut alors supposer que l’hôte serveur a trouvé sa demande satisfaisante et qu’il va envoyer tous les messages trouvés dans la file d’attente. Ce processus peut impliquer de parcourir une très grosse file d’attente de réessais, et peut prendre un certain temps.

Si une réponse de niveau 400 est reçue, le client peut alors supposer que le serveur prend la commande en charge, mais que pour une raison locale ne veut pas accepter la commande ETRN comme elle est. Dans la plupart des cas, cela voudra dire qu’il y a une liste des nœuds dont il acceptera la commande et que ce client n’est pas sur la liste. Le code de réponse 459 est présenté pour permettre une raison plus détaillée de la cause pour laquelle la mise en file d’attente distante ne peut débuter.

 

5.3 Utilisation de ETRN pour livrer des messages à un sous-domaine ou une file d’attente

Si le serveur de la demande souhaite libérer tous les messages pour un sous-domaine donné, on peut utiliser une variante de la commande ETRN. Pour effectuer cette demande, le caractère d’option '@' devrait être utilisé devant le nom du nœud. De cette façon, tous les noms de domaine qui sont formés avec un suffixe du nom du nœud spécifié seront livrés.

Par exemple, si la commande ETRN @foo.com est produite, tous les messages accumulés pour fred.foo.com, a.b.c.d.e.f.g.foo.com ou foo.com peuvent être libérés. On devrait noter que le côté qui reçoit de la commande ETRN devrait prendre une décision fondée sur le client en question de ne permettre que certaines combinaisons pour chacun des nœuds. Ceci est plus une question de sécurité que de toute autre chose.

Dans une veine semblable, il peut être nécessaire dans certaines circonstances de libérer une certaine file d’attente, alors que cette file d’attente ne correspond pas à un nom de domaine donné. À cette fin, le caractère d’option '#' peut être utilisé pour forcer le traitement d’une file d’attente donnée. Dans ce cas, le nom du nœud sera utilisé plutôt comme nom de la file d’attente, et sa structure syntaxique dépendra du serveur de réception. L’utilisation de la commande ETRN #uucp pour forcer le vidage d’une file d’attente UUCP en serait un exemple. Noter que l’utilisation de cette option est entièrement une affaire locale et il n’y a aucun moyen pour un client de trouver une liste des files d’attente de cette nature qui existeraient.

 

6 Utilisation minimale

Un client "minimal" peut utiliser cette extension avec son nom d’hôte pour lancer les files d’attente sur l’hôte serveur. Cette utilisation minimale ne traitera pas les cas où les messages pour 'x.y' sont envoyés à 's.x.y'.

Un serveur minimal peut utiliser ces extensions pour commencer le traitement des files d’attente pour tous les sites distants. Dans ce cas, la réponse d’erreur 458 ne sera pas envoyée, et il devrait toujours retourner la réponse 25 car il voudra toujours essayer et commencer le traitement pour toutes les demandes.

 

7 Exemple

L’exemple suivant illustre l’utilisation d’un traitement de file d’attente à distance avec des échecs permanents et temporaires.

S: <attente de connexion sur le port TCP 25>
C: <connexion ouverte avec le serveur>
S: 220 sigurd.innosoft.com -- Serveur SMTP (PMDF V4.2-6 #1992)
C: EHLO ymir.claremont.edu
S: 250-sigurd.innosoft.com
S: 250-EXPN
S: 250-HELP
S: 250 ETRN
C: ETRN
S: 500 Erreur de syntaxe
C: ETRN localname
S: 501 Erreur de syntaxe de paramètres
C: ETRN uu.net
S: 458 Incapable de mettre en file d’attente les messages pour le noeud uu.net

...
C: ETRN sigurd.innosoft.com
S: 250 OK, mise en file d’attente pour le nœud sigurd.innosoft.com commencée

C: ETRN innosoft.com
S: 250 OK, mise en file d’attente pour le nœud innosoft.com commencée
OU
C: ETRN sigurd.innosoft.com
S: 251 OK, pas de message en attente pour le nœud sigurd.innosoft.com
C: ETRN innosoft.com
S: 252 OK, messages en instance pour le nœud innosoft.com commencé
C: ETRN mysoft.com
S: 253 OK, 14 messages en instance pour le nœud mysoft.com commencé
...
C: ETRN foo.bar
S: 459 Le nœud foo.bar n’est pas admis: Incapable de résoudre le nom.
...
C: QUIT
S: 250 Goodbye

 

8 Considérations pour la sécurité

La présente commande ne met en cause aucune considération pour la sécurité d’aucun protocole SMTP ou ESMTP existant dans la mesure où elle réduit simplement le temps qu’un client a besoin d’attendre le réessai de l’envoi de ses messages.

Des précautions devraient être prises pour s’assurer qu’un serveur client ne puisse utiliser les caractères d’option @ et # que pour des systèmes pour lesquels cela a un sens. Manquer à mettre en œuvre quelque sorte de vérification de l’état de ces paramètres pourrait conduire à des encombrements. Cela serai évident si une personne demandait la libération de @com, qui libérerait les messages pour toutes adresse se terminant par com.

 

9 Remerciements

Ce document a été créé avec le soutien des clients de nos produits, qui ont fourni les fonctionnalités qu’ils aimeraient voir dans les logiciels qu’ils achètent.

 

10 Références

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

[2] J. Klensin, président, N. Freed, éditeur, M. Rose, E. Stefferud et D. Crocker, "Extensions de service SMTP" RFC 1425, févrirr 1993.

 

11 Adresse de l’auteur

Jack De Winter
Wildbear Consulting, Inc.
17 Brock Street
Kitchener, Ontario, Canada
N2M 1X2
Tél : +1 519 576 3873
mél : jack@wildbear.on.ca