rfc3030.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

RFC 3030                      Binary ESMTP                 December 2000


   The syntax of the extended MAIL command is identical to the MAIL
   command in [RFC821], except that a BODY=BINARYMIME parameter and
   value MUST be added.  The complete syntax of this extended command is
   defined in [ESMTP].

   If a receiver-SMTP does not indicate support the BINARYMIME message
   format then the sender-SMTP MUST NOT, under any circumstances, send
   binary data.

   If the receiver-SMTP does not support BINARYMIME and the message to
   be sent is a MIME object with a binary encoding, a sender-SMTP has
   three options with which to forward the message.  First, if the
   receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and
   the content is amenable to being encoded in 8bit, the sender-SMTP may
   implement a gateway transformation to convert the message into valid
   8bit-encoded MIME.  Second, it may implement a gateway transformation
   to convert the message into valid 7bit-encoded MIME.  Third, it may
   treat this as a permanent error and handle it in the usual manner for
   delivery failures.  The specifics of MIME content-transfer-encodings,
   including transformations from Binary MIME to 8bit or 7bit MIME are
   not described by this RFC; the conversion is nevertheless constrained
   in the following ways:

      1. The conversion MUST cause no loss of information;  MIME
         transport encodings MUST be employed as needed to insure this
         is the case.

      2. The resulting message MUST be valid 7bit or 8bit MIME.  In
         particular, the transformation MUST NOT result in nested Base-
         64 or Quoted-Printable content-transfer-encodings.

   Note that at the time of this writing there are no mechanisms for
   converting a binary MIME object into an 8-bit MIME object.  Such a
   transformation will require the specification of a new MIME content-
   transfer-encoding.

   If the MIME message contains a "Binary" content-transfer-encoding and
   the BODY parameter does not indicate BINARYMIME, the message MUST be
   accepted.  The message SHOULD be returned to the sender with an
   appropriate DSN.  The message contents MAY be returned to the sender
   if the offending content can be mangled into a legal DSN structure.
   "Fixing" and forwarding the offending content is beyond the scope of
   this document.








Vaudreuil                   Standards Track                     [Page 7]

RFC 3030                      Binary ESMTP                 December 2000


4. Examples

4.1 Simple Chunking

   The following simple dialogue illustrates the use of the large
   message extension to send a short pseudo-RFC 822 message to one
   recipient using the CHUNKING extension:

   R: <wait for connection on TCP port 25>
   S: <open connection to server>
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250 CHUNKING
   S: MAIL FROM:<[e-mail]>
   R: 250 <[e-mail]> Sender ok
   S: RCPT TO:<[e-mail]>
   R: 250 <[e-mail]> Recipient ok
   S: BDAT 86 LAST
   S: To: [e-mail]<CR><LF>
   S: From: [e-mail]<CR><LF>
   S: Subject: This is a bodyless test message<CR><LF>
   R: 250 Message OK, 86 octets received
   S: QUIT
   R: 221 Goodbye

4.2 Pipelining BINARYMIME

   The following dialogue illustrates the use of the large message
   extension to send a BINARYMIME object to two recipients using the
   CHUNKING and PIPELINING extensions:

   R: <wait for connection on TCP port
   S: <open connection to server>
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING
   S: MAIL FROM:<[e-mail]> BODY=BINARYMIME
   S: RCPT TO:<[e-mail]>
   S: RCPT TO:<[e-mail]>
   R: 250 <[e-mail]>... Sender and BINARYMIME ok
   R: 250 <[e-mail]>... Recipient ok
   R: 250 <[e-mail]>... Recipient ok
   S: BDAT 100000
   S: (First 10000 octets of canonical MIME message data)



Vaudreuil                   Standards Track                     [Page 8]

RFC 3030                      Binary ESMTP                 December 2000


   S: BDAT 324
   S: (Remaining 324 octets of canonical MIME message data)
   S: BDAT 0 LAST
   R: 250 100000 octets received
   R: 250 324 octets received
   R: 250 Message OK, 100324 octets received
   S: QUIT
   R: 221 Goodbye

5. Security Considerations

   This extension is not known to present any additional security issues
   not already endemic to electronic mail and present in fully
   conforming implementations of [RFC821], or otherwise made possible by
   [MIME].

6. References

   [BINARY]  Vaudreuil, G., "SMTP Service Extensions for Transmission of
             Large and Binary MIME Messages", RFC 1830, August 1995.

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

   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
             Messages", STD 11, RFC 822, August 1982.

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

   [SUBMIT]  Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
             December 1998.

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

   [8BIT]    Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
             Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
             RFC 1652, July 1994.

   [PIPE]    Freed, N., "SMTP Service Extensions for Command
             Pipelining", RFC 2920, September 2000.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.




Vaudreuil                   Standards Track                     [Page 9]

RFC 3030                      Binary ESMTP                 December 2000


7. Author's Address

   Gregory M. Vaudreuil
   Lucent Technologies
   17080 Dallas Parkway
   Dallas, TX 75248-1905

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










































Vaudreuil                   Standards Track                    [Page 10]

RFC 3030                      Binary ESMTP                 December 2000


Appendix A - Changes from RFC 1830

   Numerous editorial changes including required intellectual property
   boilerplate and revised authors contact information

   Corrected the simple chunking example to use the correct number of
   bytes.  Updated the pipelining example to illustrate use of the BDAT
   0 LAST construct.











































Vaudreuil                   Standards Track                    [Page 11]

RFC 3030                      Binary ESMTP                 December 2000


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.



















Vaudreuil                   Standards Track                    [Page 12]