Extension de service SMTP pour déclaration de taille de message

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.

1 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 refuser d’accepter un message (éventuellement de façon temporaire) sur la base de l’estimation par le client de la taille du message.

2 Introduction

Les extensions MIME au protocole de messagerie Internet prévoient la transmission de nombreuses sortes de données qui étaient précédemment non prises en charge par la messagerie Internet. Un résultat attendu de l’utilisation de MIME est qu’on peut s’attendre à ce que SMTP transporte une gamme beaucoup plus large de tailles de message que ce n’était précédemment le cas. Cela a un impact sur la quantité de ressources (par exemple, l’espace disque) nécessaire pour un système qui agit comme serveur.

Le présent mémo utilise le mécanisme défini dans [5] pour définir les extensions au service SMTP par lesquelles un client ("envoyeur-SMTP") peut déclarer la taille d’un message particulier à un serveur ("receveur-SMTP"), après quoi le serveur peut indiquer au client qu’il veut ou non accepter le message sur la base de la taille de message déclarée et par lesquelles un serveur ("receveur-SMTP") peut déclarer la taille maximum de message qu’il veut accepter à un client ("envoyeur-SMTP").

3 Cadre de l’extension de déclaration de taille

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

(1) le nom de l’extension de service SMTP est "Déclaration de taille de message" ;

(2) la valeur de mot clé EHLO associée à cette extension est "SIZE" ;

(3) un paramètre facultatif est permis avec cette valeur de mot clé EHLO, un nombre décimal indiquant la taille maximum de message fixée en octets que le serveur va accepter. La syntaxe du paramètre est la suivante, en notation BNF augmenté [2] :

size-param ::= [1*DIGIT]

Une valeur de paramètre de 0 (zéro) indique qu’aucune taille maximum de message fixée n’est en vigueur. Si le paramètre est omis, aucune information n’est convoyée au sujet de la taille maximum de message fixée du serveur ;

(4) un paramètre facultatif utilisant le mot clé "SIZE" est ajouté à la commande MAIL FROM. La valeur associée à ce paramètre est un nombre décimal qui indique la taille du message à transmettre. La syntaxe de cette valeur est la suivante, en notation BNF augmenté de [2] :

size-value ::= 1*20DIGIT

(5) la longueur maximum d’une ligne de commande MAIL FROM est augmentée de 26 caractères par l’ajout possible du mot clé SIZE et de sa valeur ;

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

Le reste du présent mémo spécifie comment la prise en charge de l’extension affecte le comportement d’un client et serveur SMTP.

4 L’extension de service Déclaration de taille de message

Un serveur SMTP a une limite supérieure fixée de taille de message. Toute tentative d’un client de transférer un message plus grand que cette limite supérieure fixée échouera. De plus, un serveur a normalement un espace limité pour mémoriser les messages entrants. Le transfert d’un message peut donc aussi échouer du fait d’un manque d’espace de mémoire, mais peut réussir ultérieurement.

Un client qui utilise le protocole SMTP sans extension défini en [1], peut seulement être informé de tels échecs après avoir transmis le message entier au serveur (qui élimine le message transféré). Si, cependant, le client et le serveur prennent tous deux en charge l’extension de service de déclaration de taille de message, une telle condition peut être détectée avant toute tentative de transfert.

Un client SMTP qui souhaite relayer un gros contenu peut produire la commande EHLO pour débuter une session SMTP, pour déterminer si le serveur accepte une des différentes extensions de service. Si le serveur répond par le code 250 à la commande EHLO, et si la réponse comporte la valeur de mot clé EHLO de SIZE, l’extension de déclaration de taille de message est alors acceptée.

Si un paramètre numérique suit la valeur du mot clé SIZE de la réponse EHLO, elle indique la taille du plus grand message que le serveur peut accepter. Toute tentative d’un client de transférer un message plus grand que cette limite sera rejeté avec un code de réponse d’échec permanent (552).

Un serveur qui accepte l’extension de déclaration de taille de message acceptera la version étendue de la commande MAIL décrite ci-dessous. Lorsqu’elle est acceptée par le serveur, un client peut utiliser la commande MAIL étendue (au lieu de la commande MAIL définie dans [1]) pour déclarer une estimation de la taille du message qu’il souhaite transférer. Le serveur peut alors retourner un code d’erreur approprié si il détermine qu’une tentative de transfert d’un message de cette taille va échouer.

5 Définitions

La taille du message est définie comme le nombre des octets, y compris les paires de CR-LF, mais pas du point ou des doubles points de citation de terminaison de la commande SMTP DATA, que doit transmettre le client SMTP après avoir reçu un code de réponse 354 à la commande DATA.

La taille de message maximum fixée est définie comme la taille de message du plus grand message qu’un serveur voudra jamais accepter. Une tentative de transfert de tout message plus grand que la taille maximum de message va toujours échouer. La taille maximum de message fixée peut être un dispositif de mise en œuvre du serveur SMTP, ou elle peut être choisie par l’administrateur du serveur.

La taille de message déclarée est définie comme l’estimation du client de la taille de message pour un message particulier.

6 La commande MAIL étendue

La commande MAIL étendue est produite par un client lorsqu’il souhaite informer un serveur de la taille du message à envoyer. La commande MAIL étendue est identique à la commande MAIL définie en [1], excepté qu’un paramètre SIZE apparaît après l’adresse.

La syntaxe complète de cette extension de commande est définie en [5]. Le mot clé esmtp est "SIZE" et la syntaxe pour la valeur esmtp est donnée par la syntaxe pour la valeur de taille donnée ci-dessus.

La valeur associée au paramètre SIZE est une représentation décimale de la taille de message déclarée en octets. Ce nombre devrait inclure l’en-tête de message, le corps, et les séquences de CR-LF entre les lignes, mais pas du point ou des doubles points de citation de terminaison de la commande SMTP DATA. Un seul paramètre SIZE peut être spécifié dans une même commande MAIL.

Théoriquement, la taille de message déclarée est égale à la vraie taille du message. Cependant, comme un calcul exact de la taille de message est infaisable, le client peut utiliser une estimation déduite par une méthode heuristique. De telles méthodes heuristiques devraient être choisies de telle sorte que la taille de message déclarée soit habituellement supérieure à la taille réelle du message. (Ce qui a pour effet de rendre le comptage ou non comptage des points de SMTP DATA largement académique.)

NOTE : les serveurs NE DOIVENT PAS utiliser le paramètre SIZE pour déterminer la fin du contenu dans la commande DATA.

6.1 Action du serveur à réception de la commande MAIL étendue

À réception d’une commande MAIL étendue contenant un paramètre SIZE, un serveur devrait déterminer si la taille de message déclarée excède sa taille maximum de message fixée. Si la taille de message déclarée est inférieure à la taille maximum de message fixée, le serveur peut aussi souhaiter déterminer si des ressources suffisantes sont disponibles pour mettre en mémoire tampon un message de la taille de message déclarée et pour la conserver dans une mémorisation stable, jusqu’à ce que le message puisse être délivré ou relayé à chacun de ses receveurs.

Un serveur peut répondre à la commande MAIL étendue par tout code d’erreur défini en [1] pour la commande MAIL. De plus, un des codes d’erreur suivants peut être retourné :

(1) Si le serveur manque actuellement des ressources suffisantes pour accepter un message de la taille indiquée, mais peut être capable d’accepter le message ultérieurement, il répond par le code "452 Mémoire système insuffisante".

(2) Si la taille indiquée est supérieure à la taille maximum de message fixée du serveur, il répond par le code "552 Taille de message excédant la taille maximum de message fixée".

Il est permis à un serveur, mais il n’y est pas obligé, d’accepter un message qui est, en fait, plus grand que déclaré dans la commande MAIL étendue, comme cela peut arriver si le client a employé une heuristique d’estimation de taille inappropriée.

6.2 Action du client à réception de la réponse à la commande MAIL étendue

À réception de la réponse du serveur à la commande MAIL étendue, le client agit comme suit :

(1) Si le code "452 Mémoire système insuffisante" est retourné, le client devrait ensuite envoyer une commande RSET (si il souhaite tenter d’envoyer d’autres messages) ou une commande QUIT. Le client devrait alors répéter la tentative pour envoyer ultérieurement le message au serveur.

(2) Si le code "552 Message excédant la taille maximum de message fixée" est reçu, le client devrait immédiatement envoyer une commande RSET (s’il souhaite tenter d’envoyer des messages supplémentaires), ou une commande QUIT. Le client devrait alors déclarer le message indélivrable et retourner la notification appropriée à l’envoyeur (si une adresse d’envoyeur est présente dans la commande MAIL).

Un code de réponse de succès (250) en réponse à la commande MAIL étendue ne constitue pas une garantie absolue que le transfert du message va réussir. Les clients SMTP qui utilisent la commande MAIL étendue doivent être toujours prêts à traiter aussi bien des codes de réponse d’erreur temporaires que permanents (y compris les codes 452 et 552), soit immédiatement après la production de la commande DATA, soit après le transfert du message.

6.3 Message plus grand que la taille déclarée

Une fois qu’un serveur est d’accord (via la commande MAIL étendue) pour accepter un message d’une taille particulière, il ne devrait pas retourner un code de réponse 552 après la phase de transfert de la commande DATA, à moins que la taille réelle du message transféré ne soit plus grande que la taille de message déclarée. Un serveur peut aussi choisir d’accepter un message qui est un peu plus grand que la taille de message déclarée.

Il est permis à un client de déclarer qu’un message est plus petit que sa taille réelle. Cependant, dans ce cas, un code de réponse de succès (250) n’est pas une assurance que le serveur va accepter le message ou qu’il a des ressources suffisantes pour le faire. Le serveur peut rejeter un tel message après le transfert des données.

6.4 Rejet selon le receveur sur la base de la taille de message

Un serveur qui met en œuvre la présente extension peut retourner un code de réponse 452 ou 552 en réponse à une commande RCPT, sur la base de sa volonté de ne pas accepter un message de la taille déclarée pour un receveur particulier.

(1) Si un code 452 est retourné, le client peut remettre le message en file d’attente pour livraison ultérieure au même receveur.

(2) Si un code 552 est retourné, le client peut ne pas remettre le message en file d’attente pour livraison ultérieure au même receveur.

7 Utilisation minimale

Un client "minimal" peut utiliser la présente extension simplement pour comparer sa taille de message (peut-être estimée) qu’il souhaite relayer, à la taille maximum de message fixée du serveur (à partir du paramètre du mot clé SIZE dans la réponse EHLO), pour déterminer si le serveur acceptera jamais le message. Une telle mise en œuvre n’a pas besoin de déclarer les tailles de message via la commande MAIL étendue. Cependant, elle ne sera pas capable de découvrir les limites temporaires de taille de message dues aux limitations de ressource du serveur, ni les limitations de la taille de message par receveur.

Un serveur minimal qui emploie cette extension de service peut simplement utiliser la valeur du mot clé SIZE pour informer le client le la taille du plus grand message qu’il acceptera, ou pour informer le client qu’il n’y a pas de limite fixée à la taille de message. Un tel serveur doit accepter la commande MAIL étendue et retourner un code de réponse 552 si la taille déclarée du client excède sa limite de taille fixée (s’il en est une), mais il n’a pas besoin de détecter les limitations "temporaires" à la taille de message.

Le paramètre numérique du mot clé SIZE de EHLO est facultatif. Si le paramètre est entièrement omis, il indique que le serveur n’affiche pas de taille maximum de message fixée. Un serveur qui retourne le mot clé SIZE sans paramètre en réponse à la commande EHLO ne peut pas produire une réponse positive (250) à une commande MAIL étendue contenant une spécification de SIZE sans avoir d’abord vérifié pour voir si des ressources suffisantes sont disponibles pour transférer un message de la taille déclarée, et le conserver dans une mémoire stable jusqu’à ce qu’il puisse être relayé ou délivré à ses receveurs. Si possible, le serveur devrait réellement réserver un espace de mémorisation suffisant pour transférer le message.

8 Exemple

L’exemple suivant illustre l’utilisation de la déclaration de taille 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 SIZE 1000000
C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
S: 250 Address Ok.
C: RCPT TO:<ned@innosoft.com>
S: 250 ned@innosoft.com OK; peut traiter un message de 500000 octets
C: RCPT TO:<ned@ymir.claremont.edu>
S: 552 Limite de taille de canal dépassée: ned@YMIR.CLAREMONT.EDU
C: RCPT TO:<ned@hmcvax.claremont.edu>
S: 452 Mémoire de canal insuffisante: ned@hmcvax.CLAREMONT.EDU
C: DATA
S: 354 Envoi du message, se termine par CRLF.CRLF.
...
C: .
S: 250 Des receveurs sont OK
C: QUIT
S: 221 Goodbye

9 Considérations pour la sécurité

Les extension de déclaration de taille décrites dans le présent mémo peuvent être utilisées pour faciliter des attaques brutales de déni de service. Précisément, les informations contenues dans le paramètre SIZE et l’utilisation de la commande MAIL étendue rendent plus rapide et plus facile de monter une attaque efficace de déni de service. Cependant, sauf sur des mises en oeuvre très faibles, ces extensions ne créent aucune faiblesse qui n’existe déjà avec SMTP. De plus, aucune des questions traitées n’implique de système de confiance et la possible divulgation d’informations via les mécanismes décrits dans la présente RFC.

10 Remerciements

Le présent document découle d’une contribution à un précédent travail en cours du groupe. Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear, Marshall T. Rose, et Einar Stefferud ont fourni des commentaires détaillés en réponse aux travaux en cours précédents à la fois pour ce mémo et le précédent.

11 Références

[1] J. Postel, "Protocole simple de transfert de messagerie", STD 10, RFC 821, USC/Information Sciences Institute, août 1982 (rendue obsolète par la RFC 2821, avril 2001).

[2] D. Crocker, "Norme pour le format des messages de texte ARPA Internet", STD 11, RFC 822, UDEL, août 1982 (rendue obsolète par la RFC 2822, avril 2001).

[3] N. Borenstein et N. Freed, "Extensions multi objet de messagerie Internet", RFC 1521, Bellcore, Innosoft, septembre 1993 (rendue obsolète par les RFC 2045 à 2049, novembre 1996).

[4] K. Moore, "Représentation du texte non-ASCII dans les en-têttes de message Internet", RFC 1522, Université du Tennessee, septembre 1993 (rendue obsolète par les RFC 2045 à 2049, novembre 1996).

[5] J. Klensin, N. Freed, M. Rose, E. Stefferud et D. Crocker, "Extensions de service SMTP", STD 11, RFC 1869, MCI, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc., juillet 1994 (rendue obsolète par la RFC 2821, avril2001).

[6] C. Partridge, "Acheminement de messagerie et système des domaines", STD 14, RFC 974, BBN, janvier 1986 (rendue obsolète par la RFC 2821, avril2001).

12 Adresse du président de l’éditeur et de l’auteur