GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1426

Network Working Group J. Klensin, WG Chair Request for Comments: 1426 United Nations University

                                                      N. Freed, Editor
                                          Innosoft International, Inc.
                                                               M. Rose
                                          Dover Beach Consulting, Inc.
                                                          E. Stefferud
                                   Network Management Associates, Inc.
                                                            D. Crocker
                                                     The Branch Office
                                                         February 1993
                       SMTP Service Extension
                       for 8bit-MIMEtransport

Status of this Memo

 This RFC specifies an IAB standards track protocol for the Internet
 community, and requests discussion and suggestions for improvements.
 Please refer to the current edition of the "IAB Official Protocol
 Standards" for the standardization state and status of this protocol.
 Distribution of this memo is unlimited.

1. Abstract

 This memo defines an extension to the SMTP service whereby an SMTP
 content body containing octets outside of the US ASCII octet range
 (hex 00-7F) may be relayed using SMTP.

2. Introduction

 Although SMTP is widely and robustly deployed, various extensions
 have been requested by parts of the Internet community. In
 particular, a significant portion of the Internet community wishes to
 exchange messages in which the content body consists of a MIME
 message [3] containing arbitrary octet-aligned material. This memo
 uses the mechanism described in [5] to define an extension to the
 SMTP service whereby such contents may be exchanged. Note that this
 extension does NOT eliminate the possibility of an SMTP server
 limiting line length; servers are free to implement this extension
 but nevertheless set a line length limit no lower than 1000 octets.

3. Framework for the 8bit MIME Transport Extension

 The 8bit MIME transport extension is laid out as follows:

Klensin, Freed, Rose, Stefferud & Crocker [Page 1] RFC 1426 SMTP 8bit-MIMEtransport February 1993

        (1)  the name of the SMTP service extension defined here is
             8bit-MIMEtransport;
        (2)  the EHLO keyword value associated with the extension is
             8BITMIME;
        (3)  no parameter is used with the 8BITMIME EHLO keyword;
        (4)  one optional parameter using the keyword BODY is added to
             the MAIL FROM command.  The value associated with this
             parameter is a keyword indicating whether a 7bit message
             (in strict compliance with [1]) or a MIME message (in
             strict compliance with [3]) with arbitrary octet content
             is being sent. The syntax of the value is as follows,
             using the ABNF notation of [2]:
                  body-value ::= "7BIT" / "8BITMIME"
        (5)  no additional SMTP verbs are defined by this extension;
             and,
        (6)  the next section specifies how support for the extension
             affects the behavior of a server and client SMTP.

4. The 8bit-MIMEtransport service extension

 When a client SMTP wishes to submit (using the MAIL command) a
 content body consisting of a MIME message containing arbitrary
 octet-aligned material, it first issues the EHLO command to the
 server SMTP. If the server SMTP responds with code 250 to the EHLO
 command, and the response includes the EHLO keyword value 8BITMIME,
 then the server SMTP is indicating that it supports the extended MAIL
 command and will accept MIME messages containing arbitrary octet-
 aligned material.
 The extended MAIL command is issued by a client SMTP when it wishes
 to transmit a content body consisting of a MIME message containing
 arbitrary octet-aligned material. The syntax for this command is
 identical to the MAIL command in [1], except that a BODY parameter
 must appear after the address.
 The complete syntax of this extended command is defined in [5]. The
 esmtp-keyword is BODY and the syntax for esmtp-value is given by the
 syntax for body-value shown above.
 The value associated with the BODY parameter indicates whether the
 content body which will be passed using the DATA command consists of
 a MIME message containing some arbitrary octet-aligned material

Klensin, Freed, Rose, Stefferud & Crocker [Page 2] RFC 1426 SMTP 8bit-MIMEtransport February 1993

 ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").
 A server which supports the 8-bit MIME transport service extension
 shall preserve all bits in each octet passed using the DATA command.
 Naturally, the usual SMTP data-stuffing algorithm applies so that a
 content which contains the five-character sequence of
             <CR> <LF> <DOT> <CR> <LF>
 or a content that begins with the three-character sequence of
             <DOT> <CR> <LF>
 does not prematurely terminate the transfer of the content.  Further,
 it should be noted that the CR-LF pair immediately preceeding the
 final dot is considered part of the content.  Finally, although the
 content body contains arbitrary octet-aligned material, the length of
 each line (number of octets between two CR-LF pairs), is still
 subject to SMTP server line length restrictions (which may allow as
 few as 1000 octets on a single line).
 Once a server SMTP supporting the 8bit-MIMEtransport service
 extension accepts a content body containing octets with the high-
 order (8th) bit set, the server SMTP must deliver or relay the
 content in such a way as to preserve all bits in each octet.
 If a server SMTP does not support the 8-bit MIME transport extension
 (either by not responding with code 250 to the EHLO command, or by
 not including the EHLO keyword value 8BITMIME in its response), then
 the client SMTP must not, under any circumstances, attempt to
 transfer a content which contains characters outside the US ASCII
 octet range (hex 00-7F).
 A client SMTP has two options in this case: first,  it may implement
 a gateway transformation to convert the message into valid 7bit MIME,
 or second, or may treat this as a permanent error and handle it in
 the usual manner for delivery failures.  The specifics of the
 transformation from 8bit MIME to 7bit MIME are not described by this
 RFC; the conversion is nevertheless constrained in the following
 ways:
        (1)  it must cause no loss of information; MIME transport
             encodings must be employed as needed to insure this is
             the case, and
        (2)  the resulting message must be valid 7bit MIME.

Klensin, Freed, Rose, Stefferud & Crocker [Page 3] RFC 1426 SMTP 8bit-MIMEtransport February 1993

5. Usage Example

 The following dialogue illustrates the use of the 8bit-MIMEtransport
 service extension:
        S: <wait for connection on TCP port 25>
        C: <open connection to server>
        S: 220 dbc.mtview.ca.us SMTP service ready
        C: EHLO ymir.claremont.edu
        S: 250-dbc.mtview.ca.us says hello
        S: 250 8BITMIME
        C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
        S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
        C: RCPT TO:<mrose@dbc.mtview.ca.us>
        S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
        C: DATA
        S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
         ...
        C: .
        S: 250 OK
        C: QUIT
        S: 250 Goodbye

6. Security Considerations

 This RFC does not discuss security issues and is not believed to
 raise any security issues not already endemic in electronic mail and
 present in fully conforming implementations of [1].

7. Acknowledgements

 This document represents a synthesis of the ideas of many people and
 reactions to the ideas and proposals of others.  Randall Atkinson,
 Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
 and text sufficient to be considered co-authors.  Other important
 suggestions, text, or encouragement came from 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, and the contributions of the entire IETF
 SMTP Working Group. Of course, none of the individuals are
 necessarily responsible for the combination of ideas represented
 here. Indeed, in some cases, the response to a particular criticism
 was to accept the problem identification but to include an entirely
 different solution from the one originally proposed.

Klensin, Freed, Rose, Stefferud & Crocker [Page 4] RFC 1426 SMTP 8bit-MIMEtransport February 1993

8. References

 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
     USC/Information Sciences Institute, August 1982.
 [2] Crocker, D., "Standard for the Format of ARPA Internet Text
     Messages", STD 11, RFC 822, UDEL, August 1982.
 [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
     Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
 [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
     Headers", RFC 1342, University of Tennessee, June 1992.
 [5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
     E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
     Nations University, Innosoft International, Inc., Dover Beach
     Consulting, Inc., Network Management Associates, Inc., The Branch
     Office, February 1993.
 [6] Partridge, C., "Mail Routing and the Domain System", RFC 974,
     BBN, January 1986.

9. Chair, Editor, and Authors' Addresses

     John Klensin, WG Chair
     United Nations University
     PO Box 500, Charles Street Station
     Boston, MA 02114-0500  USA
     Phone: +1 617 227 8747
     Fax: +1 617 491 6266
     Email: klensin@infoods.unu.edu
     Ned Freed, Editor
     Innosoft International, Inc.
     250 West First Street, Suite 240
     Claremont, CA 91711  USA
     Phone: +1 909 624 7907
     Fax: +1 909 621 5319
     Email: ned@innosoft.com

Klensin, Freed, Rose, Stefferud & Crocker [Page 5] RFC 1426 SMTP 8bit-MIMEtransport February 1993

     Marshall T. Rose
     Dover Beach Consulting, Inc.
     420 Whisman Court
     Moutain View, CA  94043-2186  USA
     Phone: +1 415 968 1052
     Fax: +1 415 968 2510
     Email: mrose@dbc.mtview.ca.us
     Einar A. Stefferud
     Network Management Associates, Inc.
     17301 Drey Lane
     Huntington Beach, CA, 92647-5615  USA
     Phone: +1 714 842 3711
     Fax: +1 714 848 2091
     Email: stef@nma.com
     David H. Crocker
     The Branch Office
     USA
     Email: dcrocker@mordor.stanford.edu

Klensin, Freed, Rose, Stefferud & Crocker [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1426.txt · Last modified: 1993/02/09 01:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki