rfc1830.txt

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


RFC 1830           Binary and Large Message Transport        August 1995


      <LF>.  Any transformation of text into non-canonical MIME to
      observe local storage conventions must be reversed before sending
      as BINARYMIME.  The usual line-oriented shortcuts will break if
      used with BINARYMIME.

   The syntax of the extended MAIL command is identical to the MAIL
   command in [RFC821], except that a BODY parameter must appear after
   the address.  The complete syntax of this extended command is defined
   in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value
   is given by the syntax for body-value in [ESMTP].

   If a receiver SMTP does not support the BINARYMIME message format
   (either by not responding with code 250 to the EHLO command, or by
   rejecting the BINARYMIME parameter to the MAIL FROM command, then the
   client SMTP must not, under any circumstances, send binary data using
   the DATA or BDAT commands.

   If the receiver-SMTP does not support BINARYMIME and the message
   content is a MIME object with a binary encoding, a client SMTP has
   two options in this case: first, it may implement a gateway
   transformation to convert the message into valid 7bit encoded MIME,
   or second, it may treat this as a permanent error and handle it in
   the usual manner for delivery failures.  The specifics of the
   transformation from Binary MIME to 7bit MIME are not described by
   this RFC; the conversion is nevertheless constrained in the following
   ways:

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

     o  The resulting message must be valid 7bit MIME.

   As of present there are no mechanisms for converting a binary MIME
   object into a 8 bit-MIME object.  Such a transformation will require
   the specification of a new MIME content-transfer-encoding, the
   standardization of which is discouraged by [MIME].














Vaudreuil                     Experimental                      [Page 5]

RFC 1830           Binary and Large Message Transport        August 1995


5. Examples

5.1 Simple Chunking

   The following simple dialogue illustrates the use of the large
   message extension to send a short psudo-RFC822 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 69 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, 69 octets received
          S: QUIT
          R: 221 Goodbye

5.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 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-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



Vaudreuil                     Experimental                      [Page 6]

RFC 1830           Binary and Large Message Transport        August 1995


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

6. Security Considerations

   This RFC does not discuss security issues and is not believed to
   raise any security issues not already endemic in electronic mail and
   present in fully conforming implementations of [RFC821], or otherwise
   made possible by [MIME].

7. Acknowledgments

   This document is the result of numerous discussions in the IETF SMTP
   Extensions Working Group and in particular due to the continued
   advocacy of "chunking" by Neil Katin.

8. References

     [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
        821, USC/Information Sciences Institute, August 1982.

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

     [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
        Extensions", RFC 1521, Bellcore, Innosoft, June 1992.

     [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
        Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
        1425, United Nations University, Innosoft International,
        Inc., Dover Beach Consulting, Inc., Network Management
        Associates, Inc., The Branch Office, February 1993.

     [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
        Stefferud, E., and D. Crocker, "SMTP Service Extension for
        8bit-MIMEtransport" RFC 1426, United Nations University,
        Innosoft International, Inc., Dover Beach Consulting, Inc.,
        Network Management Associates, Inc., The Branch Office,
        February 1993.

     [PIPE] Freed, N., "SMTP Service Extensions for Command
        Pipelining", Innosoft International, Work in Progress.




Vaudreuil                     Experimental                      [Page 7]

RFC 1830           Binary and Large Message Transport        August 1995


9. Author's Address

   Gregory M. Vaudreuil
   Octel Network Services
   17060 Dallas Parkway
   Suite 214
   Dallas, TX 75248-1905

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









































Vaudreuil                     Experimental                      [Page 8]