SMTP Service Extension for 8-bit MIME Transport
draft-ietf-yam-rfc1652bis-03

YAM                                                           J. Klensin
Internet-Draft
Obsoletes: 1652 (if approved)                                   N. Freed
Intended status: Standards Track                        Sun Microsystems
Expires: August 23, 2010                                         M. Rose
                                            Dover Beach Consulting, Inc.
                                                         D. Crocker, Ed.
                                             Brandenburg InternetWorking
                                                       February 19, 2010

            SMTP Service Extension for 8-bit MIME Transport
                      draft-ietf-yam-rfc1652bis-03

Abstract

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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 23, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Klensin, et al.          Expires August 23, 2010                [Page 1]
Internet-Draft            SMTP 8-bit Extension             February 2010

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

1.  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 [RFC2045][RFC2046][RFC5322] containing arbitrary octet-
   aligned material.  This memo uses the mechanism described in
   [RFC5321] 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.  Given that this
   restriction still applies, this extension does NOT provide a means
   for transferring unencoded binary via SMTP.

2.  Framework for the 8bit MIME Transport Extension

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

   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 [RFC5321]) or a MIME message (in strict compliance with
       [RFC2046][RFC2045]) with arbitrary octet content is being sent.
       The syntax of the value is as follows, using the ABNF notation of
       [RFC5234]:
   body-value = "7BIT" / "8BITMIME"

Klensin, et al.          Expires August 23, 2010                [Page 2]
Internet-Draft            SMTP 8-bit Extension             February 2010

   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.

3.  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 lines
   of 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 lines of octet-aligned material.  The syntax for this
   command is identical to the MAIL command in [RFC5321], except that a
   BODY parameter must appear after the address.  Only one BODY
   parameter may be used in a single MAIL command.

   The complete syntax of this extended command is defined in [RFC5321].
   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
   ("8BITMIME") or is encoded entirely in accordance with [RFC5321]
   ("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 preceding the
   final dot is considered part of the content.  Finally, although the
   content body contains arbitrary lines of 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 can
   allow as few as 1000 octets, inclusive of the CR-LF pair, on a single

Klensin, et al.          Expires August 23, 2010                [Page 3]
Internet-Draft            SMTP 8-bit Extension             February 2010

   line).  This restriction means that this extension provides the
   necessary facilities for transferring a MIME object with the 8BIT
   content-transfer-encoding, it DOES NOT provide a means of
   transferring an object with the BINARY content-transfer-encoding.

   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.

4.  Usage Example

   The following dialogue illustrates the use of the 8bit-MIMEtransport
   service extension:

Klensin, et al.          Expires August 23, 2010                [Page 4]
Internet-Draft            SMTP 8-bit Extension             February 2010

   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

5.  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 [RFC5321].

6.  IANA Considerations

6.1.  SMTP service extension registration

   This document defines an SMTP and Submit service extension, and IANA
   is asked to update the 8BITMIME entry in the SMTP Service Extensions
   registry, as follows:

   Keyword:   8BITMIME

   Description:   SMTP and Submit transport of 8bit MIME content

   Reference:   [[IANA: Insert this RFC number.]]

   Parameters:   See Section 2 in this specification.

6.2.  Acknowledgements

   E. Stefferud was an original author.  This version of the
   specification was produced by the YAM working group.

Klensin, et al.          Expires August 23, 2010                [Page 5]
Internet-Draft            SMTP 8-bit Extension             February 2010

   Original 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.

7.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140
   USA

   Phone: +1 617 245 1457
   Email: john+ietf@jck.com

Klensin, et al.          Expires August 23, 2010                [Page 6]
Internet-Draft            SMTP 8-bit Extension             February 2010

   Ned Freed
   Sun Microsystems
   800 Royal Oaks
   Monrovia, CA  91016-6347
   USA

   Phone: +1 909 457 4293
   Email: ned.freed@mrochek.com

   M. Rose
   Dover Beach Consulting, Inc.
   POB 255268
   Sacramento, CA  95865-5268

   Phone: +1 916 538 2535
   Email: mrose17@gmail.com

   D. Crocker (editor)
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA
   USA

   Phone: +1.408.246.8253
   Email: dcrocker@bbiw.net
   URI:   http://bbiw.net

Klensin, et al.          Expires August 23, 2010                [Page 7]