rfc1652.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:12k
源码类别:

Email服务器

开发平台:

C#

  1. Network Working Group                               J. Klensin, WG Chair
  2. Request for Comments: 1652                                           MCI
  3. Obsoletes: 1426                                         N. Freed, Editor
  4. Category: Standards Track                                       Innosoft
  5.                                                                  M. Rose
  6.                                             Dover Beach Consulting, Inc.
  7.                                                             E. Stefferud
  8.                                      Network Management Associates, Inc.
  9.                                                               D. Crocker
  10.                                                   Silicon Graphics, Inc.
  11.                                                                July 1994
  12.              SMTP Service Extension for 8bit-MIMEtransport
  13. Status of this Memo
  14.    This document specifies an Internet standards track protocol for the
  15.    Internet community, and requests discussion and suggestions for
  16.    improvements.  Please refer to the current edition of the "Internet
  17.    Official Protocol Standards" (STD 1) for the standardization state
  18.    and status of this protocol.  Distribution of this memo is unlimited.
  19. Abstract
  20.    This memo defines an extension to the SMTP service whereby an SMTP
  21.    content body consisting of text containing octets outside of the US-
  22.    ASCII octet range (hex 00-7F) may be relayed using SMTP.
  23. 1.  Introduction
  24.    Although SMTP is widely and robustly deployed, various extensions
  25.    have been requested by parts of the Internet community. In
  26.    particular, a significant portion of the Internet community wishes to
  27.    exchange messages in which the content body consists of a MIME
  28.    message [3] containing arbitrary octet-aligned material. This memo
  29.    uses the mechanism described in [5] to define an extension to the
  30.    SMTP service whereby such contents may be exchanged. Note that this
  31.    extension does NOT eliminate the possibility of an SMTP server
  32.    limiting line length; servers are free to implement this extension
  33.    but nevertheless set a line length limit no lower than 1000 octets.
  34.    Given that this restriction still applies, this extension does NOT
  35.    provide a means for transferring unencoded binary via SMTP.
  36. Klensin, Freed, Rose, Stefferud & Crocker                       [Page 1]
  37. RFC 1652                SMTP 8bit-MIMEtransport                July 1994
  38. 2.  Framework for the 8bit MIME Transport Extension
  39.    The 8bit MIME transport extension is laid out as follows:
  40.       (1)  the name of the SMTP service extension defined here is
  41.            8bit-MIMEtransport;
  42.       (2)  the EHLO keyword value associated with the extension is
  43.            8BITMIME;
  44.       (3)  no parameter is used with the 8BITMIME EHLO keyword;
  45.       (4)  one optional parameter using the keyword BODY is added to
  46.            the MAIL FROM command.  The value associated with this
  47.            parameter is a keyword indicating whether a 7bit message
  48.            (in strict compliance with [1]) or a MIME message (in
  49.            strict compliance with [3]) with arbitrary octet content
  50.            is being sent. The syntax of the value is as follows,
  51.            using the ABNF notation of [2]:
  52.                 body-value ::= "7BIT" / "8BITMIME"
  53.       (5)  no additional SMTP verbs are defined by this extension;
  54.            and,
  55.       (6)  the next section specifies how support for the extension
  56.            affects the behavior of a server and client SMTP.
  57. 3.  The 8bit-MIMEtransport service extension
  58.    When a client SMTP wishes to submit (using the MAIL command) a
  59.    content body consisting of a MIME message containing arbitrary lines
  60.    of octet-aligned material, it first issues the EHLO command to the
  61.    server SMTP. If the server SMTP responds with code 250 to the EHLO
  62.    command, and the response includes the EHLO keyword value 8BITMIME,
  63.    then the server SMTP is indicating that it supports the extended MAIL
  64.    command and will accept MIME messages containing arbitrary octet-
  65.    aligned material.
  66.    The extended MAIL command is issued by a client SMTP when it wishes
  67.    to transmit a content body consisting of a MIME message containing
  68.    arbitrary lines of octet-aligned material. The syntax for this
  69.    command is identical to the MAIL command in [1], except that a BODY
  70.    parameter must appear after the address.  Only one BODY parameter may
  71.    be used in a single MAIL command.
  72. Klensin, Freed, Rose, Stefferud & Crocker                       [Page 2]
  73. RFC 1652                SMTP 8bit-MIMEtransport                July 1994
  74.    The complete syntax of this extended command is defined in [5]. The
  75.    esmtp-keyword is BODY and the syntax for esmtp-value is given by the
  76.    syntax for body-value shown above.
  77.    The value associated with the BODY parameter indicates whether the
  78.    content body which will be passed using the DATA command consists of
  79.    a MIME message containing some arbitrary octet-aligned material
  80.    ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").
  81.    A server which supports the 8-bit MIME transport service extension
  82.    shall preserve all bits in each octet passed using the DATA command.
  83.    Naturally, the usual SMTP data-stuffing algorithm applies so that a
  84.    content which contains the five-character sequence of
  85.      <CR> <LF> <DOT> <CR> <LF>
  86.    or a content that begins with the three-character sequence of
  87.      <DOT> <CR> <LF>
  88.    does not prematurely terminate the transfer of the content.  Further,
  89.    it should be noted that the CR-LF pair immediately preceeding the
  90.    final dot is considered part of the content.  Finally, although the
  91.    content body contains arbitrary lines of octet-aligned material, the
  92.    length of each line (number of octets between two CR-LF pairs), is
  93.    still subject to SMTP server line length restrictions (which may
  94.    allow as few as 1000 octets on a single line). This restriction means
  95.    that this extension MAY provide the necessary facilities for
  96.    transferring a MIME object with the 8BIT content-transfer-encoding,
  97.    it DOES NOT provide a means of transferring an object with the BINARY
  98.    content-transfer-encoding.
  99.    Once a server SMTP supporting the 8bit-MIMEtransport service
  100.    extension accepts a content body containing octets with the high-
  101.    order (8th) bit set, the server SMTP must deliver or relay the
  102.    content in such a way as to preserve all bits in each octet.
  103.    If a server SMTP does not support the 8-bit MIME transport extension
  104.    (either by not responding with code 250 to the EHLO command, or by
  105.    not including the EHLO keyword value 8BITMIME in its response), then
  106.    the client SMTP must not, under any circumstances, attempt to
  107.    transfer a content which contains characters outside the US-ASCII
  108.    octet range (hex 00-7F).
  109.    A client SMTP has two options in this case: first, it may implement a
  110.    gateway transformation to convert the message into valid 7bit MIME,
  111.    or second, or may treat this as a permanent error and handle it in
  112. Klensin, Freed, Rose, Stefferud & Crocker                       [Page 3]
  113. RFC 1652                SMTP 8bit-MIMEtransport                July 1994
  114.    the usual manner for delivery failures.  The specifics of the
  115.    transformation from 8bit MIME to 7bit MIME are not described by this
  116.    RFC; the conversion is nevertheless constrained in the following
  117.    ways:
  118.       (1)  it must cause no loss of information; MIME transport
  119.            encodings must be employed as needed to insure this is
  120.            the case, and
  121.       (2)  the resulting message must be valid 7bit MIME.
  122. 4.  Usage Example
  123.    The following dialogue illustrates the use of the 8bit-MIMEtransport
  124.    service extension:
  125.    S: <wait for connection on TCP port 25>
  126.    C: <open connection to server>
  127.    S: 220 dbc.mtview.ca.us SMTP service ready
  128.    C: EHLO ymir.claremont.edu
  129.    S: 250-dbc.mtview.ca.us says hello
  130.    S: 250 8BITMIME
  131.    C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
  132.    S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
  133.    C: RCPT TO:<mrose@dbc.mtview.ca.us>
  134.    S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
  135.    C: DATA
  136.    S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
  137.     ...
  138.    C: .
  139.    S: 250 OK
  140.    C: QUIT
  141.    S: 250 Goodbye
  142. 5.  Security Considerations
  143.    This RFC does not discuss security issues and is not believed to
  144.    raise any security issues not already endemic in electronic mail and
  145.    present in fully conforming implementations of [1].
  146. 6.  Acknowledgements
  147.    This document represents a synthesis of the ideas of many people and
  148.    reactions to the ideas and proposals of others.  Randall Atkinson,
  149.    Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
  150.    and text sufficient to be considered co-authors.  Other important
  151.    suggestions, text, or encouragement came from Harald Alvestrand, Jim
  152.    Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
  153. Klensin, Freed, Rose, Stefferud & Crocker                       [Page 4]
  154. RFC 1652                SMTP 8bit-MIMEtransport                July 1994
  155.    Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
  156.    Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John
  157.    Wagner, Rayan Zachariassen, and the contributions of the entire IETF
  158.    SMTP Working Group. Of course, none of the individuals are
  159.    necessarily responsible for the combination of ideas represented
  160.    here. Indeed, in some cases, the response to a particular criticism
  161.    was to accept the problem identification but to include an entirely
  162.    different solution from the one originally proposed.
  163. 7.  References
  164.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  165.        USC/Information Sciences Institute, August 1982.
  166.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  167.        Messages", STD 11, RFC 822, UDEL, August 1982.
  168.    [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
  169.        Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
  170.    [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
  171.        Headers", RFC 1522, University of Tennessee, September 1993.
  172.    [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
  173.        "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
  174.        Consulting, Inc., Network Management Associates, Inc., Silicon
  175.        Graphics, Inc., July 1994.
  176.    [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  177.        974, BBN, January 1986.
  178. 8.  Chair, Editor, and Authors' Addresses
  179.    John Klensin, WG Chair
  180.    MCI Data Services Division
  181.    2100 Reston Parkway, 6th floor
  182.    Reston, VA 22091
  183.    USA
  184.    Phone:: 1 703 715 7361
  185.    Fax: +1 703 715 7435
  186.    EMail: klensin@mci.net
  187. Klensin, Freed, Rose, Stefferud & Crocker                       [Page 5]
  188. RFC 1652                SMTP 8bit-MIMEtransport                July 1994
  189.    Ned Freed, Editor
  190.    Innosoft International, Inc.
  191.    1050 East Garvey Avenue South
  192.    West Covina, CA 91790
  193.    USA
  194.    Phone:: +1 818 919 3600
  195.    Fax: +1 818 919 3614
  196.    EMail: ned@innosoft.com
  197.    Marshall T. Rose
  198.    Dover Beach Consulting, Inc.
  199.    420 Whisman Court
  200.    Moutain View, CA  94043-2186
  201.    USA
  202.    Phone: +1 415 968 1052
  203.    Fax: +1 415 968 2510
  204.    EMail: mrose@dbc.mtview.ca.us
  205.    Einar A. Stefferud
  206.    Network Management Associates, Inc.
  207.    17301 Drey Lane
  208.    Huntington Beach, CA, 92647-5615
  209.    USA
  210.    Phone: +1 714 842 3711
  211.    Fax: +1 714 848 2091
  212.    EMail: stef@nma.com
  213.    Dave Crocker
  214.    Silicon Graphics, Inc.
  215.    2011 N. Shoreline Blvd.
  216.    P.O. Box 7311
  217.    Mountain View, CA 94039
  218.    USA
  219.    Phone: +1 415 390 1804
  220.    Fax: +1 415 962 8404
  221.    EMail: dcrocker@sgi.com
  222. Klensin, Freed, Rose, Stefferud & Crocker                       [Page 6]