rfc1870.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

       and return appropriate notification to the sender (if a sender
       address was present in the MAIL command).

   A successful (250) reply code in response to the extended MAIL
   command does not constitute an absolute guarantee that the message
   transfer will succeed.  SMTP clients using the extended MAIL command
   must still be prepared to handle both temporary and permanent error
   reply codes (including codes 452 and 552), either immediately after
   issuing the DATA command, or after transfer of the message.

6.3  Messages larger than the declared size.

   Once a server has agreed (via the extended MAIL command) to accept a
   message of a particular size, it should not return a 552 reply code
   after the transfer phase of the DATA command, unless the actual size
   of the message transferred is greater than the declared message size.
   A server may also choose to accept a message which is somewhat larger
   than the declared message size.

   A client is permitted to declare a message to be smaller than its
   actual size.  However, in this case, a successful (250) reply code is
   no assurance that the server will accept the message or has
   sufficient resources to do so.  The server may reject such a message
   after its DATA transfer.



Klensin, et al              Standards Track                     [Page 5]

RFC 1870                 SMTP Size Declaration             November 1995


6.4  Per-recipient rejection based on message size.

   A server that implements this extension may return a 452 or 552 reply
   code in response to a RCPT command, based on its unwillingness to
   accept a message of the declared size for a particular recipient.

   (1) If a 452 code is returned, the client may requeue the message for
       later delivery to the same recipient.

   (2) If a 552 code is returned, the client may not requeue the message
       for later delivery to the same recipient.

7.  Minimal usage

   A "minimal" client may use this extension to simply compare its
   (perhaps estimated) size of the message that it wishes to relay, with
   the server's fixed maximum message size (from the parameter to the
   SIZE keyword in the EHLO response), to determine whether the server
   will ever accept the message.  Such an implementation need not
   declare message sizes via the extended MAIL command.  However,
   neither will it be able to discover temporary limits on message size
   due to server resource limitations, nor per-recipient limitations on
   message size.

   A minimal server that employs this service extension may simply use
   the SIZE keyword value to inform the client of the size of the
   largest message it will accept, or to inform the client that there is
   no fixed limit on message size.  Such a server must accept the
   extended MAIL command and return a 552 reply code if the client's
   declared size exceeds its fixed size limit (if any), but it need not
   detect "temporary" limitations on message size.

   The numeric parameter to the EHLO SIZE keyword is optional.  If the
   parameter is omitted entirely it indicates that the server does not
   advertise a fixed maximum message size.  A server that returns the
   SIZE keyword with no parameter in response to the EHLO command may
   not issue a positive (250) response to an extended MAIL command
   containing a SIZE specification without first checking to see if
   sufficient resources are available to transfer a message of the
   declared size, and to retain it in stable storage until it can be
   relayed or delivered to its recipients.  If possible, the server
   should actually reserve sufficient storage space to transfer the
   message.








Klensin, et al              Standards Track                     [Page 6]

RFC 1870                 SMTP Size Declaration             November 1995


8. Example

   The following example illustrates the use of size declaration with
   some permanent and temporary failures.

   S: <wait for connection on TCP port 25>
   C: <open connection to server>
   S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
   C: EHLO ymir.claremont.edu
   S: 250-sigurd.innosoft.com
   S: 250-EXPN
   S: 250-HELP
   S: 250 SIZE 1000000
   C: MAIL FROM:<[e-mail]> SIZE=500000
   S: 250 Address Ok.
   C: RCPT TO:<[e-mail]>
   S: 250 [e-mail] OK; can accomodate 500000 byte message
   C: RCPT TO:<[e-mail]>
   S: 552 Channel size limit exceeded: [e-mail]
   C: RCPT TO:<[e-mail]>
   S: 452 Insufficient channel storage: [e-mail]
   C: DATA
   S: 354 Send message, ending in CRLF.CRLF.
    ...
   C: .
   S: 250 Some recipients OK
   C: QUIT
   S: 221 Goodbye

9. Security Considerations

   The size declaration extensions described in this memo can
   conceivably be used to facilitate crude service denial attacks.
   Specifically, both the information contained in the SIZE parameter
   and use of the extended MAIL command make it somewhat quicker and
   easier to devise an efficacious service denial attack.  However,
   unless implementations are very weak, these extensions do not create
   any vulnerability that has not always existed with SMTP. In addition,
   no issues are addressed involving trusted systems and possible
   release of information via the mechanisms described in this RFC.

10.  Acknowledgements

   This document was derived from an earlier Working Group work in
   progess contribution.  Jim Conklin, Dave Crocker, Neil Katin, Eliot
   Lear, Marshall T. Rose, and Einar Stefferud provided extensive
   comments in response to earlier works in progress of both this and
   the previous memo.



Klensin, et al              Standards Track                     [Page 7]

RFC 1870                 SMTP Size Declaration             November 1995


11.  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 1521, Bellcore, Innosoft, September 1993.

   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
       Headers", RFC 1522, University of Tennessee, September 1993.

   [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
       "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
       International, Inc., Dover Beach Consulting, Inc., Network
       Management Associates, Inc., Brandenburg Consulting, November
       1995.

   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, BBN, January 1986.





























Klensin, et al              Standards Track                     [Page 8]

RFC 1870                 SMTP Size Declaration             November 1995


12.  Chair, Editor, and Author Addresses

   John Klensin, WG Chair
   MCI
   2100 Reston Parkway
   Reston, VA 22091

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Ned Freed, Editor
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Keith Moore
   Computer Science Dept.
   University of Tennessee
   107 Ayres Hall
   Knoxville, TN 37996-1301
   USA

   EMail: [e-mail]




















Klensin, et al              Standards Track                     [Page 9]