rfc2920.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 508 行 · 第 1/2 页

   S: 250 Innosoft.com
   C: MAIL FROM:<[e-mail]>
   S: 250 sender <[e-mail]> OK
   C: RCPT TO:<[e-mail]>
   S: 250 recipient <[e-mail]> OK
   C: RCPT TO:<[e-mail]>
   S: 250 recipient <[e-mail]> OK
   C: RCPT TO:<[e-mail]>
   S: 250 recipient <[e-mail]> OK
   C: DATA
   S: 354 enter mail, end with line containing only "."
    ...
   C: .
   S: 250 message sent
   C: QUIT
   S: 221 goodbye

   The client waits for a server response a total of 9 times in this
   simple example. But if pipelining is employed the following dialogue
   is possible:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready



Freed                       Standards Track                     [Page 5]

RFC 2920              SMTP for Command Pipelining         September 2000


   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: DATA
   S: 250 sender <[e-mail]> OK
   S: 250 recipient <[e-mail]> OK
   S: 250 recipient <[e-mail]> OK
   S: 250 recipient <[e-mail]> OK
   S: 354 enter mail, end with line containing only "."
    ...
   C: .
   C: QUIT
   S: 250 message sent
   S: 221 goodbye

   The total number of turnarounds has been reduced from 9 to 4.

   The next example illustrates one possible form of behavior when
   pipelining is used and all recipients are rejected:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready
   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: DATA
   S: 250 sender <[e-mail]> OK
   S: 550 remote mail to <[e-mail]> not allowed
   S: 550 remote mail to <[e-mail]> not allowed
   S: 554 no valid recipients given
   C: QUIT
   S: 221 goodbye

   The client SMTP waits for the server 4 times here as well. If the
   server SMTP does not check for at least one valid recipient prior to
   accepting the DATA command, the following dialogue would result:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready



Freed                       Standards Track                     [Page 6]

RFC 2920              SMTP for Command Pipelining         September 2000


   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: RCPT TO:<[e-mail]>
   C: DATA
   S: 250 sender <[e-mail]> OK
   S: 550 remote mail to <[e-mail]> not allowed
   S: 550 remote mail to <[e-mail]> not allowed
   S: 354 enter mail, end with line containing only "."
   C: .
   C: QUIT
   S: 554 no valid recipients
   S: 221 goodbye

5.  Security Considerations

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

6.  Acknowledgements

   This document is based on the SMTP service extension model
   presented in RFC 1425. Marshall Rose's description of SMTP
   command pipelining in his book "The Internet Message" also
   served as a source of inspiration for this extension.

7.  References

   [RFC-821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.

   [RFC-1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, October, 1989.

   [RFC-1854] Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 1854, October 1995.

   [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
              Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
              November 1995.

   [RFC-2197] Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 2197, September 1997.





Freed                       Standards Track                     [Page 7]

RFC 2920              SMTP for Command Pipelining         September 2000


8.  Author's Address

   Ned Freed
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790
   USA

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

   This document is a product of work done by the Internet Engineering
   Task Force Working Group on Messaging Extensions, Alan Cargille,
   chair.




































Freed                       Standards Track                     [Page 8]

RFC 2920              SMTP for Command Pipelining         September 2000


9.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

















Freed                       Standards Track                     [Page 9]