Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 6152
STD: 71 N. Freed
Obsoletes: 1652 Oracle
Category: Standards Track M. Rose
ISSN: 2070-1721 Dover Beach Consulting, Inc.
D. Crocker, Ed.
Brandenburg InternetWorking
March 2011
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 6152
STD: 71 N. Freed
Obsoletes: 1652 Oracle
Category: Standards Track M. Rose
ISSN: 2070-1721 Dover Beach Consulting, Inc.
D. Crocker, Ed.
Brandenburg InternetWorking
March 2011
SMTP Service Extension for 8-bit MIME Transport
用于8位MIME传输的SMTP服务扩展
Abstract
摘要
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP.
此备忘录定义了SMTP服务的扩展，其中包含US-ASCII八位字节范围（十六进制00-7F）之外的八位字节的文本组成的SMTP内容体可以使用SMTP进行中继。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6152.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6152.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Although SMTP is widely and robustly deployed, various extensions have been requested by parts of the Internet community. In particular, a significant portion of the Internet community wishes to exchange messages in which the content body consists of a MIME message [RFC2045][RFC2046][RFC5322] containing arbitrary octet-aligned material. This memo uses the mechanism described in the SMTP specification [RFC5321] to define an extension to the SMTP service whereby such contents may be exchanged. Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets. Given that this restriction still applies, this extension does NOT provide a means for transferring unencoded binary via SMTP.
尽管SMTP被广泛而可靠地部署，但互联网社区的一些成员已经请求了各种扩展。特别是，相当一部分互联网社区希望交换内容主体由MIME消息[RFC2045][RFC2046][RFC5322]组成的消息，其中包含任意八位字节对齐的材料。此备忘录使用SMTP规范[RFC5321]中描述的机制来定义SMTP服务的扩展，通过该扩展可以交换此类内容。请注意，此扩展并不能消除SMTP服务器限制行长度的可能性；服务器可以自由实现此扩展，但设置的行长度限制不低于1000个八位字节。鉴于此限制仍然适用，此扩展不提供通过SMTP传输未编码二进制文件的方法。
The 8-bit MIME transport extension is laid out as follows:
8位MIME传输扩展的布局如下：
1. the name of the SMTP service extension defined here is 8bit-MIMEtransport;
1. 此处定义的SMTP服务扩展名为8bit MIMEtransport；
2. the EHLO keyword value associated with the extension is 8BITMIME;
2. 与扩展关联的EHLO关键字值为8BITMIME；
3. no parameter is used with the 8BITMIME EHLO keyword;
3. 没有参数与8BITMIME EHLO关键字一起使用；
4. one optional parameter using the keyword BODY is added to the MAIL command. The value associated with this parameter is a keyword indicating whether a 7-bit message (in strict compliance with [RFC5321]) or a MIME message (in strict compliance with [RFC2046] and [RFC2045]) with arbitrary octet content is being sent. The syntax of the value is as follows, using the ABNF notation of [RFC5234]:
4. 将使用关键字BODY的一个可选参数添加到MAIL命令中。与此参数相关联的值是一个关键字，指示是否发送7位消息（严格遵守[RFC5321]）或具有任意八位字节内容的MIME消息（严格遵守[RFC2046]和[RFC2045]）。该值的语法如下，使用[RFC5234]的ABNF表示法：
body-value = "7BIT" / "8BITMIME"
body-value = "7BIT" / "8BITMIME"
5. no additional SMTP verbs are defined by this extension; and
5. 此扩展未定义其他SMTP谓词；和
6. the next section specifies how support for the extension affects the behavior of a server and client SMTP.
6. 下一节指定对扩展的支持如何影响服务器和客户端SMTP的行为。
When a client SMTP wishes to submit (using the MAIL command) a content body consisting of a MIME message containing arbitrary lines of octet-aligned material, it first issues the EHLO command to the server SMTP. If the server SMTP responds with code 250 to the EHLO
当客户端SMTP希望提交（使用MAIL命令）由包含任意行八位组对齐材料的MIME消息组成的内容体时，它首先向服务器SMTP发出EHLO命令。如果服务器SMTP以代码250响应EHLO
command, and the response includes the EHLO keyword value 8BITMIME, then the server SMTP is indicating that it supports the extended MAIL command and will accept MIME messages containing arbitrary octet-aligned material.
命令，并且响应包含EHLO关键字值8BITMIME，则服务器SMTP表示它支持扩展邮件命令，并将接受包含任意八位字节对齐材料的MIME消息。
The extended MAIL command is issued by a client SMTP when it wishes to transmit a content body consisting of a MIME message containing arbitrary lines of octet-aligned material. The syntax for this command is identical to the MAIL command in RFC 5321, except that a BODY parameter must appear after the address. Only one BODY parameter may be used in a single MAIL command.
当客户端SMTP希望传输由包含任意行八位字节对齐材料的MIME消息组成的内容体时，会发出extended MAIL命令。此命令的语法与RFC 5321中的MAIL命令相同，只是地址后面必须出现BODY参数。单个邮件命令中只能使用一个BODY参数。
The complete syntax of this extended command is defined in RFC 5321. The esmtp-keyword is BODY, and the syntax for esmtp-value is given by the syntax for body-value shown above.
RFC 5321中定义了此扩展命令的完整语法。esmtp关键字是BODY，上面显示的BODY value语法给出了esmtp value的语法。
The value associated with the BODY parameter indicates whether the content body that will be passed using the DATA command consists of a MIME message containing some arbitrary octet-aligned material ("8BITMIME") or is encoded entirely in accordance with RFC 5321 ("7BIT").
与BODY参数关联的值指示将使用DATA命令传递的内容体是由包含任意八位字节对齐的材料（“8BITMIME”）的MIME消息组成，还是完全按照RFC 5321（“7BIT”）进行编码。
A server that supports the 8-bit MIME transport service extension shall preserve all bits in each octet passed using the DATA command. Naturally, the usual SMTP data-stuffing algorithm applies, so that a content that contains the five-character sequence of <CR> <LF> <DOT> <CR> <LF> or a content that begins with the three-character sequence of <DOT> <CR> <LF> does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceding the final dot is considered part of the content. Finally, although the content body contains arbitrary lines of octet-aligned material, the length of each line (number of octets between two CR-LF pairs) is still subject to SMTP server line length restrictions (which can allow as few as 1000 octets, inclusive of the CR-LF pair, on a single line). This restriction means that this extension provides the necessary facilities for transferring a MIME object with the 8BIT content-transfer-encoding, it DOES NOT provide a means of transferring an object with the BINARY content-transfer-encoding.
支持8位MIME传输服务扩展的服务器应保留使用DATA命令传递的每个八位字节中的所有位。当然，通常的SMTP数据填充算法适用，因此包含五个字符序列<CR><LF><DOT><CR><LF>的内容或以三个字符序列<DOT><CR><LF>开头的内容不会过早终止内容的传输。此外，应注意，紧靠最终点之前的CR-LF对被视为内容的一部分。最后，尽管内容正文包含八位字节对齐材料的任意行，但每行的长度（两个CR-LF对之间的八位字节数）仍受SMTP服务器行长度限制（一行上最多允许1000个八位字节，包括CR-LF对）。此限制意味着此扩展为使用8位内容传输编码传输MIME对象提供了必要的便利，但不提供使用二进制内容传输编码传输对象的方法。
Once a server SMTP supporting the 8bit-MIMEtransport service extension accepts a content body containing octets with the high-order (8th) bit set, the server SMTP must deliver or relay the content in such a way as to preserve all bits in each octet.
一旦支持8位MIMEtransport服务扩展的服务器SMTP接受包含设置了高阶（第8位）位的八位字节的内容正文，服务器SMTP必须以保留每个八位字节中所有位的方式传递或中继内容。
If a server SMTP does not support the 8-bit MIME transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BITMIME in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content that contains characters outside of the US-ASCII octet range (hex 00-7F).
如果服务器SMTP不支持8位MIME传输扩展（不使用代码250响应EHLO命令，或不在其响应中包含EHLO关键字值8BITMIME），则客户端SMTP在任何情况下都不得尝试传输包含US-ASCII八位字节范围外字符的内容（十六进制00-7F）。
A client SMTP has two options in this case: first, it may implement a gateway transformation to convert the message into valid 7-bit MIME, or second, it may treat the barrier to 8-bit as a permanent error and handle it in the usual manner for delivery failures. The specifics of the transformation from 8-bit MIME to 7-bit MIME are not described by this RFC; the conversion is nevertheless constrained in the following ways:
在这种情况下，客户端SMTP有两个选项：第一，它可以实现网关转换以将消息转换为有效的7位MIME；第二，它可以将8位的屏障视为永久错误，并以通常的方式处理传递失败。本RFC未描述从8位MIME到7位MIME的转换细节；然而，转换受到以下方面的限制：
1. it must cause no loss of information; MIME transport encodings must be employed as needed to insure this is the case, and
1. 不得造成信息丢失；必须根据需要使用MIME传输编码来确保这种情况，并且
2. the resulting message must be valid 7-bit MIME.
2. 生成的消息必须是有效的7位MIME。
The following dialogue illustrates the use of the 8bit-MIMEtransport service extension:
以下对话说明了8位MIMEtransport服务扩展的使用：
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 8BITMIME
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
C: DATA
S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
...
C: .
S: 250 OK
C: QUIT
S: 250 Goodbye
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 8BITMIME
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
C: DATA
S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
...
C: .
S: 250 OK
C: QUIT
S: 250 Goodbye
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 RFC 5321, including attacks facilitated by the presence of an option negotiation mechanism. Since MIME semantics are transport-neutral, the 8BITMIME option provides no more added capability to disseminate malware than is provided by unextended 7-bit SMTP.
本RFC不讨论安全问题，也不认为会提出电子邮件中尚未出现的、RFC 5321完全一致性实现中未出现的任何安全问题，包括存在选项协商机制所促成的攻击。由于MIME语义与传输无关，8BITMIME选项与未扩展的7位SMTP相比，不提供更多传播恶意软件的功能。
This document defines an SMTP and Submit service extension. IANA has updated the 8BITMIME entry in the SMTP Service Extensions registry, as follows:
此文档定义SMTP和提交服务扩展名。IANA已更新SMTP服务扩展注册表中的8BITMIME项，如下所示：
Keyword: 8BITMIME
关键词：8BITMIME
Description: SMTP and Submit transport of 8-bit MIME content
描述：SMTP和提交8位MIME内容的传输
Reference: [RFC6152]
参考文献：[RFC6152]
Parameters: See Section 2 in this specification.
参数：见本规范第2节。
E. Stefferud was an original author. This version of the specification was produced by the YAM working group.
E.Stefferud是一位原创作家。本规范版本由YAM工作组编制。
Original acknowledgements: This document represents a synthesis of the ideas of many people and reactions to the ideas and proposals of others. Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas and text sufficient to be considered co-authors. Other important suggestions, text, or encouragement came from Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John Wagner, Rayan Zachariassen, and the contributions of the entire IETF SMTP Working Group. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. Indeed, in some cases, the response to a particular criticism was to accept the problem identification but to include an entirely different solution from the one originally proposed.
原始确认：本文件综合了许多人的想法以及对其他人的想法和建议的反应。Randall Atkinson、Craig Everhart、Risto Kankkunen和Greg Vaudreuil提供了足以被视为共同作者的想法和文本。其他重要的建议、文本或鼓励来自哈拉尔·阿尔维斯特兰、吉姆·康克林、马克·克里斯宾、弗兰克·达克鲁斯、奥拉富·古德蒙德森、佩尔·海德兰、克里斯蒂安·惠特玛、尼尔·卡廷、艾略特·李尔、哈罗德·米勒、基思·摩尔、丹·奥斯卡松、朱利安·奥尼尔斯、尼尔·里克特、约翰·瓦格纳、雷恩·扎卡里森、，以及整个IETF SMTP工作组的贡献。当然，没有一个人必须对这里所代表的思想组合负责。事实上，在某些情况下，对特定批评的回应是接受问题识别，但包括与最初提出的解决方案完全不同的解决方案。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
Authors' Addresses
作者地址
John C. Klensin 1770 Massachusetts Ave, Ste. 322 Cambridge, MA 02140 USA
约翰·C·克伦辛1770马萨诸塞大道，圣。322美国马萨诸塞州剑桥02140
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Ned Freed Oracle 800 Royal Oaks Monrovia, CA 91016-6347 USA
美国加利福尼亚州蒙罗维亚皇家橡树园800号，邮编91016-6347
EMail: ned.freed@mrochek.com
EMail: ned.freed@mrochek.com
M. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 USA
M.罗斯多佛海滩咨询公司，美国加利福尼亚州萨克拉门托市POB 255268，邮编95865-5268
Phone: +1 916 538 2535
EMail: mrose17@gmail.com
Phone: +1 916 538 2535
EMail: mrose17@gmail.com
D. Crocker (editor) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA USA
D.克罗克（编辑）布兰登堡互联675美国加利福尼亚州桑尼维尔云杉博士
Phone: +1 408 246 8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Phone: +1 408 246 8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net