Extension de service SMTP pour transport MIME sur 8 bits

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 corps de contenu SMTP consistant en texte contenant des octets en-dehors de la gamme d’octets US-ASCII (hex 00-7F) peut être relayé en utilisant SMTP.

1 Introduction

Bien que SMTP soit largement développé et de façon solide, diverses extensions ont été demandées par des parties de la communauté de l’Internet. En particulier, une portion significative de la communauté de l’Internet souhaite échanger des messages dans lesquels le corps du contenu consiste en un message MIME [3] contenant du matériel arbitraire aligné sur l’octet. Le présent mémo utilise le mécanisme décrit en [5] pour définir une extension au service SMTP par laquelle un tel contenu puisse être échangé. Noter que cette extension N’ÉLIMINE PAS la possibilité qu’un serveur SMTP limite la longueur de ligne ; les serveurs ont toute liberté pour mettre en œuvre cette extension mais établir néanmoins une limite de longueur de ligne qui ne soit pas inférieure à 1000 octets. Étant donné que cette restriction s’applique toujours, la présente extension NE FOURNIT pas un moyen de transférer du binaire non codé via SMTP.

2 Cadre de l’extension de transport MIME à 8 bits

L’extension de transport MIME à 8 bits se présente comme suit :

(1) Le nom de l’extension de service SMTP définie ici est 8bit-MIMEtransport ;

(2) La valeur du mot clé EHLO associée à cette extension est 8BITMIME ;

(3) Aucun paramètre n’est utilisé avec le mot clé EHLO 8BITMIME ;

(4) Un paramètre facultatif utilisant le mot clé BODY est ajouté à la commande MAIL FROM. La valeur associée à ce paramètre est un mot clé indiquant si un message à 7 bits (en stricte conformité avec [1]) ou un message MIME (en stricte conformité avec [3]) avec un contenu arbitraire d’octets est envoyé. La syntaxe de la valeur est la suivante, en utilisant la notation ABNF de [2] :

body-value ::= "7BIT" / "8BITMIME"

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

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

3 L’extension de service de transport MIME à 8 bits

Lorsque un client SMTP souhaite soumettre (en utilisant la commande MAIL) un corps de contenu consistant en un message MIME contenant des lignes arbitraires de matériel aligné sur l’octet, 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 inclut la valeur de mot clé EHLO de 8BITMIME, le serveur SMTP indique alors qu’il accepte l’extension de commande MAIL et acceptera les messages MIME contenant du matériel arbitraire aligné sur l’octet.

La commande MAIL étendue est produite par un client SMTP lorsqu’il souhaite transmettre un corps de contenu consistant en un message MIME contenant des lignes arbitraires de matériel aligné sur l’octet. La syntaxe de cette commande est identique à celle de la commande en [1], excepté qu’un paramètre BODY doit apparaître après l’adresse. Un seul paramètre BODY peut être utilisé dans une seule commande MAIL.

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

La valeur associée au paramètre BODY indique si le corps de contenu qui sera passé en utilisant la commande DATA consiste en un message MIME contenant du matériel arbitraire aligné sur l’octet ("8BITMIME") ou est entièrement codé en conformité à [1] ("7BIT").

Un serveur qui accepte l’extension de service de transport MIME à 8 bits devra préserver tous les bits de chaque octet passé en utilisant la commande DATA.

Naturellement, l’algorithme habituel de bourrage des données SMTP s’applique de telle sorte qu’un contenu qui contient la séquence de cinq caractères de <CR> <LF> <DOT> <CR> <LF> ou un contenu qui commence par la séquence de trois caractères de <DOT> <CR> <LF> ne termine pas prématurément le transfert du contenu.

De plus, il vaut de noter que la paire CR-LF qui précède immédiatement le point final fait partie du contenu. Finalement, bien que le corps de contenu contienne des lignes arbitraires de matériel aligné sur l’octet, la longueur de chaque ligne (nombre d’octets entre deux paires de CR-LF), est toujours soumise aux restrictions sur la longueur de ligne de serveur SMTP (qui peut ne pas permettre plus de 1000 octets sur une seule ligne). Cette restriction signifie que cette extension PEUT fournir les facilités nécessaires au transfert d’un objet MIME avec le codage de transfert de contenu 8BIT, elle NE FOURNIT PAS le moyen de transférer un objet avec le codage de transfert de contenu BINARY.

Une fois qu’un serveur SMTP qui prend en charge l’extension de service de transport MIME à 8 bits a accepté un corps de contenu qui contient des octets avec le bit de plus fort poids (le huitième, le plus à gauche) établi (mis à 1), le serveur SMTP doit livrer ou relayer le contenu de façon à préserver tous les bits de chaque octet.

Si un serveur SMTP ne prend pas en charge l’extension de service de transport MIME à 8 bits (en ne répondant pas par un code 250 à la commande EHLO, ou en n’incluant pas la valeur de mot clé EHLO de 8BITMIME dans sa réponse), le client SMTP ne doit alors dans aucun cas essayer de transférer un contenu qui contient des caractères en-dehors de la gamme d’octets de l’US-ASCII (hexadécimaux de 00 à 7F).

Un client SMTP a deux options dans ce cas : premièrement, il peut mettre en œuvre une transformation de passerelle pour convertir le message en MIME à 7 bits valide, ou deuxièmement, il peut traiter cela comme une erreur permanente et utiliser les procédures habituelles pour les échecs de livraison. Les spécificités de la transformation du MIME à 8 bits en MIME à 7 bits ne sont pas décrites dans la présente RFC; mais les contraintes suivantes s’appliquent néanmoins à la conversion :

(1) elle ne doit causer aucune perte d’information ; le codage de transport MIME doit être utilisé en tant que de besoin pour s’assurer que c’est le cas, et

(2) le message résultant doit être du MIME à 7 bits valide.

4 Exemple d’utilisation

Le dialogue suivant illustre l’utilisation de l’extension de service de transport MIME à 8 bits :

S: <attend la connexion sur le port TCP 25>
C: <connexion ouverte avec le serveur>
S: 220 dbc.mtview.ca.us service SMTP prêt
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us dit hello
S: 250 8BITMIME
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
S: 250 <ned@ymir.claremont.edu>... Envoyer et 8BITMIME ok
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Receveur ok
C: DATA
S: 354 Envoi du message 8BITMIME, se terminant par CRLF.CRLF.
...
C: .
S: 250 OK
C: QUIT
S: 250 Goodbye

5 Considérations pour la sécurité

La présente RFC n’expose pas de questions de sécurité et n’est pas supposée soulever de questions de sécurité qui ne soient déjà endémique dans la messagerie électronique dans les mises en œuvre pleinement conformes à [1].

6 Remerciements

Le présent document représente une synthèse des idées de nombreuses personnes et des réactions aux idées et propositions des autres. Randall Atkinson, Craig Everhart, Risto Kankkunen et Greg Vaudreuil ont contribué aux idées et au texte de façon suffisante pour être considérés comme coauteurs. D’autres importantes suggestions, textes, ou encouragements nous sont venus de Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John Wagner, Rayan Zachariassen, et des contributions de tout le groupe de travail SMTP de l’IETF. Bien sûr, aucun n’est individuellement nécessairement responsable de la combinaison des idées représentées ici. Aussi, dans certains cas, la réponse à une critique particulière était d’accepter l’identification du problème mais d’inclure une solution entièrement différente de celle proposée à l’origine.

7 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", RFC 1651, MCI, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc., juillet 1994 (rendue obsolète par les RFC 1869 et 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).

8 Adresse du président, de l’éditeur et des auteurs