home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1870 < prev    next >
Text File  |  1995-11-08  |  18KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               J. Klensin, WG Chair
  8. Request For Comments: 1870                                           MCI
  9. STD: 10                                                 N. Freed, Editor
  10. Obsoletes: 1653                             Innosoft International, Inc.
  11. Category: Standards Track                                       K. Moore
  12.                                                  University of Tennessee
  13.                                                            November 1995
  14.  
  15.  
  16.                          SMTP Service Extension
  17.                       for Message Size Declaration
  18.  
  19. Status of this Memo
  20.  
  21.    This document specifies an Internet standards track protocol for the
  22.    Internet community, and requests discussion and suggestions for
  23.    improvements.  Please refer to the current edition of the "Internet
  24.    Official Protocol Standards" (STD 1) for the standardization state
  25.    and status of this protocol.  Distribution of this memo is unlimited.
  26.  
  27. 1.  Abstract
  28.  
  29.    This memo defines an extension to the SMTP service whereby an SMTP
  30.    client and server may interact to give the server an opportunity to
  31.    decline to accept a message (perhaps temporarily) based on the
  32.    client's estimate of the message size.
  33.  
  34. 2.  Introduction
  35.  
  36.    The MIME extensions to the Internet message protocol provide for the
  37.    transmission of many kinds of data which were previously unsupported
  38.    in Internet mail.  One expected result of the use of MIME is that
  39.    SMTP will be expected to carry a much wider range of message sizes
  40.    than was previously the case.  This has an impact on the amount of
  41.    resources (e.g. disk space) required by a system acting as a server.
  42.  
  43.    This memo uses the mechanism defined in [5] to define extensions to
  44.    the SMTP service whereby a client ("sender-SMTP") may declare the
  45.    size of a particular message to a server ("receiver-SMTP"), after
  46.    which the server may indicate to the client that it is or is not
  47.    willing to accept the message based on the declared message size and
  48.    whereby a server ("receiver-SMTP") may declare the maximum message
  49.    size it is willing to accept to a client ("sender-SMTP").
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Klensin, et al              Standards Track                     [Page 1]
  59.  
  60. RFC 1870                 SMTP Size Declaration             November 1995
  61.  
  62.  
  63. 3.  Framework for the Size Declaration Extension
  64.  
  65.    The following service extension is therefore defined:
  66.  
  67.    (1) the name of the SMTP service extension is "Message Size
  68.        Declaration";
  69.  
  70.    (2) the EHLO keyword value associated with this extension is "SIZE";
  71.  
  72.    (3) one optional parameter is allowed with this EHLO keyword value, a
  73.        decimal number indicating the fixed maximum message size in bytes
  74.        that the server will accept.  The syntax of the parameter is as
  75.        follows, using the augmented BNF notation of [2]:
  76.  
  77.            size-param ::= [1*DIGIT]
  78.  
  79.        A parameter value of 0 (zero) indicates that no fixed maximum
  80.        message size is in force.  If the parameter is omitted no
  81.        information is conveyed about the server's fixed maximum message
  82.        size;
  83.  
  84.    (4) one optional parameter using the keyword "SIZE" is added to the
  85.        MAIL FROM command.  The value associated with this parameter is a
  86.        decimal number indicating the size of the message that is to be
  87.        transmitted.  The syntax of the value is as follows, using the
  88.        augmented BNF notation of [2]:
  89.  
  90.            size-value ::= 1*20DIGIT
  91.  
  92.    (5) the maximum length of a MAIL FROM command line is increased by 26
  93.        characters by the possible addition of the SIZE keyword and
  94.        value;
  95.  
  96.    (6) no additional SMTP verbs are defined by this extension.
  97.  
  98.    The remainder of this memo specifies how support for the extension
  99.    affects the behavior of an SMTP client and server.
  100.  
  101. 4.  The Message Size Declaration service extension
  102.  
  103.    An SMTP server may have a fixed upper limit on message size.  Any
  104.    attempt by a client to transfer a message which is larger than this
  105.    fixed upper limit will fail.  In addition, a server normally has
  106.    limited space with which to store incoming messages.  Transfer of a
  107.    message may therefore also fail due to a lack of storage space, but
  108.    might succeed at a later time.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Klensin, et al              Standards Track                     [Page 2]
  115.  
  116. RFC 1870                 SMTP Size Declaration             November 1995
  117.  
  118.  
  119.    A client using the unextended SMTP protocol defined in [1], can only
  120.    be informed of such failures after transmitting the entire message to
  121.    the server (which discards the transferred message).  If, however,
  122.    both client and server support the Message Size Declaration service
  123.    extension, such conditions may be detected before any transfer is
  124.    attempted.
  125.  
  126.    An SMTP client wishing to relay a large content may issue the EHLO
  127.    command to start an SMTP session, to determine if the server supports
  128.    any of several service extensions.  If the server responds with code
  129.    250 to the EHLO command, and the response includes the EHLO keyword
  130.    value SIZE, then the Message Size Declaration extension is supported.
  131.  
  132.    If a numeric parameter follows the SIZE keyword value of the EHLO
  133.    response, it indicates the size of the largest message that the
  134.    server is willing to accept.  Any attempt by a client to transfer a
  135.    message which is larger than this limit will be rejected with a
  136.    permanent failure (552) reply code.
  137.  
  138.    A server that supports the Message Size Declaration extension will
  139.    accept the extended version of the MAIL command described below.
  140.    When supported by the server, a client may use the extended MAIL
  141.    command (instead of the MAIL command as defined in [1]) to declare an
  142.    estimate of the size of a message it wishes to transfer.  The server
  143.    may then return an appropriate error code if it determines that an
  144.    attempt to transfer a message of that size would fail.
  145.  
  146. 5.  Definitions
  147.  
  148.    The message size is defined as the number of octets, including CR-LF
  149.    pairs, but not the SMTP DATA command's terminating dot or doubled
  150.    quoting dots, to be transmitted by the SMTP client after receiving
  151.    reply code 354 to the DATA command.
  152.  
  153.    The fixed maximum message size is defined as the message size of the
  154.    largest message that a server is ever willing to accept.  An attempt
  155.    to transfer any message larger than the fixed maximum message size
  156.    will always fail.  The fixed maximum message size may be an
  157.    implementation artifact of the SMTP server, or it may be chosen by
  158.    the administrator of the server.
  159.  
  160.    The declared message size is defined as a client's estimate of the
  161.    message size for a particular message.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Klensin, et al              Standards Track                     [Page 3]
  171.  
  172. RFC 1870                 SMTP Size Declaration             November 1995
  173.  
  174.  
  175. 6.  The extended MAIL command
  176.  
  177.    The extended MAIL command is issued by a client when it wishes to
  178.    inform a server of the size of the message to be sent.  The extended
  179.    MAIL command is identical to the MAIL command as defined in [1],
  180.    except that a SIZE parameter appears after the address.
  181.  
  182.    The complete syntax of this extended command is defined in [5]. The
  183.    esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
  184.    the syntax for size-value shown above.
  185.  
  186.    The value associated with the SIZE parameter is a decimal
  187.    representation of the declared message size in octets.  This number
  188.    should include the message header, body, and the CR-LF sequences
  189.    between lines, but not the SMTP DATA command's terminating dot or
  190.    doubled quoting dots. Only one SIZE parameter may be specified in a
  191.    single MAIL command.
  192.  
  193.    Ideally, the declared message size is equal to the true message size.
  194.    However, since exact computation of the message size may be
  195.    infeasable, the client may use a heuristically-derived estimate.
  196.    Such heuristics should be chosen so that the declared message size is
  197.    usually larger than the actual message size. (This has the effect of
  198.    making the counting or non-counting of SMTP DATA dots largely an
  199.    academic point.)
  200.  
  201.    NOTE: Servers MUST NOT use the SIZE parameter to determine end of
  202.    content in the DATA command.
  203.  
  204. 6.1  Server action on receipt of the extended MAIL command
  205.  
  206.    Upon receipt of an extended MAIL command containing a SIZE parameter,
  207.    a server should determine whether the declared message size exceeds
  208.    its fixed maximum message size.  If the declared message size is
  209.    smaller than the fixed maximum message size, the server may also wish
  210.    to determine whether sufficient resources are available to buffer a
  211.    message of the declared message size and to maintain it in stable
  212.    storage, until the message can be delivered or relayed to each of its
  213.    recipients.
  214.  
  215.    A server may respond to the extended MAIL command with any of the
  216.    error codes defined in [1] for the MAIL command.  In addition, one of
  217.    the following error codes may be returned:
  218.  
  219.    (1) If the server currently lacks sufficient resources to accept a
  220.        message of the indicated size, but may be able to accept the
  221.        message at a later time, it responds with code "452 insufficient
  222.        system storage".
  223.  
  224.  
  225.  
  226. Klensin, et al              Standards Track                     [Page 4]
  227.  
  228. RFC 1870                 SMTP Size Declaration             November 1995
  229.  
  230.  
  231.    (2) If the indicated size is larger than the server's fixed maximum
  232.        message size, the server responds with code "552 message size
  233.        exceeds fixed maximium message size".
  234.  
  235.    A server is permitted, but not required, to accept a message which
  236.    is, in fact, larger than declared in the extended MAIL command, such
  237.    as might occur if the client employed a size-estimation heuristic
  238.    which was inaccurate.
  239.  
  240. 6.2  Client action on receiving response to extended MAIL command
  241.  
  242.    The client, upon receiving the server's response to the extended MAIL
  243.    command, acts as follows:
  244.  
  245.    (1) If the code "452 insufficient system storage" is returned, the
  246.        client should next send either a RSET command (if it wishes to
  247.        attempt to send other messages) or a QUIT command. The client
  248.        should then repeat the attempt to send the message to the server
  249.        at a later time.
  250.  
  251.    (2) If the code "552 message exceeds fixed maximum message size" is
  252.        received, the client should immediately send either a RSET command
  253.        (if it wishes to attempt to send additional messages), or a QUIT
  254.        command.  The client should then declare the message undeliverable
  255.        and return appropriate notification to the sender (if a sender
  256.        address was present in the MAIL command).
  257.  
  258.    A successful (250) reply code in response to the extended MAIL
  259.    command does not constitute an absolute guarantee that the message
  260.    transfer will succeed.  SMTP clients using the extended MAIL command
  261.    must still be prepared to handle both temporary and permanent error
  262.    reply codes (including codes 452 and 552), either immediately after
  263.    issuing the DATA command, or after transfer of the message.
  264.  
  265. 6.3  Messages larger than the declared size.
  266.  
  267.    Once a server has agreed (via the extended MAIL command) to accept a
  268.    message of a particular size, it should not return a 552 reply code
  269.    after the transfer phase of the DATA command, unless the actual size
  270.    of the message transferred is greater than the declared message size.
  271.    A server may also choose to accept a message which is somewhat larger
  272.    than the declared message size.
  273.  
  274.    A client is permitted to declare a message to be smaller than its
  275.    actual size.  However, in this case, a successful (250) reply code is
  276.    no assurance that the server will accept the message or has
  277.    sufficient resources to do so.  The server may reject such a message
  278.    after its DATA transfer.
  279.  
  280.  
  281.  
  282. Klensin, et al              Standards Track                     [Page 5]
  283.  
  284. RFC 1870                 SMTP Size Declaration             November 1995
  285.  
  286.  
  287. 6.4  Per-recipient rejection based on message size.
  288.  
  289.    A server that implements this extension may return a 452 or 552 reply
  290.    code in response to a RCPT command, based on its unwillingness to
  291.    accept a message of the declared size for a particular recipient.
  292.  
  293.    (1) If a 452 code is returned, the client may requeue the message for
  294.        later delivery to the same recipient.
  295.  
  296.    (2) If a 552 code is returned, the client may not requeue the message
  297.        for later delivery to the same recipient.
  298.  
  299. 7.  Minimal usage
  300.  
  301.    A "minimal" client may use this extension to simply compare its
  302.    (perhaps estimated) size of the message that it wishes to relay, with
  303.    the server's fixed maximum message size (from the parameter to the
  304.    SIZE keyword in the EHLO response), to determine whether the server
  305.    will ever accept the message.  Such an implementation need not
  306.    declare message sizes via the extended MAIL command.  However,
  307.    neither will it be able to discover temporary limits on message size
  308.    due to server resource limitations, nor per-recipient limitations on
  309.    message size.
  310.  
  311.    A minimal server that employs this service extension may simply use
  312.    the SIZE keyword value to inform the client of the size of the
  313.    largest message it will accept, or to inform the client that there is
  314.    no fixed limit on message size.  Such a server must accept the
  315.    extended MAIL command and return a 552 reply code if the client's
  316.    declared size exceeds its fixed size limit (if any), but it need not
  317.    detect "temporary" limitations on message size.
  318.  
  319.    The numeric parameter to the EHLO SIZE keyword is optional.  If the
  320.    parameter is omitted entirely it indicates that the server does not
  321.    advertise a fixed maximum message size.  A server that returns the
  322.    SIZE keyword with no parameter in response to the EHLO command may
  323.    not issue a positive (250) response to an extended MAIL command
  324.    containing a SIZE specification without first checking to see if
  325.    sufficient resources are available to transfer a message of the
  326.    declared size, and to retain it in stable storage until it can be
  327.    relayed or delivered to its recipients.  If possible, the server
  328.    should actually reserve sufficient storage space to transfer the
  329.    message.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Klensin, et al              Standards Track                     [Page 6]
  339.  
  340. RFC 1870                 SMTP Size Declaration             November 1995
  341.  
  342.  
  343. 8. Example
  344.  
  345.    The following example illustrates the use of size declaration with
  346.    some permanent and temporary failures.
  347.  
  348.    S: <wait for connection on TCP port 25>
  349.    C: <open connection to server>
  350.    S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
  351.    C: EHLO ymir.claremont.edu
  352.    S: 250-sigurd.innosoft.com
  353.    S: 250-EXPN
  354.    S: 250-HELP
  355.    S: 250 SIZE 1000000
  356.    C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
  357.    S: 250 Address Ok.
  358.    C: RCPT TO:<ned@innosoft.com>
  359.    S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
  360.    C: RCPT TO:<ned@ymir.claremont.edu>
  361.    S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
  362.    C: RCPT TO:<ned@hmcvax.claremont.edu>
  363.    S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
  364.    C: DATA
  365.    S: 354 Send message, ending in CRLF.CRLF.
  366.     ...
  367.    C: .
  368.    S: 250 Some recipients OK
  369.    C: QUIT
  370.    S: 221 Goodbye
  371.  
  372. 9. Security Considerations
  373.  
  374.    The size declaration extensions described in this memo can
  375.    conceivably be used to facilitate crude service denial attacks.
  376.    Specifically, both the information contained in the SIZE parameter
  377.    and use of the extended MAIL command make it somewhat quicker and
  378.    easier to devise an efficacious service denial attack.  However,
  379.    unless implementations are very weak, these extensions do not create
  380.    any vulnerability that has not always existed with SMTP. In addition,
  381.    no issues are addressed involving trusted systems and possible
  382.    release of information via the mechanisms described in this RFC.
  383.  
  384. 10.  Acknowledgements
  385.  
  386.    This document was derived from an earlier Working Group work in
  387.    progess contribution.  Jim Conklin, Dave Crocker, Neil Katin, Eliot
  388.    Lear, Marshall T. Rose, and Einar Stefferud provided extensive
  389.    comments in response to earlier works in progress of both this and
  390.    the previous memo.
  391.  
  392.  
  393.  
  394. Klensin, et al              Standards Track                     [Page 7]
  395.  
  396. RFC 1870                 SMTP Size Declaration             November 1995
  397.  
  398.  
  399. 11.  References
  400.  
  401.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  402.        USC/Information Sciences Institute, August 1982.
  403.  
  404.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  405.        Messages", STD 11, RFC 822, UDEL, August 1982.
  406.  
  407.    [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
  408.        Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
  409.  
  410.    [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
  411.        Headers", RFC 1522, University of Tennessee, September 1993.
  412.  
  413.    [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
  414.        "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
  415.        International, Inc., Dover Beach Consulting, Inc., Network
  416.        Management Associates, Inc., Brandenburg Consulting, November
  417.        1995.
  418.  
  419.    [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  420.        974, BBN, January 1986.
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Klensin, et al              Standards Track                     [Page 8]
  451.  
  452. RFC 1870                 SMTP Size Declaration             November 1995
  453.  
  454.  
  455. 12.  Chair, Editor, and Author Addresses
  456.  
  457.    John Klensin, WG Chair
  458.    MCI
  459.    2100 Reston Parkway
  460.    Reston, VA 22091
  461.  
  462.    Phone: +1 703 715-7361
  463.    Fax: +1 703 715-7436
  464.    EMail: klensin@mci.net
  465.  
  466.  
  467.    Ned Freed, Editor
  468.    Innosoft International, Inc.
  469.    1050 East Garvey Avenue South
  470.    West Covina, CA 91790
  471.    USA
  472.  
  473.    Phone: +1 818 919 3600
  474.    Fax: +1 818 919 3614
  475.    EMail: ned@innosoft.com
  476.  
  477.  
  478.    Keith Moore
  479.    Computer Science Dept.
  480.    University of Tennessee
  481.    107 Ayres Hall
  482.    Knoxville, TN 37996-1301
  483.    USA
  484.  
  485.    EMail: moore@cs.utk.edu
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Klensin, et al              Standards Track                     [Page 9]
  507.  
  508.