Network Working Group J. Yao, Ed.
Request for Comments: 5336 W. Mao, Ed.
Updates: 2821, 2822, 4952 CNNIC
Category: Experimental September 2008
Network Working Group J. Yao, Ed.
Request for Comments: 5336 W. Mao, Ed.
Updates: 2821, 2822, 4952 CNNIC
Category: Experimental September 2008
SMTP Extension for Internationalized Email Addresses
用于国际化电子邮件地址的SMTP扩展
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.
此文档指定用于传输和传递具有国际化电子邮件地址或标题信息的电子邮件的SMTP扩展名。另一份文件中规定了与未实施本规范的系统的通信。本文档更新了RFC 2821和RFC 2822中定义的一些语法和规则，并更新了RFC 4952。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 9
3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 10
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 12
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 20
A.1. Conventional Message and Internationalized Message . . . . 20
A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 20
A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 20
A.5. Applicability of SMTP Extension to Additional Uses . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 9
3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 10
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 12
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 20
A.1. Conventional Message and Internationalized Message . . . . 20
A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 20
A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 20
A.5. Applicability of SMTP Extension to Additional Uses . . . . 21
An internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of clients and servers, while domain names are resolved by name servers looking up those names in their own tables. In addition to this, the Simple Mail Transfer Protocol [RFC2821] provides a negotiation mechanism about service extension with which clients can discover server capabilities and make decisions for further processing. An extended overview of the extension model for internationalized addresses and headers appears in [RFC4952], referred to as "the framework document" or just as "Framework" elsewhere in this specification. This document specifies an SMTP extension to permit internationalized email addresses in envelopes, and UNICODE characters (encoded in UTF-8) [RFC3629] in headers.
国际化电子邮件地址包括两部分，本地部分和域部分。协议使用电子邮件地址的方式与使用域名的方式不同。最关键的区别在于，电子邮件是通过一系列客户端和服务器发送的，而域名是由名称服务器在自己的表中查找这些名称来解析的。除此之外，简单邮件传输协议[RFC2821]还提供了一种关于服务扩展的协商机制，客户机可以通过该机制发现服务器功能并做出进一步处理的决策。[RFC4952]中显示了国际化地址和头的扩展模型的扩展概述，在本规范的其他地方称为“框架文档”或“框架”。本文档指定了一个SMTP扩展，以允许在信封中使用国际化电子邮件地址，并在标题中使用UNICODE字符（UTF-8编码）[RFC3629]。
The framework document specifies the requirements for, and describes components of, full internationalization of electronic mail. A thorough understanding of the information in that document and in the base Internet email specifications [RFC2821] [RFC2822] is necessary to understand and implement this specification.
该框架文件规定了电子邮件完全国际化的要求，并描述了其组成部分。要理解和实施本规范，必须彻底了解该文件和基本互联网电子邮件规范[RFC2821][RFC2822]中的信息。
This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension [RFC2821] for internationalized email address transport delivery.
本文档指定了电子邮件国际化工作的一个元素，特别是用于国际化电子邮件地址传输传递的SMTP扩展[RFC2821]的定义。
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 "conventional message" and "internationalized message" are defined in an appendix to this specification. The terms "UTF-8 string" or "UTF-8 character" are used informally to refer to Unicode characters encoded in UTF-8 [RFC3629]. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications [RFC2821] [RFC2822]. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "i18mail address", "UTF8SMTP", "message", and "mailing list" are used in this document according to the definitions in the framework document.
术语“常规消息”和“国际化消息”在本规范附录中有定义。术语“UTF-8字符串”或“UTF-8字符”非正式地用于指用UTF-8编码的Unicode字符[RFC3629]。本规范中使用的所有其他专用术语在框架文件或基本互联网电子邮件规范[RFC2821][RFC2822]中定义。特别是，根据框架文件中的定义，本文件中使用了术语“ASCII地址”、“国际化电子邮件地址”、“非ASCII地址”、“I18邮件地址”、“UTF8SMTP”、“邮件”和“邮件列表”。
This specification defines only those Augmented BNF (ABNF) [RFC5234] syntax rules that are different from those of the base email specifications [RFC2821][RFC2822] and, where the earlier rules are upgraded or extended, gives them new names. When the new rule is a small modification to the older one, it is typically given a name starting with "u". Rules that are undefined here may be found in the base email specifications under the same names.
本规范仅定义那些与基本电子邮件规范[RFC2821][RFC2822]不同的增广BNF（ABNF）[RFC5234]语法规则，并且在升级或扩展早期规则的情况下，为它们提供新名称。当新规则是对旧规则的一个小修改时，通常会给它一个以“u”开头的名称。此处未定义的规则可以在相同名称的基本电子邮件规范中找到。
This specification describes an optional extension to the email transport mechanism that permits non-ASCII [ASCII] characters in both the envelope and header fields of messages, which are encoded with UTF-8 [RFC3629] characters. The extension is identified with the token "UTF8SMTP". In order to provide information that may be needed in downgrading, an optional alternate ASCII address may be needed if an SMTP client attempts to transfer an internationalized message and encounters a server that does not support this extension.
本规范描述了电子邮件传输机制的可选扩展，该扩展允许在消息的信封和标题字段中使用非ASCII[ASCII]字符，这些字段使用UTF-8[RFC3629]字符编码。扩展名由令牌“UTF8SMTP”标识。为了提供降级时可能需要的信息，如果SMTP客户端试图传输国际化邮件，但遇到不支持此扩展的服务器，则可能需要可选的备用ASCII地址。
The EAI UTF-8 header specification [RFC5335] provides the details of how and where non-ASCII characters are permitted in the header fields of messages. The context for this specification is described in the framework document.
EAI UTF-8标头规范[RFC5335]提供了消息标头字段中允许非ASCII字符的方式和位置的详细信息。框架文档中描述了本规范的上下文。
The following service extension is defined:
定义了以下服务扩展：
1. The name of the SMTP service extension is "Email Address Internationalization".
1. SMTP服务扩展名为“电子邮件地址国际化”。
2. The EHLO keyword value associated with this extension is "UTF8SMTP".
2. 与此扩展关联的EHLO关键字值为“UTF8SMTP”。
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 that keyword. Clients MUST ignore any parameters; that is, clients MUST behave as if the parameters do not appear. If a server includes UTF8SMTP in its EHLO response, it MUST be fully compliant with this version of this specification.
3. 没有为此EHLO关键字值定义参数值。为了允许将来（尽管是意外的）扩展，EHLO响应不得包含该关键字的任何参数。客户必须忽略任何参数；也就是说，客户机的行为必须与参数未出现时的行为相同。如果服务器在其EHLO响应中包含UTF8SMTP，则它必须完全符合本规范的此版本。
4. One optional parameter, ALT-ADDRESS, is added to the MAIL and RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII address which can be used as a substitute for the corresponding primary (i18mail) address when downgrading. More discussion of the use of this parameter appears in [RFC4952] and [Downgrade].
4. SMTP的MAIL和RCPT命令中添加了一个可选参数ALT-ADDRESS。ALT-ADDRESS指定一个全ASCII地址，在降级时，该地址可用作相应主（i18mail）地址的替代地址。有关此参数使用的更多讨论，请参见[RFC4952]和[降级]。
5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN commands. The parameter UTF8REPLY has no value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.
5. VRFY和EXPN命令中添加了一个可选参数“UTF8REPLY”。参数UTF8REPLY没有值。该参数表示SMTP客户端可以在VRFY和EXPN命令的回复中接受UTF-8编码的Unicode字符。
6. No additional SMTP verbs are defined by this extension.
6. 此扩展未定义其他SMTP谓词。
7. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC1652].
7. 提供此扩展的服务器必须支持并宣布8BITMIME扩展[RFC1652]。
8. 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).
8. SMTP邮件和RCPT命令的反向路径和正向路径已扩展，以允许在邮箱名称（地址）中使用UTF-8编码的Unicode字符。
9. The mail message body is extended as specified in [RFC5335].
9. 邮件正文按照[RFC5335]中的规定进行扩展。
10. The maximum length of MAIL and RCPT command lines is increased by 460 characters by the possible addition of the ALT-ADDRESS keyword and value.
10. 通过可能添加ALT-ADDRESS关键字和值，MAIL和RCPT命令行的最大长度增加了460个字符。
11. The UTF8SMTP extension is valid on the submission port [RFC4409].
11. UTF8SMTP扩展在提交端口[RFC4409]上有效。
An SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 2821 specifies that a mailbox can appear. That string MUST be parsed only as specified in RFC 2821, i.e., by separating the mailbox into source route, local part, and domain part, using only the characters colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. Once isolated by this parsing process, the local part MUST be treated as opaque unless the SMTP server is the final delivery Mail Transfer Agent (MTA). Any domain names that are to be looked up in the DNS MUST first be processed into the form specified in "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] by means of the ToASCII() operation unless they are already in that form. Any domain names that are to be compared to local strings SHOULD be checked for validity and then MUST be compared as specified in Section 3.4 of IDNA.
宣布此扩展的SMTP服务器必须准备好在RFC 2821指定可以显示邮箱的任何位置接受UTF-8字符串[RFC3629]。该字符串必须仅按照RFC 2821中的规定进行解析，即仅使用此处规定的冒号（U+003A）、逗号（U+002C）和at符号（U+0040）将邮箱分为源路由、本地部分和域部分。通过此解析过程隔离后，必须将本地部分视为不透明部分，除非SMTP服务器是最终传递邮件传输代理（MTA）。必须首先通过ToASCII（）操作将要在DNS中查找的任何域名处理为“应用程序中的域名国际化（IDNA）”[RFC3490]中指定的格式，除非它们已经是该格式。应检查要与本地字符串进行比较的任何域名的有效性，然后必须按照IDNA第3.4节的规定进行比较。
An SMTP client that receives the UTF8SMTP 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 [RFC5335] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as either ACE (ASCII Compatible Encoding) labels (as specified in IDNA [RFC3490]) or UTF-8 strings. All labels in domain parts of mailbox names which are IDNs (either UTF-8 or ACE strings) MUST be valid. If the original client submits a message to a Message Submission Server ("MSA") [RFC4409], it is the responsibility of the MSA that all domain labels are valid; otherwise, it is the original client's responsibility. The presence of the UTF8SMTP extension does not change the requirement of RFC 2821 that servers relaying mail MUST NOT attempt to parse, evaluate, or transform the local part in any way.
接收UTF8SMTP extension关键字以响应EHLO命令的SMTP客户端可以将SMTP命令中的邮箱名称作为UTF-8格式的国际化字符串进行传输。它可以发送UTF-8头[RFC5335]（也可以包括UTF-8中的邮箱名称）。它可以将SMTP命令中邮箱名称的域部分或邮件头作为ACE（ASCII兼容编码）标签（如IDNA[RFC3490]中所述）或UTF-8字符串传输。邮箱名称的域部分中IDN（UTF-8或ACE字符串）的所有标签必须有效。如果原始客户端向消息提交服务器（“MSA”）[RFC4409]提交消息，则MSA有责任确保所有域标签有效；否则，由原客户负责。UTF8SMTP扩展的存在不会改变RFC 2821的要求，即中继邮件的服务器不得尝试以任何方式解析、计算或转换本地部分。
If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP client MUST NOT transmit an internationalized address and MUST NOT transmit a mail message containing internationalized mail headers as described in [RFC5335] at any level within its MIME structure. (For this paragraph, the internationalized domain name in the form of ACE labels as specified in IDNA [RFC3490] is not considered as "internationalized".) Instead, if an SMTP client (SMTP sender) attempts to transfer an internationalized message and encounters a server that does not support the extension, it MUST make one of the following four choices:
如果服务器未提供UTF8SMTP SMTP扩展，SMTP客户端不得传输国际化地址，也不得在其MIME结构的任何级别传输包含[RFC5335]中所述国际化邮件头的邮件消息。（对于本段，IDNA[RFC3490]中规定的ACE标签形式的国际化域名不被视为“国际化”。）相反，如果SMTP客户端（SMTP发件人）尝试传输国际化邮件，但遇到不支持扩展的服务器，它必须做出以下四个选择之一：
1. If and only if the SMTP client (sender) is a Message Submission Server ("MSA") [RFC4409], it MAY, consistent with the general provisions for changes by such servers, rewrite the envelope, headers, or message material to make them entirely ASCII and consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822].
1. 如果且仅当SMTP客户端（发送方）是邮件提交服务器（“MSA”）[RFC4409]，它可以按照此类服务器更改的一般规定，重写信封、标题或邮件材料，使其完全符合ASCII，并符合RFC 2821[RFC2821]和RFC 2822[RFC2822]的规定。
2. It may either reject the message during the SMTP transaction or accept the message and then generate and transmit a notification of non-deliverability. Such notification MUST be done as specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI delivery status notification (DSN) specification [RFC5337].
2. 它可以在SMTP事务期间拒绝邮件，也可以接受邮件，然后生成并传输不可交付性通知。此类通知必须按照RFC 2821[RFC2821]、RFC 3464[RFC3464]和EAI交付状态通知（DSN）规范[RFC5337]的规定进行。
3. It may find an alternate route to the destination that permits UTF8SMTP. That route may be discovered by trying alternate Mail eXchanger (MX) hosts (using preference rules as specified in RFC 2821) or using other means available to the SMTP-sender.
3. 它可能会找到到允许UTF8SMTP的目标的备用路由。可以通过尝试备用邮件交换器（MX）主机（使用RFC 2821中指定的首选项规则）或使用SMTP发件人可用的其他方式来发现该路由。
4. If and only if ASCII addresses are available for all addresses that appear in the return path and the specific forward paths being attempted, it may downgrade the message to an all-ASCII
4. 如果且仅当ASCII地址可用于返回路径中出现的所有地址和正在尝试的特定转发路径时，它可能会将消息降级为全部ASCII地址
form as specified in [Downgrade]. An ASCII address is considered to be "available" for a particular address if the original address in the envelope is in ASCII or if an ALT-ADDRESS parameter is specified for a UTF8SMTP address.
按照[降级]中的规定填写表格。如果信封中的原始地址为ASCII格式，或者如果为UTF8SMTP地址指定了ALT-address参数，则ASCII地址被视为特定地址的“可用”。
The difference between choice 1 and choice 4 is that choice 1 is constrained by Message Submission [RFC4409], while choice 4 is constrained by [Downgrade].
选项1和选项4之间的区别在于，选项1受消息提交[RFC4409]的约束，而选项4受[降级]的约束。
RFC 2821, Section 4.1.2, defines the syntax of a mailbox entirely in terms of ASCII characters, using the production for a mailbox and those productions on which it depends.
RFC 2821第4.1.2节使用邮箱的产品及其所依赖的产品，完全按照ASCII字符定义邮箱的语法。
The key changes made by this specification are, informally, to
非正式地说，本规范所做的主要变更如下：
o Change the definition of "sub-domain" to permit either the definition above or a UTF-8 string representing a DNS label that is conformant with IDNA [RFC3490].
o 更改“子域”的定义，以允许上述定义或表示符合IDNA[RFC3490]的DNS标签的UTF-8字符串。
o Change the definition of "Atom" to permit either the definition above or a UTF-8 string. That string MUST NOT contain any of the ASCII characters (either graphics or controls) that are not permitted in "atext"; it is otherwise unrestricted.
o 更改“Atom”的定义以允许上面的定义或UTF-8字符串。该字符串不得包含“atext”中不允许的任何ASCII字符（图形或控件）；它在其他方面是不受限制的。
According to the description above, the syntax of an internationalized email mailbox name (address) is defined in ABNF [RFC5234] as follows.
根据上述描述，国际化电子邮件邮箱名称（地址）的语法在ABNF[RFC5234]中定义如下。
uMailbox = uLocal-part "@" uDomain ; Replace Mailbox in RFC 2821, Section 4.1.2
uMailbox=uLocal零件“@”uDomain；替换RFC 2821第4.1.2节中的邮箱
uLocal-part = uDot-string / uQuoted-string ; MAY be case-sensitive ; Replace Local-part in RFC 2821, Section 4.1.2
uLocal部分=uDot字符串/uQuoted字符串；可能区分大小写；更换RFC 2821第4.1.2节中的局部零件
uDot-string = uAtom *("." uAtom) ; Replace Dot-string in RFC 2821, Section 4.1.2
uDot字符串=uAtom*（“”uAtom）；替换RFC 2821第4.1.2节中的点字符串
uAtom = 1*ucharacter
; Replace Atom in RFC 2821, Section 4.1.2
uAtom = 1*ucharacter
; Replace Atom in RFC 2821, Section 4.1.2
ucharacter = atext / UTF8-non-ascii
ucharacter = atext / UTF8-non-ascii
atext = <See Section 3.2.4 of RFC 2822>
atext = <See Section 3.2.4 of RFC 2822>
uQuoted-string = DQUOTE *uqcontent DQUOTE ; Replace Quoted-string in RFC 2821, Section 4.1.2
uquote字符串=DQUOTE*uqcontent DQUOTE；替换RFC 2821第4.1.2节中引用的字符串
DQUOTE = <See appendix B.1 of RFC 5234>
DQUOTE = <See appendix B.1 of RFC 5234>
uqcontent = qcontent / UTF8-non-ascii
uqcontent = qcontent / UTF8-non-ascii
qcontent = <See Section 3.2.5 of RFC 2822>
qcontent = <See Section 3.2.5 of RFC 2822>
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal
; Replace Domain in RFC 2821, Section 4.1.2
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal
; Replace Domain in RFC 2821, Section 4.1.2
address-literal = <See Section 4.1.2 of RFC 2822>
address-literal = <See Section 4.1.2 of RFC 2822>
sub-udomain = uLet-dig [uLdh-str] ; Replace sub-domain in RFC 2821, Section 4.1.2
亚udomain=uLet dig[uLdh str]；替换RFC 2821第4.1.2节中的子域
uLet-dig = Let-dig / UTF8-non-ascii
uLet-dig = Let-dig / UTF8-non-ascii
Let-dig = <See Section 4.1.3 of RFC 2821>
Let-dig = <See Section 4.1.3 of RFC 2821>
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig
; Replace Ldh-str in RFC 2821, Section 4.1.3
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig
; Replace Ldh-str in RFC 2821, Section 4.1.3
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <See Section 4 of RFC 3629>
UTF8-2 = <See Section 4 of RFC 3629>
UTF8-3 = <See Section 4 of RFC 3629>
UTF8-3 = <See Section 4 of RFC 3629>
UTF8-4 = <See Section 4 of RFC 3629>
UTF8-4 = <See Section 4 of RFC 3629>
The value of "uDomain" SHOULD be verified by applying the tests specified as part of IDNA [RFC3490]. If that verification fails, the email address with that uDomain MUST NOT be regarded as a valid email address.
应通过应用IDNA[RFC3490]中规定的试验来验证“uDomain”的值。如果验证失败，则带有该域的电子邮件地址不得视为有效的电子邮件地址。
If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and RCPT commands is extended to support the optional esmtp-keyword "ALT-ADDRESS". That keyword specifies an alternate all-ASCII address that may be used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value, which is defined below).
如果提供UTF8SMTP扩展名，SMTP邮件和RCPT命令的语法将被扩展以支持可选的esmtp关键字“ALT-ADDRESS”。该关键字指定降级时可能使用的备用全部ASCII地址。如果使用ALT-ADDRESS esmtp关键字，则它必须具有关联的esmtp值（ALT-ADDRESS esmtp值，定义如下）。
While it may be tempting to consider ALT-ADDRESS as a general-purpose second-chance address, such behavior is not defined here. Instead, in this specification ALT-ADDRESS only has meaning when the associated primary address is non-ASCII and the message is downgraded. This restriction allows for future extension of the specification even though no such extensions are currently anticipated.
虽然考虑ALT-Advor作为通用第二机会地址可能是诱人的，但此处没有定义这样的行为。相反，在本规范中，ALT-ADDRESS仅在相关主地址为非ASCII且消息降级时才有意义。这一限制允许规范的未来扩展，即使目前没有预期此类扩展。
Based on the definition of mail-parameters in [RFC2821], the ALT-ADDRESS parameter usage in the commands of MAIL and RCPT is defined as follows. The following definitions are given in the same format as used in RFC 2821.
根据[RFC2821]中邮件参数的定义，mail和RCPT命令中的ALT-ADDRESS参数用法定义如下。以下定义的格式与RFC 2821中使用的格式相同。
"MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF
; Update the MAIL command in RFC 2821, Section 4.1.1.2.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param> in RFC 2821.
"MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF
; Update the MAIL command in RFC 2821, Section 4.1.1.2.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param> in RFC 2821.
"RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" /
uForward-path) [ SP Rcpt-parameters ] CRLF
; Update RCPT command in RFC 2821, Section 4.1.1.3.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param>.
; uDomain is defined in Section 3.3 of this document.
"RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" /
uForward-path) [ SP Rcpt-parameters ] CRLF
; Update RCPT command in RFC 2821, Section 4.1.1.3.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param>.
; uDomain is defined in Section 3.3 of this document.
uReverse-path = uPath ; Replace Reverse-path in RFC 2821, Section 4.1.2.
uReverse路径=上行路径；替换RFC 2821第4.1.2节中的反向路径。
uForward-path = uPath ; Replace Forward-path in RFC 2821, Section 4.1.2.
uForward路径=上行路径；替换RFC 2821第4.1.2节中的正向路径。
uPath = "<" [ A-d-l ":" ] uMailbox ">" ; Replace Path in RFC 2821, Section 4.1.2. ; uMailbox is defined in Section 3.3 of this document.
uPath=“<”[A-d-l:“]uMailbox”>”；替换RFC 2821第4.1.2节中的路径；uMailbox在本文件第3.3节中有定义。
A-d-l = <See Section 4.1.2 of RFC 2821>
A-d-l = <See Section 4.1.2 of RFC 2821>
ALT-ADDRESS-parameter = "ALT-ADDRESS=" ALT-ADDRESS-value
ALT-ADDRESS参数=“ALT-ADDRESS=”ALT-ADDRESS值
ALT-ADDRESS-value = xtext ; The value is a mailbox name encoded as xtext.
ALT地址值=xtext；该值是编码为xtext的邮箱名称。
xtext = <See Section 4.2 of RFC 3461>
xtext = <See Section 4.2 of RFC 3461>
The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email address before xtext encoding.
ALT ADDRESS参数在任何MAIL或RCPT命令中不得出现多次。在xtext编码之前，ALT ADDRESS esmtp值必须是所有ASCII电子邮件地址。
An "internationalized message" as defined in the appendix of this specification MUST NOT be sent to an SMTP server that does not support UTF8SMTP. Such a message MAY be rejected by a server if it lacks ALT-ADDRESSes as discussed in Section 3.2 of this specification.
不得将本规范附录中定义的“国际化邮件”发送到不支持UTF8SMTP的SMTP服务器。如果缺少本规范第3.2节中讨论的ALT地址，则服务器可能会拒绝此类消息。
The three-digit reply codes used in this section are consistent with their meanings as defined in RFC 2821.
本节中使用的三位数回复代码与RFC 2821中定义的含义一致。
When messages are rejected because the RCPT command requires an ALT-ADDRESS, the response code 553 is used with the meaning "mailbox name not allowed". When messages are rejected for other reasons, such as the MAIL command requiring an ALT-ADDRESS, the response code 550 is used with the meaning "mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], response code "X.6.7" [RFC5248] is used, meaning that "The ALT-ADDRESS is required but not specified".
当由于RCPT命令需要ALT-ADDRESS而拒绝邮件时，响应代码553的含义为“邮箱名称不允许”。当消息由于其他原因被拒绝时，例如需要ALT-ADDRESS的MAIL命令，响应代码550的含义是“邮箱不可用”。当服务器支持增强型邮件系统状态代码[RFC3463]时，使用响应代码“X.6.7”[RFC5248]，表示“需要ALT-ADDRESS，但未指定”。
If the response code is issued after the final "." of the DATA command, the response code "554" is used with the meaning "Transaction failed". When the server supports enhanced mail system status codes [RFC3463], response code "X.6.9" [RFC5248] is used, meaning that "UTF8SMTP downgrade failed".
如果响应代码是在数据命令的最后一个“.”之后发出的，则使用响应代码“554”表示“事务失败”。当服务器支持增强型邮件系统状态代码[RFC3463]时，使用响应代码“X.6.9”[RFC5248]，表示“UTF8SMTP降级失败”。
There is no ESMTP parameter to assert that a message is an internationalized message. An SMTP server that requires accurate knowledge of whether a message is internationalized is required to parse all message header fields and MIME header fields in the message body.
没有ESMTP参数可以断言消息是国际化消息。需要准确了解邮件是否国际化的SMTP服务器才能解析邮件正文中的所有邮件头字段和MIME头字段。
While this specification requires that servers support the 8BITMIME extension [RFC1652] to ensure that servers have adequate handling capability for 8-bit data and to avoid a number of complex encoding problems, the use of internationalized addresses obviously does not require non-ASCII body parts in the MIME message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME parameter if that is appropriate given the body content or, with the BODY=BINARYMIME parameter, if the server advertises BINARYMIME [RFC3030] and that is appropriate.
虽然本规范要求服务器支持8BITMIME扩展[RFC1652]，以确保服务器具有足够的8位数据处理能力，并避免许多复杂的编码问题，但使用国际化地址显然不需要MIME消息中的非ASCII正文部分。UTF8SMTP扩展名可与BODY=8BITMIME参数一起使用，如果该参数在给定BODY内容时适用，或者与BODY=BINARYMIME参数一起使用，如果服务器播发BINARYMIME[RFC3030]且该参数适用。
Assuming that the server advertises UTF8SMTP and 8BITMIME, and receives at least one non-ASCII address, with or without ALT-ADDRESS, the precise interpretation of 'No BODY parameter', "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is:
假设服务器播发UTF8SMTP和8BITMIME，并接收至少一个非ASCII地址（带或不带ALT-address），则MAIL命令中“无正文参数”、“正文=8BITMIME”和“正文=BINARYMIME”的精确解释为：
1. If there is no BODY parameter, the header contains UTF-8 characters, but all the body parts are in ASCII (possibly as the result of a content-transfer-encoding).
1. 如果没有正文参数，则标头包含UTF-8字符，但所有正文部分均为ASCII格式（可能是内容传输编码的结果）。
2. If a BODY=8BITMIME parameter is present, the header contains UTF-8 characters, and some or all of the body parts contain 8-bit line-oriented data.
2. 如果存在BODY=8BITMIME参数，则标头包含UTF-8字符，并且某些或所有正文部分包含8位面向行的数据。
3. If a BODY=BINARYMIME parameter is present, the header contains UTF-8 characters, and some or all body parts contain binary data without restriction as to line lengths or delimiters.
3. 如果存在BODY=BINARYMIME参数，则标头包含UTF-8字符，并且某些或所有正文部分包含二进制数据，而不受行长或分隔符的限制。
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 2821 specifies a mailbox, this specification expects UTF-8 to be used for the entire string; when RFC 2821 specifies a domain name, the name SHOULD be in the form of ACE labels if its raw form is non-ASCII.
邮件传输过程中携带的信息包括各种上下文中的地址（“邮箱”）和域名，以及mail和RCPT命令和扩展的替代命令。一般来说，规则是，当RFC 2821指定邮箱时，该规范要求对整个字符串使用UTF-8；当RFC 2821指定域名时，如果其原始形式为非ASCII，则该名称应采用ACE标签的形式。
The following subsections list and discuss all of the relevant cases.
以下小节列出并讨论了所有相关案例。
When an SMTP connection is opened, the server normally sends a "greeting" response consisting of the 220 response code and some information. The client then sends the EHLO command. Since the client cannot know whether the server supports UTF8SMTP until after it receives the response from EHLO, any domain names that appear in this dialogue, or in responses to EHLO, MUST be in the hostname form, i.e., internationalized ones MUST be in the form of ACE labels.
当SMTP连接打开时，服务器通常会发送一个由220响应代码和一些信息组成的“问候”响应。然后，客户端发送EHLO命令。由于客户端在收到来自EHLO的响应之前无法知道服务器是否支持UTF8SMTP，因此此对话框中出现的或响应EHLO的任何域名必须采用主机名形式，即国际化域名必须采用ACE标签的形式。
Organizations often authorize multiple servers to accept mail addressed to them. For example, the organization may itself operate more than one server, and may also or instead have an agreement with other organizations to accept mail as a backup. Authorized servers are generally listed in MX records as described in RFC 2821. When more than one server accepts mail for the domain-part of a mailbox, it is strongly advised that either all or none of them support the UTF8SMTP extension. Otherwise, surprising downgrades can happen during temporary failures, which users might perceive as a serious reliability issue.
组织通常授权多台服务器接受发往它们的邮件。例如，组织本身可以操作多台服务器，也可以与其他组织签订协议，接受邮件作为备份。授权服务器通常列在MX记录中，如RFC 2821所述。当一个邮箱的域部分有多个服务器接受邮件时，强烈建议它们全部或全部不支持UTF8SMTP扩展。否则，在临时故障期间可能会发生意外降级，用户可能会认为这是一个严重的可靠性问题。
When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content. "Time stamp" or "Received" appears in the form of "Received:" lines. The most important use of Received: lines is for debugging mail faults. When the delivery SMTP server makes the "final delivery" of a message, it inserts a Return-path line at the beginning of the mail data. The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For the trace information, this memo updates the time stamp line and the return path line [RFC2821] formally defined as follows:
当SMTP服务器接收到要传递或进一步处理的邮件时，它必须在邮件内容的开头插入跟踪（“时间戳”或“已接收”）信息。“时间戳”或“已接收”以“已接收：”行的形式出现。Received:行最重要的用途是调试邮件故障。当传递SMTP服务器对邮件进行“最终传递”时，它会在邮件数据的开头插入一个返回路径行。返回路径的主要目的是指定指示未送达或其他邮件系统故障的消息要发送到的地址。对于跟踪信息，此备忘录更新正式定义的时间戳行和返回路径行[RFC2821]，如下所示：
uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF>
; Replaces Return-path-line in Section 4.4 of RFC 2821
; uReverse-path is defined in Section 3.3 of this document
uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF>
; Replaces Return-path-line in Section 4.4 of RFC 2821
; uReverse-path is defined in Section 3.3 of this document
uTime-stamp-line = "Received:" FWS uStamp <CRLF>
; Replaces Time-stamp-line in Section 4.4 of RFC 2821
uTime-stamp-line = "Received:" FWS uStamp <CRLF>
; Replaces Time-stamp-line in Section 4.4 of RFC 2821
uStamp = From-domain By-domain uOpt-info ";" FWS date-time ; Replaces Stamp in Section 4.4 of RFC 2821
uStamp=来自各个域的uOpt信息“；“FWS日期时间；替换RFC 2821第4.4节中的印章
uOpt-info = [Via] [With] [ID] [uFor]
; Replaces Opt-info in Section 4.4 of RFC 2821
; The protocol value for With will allow a UTF8SMTP value
uOpt-info = [Via] [With] [ID] [uFor]
; Replaces Opt-info in Section 4.4 of RFC 2821
; The protocol value for With will allow a UTF8SMTP value
uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
; Replaces For in Section 4.4 of RFC 2821
; uPath and uMailbox are defined in Sections 2.4 and
; 2.3, respectively, of this document
uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
; Replaces For in Section 4.4 of RFC 2821
; uPath and uMailbox are defined in Sections 2.4 and
; 2.3, respectively, of this document
Note: The FOR parameter has been changed to match the definition in [RFC2821bis], permitting only one address in the For clause. The group working on that document reached mailing list consensus that the syntax in [RFC2821] that permitted more than one address was simply a mistake.
注意：FOR参数已更改为与[RFC2821bis]中的定义相匹配，只允许FOR子句中有一个地址。编写该文件的小组达成了邮件列表共识，[RFC2821]中允许多个地址的语法只是一个错误。
Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII domain names may be used, internationalized domain names in Received fields MUST be transmitted in the form of ACE labels. The protocol value of the WITH clause when this extension is used is one of the UTF8SMTP values specified in the "IANA Considerations" section of this document.
除了可以使用非ASCII域名的“uFor”子句和“uReverse path”值外，接收字段中的国际化域名必须以ACE标签的形式传输。使用此扩展时WITH子句的协议值是本文档“IANA注意事项”部分中指定的UTF8SMTP值之一。
If the client issues a RCPT command containing non-ASCII characters, the SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 response codes.
如果客户端发出包含非ASCII字符的RCPT命令，则允许SMTP服务器在与251和551响应代码关联的电子邮件地址中使用UTF-8字符。
If an SMTP client follows this specification and sends any RCPT commands containing non-ASCII addresses, it MUST be able to accept and process 251 or 551 responses containing UTF-8 email addresses. If a given RCPT command does not include a non-ASCII envelope address, the 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 addresses.
如果SMTP客户端遵循此规范并发送任何包含非ASCII地址的RCPT命令，则它必须能够接受和处理包含UTF-8电子邮件地址的251或551响应。如果给定的RCPT命令不包括非ASCII信封地址，则服务器不得返回包含非ASCII邮箱的251或551响应。相反，它必须将这些响应转换为250或550个不包含地址的响应。
If the VRFY and EXPN commands are transmitted with an optional parameter "UTF8REPLY", it indicates the client can accept UTF-8 strings in replies from those commands. This allows the server to use UTF-8 strings in mailbox names and full names that occur in replies without concern that the client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies from the VRFY and EXPN commands that contain UTF-8 strings. However, the SMTP server MUST NOT use UTF-8
如果使用可选参数“UTF8REPLY”传输VRFY和EXPN命令，则表示客户端可以在这些命令的回复中接受UTF-8字符串。这允许服务器在回复中出现的邮箱名和全名中使用UTF-8字符串，而不必担心客户端可能会被它们混淆。符合此规范的SMTP客户端必须接受并正确处理来自包含UTF-8字符串的VRFY和EXPN命令的回复。但是，SMTP服务器不得使用UTF-8
strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter. Most replies do not require that a mailbox name be included in the returned text, and therefore UTF-8 is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox, making the provisions of this section important.
如果SMTP客户端未通过传输此参数明确允许此类回复，则回复中的字符串。大多数回复不要求在返回的文本中包含邮箱名称，因此不需要UTF-8。一些回复，尤其是成功执行VRFY和EXPN命令后产生的回复，确实包含邮箱，因此本节的规定非常重要。
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
验证（VRFY）和扩展（EXPN）命令语法已更改为：
"VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF ; uLocal-part and uMailbox are defined in ; Section 3.3 of this document.
“VRFY”SP（uLocal部件/uMailbox）[SP“UTF8REPLY”]CRLF；uLocal部件和uMailbox在中定义；本文件第3.3节。
"EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF ; uLocal-part and uMailbox are defined in ; Section 3.3 of this document.
“EXPN”SP（uLocal部件/uMailbox）[SP“UTF8REPLY”]CRLF；uLocal部件和uMailbox在中定义；本文件第3.3节。
The "UTF8REPLY" parameter does not use a value. If the reply to a VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP client does not use the "UTF8REPLY" parameter, then the server MUST use either the response code 252 or 550. Response code 252, defined in [RFC2821], means "Cannot VRFY user, but will accept the message and attempt the delivery". Response code 550, also defined in [RFC2821], means "Requested action not taken: mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], the enhanced response code as specified below is used. Using the "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that command only.
“UTF8REPLY”参数不使用值。如果对验证（VRFY）或扩展（EXPN）命令的回复需要UTF-8，但SMTP客户端不使用“UTF8REPLY”参数，则服务器必须使用响应代码252或550。[RFC2821]中定义的响应代码252表示“无法接收用户，但将接受消息并尝试传递”。响应代码550（也在[RFC2821]中定义）表示“未采取请求的操作：邮箱不可用”。当服务器支持增强型邮件系统状态代码[RFC3463]时，将使用下面指定的增强型响应代码。将“UTF8REPLY”参数与VERIFY（VRFY）或EXPN（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 <uMailbox> ; uMailbox is defined in Section 3.3 of this document. ; User Name can contain non-ASCII characters.
用户名<uMailbox>；uMailbox在本文件第3.3节中有定义；用户名可以包含非ASCII字符。
uMailbox ; uMailbox is defined in Section 3.3 of this document.
uMailbox；uMailbox在本文件第3.3节中有定义。
If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in the reply, and the server supports enhanced mail system status codes [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" [RFC5248], 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 client".
如果SMTP回复需要UTF-8字符串，但在回复中不允许UTF-8，并且服务器支持增强邮件系统状态代码[RFC3463]，则增强响应代码为“X.6.8”或“X.6.10”[RFC5248]，这意味着“需要包含UTF-8字符串的回复来显示邮箱名称，但客户端不允许这种形式的响应。”。
If the SMTP client does not support the UTF8SMTP 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 crash. Internationalized messages in replies are only allowed in the commands under the situations described above. Under any other circumstances, UTF-8 text MUST NOT appear in the reply.
如果SMTP客户端不支持UTF8SMTP扩展，但在答复中收到UTF-8字符串，则可能无法向用户正确报告答复，并且某些客户端可能会崩溃。在上述情况下，答复中的国际化消息仅允许在命令中使用。在任何其他情况下，答复中不得出现UTF-8文本。
Although UTF-8 is needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 for any other purposes. SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section.
尽管根据本节规定的规则，需要UTF-8来表示回复中的电子邮件地址，但此扩展不允许将UTF-8用于任何其他目的。SMTP服务器不得在回复中包含非ASCII字符，本节特别允许的有限情况除外。
IANA has added a new value "UTF8SMTP" to the SMTP Service Extension subregistry of the Mail Parameters registry, according to the following data:
IANA已根据以下数据向邮件参数注册表的SMTP服务扩展子区添加了一个新值“UTF8SMTP”：
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| UTF8SMTP | Internationalized email address | [RFC5336] |
+----------+---------------------------------+-----------+
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| UTF8SMTP | Internationalized email address | [RFC5336] |
+----------+---------------------------------+-----------+
This document adds new values to the SMTP Enhanced Status Code subregistry of the Mail Parameters registry, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and being based on [RFC5248]. The registration data is as follows:
本文件根据本文件第3.5节和第3.7.4.2节中的指导，并基于[RFC5248]，向邮件参数注册表的SMTP增强状态代码子区添加新值。登记资料如下：
Code: X.6.7 Sample Text: The ALT-ADDRESS is required but not specified Associated basic status code: 553, 550 Description: This indicates the reception of a MAIL or RCPT command that required an ALT-ADDRESS parameter but such parameter was not present. Defined: RFC 5336 (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
代码：X.6.7示例文本：ALT-ADDRESS是必需的，但未指定相关的基本状态代码：553550说明：这表示接收到需要ALT-ADDRESS参数但该参数不存在的邮件或RCPT命令。定义：RFC 5336（实验轨道）提交人：姚建康变更控制员：IESG。
Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the client Associated basic status code: 553, 550 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 client. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
代码：X.6.8示例文本：需要UTF-8字符串回复，但客户端关联的基本状态代码不允许：553550说明：这表示需要包含UTF-8字符串的回复来显示邮箱名称，但客户端不允许这种形式的响应。定义：RFC 5336。（实验曲目）提交人：姚建康变更控制员：IESG。
Code: X.6.9 Sample Text: UTF8SMTP downgrade failed Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
代码：X.6.9示例文本：UTF8SMTP降级失败关联的基本状态代码：550说明：这表示在数据命令的最后一个“.”之后事务失败。定义：RFC 5336。（实验曲目）提交人：姚建康变更控制员：IESG。
Code: X.6.10 Sample Text: UTF-8 string reply is required, but not permitted by the client Associated basic status code: 252 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 client. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
代码：X.6.10示例文本：需要UTF-8字符串回复，但客户端关联的基本状态代码不允许：252说明：这表示需要包含UTF-8字符串的回复来显示邮箱名称，但客户端不允许该响应形式。定义：RFC 5336。（实验曲目）提交人：姚建康变更控制员：IESG。
The "Mail Transmission Types" registry under the Mail Parameters registry is requested to be updated to include the following new entries:
要求更新邮件参数注册表下的“邮件传输类型”注册表，以包括以下新条目：
+---------------+----------------------------+----------------------+
| WITH protocol | Description | Reference |
| types | | |
+---------------+----------------------------+----------------------+
| UTF8SMTP | UTF8SMTP with Service | [RFC5336] |
| | Extensions | |
| UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFC5336] |
| UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFC5336] |
| UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] |
| | STARTTLS and SMTP AUTH | [RFC5336] |
+---------------+----------------------------+----------------------+
+---------------+----------------------------+----------------------+
| WITH protocol | Description | Reference |
| types | | |
+---------------+----------------------------+----------------------+
| UTF8SMTP | UTF8SMTP with Service | [RFC5336] |
| | Extensions | |
| UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFC5336] |
| UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFC5336] |
| UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] |
| | STARTTLS and SMTP AUTH | [RFC5336] |
+---------------+----------------------------+----------------------+
See the extended security considerations discussion in the framework document [RFC4952].
请参阅框架文档[RFC4952]中的扩展安全注意事项讨论。
Much of the text in the initial version of this specification was derived or copied from [Emailaddr] with the permission of the author. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the WG 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, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here.
本规范初始版本中的大部分文本是在作者许可下从[Emailaddr]派生或复制的。收到了来自李晓东、徐乃文、高阳宇、Yoshiro YONEYA和喷气机团队其他成员的重要意见和建议，并将其纳入规范。工作组和设计团队的许多成员提供了额外的重要意见和建议，通常还有具体的文本。这些贡献包括来自约翰·克莱辛、查尔斯·林赛、戴夫·克罗克、哈拉尔·特维特·阿尔维斯特朗、马科斯·桑兹、克里斯·纽曼、马丁·杜尔斯、埃德蒙·钟、托尼·芬奇、卡里·赫塔、兰德尔·盖伦斯、弗兰克·埃勒曼、阿列克谢·梅尔尼科夫、皮特·雷斯尼克、S·穆内萨米、李秀波、肖恩·斯蒂尔、阿尔弗雷德·霍恩斯、米格尔·加西亚、马格纳斯·韦斯特隆德的材料，还有拉尔斯·艾格特。当然，没有一个人必须对这里所代表的思想组合负责。
[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年。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[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月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[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月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409]Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年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", BCP 138, RFC 5248, June 2008.
[RFC5248]Hansen，T.和J.Klensin，“SMTP增强邮件系统状态代码的注册表”，BCP 138，RFC 5248，2008年6月。
[RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]Abel，Y.，编辑，“国际化电子邮件标题”，RFC 53352008年9月。
[RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
[RFC5337]Newman，C.和A.Melnikov，编辑，“国际化交付状态和处置通知”，RFC 5337，2008年9月。
[Downgrade] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
[降级]Fujiwara，K.和Y.Yoneya，“电子邮件地址国际化的降级机制”，正在进行的工作，2008年7月。
[Emailaddr] Klensin, J., "Internationalization of Email Addresses", Work in Progress, July 2005.
[Emailaddr]Klensin，J.，“电子邮件地址的国际化”，正在进行的工作，2005年7月。
[RFC0974] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
[RFC0974]帕特里奇，C.，“邮件路由和域系统”，RFC974，1986年1月。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033]迈尔斯，J.，“本地邮件传输协议”，RFC20331996年10月。
[RFC2821bis] Klensin, J., "Simple Mail Transfer Protocol", Work in Progress, July 2008.
[RFC2821bis]Klensin，J.，“简单邮件传输协议”，正在进行的工作，2008年7月。
[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., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954]Siemborski，R.，Ed.和A.Melnikov，Ed.，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
RFC 4952, the overview and framework document covering this set of extensions for internationalized email, was completed before this specification, which specifies a particular part of the protocol set. This appendix, which is normative, contains material that would have been incorporated into RFC 4952 had it been delayed until the work described in the rest of this specification was completed. This material should be included in any update to RFC 4952.
RFC 4952是涵盖这组国际化电子邮件扩展的概述和框架文档，它是在本规范之前完成的，该规范指定了协议集的特定部分。本附录为规范性附录，包含本规范其余部分所述工作完成后才纳入RFC 4952的材料。该材料应包含在RFC 4952的任何更新中。
o A conventional message is one that does not use any extension defined in this document or in the UTF-8 header specification [RFC5335], and which is strictly conformant to RFC 2822 [RFC2822].
o 传统消息不使用本文档或UTF-8头规范[RFC5335]中定义的任何扩展，并且严格符合RFC 2822[RFC2822]。
o An internationalized message is a message utilizing one or more of the extensions defined in this specification or in the UTF-8 header specification [RFC5335], so that it is no longer conformant to the RFC 2822 specification of a message.
o 国际化消息是使用本规范或UTF-8标头规范[RFC5335]中定义的一个或多个扩展的消息，因此它不再符合消息的RFC 2822规范。
LMTP [RFC2033] may be used as the final delivery agent. In such cases, LMTP may be arranged to deliver the mail to the mail store. The mail store may not have UTF8SMTP capability. LMTP needs to be updated to deal with these situations.
LMTP[RFC2033]可用作最终交付代理。在这种情况下，可以安排LMTP将邮件递送到邮件商店。邮件存储可能没有UTF8SMTP功能。需要更新LMTP以应对这些情况。
The existing Draft Standard regarding delivery status notifications (DSNs) [RFC3461] is limited to ASCII text in the machine readable portions of the protocol. "International Delivery Status and Disposition Notifications" [RFC5337] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the UTF8SMTP and the DSN extension, that server MUST implement EAI DSN [RFC5337] including support for the ORCPT parameter.
关于交付状态通知（DSN）[RFC3461]的现有标准草案仅限于协议机器可读部分中的ASCII文本。“国际传递状态和处置通知”[RFC5337]为国际电子邮件地址添加了新的地址类型，因此即使降级后，也可以正确保留具有非ASCII字符的原始收件人地址。如果SMTP服务器同时播发UTF8SMTP和DSN扩展，则该服务器必须实现EAI DSN[RFC5337]，包括对ORCPT参数的支持。
In the absence of this extension, SMTP clients and servers are constrained to using only those addresses permitted by RFC 2821. The local parts of those addresses MAY be made up of any ASCII characters, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a
在没有此扩展的情况下，SMTP客户端和服务器仅限于使用RFC 2821允许的地址。这些地址的本地部分可能由任何ASCII字符组成，尽管其中一些字符必须按照其中的规定引用。值得注意的是，在国际化背景下，一些系统使用超粗ASCII字符（a
character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization SHOULD be phased out as this extension becomes widely deployed, but backward-compatibility considerations require that it continue to be supported.
字符、退格和另一个字符），以近似非ASCII字符。随着此扩展的广泛部署，这种形式的国际化应该被逐步淘汰，但是向后兼容性的考虑需要继续支持它。
Among other protocol changes, the SMTP extension allows an optional alternate address to be supplied with the MAIL and RCPT commands. For the purposes of this set of specifications, this alternate address only has meaning when the primary address contains UTF-8 characters and the message is downgraded. While it may be tempting to consider the alternate address as a general-purpose second-chance address to be used whenever the primary address is rejected, such behavior is not defined here. This restriction allows for future extensions to be developed which create such a general-purpose second-chance address, although no specific work on such an extension is currently anticipated. Note that any such extension needs to consider the question of what the [RFC0974] sequencing rules mean when different possible servers support different sets of ESMTP options (or, in this case, addresses). The answer to this question may also imply updates to [RFC2821].
在其他协议更改中，SMTP扩展允许在MAIL和RCPT命令中提供可选的备用地址。就本规范而言，此备用地址仅在主地址包含UTF-8字符且消息降级时才有意义。尽管当主地址被拒绝时，将备用地址视为通用的第二机会地址是很诱人的，但此处没有定义这样的行为。这一限制允许开发将来的扩展来创建这样一个通用的第二次机会地址，尽管目前还没有关于这种扩展的具体工作。注意，任何这样的扩展需要考虑当不同的服务器支持不同的ESMTP选项集（或者，在这种情况下，地址）时，[RCF094]排序规则意味着什么。此问题的答案也可能意味着[RFC2821]的更新。
Authors' Addresses
作者地址
Jiankang YAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
姚建康（编辑）北京中关村南四街4号CNNIC
Phone: +86 10 58813007
EMail: yaojk@cnnic.cn
Phone: +86 10 58813007
EMail: yaojk@cnnic.cn
Wei MAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
魏茂（编辑）北京中关村南四街4号CNNIC
Phone: +86 10 58812230
EMail: maowei_ietf@cnnic.cn
Phone: +86 10 58812230
EMail: maowei_ietf@cnnic.cn
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.