Internet Engineering Task Force (IETF) J. Yao
Request for Comments: 6531 W. Mao
Obsoletes: 5336 CNNIC
Category: Standards Track February 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Yao
Request for Comments: 6531 W. Mao
Obsoletes: 5336 CNNIC
Category: Standards Track February 2012
ISSN: 2070-1721
SMTP Extension for Internationalized Email
用于国际化电子邮件的SMTP扩展
Abstract
摘要
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information.
此文档指定用于传输和传递具有国际化电子邮件地址或标题信息的电子邮件的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/rfc6531.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6531.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在IETF标准过程之外修改此类材料。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes Made to Other Specifications . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 8
3.5. Non-ASCII Addresses and Reply-Codes . . . . . . . . . . . 9
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13
4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
4.3. WITH Protocol Types Sub-Registry of the Mail
Transmission Types Registry . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes Made to Other Specifications . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 8
3.5. Non-ASCII Addresses and Reply-Codes . . . . . . . . . . . 9
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13
4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
4.3. WITH Protocol Types Sub-Registry of the Mail
Transmission Types Registry . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 18
The document defines a Simple Mail Transfer Protocol [RFC5321] extension so servers can advertise the ability to accept and process internationalized email addresses (see Section 1.1) and internationalized email headers [RFC6532].
该文件定义了一个简单邮件传输协议[RFC5321]扩展，因此服务器可以公布接受和处理国际化电子邮件地址（见第1.1节）和国际化电子邮件头[RFC6532]的能力。
An extended overview of the extension model for internationalized email addresses and the email header appears in RFC 6530 [RFC6530], referred to as "the framework document" in this specification. A thorough understanding of the information in that document and in the base Internet email specifications [RFC5321] [RFC5322] is necessary to understand and implement this specification.
RFC 6530[RFC6530]中显示了国际化电子邮件地址和电子邮件标题扩展模型的扩展概述，在本规范中称为“框架文档”。要理解和实施本规范，必须彻底了解该文件和基本互联网电子邮件规范[RFC5321][RFC5322]中的信息。
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]中所述进行解释。
The terms "UTF-8 string" or "UTF-8 character" are used to refer to Unicode characters, which may or may not be members of the ASCII subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "SMTPUTF8", "internationalized message", and "message" are used in this document according to the definitions in the framework document [RFC6530].
术语“UTF-8字符串”或“UTF-8字符”用于指标准Unicode编码形式UTF-8[RFC3629]中的Unicode字符，这些字符可能是也可能不是ASCII子集的成员。本规范中使用的所有其他专用术语在框架文档或基本Internet电子邮件规范中定义。特别是，根据框架文件[RFC6530]中的定义，本文件中使用了术语“ASCII地址”、“国际化电子邮件地址”、“非ASCII地址”、“SMTPUTF8”、“国际化消息”和“消息”。
Strings referred to in this document, including ASCII strings, MUST be expressed in UTF-8.
本文档中提及的字符串（包括ASCII字符串）必须用UTF-8表示。
This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some basic rules in this document are identified in Section 3.3 as being defined (under the same names) in RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532].
本规范使用增广BNF（ABNF）规则[RFC5234]。本文件中的一些基本规则在第3.3节中确定为RFC 5234[RFC5234]、RFC 5321[RFC5321]、RFC 5890[RFC5890]或RFC 6532[RFC6532]中定义的（以相同的名称）。
This specification extends some syntax rules defined in RFC 5321 and permits internationalized email addresses in the envelope and in trace fields, but it does not modify RFC 5321. It permits data formats defined in RFC 6532 [RFC6532], but it does not modify RFC 5322. It does require that the 8BITMIME extension [RFC6152] be announced by the SMTPUTF8-aware SMTP server and used with "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not modify the 8BITMIME specification in any way.
本规范扩展了RFC 5321中定义的一些语法规则，并允许在信封和跟踪字段中使用国际化电子邮件地址，但不修改RFC 5321。它允许RFC 6532[RFC6532]中定义的数据格式，但不修改RFC 5322。它确实要求支持SMTPUTF8的SMTP服务器宣布8BITMIME扩展[RFC6152]，并由支持SMTPUTF8的SMTP客户端与“BODY=8BITMIME”一起使用，但它不会以任何方式修改8BITMIME规范。
This specification replaces an earlier, experimental, approach to the same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes the changes in approach between RFC 5336 [RFC5336] and this specification. Anyone trying to convert an implementation from the experimental specification to the specification in this document will need to review those changes carefully.
本规范取代了以前针对同一问题的实验性方法[RFC5336]。RFC 6530[RFC6530]第6节描述了RFC 5336[RFC5336]与本规范之间的方法变更。任何试图将一个实现从实验规范转换为本文中的规范的人都需要仔细审查这些更改。
This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension for internationalized email. The extension is identified with the token "SMTPUTF8".
本文档指定了电子邮件国际化工作的一个元素，特别是国际化电子邮件的SMTP扩展的定义。扩展名由标记“SMTPUTF8”标识。
The internationalized email headers specification [RFC6532] provides the details of email header features enabled by this extension.
国际化电子邮件头规范[RFC6532]提供了此扩展启用的电子邮件头功能的详细信息。
The following service extension is defined:
定义了以下服务扩展：
1. The name of the SMTP service extension is "Internationalized Email".
1. SMTP服务扩展名为“国际化电子邮件”。
2. The EHLO keyword value associated with this extension is "SMTPUTF8".
2. 与此扩展关联的EHLO关键字值为“SMTPUTF8”。
3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword. The SMTPUTF8-aware SMTP client MUST ignore any parameters if they appear for this keyword; that is, the SMTPUTF8-aware SMTP client MUST behave as if the parameters do not appear. If an SMTP server includes SMTPUTF8 in its EHLO response, it MUST be fully compliant with this version of this specification.
3. 没有为此EHLO关键字值定义参数值。为了允许将来（尽管是意外的）扩展，EHLO响应不得包含此关键字的任何参数。支持SMTPUTF8的SMTP客户端必须忽略任何参数，如果这些参数出现在此关键字中；也就是说，支持SMTPUTF8的SMTP客户端的行为必须与不显示参数一样。如果SMTP服务器在其EHLO响应中包含SMTPUTF8，则它必须完全符合本规范的此版本。
4. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. The parameter does not accept a value. If this parameter is set in the MAIL command, it indicates that the SMTP client is SMTPUTF8-aware. Its presence also asserts that the envelope includes the non-ASCII address, the message being sent is an internationalized message, or the message being sent needs the SMTPUTF8 support.
4. MAIL命令中添加了一个可选参数SMTPUTF8。该参数不接受值。如果在MAIL命令中设置了此参数，则表示SMTP客户端支持SMTPUTF8。它的存在还表明信封包含非ASCII地址，发送的消息是国际化消息，或者发送的消息需要SMTPUTF8支持。
5. The maximum length of a MAIL command line is increased by 10 characters to accommodate the possible addition of the SMTPUTF8 parameter.
5. 邮件命令行的最大长度增加了10个字符，以适应可能添加的SMTPUTF8参数。
6. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not accept a value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.
6. 验证（VRFY）和扩展（EXPN）命令中添加了一个可选参数SMTPUTF8。SMTPUTF8参数不接受值。该参数表示SMTP客户端可以在VRFY和EXPN命令的回复中接受UTF-8编码的Unicode字符。
7. No additional SMTP verbs are defined by this extension.
7. 此扩展未定义其他SMTP谓词。
8. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].
8. 提供此扩展的服务器必须支持并宣布8BITMIME扩展[RFC6152]。
9. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses).
9. SMTP邮件和RCPT命令的反向路径和正向路径已扩展，以允许在邮箱名称（地址）中使用UTF-8编码的Unicode字符。
10. The mail message body is extended as specified in RFC 6532 [RFC6532].
10. 邮件正文按照RFC 6532[RFC6532]中的规定进行扩展。
11. The SMTPUTF8 extension is valid on the submission port [RFC6409]. It may also be used with the Local Mail Transfer Protocol (LMTP) [RFC2033]. When these protocols are used, their use should be reflected in the trace field WITH keywords as appropriate [RFC3848].
11. SMTPUTF8扩展在提交端口[RFC6409]上有效。它也可以与本地邮件传输协议（LMTP）[RFC2033]一起使用。当使用这些协议时，它们的使用应反映在跟踪字段中，并酌情使用关键字[RFC3848]。
An SMTP server that announces the SMTPUTF8 extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a <mailbox> can appear. Although the characters in the <local-part> are permitted to contain non-ASCII characters, the actual parsing of the <local-part> and the delimiters used are unchanged from the base email specification [RFC5321]. Any domain name to be looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or server MUST either use a Unicode-aware DNS library, or transform the internationalized domain name to A-label form (i.e., a fully-qualified domain name that contains one or more A-labels but no U-labels) as specified in RFC 5890 [RFC5890].
宣布SMTPUTF8扩展名的SMTP服务器必须准备好在RFC 5321指定可以出现<邮箱>的任何位置接受UTF-8字符串[RFC3629]。尽管<local part>中的字符允许包含非ASCII字符，但是<local part>的实际解析和使用的定界符与基本电子邮件规范[RFC5321]相同。要在DNS中查找的任何域名必须符合应用程序中的域名国际化（IDNA）[RFC5890]的规定，并按照规定进行处理。进行查找时，支持SMTPUTF8的SMTP客户端或服务器必须使用支持Unicode的DNS库，或者按照RFC 5890[RFC5890]的规定，将国际化域名转换为a标签形式（即，包含一个或多个a标签但不包含U标签的完全限定域名）。
An SMTP client that receives the SMTPUTF8 extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form. It MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in
接收SMTPUTF8 extension关键字以响应EHLO命令的SMTP客户端可以将SMTP命令中的邮箱名称作为UTF-8格式的国际化字符串进行传输。它可以发送一个UTF-8报头[RFC6532]（也可以在其中包含邮箱名称）
UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. The presence of the SMTPUTF8 extension does not change the server-relaying behaviors described in RFC 5321.
UTF-8）。它可以在SMTP命令或邮件头中以A标签或U标签的形式传输邮箱名称的域部分[RFC5890]。SMTPUTF8扩展的存在不会改变RFC 5321中描述的服务器中继行为。
If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in RFC 6532 [RFC6532] at any level within its MIME structure [RFC2045]. (For this paragraph, the internationalized domain name in A-label form as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, the best action for it to take depends on other conditions. In particular:
如果SMTP服务器未提供SMTPUTF8 SMTP扩展，则支持SMTPUTF8的SMTP客户端不得传输国际化电子邮件地址，也不得在其MIME结构[RFC2045]的任何级别传输包含RFC 6532[RFC6532]中所述国际化邮件头的邮件。（对于本段，IDNA定义[RFC5890]中指定的A标签形式的国际化域名不被视为“国际化”。）相反，如果支持SMTPUTF8的SMTP客户端（发件人）尝试传输国际化邮件，但遇到不支持扩展的SMTP服务器，它采取的最佳行动取决于其他条件。特别地：
o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document.
o 如果它是一个消息提交代理（MSA）[RFC6409][RFC5598]，它可以选择自己的方式来处理这种情况，使用RFC 6409允许的更改地址或以其他方式修复和转换消息的广泛自由裁量权。只要生成的消息符合RFC 5321的要求（即没有SMTPUTF8扩展），该转换的细节就不在本文档的范围之内。
o If it is not an MSA or is an MSA and does not choose to transform the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmitting a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321, RFC 3464 [RFC3464], and RFC 6533 [RFC6533].
o 如果它不是MSA或MSA且不选择将消息转换为不需要SMTPUTF8扩展名的消息，则应拒绝该消息。通常，这可以通过在SMTP事务期间生成适当的回复或接受邮件，然后生成并发送未送达通知来完成。如果做出后一种选择，通知流程必须符合RFC 5321、RFC 3464[RFC3464]和RFC 6533[RFC6533]的要求。
o As specified in Section 2.2.3 of RFC 5321, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section.
o 如RFC 5321第2.2.3节所述，具有额外信息和/或特殊情况知识的SMTP客户端可选择重新查询邮件并稍后重试和/或尝试该节所述的备用MX主机。
This document applies when an SMTPUTF8-aware SMTP client or server supports the SMTPUTF8 extension. For all other cases, and for addresses and messages that do not require an SMTPUTF8 extension, SMTPUTF8-aware SMTP clients and servers do not change the behavior specified in RFC 5321 [RFC5321].
当支持SMTPUTF8的SMTP客户端或服务器支持SMTPUTF8扩展时，本文档适用。对于所有其他情况，以及不需要SMTPUTF8扩展名的地址和邮件，支持SMTPUTF8的SMTP客户端和服务器不会更改RFC 5321[RFC5321]中指定的行为。
If an SMTPUTF8-aware SMTP server advertises the Delivery Status Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 [RFC6533].
如果支持SMTPUTF8的SMTP服务器播发传递状态通知（DSN）[RFC3461]扩展，则它必须实现RFC 6533[RFC6533]。
RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters. This document extends <Mailbox> to add support of non-ASCII characters.
RFC 5321第4.1.2节完全根据ASCII字符定义了<Mailbox>的语法。本文档扩展了<Mailbox>以添加对非ASCII字符的支持。
The key changes made by this specification include:
本规范所做的关键变更包括：
o The <Mailbox> ABNF rule is imported from RFC 5321 and updated in order to support the internationalized email address. Other related rules are imported from RFC 5321, RFC 5234, RFC 5890, and RFC 6532, or are extended in this document.
o <Mailbox>ABNF规则从RFC 5321导入并更新，以支持国际化电子邮件地址。其他相关规则从RFC 5321、RFC 5234、RFC 5890和RFC 6532导入，或在本文档中进行扩展。
o The definition of <sub-domain> is extended to permit both the RFC 5321 definition and a UTF-8 string in a DNS label that conforms with IDNA definitions [RFC5890].
o 扩展了<sub-domain>的定义，以允许RFC 5321定义和符合IDNA定义[RFC5890]的DNS标签中的UTF-8字符串。
o The definition of <atext> is extended to permit both the RFC 5321 definition and a UTF-8 string. That string MUST NOT contain any of the ASCII graphics or control characters.
o 扩展了<atext>的定义，以允许RFC 5321定义和UTF-8字符串。该字符串不得包含任何ASCII图形或控制字符。
The following ABNF rules imported from RFC 5321, Section 4.1.2, are updated directly or indirectly by this document:
本文件直接或间接更新了从RFC 5321第4.1.2节导入的以下ABNF规则：
o <Mailbox>
o <邮箱>
o <Local-part>
o <本地部分>
o <Dot-string>
o <Dot string>
o <Quoted-string>
o <Quoted string>
o <QcontentSMTP>
o <QcontentSMTP>
o <Domain>
o <Domain>
o <Atom>
o <Atom>
The following ABNF rule will be imported from RFC 6532, Section 3.1, directly:
以下ABNF规则将直接从RFC 6532第3.1节导入：
o <UTF8-non-ascii>
o <UTF8非ascii>
The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly:
以下ABNF规则将直接从RFC 5234附录B.1中导入：
o <DQUOTE>
o <DQUOTE>
The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly:
以下ABNF规则将直接从RFC 5890第2.3.2.1节导入：
o <U-label>
o <U-label>
The following rules are extended in ABNF [RFC5234] as follows.
以下规则在ABNF[RFC5234]中扩展如下。
sub-domain =/ U-label ; extend the definition of sub-domain in RFC 5321, Section 4.1.2
子域=/U-label；扩展RFC 5321第4.1.2节中子域的定义
atext =/ UTF8-non-ascii
; extend the implicit definition of atext in
; RFC 5321, Section 4.1.2, which ultimately points to
; the actual definition in RFC 5322, Section 3.2.3
atext =/ UTF8-non-ascii
; extend the implicit definition of atext in
; RFC 5321, Section 4.1.2, which ultimately points to
; the actual definition in RFC 5322, Section 3.2.3
qtextSMTP =/ UTF8-non-ascii ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2
qtextSMTP=/UTF8非ascii；扩展RFC 5321第4.1.2节中qtextSMTP的定义
esmtp-value =/ UTF8-non-ascii ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2
esmtp值=/UTF8非ascii；扩展RFC 5321第4.1.2节中esmtp值的定义
If the envelope or message being sent requires the capabilities of the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command. If this parameter is provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP client is aware that neither the envelope nor the message being sent requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT supply the SMTPUTF8 parameter with the MAIL command.
如果要发送的信封或邮件需要SMTPUTF8扩展的功能，则支持SMTPUTF8的SMTP客户端必须在MAIL命令中提供SMTPUTF8参数。如果提供了此参数，则它不能接受值。如果支持SMTPUTF8的SMTP客户端知道信封和正在发送的邮件都不需要任何SMTPUTF8扩展功能，则不应在MAIL命令中提供SMTPUTF8参数。
Because there is no guarantee that a next-hop SMTP server will support the SMTPUTF8 extension, use of the SMTPUTF8 extension always carries a risk of transmission failure. In fact, during the early stages of deployment for the SMTPUTF8 extension, the risk will be quite high. Hence, there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting ASCII [ASCII] characters (0x7f and below) as UTF-8 form is that it permits pure-Unicode environments.
由于无法保证下一跳SMTP服务器将支持SMTPUTF8扩展，因此使用SMTPUTF8扩展始终存在传输失败的风险。事实上，在SMTPUTF8扩展部署的早期阶段，风险相当高。因此，在不使用此扩展的情况下发送仅ASCII消息具有明显的近期优势。将ASCII[ASCII]字符（0x7f及以下）转换为UTF-8格式的长期优势在于它允许纯Unicode环境。
An SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8. If the SMTP server does not support this option, then the SMTPUTF8-aware SMTP client has three choices according to Section 3.2 of this specification.
支持SMTPUTF8的SMTP客户端不得向不支持SMTPUTF8的SMTP服务器发送国际化邮件。如果SMTP服务器不支持此选项，则根据本规范第3.2节，支持SMTPUTF8的SMTP客户端有三种选择。
The three-digit reply-codes used in this section are based on their meanings as defined in RFC 5321.
本节中使用的三位数回复代码基于RFC 5321中定义的含义。
When messages are rejected because the RCPT command requires an ASCII address, the reply-code 553 is returned with the meaning "mailbox name not allowed". When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII addresses not permitted for that sender/recipient".
当由于RCPT命令需要ASCII地址而拒绝邮件时，将返回回复代码553，其含义为“不允许使用邮箱名称”。当邮件命令需要ASCII地址而拒绝邮件时，返回的回复代码550表示“邮箱不可用”。当支持SMTPUTF8的SMTP服务器支持增强的邮件系统状态代码[RFC3463]时，将使用回复代码“X.6.7”[RFC5248]（参见第4节），这意味着“该发件人/收件人不允许使用非ASCII地址”。
When messages are rejected for other reasons, the server follows the model of the base email specification in RFC 5321; this extension does not change those circumstances or reply messages.
当邮件因其他原因被拒绝时，服务器遵循RFC 5321中的基本电子邮件规范模型；此扩展不会更改这些情况或回复消息。
If a message is rejected after the final "." of the DATA command because one or more recipients are unable to accept and process a message with internationalized email headers, the reply-code "554" is used with the meaning "Transaction failed". If the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this condition, meaning "UTF-8 header message cannot be transmitted to one or more recipients, so the message must be rejected".
如果由于一个或多个收件人无法接受和处理带有国际化电子邮件标题的邮件，在数据命令的最后一个“.”之后拒绝了邮件，则回复代码“554”的含义为“交易失败”。如果支持SMTPUTF8的SMTP服务器支持增强型邮件系统状态代码[RFC3463]，则回复代码“X.6.9”[RFC5248]（请参阅第4节）用于指示此情况，这意味着“UTF-8标头消息无法传输到一个或多个收件人，因此必须拒绝该消息”。
The SMTPUTF8-aware SMTP servers are encouraged to detect that recipients cannot accept internationalized messages and generate an error after the RCPT command rather than waiting until after the DATA command to issue an error.
建议支持SMTPUTF8的SMTP服务器检测收件人无法接受国际化邮件并在RCPT命令后生成错误，而不是等到DATA命令后才发出错误。
The MAIL command parameter SMTPUTF8 asserts that a message is an internationalized message or the message being sent needs the SMTPUTF8 support. There is still a chance that a message being sent via the MAIL command with the SMTPUTF8 parameter is not an internationalized message. An SMTPUTF8-aware SMTP client or server that requires accurate knowledge of whether a message is internationalized needs to parse all message header fields and MIME
邮件命令参数SMTPUTF8断言消息是国际化消息，或者正在发送的消息需要SMTPUTF8支持。通过带有SMTPUTF8参数的MAIL命令发送的消息仍有可能不是国际化消息。需要准确了解邮件是否国际化的SMTPUTF8感知SMTP客户端或服务器需要解析所有邮件头字段和MIME
header fields [RFC2045] in the message body. However, this specification does not require that the SMTPUTF8-aware SMTP client or server inspects the message.
消息正文中的标题字段[RFC2045]。但是，此规范不要求支持SMTPUTF8的SMTP客户端或服务器检查邮件。
Although this specification requires that SMTPUTF8-aware SMTP servers support the 8BITMIME extension [RFC6152] to ensure that servers have adequate handling capability for 8-bit data, it does not require non-ASCII body parts in the MIME message as specified in RFC 2045. The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content):
尽管本规范要求支持SMTPUTF8的SMTP服务器支持8BITMIME扩展[RFC6152]，以确保服务器具有足够的8位数据处理能力，但它不需要RFC 2045中规定的MIME消息中的非ASCII正文部分。SMTPUTF8扩展可按如下方式使用（假设其适用于正文内容）：
- with the BODY=8BITMIME parameter [RFC6152], or
- 具有BODY=8BITMIME参数[RFC6152]，或
- with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030].
- 如果SMTP服务器播发BINARYMIME[RFC3030]，则使用BODY=BINARYMIME参数。
The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that, when RFC 5321 specifies a mailbox, this SMTP extension requires UTF-8 form to be used for the entire string. When RFC 5321 specifies a domain name, the internationalized domain name SHOULD be in U-label form if the SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label form.
邮件传输过程中携带的信息包括各种上下文中的地址（“邮箱”）和域名，以及mail和RCPT命令和扩展的替代命令。通常，规则是，当RFC 5321指定邮箱时，此SMTP扩展需要对整个字符串使用UTF-8表单。当RFC 5321指定域名时，如果支持SMTPUTF8扩展，则国际化域名应为U标签形式；否则，应采用A标签形式。
The following subsections list and discuss all of the relevant cases.
以下小节列出并讨论了所有相关案例。
When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The SMTP client then sends the EHLO command. Since the SMTP client cannot know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the EHLO command. If the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels.
当SMTP连接打开时，SMTP服务器将发送一个“问候”响应，其中包括220回复代码和一些信息。然后SMTP客户端发送EHLO命令。由于SMTP客户端在收到对EHLO的响应之前无法知道SMTP服务器是否支持SMTPUTF8，因此支持SMTPUTF8的SMTP客户端必须在EHLO命令中仅发送ASCII（LDH标签或A标签[RFC5890]）域。如果支持SMTPUTF8的SMTP服务器在EHLO响应中提供域名，则它们必须采用LDH标签或A标签的形式。
If multiple DNS MX records are used to specify multiple servers for a domain (as described in Section 5 of RFC 5321 [RFC5321]), it is strongly advised that all or none of them SHOULD support the SMTPUTF8
如果使用多个DNS MX记录为一个域指定多个服务器（如RFC 5321[RFC5321]第5节所述），强烈建议所有或所有DNS MX记录都应支持SMTPUTF8
extension. Otherwise, unexpected rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues.
扩大否则，在临时或永久故障期间可能会发生意外拒绝，用户可能会认为这是严重的可靠性问题。
The trace information <Return-path-line>, <Time-stamp-line>, and their related rules are defined in Section 4.4 of RFC 5321 [RFC5321]. This document updates <Mailbox> and <Domain> to support non-ASCII characters. When the SMTPUTF8 extension is used, the 'Reverse-path' clause of the Return-path-line may include an internationalized domain name that uses the U-label form. Also, the 'Stamp' clause of the Time-stamp-line may include an internationalized domain name that uses the U-label form.
RFC 5321[RFC5321]第4.4节定义了跟踪信息<返回路径线>，<时间戳线>，以及它们的相关规则。此文档将更新<Mailbox>和<Domain>以支持非ASCII字符。使用SMTPUTF8扩展名时，返回路径行的“反向路径”子句可能包括使用U标签形式的国际化域名。此外，时间戳行的“Stamp”子句可能包括使用U标签形式的国际化域名。
If the messages that include trace fields are sent by an SMTPUTF8- aware SMTP client or relay server without the SMTPUTF8 parameter included in the MAIL commands, trace field values must conform to RFC 5321 regardless of the SMTP server's capability.
如果包含跟踪字段的邮件由支持SMTPUTF8的SMTP客户端或中继服务器发送，而邮件命令中不包含SMTPUTF8参数，则无论SMTP服务器的功能如何，跟踪字段值都必须符合RFC 5321。
When an SMTPUTF8-aware SMTP server adds a trace field to a message that was or will be transmitted with the SMTPUTF8 parameter included in the MAIL commands, that server SHOULD use the U-label form for internationalized domain names in the new trace field.
当支持SMTPUTF8的SMTP服务器将跟踪字段添加到已使用或将使用邮件命令中包含的SMTPUTF8参数传输的邮件时，该服务器应在新跟踪字段中使用国际化域名的U标签形式。
The protocol value of the 'WITH' clause when this extension is used is one of the SMTPUTF8 values specified in the "IANA Considerations" section of this document.
使用此扩展时，“WITH”子句的协议值是本文档“IANA注意事项”部分中指定的SMTPUTF8值之一。
If an SMTP client follows this specification and sends any MAIL commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them. If a given MAIL command does not include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses.
如果SMTP客户端遵循此规范并发送包含SMTPUTF8参数的任何邮件命令，则支持SMTPUTF8的SMTP服务器允许在与251和551回复代码关联的电子邮件地址中使用UTF-8字符，并且SMTP客户端必须能够接受和处理这些字符。如果给定的邮件命令不包含SMTPUTF8参数，则支持SMTPUTF8的SMTP服务器不得返回包含非ASCII邮箱的251或551响应。相反，它必须将这些响应转换为250或550个不包含非ASCII地址的响应。
If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN commands, it indicates that the SMTP client can accept UTF-8 strings in replies to those commands. The parameter with the VRFY and EXPN
如果使用VRFY和EXPN命令传输SMTPUTF8参数，则表明SMTP客户端可以在对这些命令的回复中接受UTF-8字符串。带有VRFY和EXPN的参数
commands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware SMTP server to use UTF-8 strings in mailbox names and full names that occur in replies, without concern that the SMTP client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies to the VRFY and EXPN commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter with the VRFY and EXPN commands.
只有在SMTP客户端看到带有SMTPUTF8关键字的EHLO响应后，才应使用命令。这允许支持SMTPUTF8的SMTP服务器在回复中出现的邮箱名称和全名中使用UTF-8字符串，而无需担心SMTP客户端可能会被它们混淆。符合此规范的SMTP客户端必须接受并正确处理对包含UTF-8字符串的VRFY和EXPN命令的答复。但是，如果SMTP客户端未通过使用VRFY和EXPN命令传输此参数明确允许此类回复，则支持SMTPUTF8的SMTP服务器不得在回复中使用UTF-8字符串。
Most replies do not require that a mailbox name be included in the returned text, and therefore a UTF-8 string is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox.
大多数回复不要求在返回的文本中包含邮箱名称，因此不需要UTF-8字符串。一些回复，尤其是成功执行VRFY和EXPN命令后产生的回复，确实包含邮箱。
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
验证（VRFY）和扩展（EXPN）命令语法已更改为：
vrfy = "VRFY" SP String [ SP "SMTPUTF8" ] CRLF ; String may include Non-ASCII characters
vrfy=“vrfy”SP字符串[SP“SMTPUTF8”]CRLF；字符串可能包括非ASCII字符
expn = "EXPN" SP String [ SP "SMTPUTF8" ] CRLF ; String may include Non-ASCII characters
expn=“expn”SP String[SP“SMTPUTF8”]CRLF；字符串可能包括非ASCII字符
The SMTPUTF8 parameter does not accept a value. If the reply to a VRFY or EXPN command requires a UTF-8 string, but the SMTP client did not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST use either the reply-code 252 or 550. Reply-code 252, defined in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". Reply-code 550, also defined in RFC 5321 [RFC5321], means "Requested action not taken: mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code as specified below is used. Using the SMTPUTF8 parameter with a VRFY or EXPN command enables UTF-8 replies for that command only.
SMTPUTF8参数不接受值。如果回复VRFY或EXPN命令需要UTF-8字符串，但SMTP客户端未使用SMTPUTF8参数，则支持SMTPUTF8的SMTP服务器必须使用回复代码252或550。RFC 5321[RFC5321]中定义的回复代码252表示“无法验证用户，但将接受消息并尝试传递”。回复代码550也在RFC 5321[RFC5321]中定义，表示“未采取请求的操作：邮箱不可用”。当支持SMTPUTF8的SMTP服务器支持增强邮件系统状态代码[RFC3463]时，将使用下面指定的增强回复代码。将SMTPUTF8参数与VRFY或EXPN命令一起使用时，仅对该命令启用UTF-8应答。
If a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms:
如果返回正常成功响应（即250），则响应可能包括用户的全名，并且必须包括用户的邮箱。必须采用以下任一形式：
User Name <Mailbox> ; Mailbox is defined in Section 3.3 of this document. ; User Name can contain non-ASCII characters.
用户名<邮箱>；邮箱定义见本文件第3.3节；用户名可以包含非ASCII字符。
Mailbox ; Mailbox is defined in Section 3.3 of this document.
邮箱邮箱定义见本文件第3.3节。
If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not allowed in the reply, and the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client".
如果SMTP回复需要UTF-8字符串，但在回复中不允许使用UTF-8字符串，并且支持SMTPUTF8的SMTP服务器支持增强的邮件系统状态代码[RFC3463]，则增强的回复代码为“X.6.8”[RFC5248]（参见第4节），即“需要包含UTF-8字符串的回复来显示邮箱名称，但SMTP客户端不允许使用这种形式的响应。”。
If the SMTP client does not support the SMTPUTF8 extension, but receives a UTF-8 string in a reply, it may not be able to properly report the reply to the user, and some clients might mishandle that reply. Internationalized messages in replies are only allowed in the commands under the situations described above.
如果SMTP客户端不支持SMTPUTF8扩展名，但在答复中收到UTF-8字符串，则它可能无法向用户正确报告答复，某些客户端可能会错误处理该答复。在上述情况下，答复中的国际化消息仅允许在命令中使用。
Although UTF-8 strings are needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 strings for any other purposes. SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section.
尽管根据本节规定的规则，响应中需要UTF-8字符串来表示电子邮件地址，但此扩展不允许将UTF-8字符串用于任何其他目的。支持SMTPUTF8的SMTP服务器不得在回复中包含非ASCII字符，本节特别允许的有限情况除外。
IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" registry of the "Mail Parameters" registry, according to the following data:
IANA已根据以下数据向“邮件参数”注册表的“SMTP服务扩展”注册表添加了一个新值“SMTPUTF8”：
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| SMTPUTF8 | Internationalized email address | [RFC6531] |
+----------+---------------------------------+-----------+
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| SMTPUTF8 | Internationalized email address | [RFC6531] |
+----------+---------------------------------+-----------+
The code definitions in this document replace those specified in RFC 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and based on RFC 5248 [RFC5248]. IANA has updated the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" with the following data:
根据本文件第3.5节和第3.7.4.2节的指导，并基于RFC 5248[RFC5248]，本文件中的代码定义取代RFC 5336中规定的代码定义。IANA已使用以下数据更新了“简单邮件传输协议（SMTP）增强状态代码注册表”：
Code: X.6.7 Sample Text: Non-ASCII addresses not permitted for that sender/recipient Associated basic status code: 550, 553 Description: This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: ima@ietf.org
代码：X.6.7示例文本：与发件人/收件人关联的基本状态代码不允许使用非ASCII地址：550553说明：这表示接收到不允许使用非ASCII地址的邮件或RCPT命令。定义：RFC 6531（标准跟踪）提交人：姚建康变更控制员：ima@ietf.org
Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the SMTP client Associated basic status code: 252, 550, 553 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: ima@ietf.org
代码：X.6.8示例文本：UTF-8字符串回复是必需的，但SMTP客户端不允许相关的基本状态代码：252、550、553说明：这表示需要包含UTF-8字符串的回复来显示邮箱名称，但SMTP客户端不允许该响应形式。定义：RFC 6531（标准跟踪）提交人：姚建康变更控制员：ima@ietf.org
Code: X.6.9 Sample Text: UTF-8 header message cannot be transferred to one or more recipients, so the message must be rejected Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: ima@ietf.org
代码：X.6.9示例文本：UTF-8标头消息无法传输到一个或多个收件人，因此必须拒绝该消息关联的基本状态代码：550说明：这表示在数据命令的最终“.”之后事务失败。定义：RFC 6531（标准跟踪）提交人：姚建康变更控制员：ima@ietf.org
Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated.
代码：X.6.10说明：这是X.6.8的副本，因此不推荐使用。
4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types Registry
4.3. 使用邮件传输类型注册表的协议类型子注册表
IANA has modified or added the following entries in the "WITH protocol types" sub-registry under the "Mail Transmission Types" registry.
IANA已在“邮件传输类型”注册表下的“具有协议类型”子注册表中修改或添加了以下条目。
+--------------+------------------------------+---------------------+
| WITH | Description | Reference |
| protocol | | |
| types | | |
+--------------+------------------------------+---------------------+
| UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] |
| UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
| | STARTTLS | |
| UTF8SMTPSA | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
| | STARTTLS and AUTH | [RFC6531] |
| UTF8LMTP | LMTP with SMTPUTF8 | [RFC6531] |
| UTF8LMTPA | LMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8LMTPS | LMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
| | STARTTLS | |
| UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
| | STARTTLS and AUTH | [RFC6531] |
+--------------+------------------------------+---------------------+
+--------------+------------------------------+---------------------+
| WITH | Description | Reference |
| protocol | | |
| types | | |
+--------------+------------------------------+---------------------+
| UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] |
| UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
| | STARTTLS | |
| UTF8SMTPSA | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
| | STARTTLS and AUTH | [RFC6531] |
| UTF8LMTP | LMTP with SMTPUTF8 | [RFC6531] |
| UTF8LMTPA | LMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8LMTPS | LMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
| | STARTTLS | |
| UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
| | STARTTLS and AUTH | [RFC6531] |
+--------------+------------------------------+---------------------+
The extended security considerations discussion in the framework document [RFC6530] applies here.
框架文档[RFC6530]中的扩展安全注意事项讨论适用于此处。
More security considerations are discussed below:
下面将讨论更多安全注意事项：
Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other cases, in particular:
除了在电子邮件全局系统中使用（在SMTP信封和邮件标题中），国际化电子邮件地址还将显示在其他情况下，特别是：
o the logging systems of SMTP transactions and other logs to monitor the email systems;
o SMTP交易记录系统和其他日志，用于监控电子邮件系统；
o the trouble ticket systems used by security teams to manage security incidents, when an email address is involved;
o 当涉及电子邮件地址时，安全团队用于管理安全事件的故障单系统；
In order to avoid problems that could cause loss of data, this will likely require extending these systems to support full UTF-8, or require providing an adequate mechanism for mapping non-ASCII strings to ASCII.
为了避免可能导致数据丢失的问题，这可能需要扩展这些系统以支持完整的UTF-8，或者需要提供将非ASCII字符串映射到ASCII的适当机制。
Another security aspect to be considered is related to the ability by security team members to quickly understand, read, and identify email addresses from the logs, when they are tracking an incident. Mechanisms to automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use by log readers that cannot easily read non-ASCII information.
另一个需要考虑的安全方面是，安全团队成员在跟踪事件时能够快速理解、阅读和识别日志中的电子邮件地址。应实施自动快速提供国际化电子邮件地址来源或所有权的机制，以供无法轻松读取非ASCII信息的日志读取器使用。
The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). Sections 3.5 and 7.3 of RFC 5321 give detailed descriptions of use and possible behaviors. Implementation of internationalized addresses can also affect logs and actions by these tools.
SMTP命令VRFY和EXPN有时用于没有要传输的邮件的SMTP事务中（通过用于在识别潜在垃圾邮件时采取自动操作的工具）。RFC 5321第3.5节和第7.3节详细描述了使用和可能的行为。国际化地址的实现也会影响这些工具的日志和操作。
This document revises RFC 5336 [RFC5336] based on the result of the Email Address Internationalization (EAI) working group's discussion. Many EAI working group members did tests and implementations to move this document to the Standards Track. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA, and other members of JET and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the working group and design team. Those contributions include material from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here.
本文件根据电子邮件地址国际化（EAI）工作组的讨论结果对RFC 5336[RFC5336]进行了修订。许多EAI工作组成员进行了测试和实现，以将此文档转移到标准轨道。从李晓东、徐乃文、高阳宇、Yoseya Yoshiro YONEYA和JET的其他成员处收到了重要的意见和建议，并纳入了规范中。工作组和设计团队的许多成员提出了其他重要的意见和建议，通常还有具体的文本。这些贡献包括来自约翰·C·克莱辛、查尔斯·林赛、戴夫·克罗克、哈拉尔·特维特·阿尔维斯特朗、马科斯·桑兹、克里斯·纽曼、马丁·杜尔斯、埃德蒙·钟、托尼·芬奇、卡里·赫塔、兰德尔·盖伦斯、弗兰克·埃勒曼、亚历克赛·梅尔尼科夫、皮特·雷斯尼克、S·穆内萨米、苏博克·李、肖恩·斯蒂尔、阿尔弗雷德·霍恩斯、米格尔·加西亚、马格纳斯·韦斯特隆德的材料，Joseph Yee和Lars Eggert。当然，没有一个人必须对这里所代表的思想组合负责。
Thanks a lot to Dave Crocker for his comments and helping with ABNF refinement.
非常感谢Dave Crocker的评论和对ABNF改进的帮助。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII]美国国家标准协会（前美国标准协会），“美国信息交换代码”，ANSI X3.4-1968，1968年。
[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月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 3629，2003年11月。
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.
[RFC3848]Newman，C.，“ESMTP和LMTP传输类型登记”，RFC 3848，2004年7月。
[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月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.
[RFC5248]Hansen，T.和J.Klensin，“SMTP增强邮件系统状态代码的注册表”，RFC 5248，2008年6月。
[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月。
[RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.
[RFC5890]Klensin，J.“应用程序中的域名国际化（IDNA定义）”，RFC 58902010年6月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152]Klensin，J.，Freed，N.，Rose，M.，和D.Crocker，“8位MIME传输的SMTP服务扩展”，STD 71，RFC 6152，2011年3月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409]Gellens，R.和J.Klensin，“邮件信息提交”，STD 72，RFC 6409，2011年11月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC6530，2012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件标题”，RFC 6532，2012年2月。
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.
[RFC6533]Hansen，T.，Ed.，Newman，C.，和A.Melnikov，Ed.，“国际化交付状态和处置通知”，RFC RFC6533，2012年2月。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033]迈尔斯，J.，“本地邮件传输协议”，RFC20331996年10月。
[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月。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[RFC3030]Vaudreuil，G.“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336]Yao，J.和W.Mao，“国际化电子邮件地址的SMTP扩展”，RFC 53362008年9月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
Authors' Addresses
作者地址
Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China
中国北京中关村南四街4号建康姚CNNIC
Phone: +86 10 58813007
EMail: yaojk@cnnic.cn
Phone: +86 10 58813007
EMail: yaojk@cnnic.cn
Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China
中国北京中关村南四街4号伟茂CNNIC
Phone: +86 10 58812230
EMail: maowei_ietf@cnnic.cn
Phone: +86 10 58812230
EMail: maowei_ietf@cnnic.cn