Network Working Group G. Vaudreuil
Request for Comments: 3030 Lucent Technologies
Obsolete: 1830 December 2000
Category: Standards Track
Network Working Group G. Vaudreuil
Request for Comments: 3030 Lucent Technologies
Obsolete: 1830 December 2000
Category: Standards Track
SMTP Service Extensions for Transmission of Large and Binary MIME Messages
用于传输大型和二进制MIME消息的SMTP服务扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (Multipurpose Internet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830.
此备忘录定义了SMTP（简单邮件传输协议）服务的两个扩展。第一个扩展使SMTP客户端和服务器能够协商使用数据命令的替代方法，称为“BDAT”，以便高效地发送大型MIME（多用途Internet邮件扩展）消息。第二个扩展利用BDAT命令允许协商发送采用二进制传输编码的MIME消息。本文件旨在更新和废弃RFC 1830。
Working Group Summary
工作组摘要
This protocol is not the product of an IETF working group, however the specification resulted from discussions within the ESMTP working group. The resulting protocol documented in RFC 1830 was classified as experimental at that time due to questions about the robustness of the Binary Content-Transfer-Encoding deployed in then existent MIME implementations. As MIME has matured and other uses of the Binary Content-Transfer-Encoding have been deployed, these concerns have been allayed. With this document, Binary ESMTP is expected to become standards-track.
本协议不是IETF工作组的产品，但是该规范是ESMTP工作组内部讨论的结果。由于当时存在的MIME实现中部署的二进制内容传输编码的健壮性问题，RFC1830中记录的最终协议当时被归类为实验协议。随着MIME的成熟和二进制内容传输编码的其他用途的部署，这些担忧已经得到缓解。通过本文档，二进制ESMTP有望成为标准跟踪。
Document Conventions
文件惯例
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Table of Contents
目录
1. Overview ................................................... 2
2. Framework for the Large Message Extensions ................. 3
3. Framework for the Binary Service Extension ................. 5
4. Examples ................................................... 8
4.1 Simple Chunking .......................................... 8
4.2 Pipelining BINARYMIME .................................... 8
5. Security Considerations .................................... 9
6. References ................................................. 9
7. Author's Address ........................................... 10
8. Appendix A - Changes from RFC 1830 ......................... 11
9. Full Copyright Statement ................................... 12
1. Overview ................................................... 2
2. Framework for the Large Message Extensions ................. 3
3. Framework for the Binary Service Extension ................. 5
4. Examples ................................................... 8
4.1 Simple Chunking .......................................... 8
4.2 Pipelining BINARYMIME .................................... 8
5. Security Considerations .................................... 9
6. References ................................................. 9
7. Author's Address ........................................... 10
8. Appendix A - Changes from RFC 1830 ......................... 11
9. Full Copyright Statement ................................... 12
The MIME extensions to the Internet message format provides for the transmission of many kinds of data that were previously unsupported in Internet mail. Anticipating the need to transport the new media more efficiently, the SMTP protocol has been extended to provide transport for new message types. RFC 1652 defines one such extension for the transmission of unencoded 8-bit MIME messages [8BIT]. This service extension permits the receiver SMTP to declare support for 8-bit body parts and the sender to request 8-bit transmission of a particular message.
Internet消息格式的MIME扩展提供了以前Internet邮件中不支持的多种数据的传输。考虑到更高效地传输新媒体的需要，SMTP协议已被扩展以提供新消息类型的传输。RFC1652定义了一个这样的扩展，用于传输未编码的8位MIME消息[8BIT]。此服务扩展允许收件人SMTP声明对8位正文部分的支持，并允许发件人请求特定邮件的8位传输。
One expected result of the use of MIME is that the Internet mail system will be expected to carry very large mail messages. In such transactions, there is a performance-based desire to eliminate the requirement that the message be scanned for "CR LF . CR LF" sequences upon sending and receiving to detect the end of message.
使用MIME的一个预期结果是，互联网邮件系统将承载非常大的邮件消息。在这种事务中，基于性能的愿望是消除在发送和接收时扫描消息以检测消息结束的“CR-LF.CR-LF”序列的要求。
Independent of the need to send large messages, Internet mail is increasingly multimedia. There is a need to avoid the overhead of base64 and quoted-printable encoding of binary objects sent using the MIME message format over SMTP between hosts that support binary message processing.
独立于发送大量信息的需要，互联网邮件越来越多媒体化。需要避免在支持二进制消息处理的主机之间通过SMTP使用MIME消息格式发送的二进制对象的base64和引用的可打印编码的开销。
This memo uses the mechanism defined in [ESMTP] to define two extensions to the SMTP service whereby an SMTP server ("receiver-SMTP") may declare support for the message chunking transmission mode and support for the reception of Binary messages, which the SMTP client ("sender-SMTP") is then free to use.
此备忘录使用[ESMTP]中定义的机制来定义SMTP服务的两个扩展，SMTP服务器（“接收方SMTP”）可以声明支持邮件分块传输模式，并支持接收二进制邮件，然后SMTP客户端（“发送方SMTP”）可以自由使用。
The following service extension is hereby defined:
特此定义以下服务扩展：
1) The name of the data chunking service extension is "CHUNKING".
1) 数据分块服务扩展名为“分块”。
2) The EHLO keyword value associated with this extension is "CHUNKING".
2) 与此扩展关联的EHLO关键字值为“CHUNKING”。
3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA" command of [RFC821]. The BDAT verb takes two arguments. The first argument indicates the length, in octets, of the binary data chunk. The second optional argument indicates that the data chunk is the last.
3) 新的SMTP谓词BDAT被定义为[RFC821]的“数据”命令的替代命令。BDAT动词有两个参数。第一个参数表示二进制数据块的长度（以八位字节为单位）。第二个可选参数指示数据块是最后一个。
bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
chunk-size ::= 1*DIGIT
end-marker ::= "LAST"
bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
chunk-size ::= 1*DIGIT
end-marker ::= "LAST"
4) This extension may be used for SMTP message submission. [Submit]
4) 此扩展名可用于SMTP邮件提交。[提交]
5) Servers that offer the BDAT extension MUST continue to support the regular SMTP DATA command. Clients are free to use DATA to transfer appropriately encoded to servers that support the CHUNKING extension if they wish to do so.
5) 提供BDAT扩展的服务器必须继续支持常规SMTP数据命令。如果客户机愿意，他们可以自由地使用数据将经过适当编码的数据传输到支持分块扩展的服务器。
The CHUNKING service extension enables the use of the BDAT alternative to the DATA command. This extension can be used for any message, whether 7-bit, 8BITMIME or BINARYMIME.
分块服务扩展支持使用BDAT替代DATA命令。此扩展可用于任何消息，无论是7位、8位MIME还是二进制MIME。
When a sender-SMTP wishes to send (using the MAIL command) a large message using the CHUNKING extension, it first issues the EHLO command to the receiver-SMTP. If the receiver-SMTP responds with code 250 to the EHLO command and the response includes the EHLO keyword value CHUNKING, then the receiver-SMTP is indicating that it supports the BDAT command and will accept the sending of messages in chunks.
当发送方SMTP希望（使用MAIL命令）使用分块扩展发送大邮件时，它首先向接收方SMTP发出EHLO命令。如果接收方SMTP以代码250响应EHLO命令，且响应包含EHLO关键字值分块，则接收方SMTP表示它支持BDAT命令，并将接受分块发送消息。
After all MAIL and RCPT responses are collected and processed, the message is sent using a series of BDAT commands. The BDAT command takes one required argument, the exact length of the data segment in
收集和处理所有邮件和RCPT响应后，使用一系列BDAT命令发送消息。BDAT命令接受一个必需的参数，即数据段的精确长度
octets. The message data is sent immediately after the trailing <CR> <LF> of the BDAT command line. Once the receiver-SMTP receives the specified number of octets, it will return a 250 reply code.
八位组。消息数据在BDAT命令行的尾部<CR><LF>之后立即发送。一旦接收方SMTP收到指定数量的八位字节，它将返回250个应答码。
The optional LAST parameter on the BDAT command indicates that this is the last chunk of message data to be sent. The last BDAT command MAY have a byte-count of zero indicating there is no additional data to be sent. Any BDAT command sent after the BDAT LAST is illegal and MUST be replied to with a 503 "Bad sequence of commands" reply code. The state resulting from this error is indeterminate. A RSET command MUST be sent to clear the transaction before continuing.
BDAT命令上可选的最后一个参数表示这是要发送的最后一个消息数据块。最后一个BDAT命令的字节计数可能为零，表示没有要发送的其他数据。在BDAT LAST之后发送的任何BDAT命令都是非法的，必须使用503“命令序列错误”回复代码进行回复。此错误导致的状态不确定。在继续之前，必须发送RSET命令以清除事务。
A 250 response MUST be sent to each successful BDAT data block within a mail transaction. If a failure occurs after a BDAT command is received, the receiver-SMTP MUST accept and discard the associated message data before sending the appropriate 5XX or 4XX code. If a 5XX or 4XX code is received by the sender-SMTP in response to a BDAT chunk, the transaction should be considered failed and the sender-SMTP MUST NOT send any additional BDAT segments. If the receiver-SMTP has declared support for command pipelining [PIPE], the receiver SMTP MUST be prepared to accept and discard additional BDAT chunks already in the pipeline after the failed BDAT.
必须向邮件事务中每个成功的BDAT数据块发送250响应。如果在收到BDAT命令后发生故障，则在发送相应的5XX或4XX代码之前，接收方SMTP必须接受并放弃关联的邮件数据。如果发件人SMTP收到5XX或4XX代码以响应BDAT区块，则应认为事务失败，并且发件人SMTP不得发送任何其他BDAT段。如果接收方SMTP已声明支持命令管道[PIPE]，则接收方SMTP必须准备接受和放弃失败的BDAT后管道中已存在的其他BDAT块。
Note: An error on the receiver-SMTP such as disk full or imminent shutdown can only be reported after the BDAT segment has been received. It is therefore important to choose a reasonable chunk size given the expected end-to-end bandwidth.
注意：只有在收到BDAT段后，才能报告SMTP接收器上的错误，如磁盘已满或即将关闭。因此，考虑到预期的端到端带宽，选择合理的块大小非常重要。
Note: Because the receiver-SMTP does not acknowledge the BDAT command before the message data is sent, it is important to send the BDAT only to systems that have declared their capability to accept BDAT commands. Illegally sending a BDAT command and associated message data to a non-CHUNKING capable system will result in the receiver-SMTP parsing the associated message data as if it were a potentially very long, ESMTP command line containing binary data.
注意：由于收件人SMTP在发送消息数据之前不确认BDAT命令，因此必须仅将BDAT发送给已声明能够接受BDAT命令的系统。非法将BDAT命令和关联的消息数据发送到不支持分块的系统将导致接收方SMTP解析关联的消息数据，就好像它是包含二进制数据的可能非常长的ESMTP命令行一样。
The resulting state from a failed BDAT command is indeterminate. A RSET command MUST be issued to clear the transaction before additional commands may be sent. The RSET command, when issued after the first BDAT and before the BDAT LAST, clears all segments sent during that transaction and resets the session.
失败的BDAT命令的结果状态不确定。必须发出RSET命令以清除事务，然后才能发送其他命令。在第一次BDAT之后和最后一次BDAT之前发出RSET命令时，将清除该事务期间发送的所有段，并重置会话。
DATA and BDAT commands cannot be used in the same transaction. If a DATA statement is issued after a BDAT for the current transaction, a 503 "Bad sequence of commands" MUST be issued. The state resulting from this error is indeterminate. A RSET command MUST be sent to
DATA和BDAT命令不能在同一事务中使用。如果在当前事务的BDAT之后发出DATA语句，则必须发出503“错误命令序列”。此错误导致的状态不确定。必须向发送RSET命令
clear the transaction before continuing. There is no prohibition on using DATA and BDAT in the same session, so long as they are not mixed in the same transaction.
在继续之前清除事务。不禁止在同一会话中使用数据和BDAT，只要它们不在同一事务中混合。
The local storage size of a message may not accurately reflect the actual size of the message sent due to local storage conventions. In particular, text messages sent with the BDAT command MUST be sent in the canonical MIME format with lines delimited with a <CR><LF>. It may not be possible to convert the entire message to the canonical format at once. CHUNKING provides a mechanism to convert the message to canonical form, accurately count the bytes, and send the message a single chunk at a time.
由于本地存储约定，消息的本地存储大小可能无法准确反映发送的消息的实际大小。特别是，使用BDAT命令发送的文本消息必须以规范的MIME格式发送，并以<CR><LF>分隔行。可能无法立即将整个消息转换为规范格式。分块提供了一种机制，可以将消息转换为规范形式，准确地计算字节数，并一次发送一个分块消息。
Note: Correct byte counting is essential. If the sender-SMTP indicates a chunk-size larger than the actual chunk-size, the receiver-SMTP will continue to wait for the remainder of the data or when using streaming, will read the subsequent command as additional message data. In the case where a portion of the previous command was read as data, the parser will return a syntax error when the incomplete command is read.
注意：正确的字节计数至关重要。如果发送方SMTP指示的区块大小大于实际区块大小，则接收方SMTP将继续等待剩余的数据，或者在使用流传输时，将后续命令作为附加邮件数据读取。在前一个命令的一部分被读取为数据的情况下，当读取不完整的命令时，解析器将返回语法错误。
If the sender-SMTP indicates a chunk-size smaller than the actual chunk-size, the receiver-SMTP will interpret the remainder of the message data as invalid commands. Note that the remainder of the message data may be binary and as such lexicographical parsers MUST be prepared to receive, process, and reject lines of arbitrary octets.
如果发件人SMTP指示的数据块大小小于实际数据块大小，则收件人SMTP会将邮件数据的其余部分解释为无效命令。注意，消息数据的其余部分可能是二进制的，因此词典解析器必须准备好接收、处理和拒绝任意八位字节的行。
The following service extension is hereby defined:
特此定义以下服务扩展：
1) The name of the binary service extension is "BINARYMIME".
1) 二进制服务扩展名为“BINARYMIME”。
2) The EHLO keyword value associated with this extension is "BINARYMIME".
2) 与此扩展关联的EHLO关键字值为“BINARYMIME”。
3) The BINARYMIME service extension can only be used with the "CHUNKING" service extension.
3) BINARYMIME服务扩展只能与“分块”服务扩展一起使用。
4) No parameter is used with the BINARYMIME keyword.
4) 没有参数与BINARYMIME关键字一起使用。
5) [8BIT] defines the BODY parameter for the MAIL command. This extension defines an additional value for the BODY parameter, "BINARYMIME". The value "BINARYMIME" associated with this parameter indicates that this message is a Binary MIME message (in
5) [8BIT]定义邮件命令的正文参数。此扩展为主体参数“BINARYMIME”定义了一个附加值。与此参数关联的值“BINARYMIME”表示此消息是二进制MIME消息（在
strict compliance with [MIME]) with arbitrary octet content being sent. The revised syntax of the value is as follows, using the ABNF notation of [RFC822]:
严格遵守[MIME]），发送任意八位字节内容。使用[RFC822]的ABNF符号，修改后的值语法如下：
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
6) No new verbs are defined for the BINARYMIME extension.
6) 没有为BINARYMIME扩展定义新的谓词。
7) This extension may be used for SMTP message submission. [Submit]
7) 此扩展名可用于SMTP邮件提交。[提交]
8) The maximum length of a MAIL FROM command line is increased by 16 characters by the possible addition of the BODY=BINARYMIME keyword and value;.
8) 通过可能添加BODY=BINARYMIME关键字和value；，来自命令行的邮件的最大长度增加了16个字符；。
A sender-SMTP may request that a binary MIME message be sent without transport encoding by sending a BODY parameter with a value of "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a MAIL command with the BINARYMIME body-value, it agrees to preserve all bits in each octet passed using the BDAT command. Once a receiver-SMTP supporting the BINARYMIME service extension accepts a message containing binary material, the receiver-SMTP MUST deliver or relay the message in such a way as to preserve all bits in each octet.
发件人SMTP可以通过使用MAIL命令发送值为“BINARYMIME”的正文参数，请求在不使用传输编码的情况下发送二进制MIME消息。当接收方SMTP接受具有BINARYMIME正文值的邮件命令时，它同意保留使用BDAT命令传递的每个八位字节中的所有位。一旦支持BINARYMIME服务扩展的接收方SMTP接受包含二进制内容的消息，接收方SMTP必须以保留每个八位字节中所有位的方式传递或中继该消息。
BINARYMIME cannot be used with the DATA command. If a DATA command is issued after a MAIL command containing the body-value of "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent. The resulting state from this error condition is indeterminate and the transaction MUST be reset with the RSET command.
BINARYMIME不能与DATA命令一起使用。如果在包含“BINARYMIME”主体值的邮件命令之后发出数据命令，则必须发送503“命令序列错误”响应。此错误条件的结果状态不确定，必须使用RSET命令重置事务。
It is especially important when using BINARYMIME to ensure that the
MIME message itself is properly formed. In particular, it is
essential that text be canonically encoded with each line properly
terminated with <CR><LF>. Any transformation of text into non-
canonical MIME to observe local storage conventions MUST be reversed
before sending as BINARYMIME. Some line-oriented shortcuts will
break if used with BINARYMIME. A sender-SMTP MUST use the canonical
encoding for a given MIME content-type. In particular, text/* MUST
be sent with <CR><LF> terminated lines.
It is especially important when using BINARYMIME to ensure that the
MIME message itself is properly formed. In particular, it is
essential that text be canonically encoded with each line properly
terminated with <CR><LF>. Any transformation of text into non-
canonical MIME to observe local storage conventions MUST be reversed
before sending as BINARYMIME. Some line-oriented shortcuts will
break if used with BINARYMIME. A sender-SMTP MUST use the canonical
encoding for a given MIME content-type. In particular, text/* MUST
be sent with <CR><LF> terminated lines.
Note: Although CR and LF do not necessarily represent ends of text lines in BDAT chunks and use of the binary transfer encoding is allowed, the RFC 2781 prohibition against using a UTF-16 charset within the text top-level media type remains.
注意：尽管CR和LF不一定表示BDAT块中文本行的结尾，并且允许使用二进制传输编码，但RFC 2781禁止在文本顶级媒体类型中使用UTF-16字符集。
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].
扩展邮件命令的语法与[RFC821]中的邮件命令相同，只是必须添加BODY=BINARYMIME参数和值。此扩展命令的完整语法在[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.
如果收件人SMTP不表示支持二进制MIME消息格式，则发件人SMTP在任何情况下都不得发送二进制数据。
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:
如果收件人SMTP不支持BINARYMIME，并且要发送的邮件是具有二进制编码的MIME对象，则发件人SMTP有三个转发邮件的选项。首先，如果接收方SMTP支持8位MIMEtransport扩展[8位]，并且内容可以用8位编码，则发送方SMTP可以实施网关转换，将消息转换为有效的8位编码MIME。其次，它可以实现网关转换，将消息转换为有效的7bit编码MIME。第三，它可能会将此视为永久性错误，并以交付失败时的通常方式进行处理。MIME内容传输编码的细节，包括从二进制MIME到8位或7位MIME的转换，不在本RFC中描述；然而，转换受到以下方面的限制：
1. The conversion MUST cause no loss of information; MIME transport encodings MUST be employed as needed to insure this is the case.
1. 转换不得导致信息丢失；必须根据需要使用MIME传输编码来确保这种情况。
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.
2. 生成的消息必须是有效的7位或8位MIME。特别是，转换不得导致嵌套的Base-64或引用的可打印内容传输编码。
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.
请注意，在撰写本文时，没有将二进制MIME对象转换为8位MIME对象的机制。这种转换需要指定新的MIME内容传输编码。
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.
如果MIME消息包含“二进制”内容传输编码，并且正文参数不指示BINARYMIME，则必须接受该消息。应使用适当的DSN将邮件返回给发件人。如果有问题的内容可能被篡改成合法的DSN结构，则可以将邮件内容返回给发件人。“修复”和转发有问题的内容超出了本文档的范围。
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:
下面的简单对话说明了如何使用大消息扩展插件，使用分块扩展插件向一个收件人发送短伪RFC 822消息：
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:<Sam@Random.com>
R: 250 <Sam@Random.com> Sender ok
S: RCPT TO:<Susan@Random.com>
R: 250 <Susan@random.com> Recipient ok
S: BDAT 86 LAST
S: To: Susan@random.com<CR><LF>
S: From: Sam@random.com<CR><LF>
S: Subject: This is a bodyless test message<CR><LF>
R: 250 Message OK, 86 octets received
S: QUIT
R: 221 Goodbye
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:<Sam@Random.com>
R: 250 <Sam@Random.com> Sender ok
S: RCPT TO:<Susan@Random.com>
R: 250 <Susan@random.com> Recipient ok
S: BDAT 86 LAST
S: To: Susan@random.com<CR><LF>
S: From: Sam@random.com<CR><LF>
S: Subject: This is a bodyless test message<CR><LF>
R: 250 Message OK, 86 octets received
S: QUIT
R: 221 Goodbye
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:
下面的对话框演示了如何使用大消息扩展，使用分块和管道扩展将BINARYMIME对象发送给两个收件人：
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:<ned@ymir.claremont.edu> BODY=BINARYMIME
S: RCPT TO:<gvaudre@cnri.reston.va.us>
S: RCPT TO:<jstewart@cnri.reston.va.us>
R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
S: BDAT 100000
S: (First 10000 octets of canonical MIME message data)
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:<ned@ymir.claremont.edu> BODY=BINARYMIME
S: RCPT TO:<gvaudre@cnri.reston.va.us>
S: RCPT TO:<jstewart@cnri.reston.va.us>
R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
S: BDAT 100000
S: (First 10000 octets of canonical MIME message data)
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
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
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].
已知此扩展不会出现任何其他安全问题，这些问题不是电子邮件特有的，也不会出现在[RFC821]的完全一致性实现中，或者[MIME]可能出现的。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[BINARY]Vaudreuil，G.“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 1830，1995年8月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Borenstein，N.和N.Freed，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提交]Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[ESMTP]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“SMTP服务扩展”，RFC 18691995年11月。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BIT]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“8BIT MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", RFC 2920, September 2000.
[PIPE]Freed，N.，“用于命令管道的SMTP服务扩展”，RFC 2920，2000年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905
Gregory M.Vaudreuil-Lucent Technologies 17080达拉斯公园路德克萨斯州达拉斯75248-1905
Phone/Fax: +1-972-733-2722
EMail: GregV@ieee.org
Phone/Fax: +1-972-733-2722
EMail: GregV@ieee.org
Appendix A - Changes from RFC 1830
附录A-对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.
更正了简单分块示例以使用正确的字节数。更新了管道示例以说明BDAT 0 LAST构造的使用。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。