Network Working Group T. Hansen
Request for Comments: 5248 AT&T Laboratories
BCP: 138 J. Klensin
Updates: 3463, 4468, 4954 June 2008
Category: Best Current Practice
Network Working Group T. Hansen
Request for Comments: 5248 AT&T Laboratories
BCP: 138 J. Klensin
Updates: 3463, 4468, 4954 June 2008
Category: Best Current Practice
A Registry for SMTP Enhanced Mail System Status Codes
SMTP增强邮件系统状态代码的注册表
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry.
增强型邮件系统状态代码规范RFC 3463建立了一个新的代码模型，并列出了一组状态代码。虽然它预计随着时间的推移会增加更多的代码，但它没有提供登记和跟踪这些代码的明确机制。本文档指定了邮件系统增强状态代码的IANA注册表，并使用已发布的标准跟踪文档中迄今为止建立的代码以及行业中已建立的其他代码初始化该注册表。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . . 2
2.2. Review Process for New Values . . . . . . . . . . . . . . . 4
2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 4
2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
2.1. SMTP Enhanced Status Codes Registry . . . . . . . . . . . . 2
2.2. Review Process for New Values . . . . . . . . . . . . . . . 4
2.3. Registration Updates . . . . . . . . . . . . . . . . . . . 4
2.4. Initial Values . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
Enhanced Status Codes for SMTP were first defined in [RFC1893], which was subsequently replaced by [RFC3463]. While it anticipated that more codes would be added over time (see section 2 of [RFC3463]), it did not provide an explicit mechanism for registering and tracking those codes. Since then, various RFCs have been published and internet drafts proposed that define additional status codes. However, without an IANA registry, conflicts in definitions have begun to appear.
SMTP的增强状态代码首先在[RFC1893]中定义，随后被[RFC3463]替换。虽然预计随着时间的推移会增加更多的代码（见[RFC3463]第2节），但并未提供登记和跟踪这些代码的明确机制。从那时起，各种RFC已经发布，并提出了定义附加状态代码的互联网草案。然而，如果没有IANA注册中心，定义中的冲突已经开始出现。
This RFC defines such an IANA registry and was written to help prevent further conflicts from appearing in the future. It initializes the registry with the established standards-track enhanced status codes from [RFC3463], [RFC3886], [RFC4468], and [RFC4954]. In addition, this document adds several codes to the registry that were established by various internet drafts and have come into common use, despite the expiration of the documents themselves.
此RFC定义了这样一个IANA注册表，其编写目的是帮助防止将来出现进一步的冲突。它使用[RFC3463]、[RFC3886]、[RFC4468]和[RFC4954]中建立的标准轨道增强状态代码初始化注册表。此外，本文件还向登记处添加了若干代码，这些代码是由各种互联网草案建立的，并已普遍使用，尽管文件本身已过期。
As specified in [RFC3463], an enhanced status code consists of a three-part code, with each part being numeric and separated by a period character. The three portions are known as the class sub-code, the subject sub-code, and the detail sub-code. In the tables, a wildcard for the class sub-code is represented by an X, a wildcard for a subject sub-code is represented by an XXX, and a wildcard for a detail sub-code is represented by a YYY. For example, 3.XXX.YYY has an unspecified subject sub-code and an unspecified status code, and X.5.0 is has an unspecified class sub-code. (This is a change from [RFC3463], which uses XXX for both the subject sub-code and detail sub-code wildcards.)
如[RFC3463]所述，增强型状态代码由三部分组成，每部分为数字，并用句点字符分隔。这三部分被称为类子代码、主题子代码和细节子代码。在表中，类别子代码的通配符由X表示，主题子代码的通配符由XXX表示，详细信息子代码的通配符由YYY表示。例如，3.XXX.YYY具有未指定的主题子代码和未指定的状态代码，而X.5.0 is具有未指定的类别子代码。（这是对[RFC3463]的更改，它使用XXX作为主题子代码和详细子代码通配符。）
IANA has created the registry "SMTP Enhanced Status Codes". The SMTP Enhanced Status Codes registry will have three tables:
IANA已创建注册表“SMTP增强状态代码”。SMTP增强状态代码注册表将有三个表：
o Class Sub-Codes Each of the entries in this table represent class sub-codes and all have an unspecified subject sub-code and an unspecified detail sub-code.
o 类别子代码本表中的每个条目都表示类别子代码，并且都有未指定的主题子代码和未指定的详细信息子代码。
o Subject Sub-Codes Each of the entries in this table represent subject sub-codes and all have an unspecified class sub-code and an unspecified detail sub-code.
o 主题子代码本表中的每个条目都代表主题子代码，并且都有未指定的类别子代码和未指定的详细信息子代码。
o Enumerated Status Codes Each of the entries in this table represent the combination of a subject sub-code and a detail sub-code. All entries will have an unspecified class sub-code, a specified subject sub-code, and a specified detail sub-code.
o 枚举状态代码此表中的每个条目表示主题子代码和详细子代码的组合。所有条目都将具有未指定的类别子代码、指定的主题子代码和指定的详细信息子代码。
Each entry in the tables will include the following. (The sub-code tables will not have the Associated Basic Status Code entries.)
表中的每个条目将包括以下内容。（子代码表将没有关联的基本状态代码条目。）
Code: The status code. For example, 3.XXX.YYY is a class sub-code with an unspecified subject sub-code and an unspecified detail sub-code, and X.5.0 is an enumerated status code with an unspecified class sub-code.
代码：状态代码。例如，3.XXX.YYY是带有未指定主题子代码和未指定细节子代码的类别子代码，而X.5.0是带有未指定类别子代码的枚举状态代码。
Summary: or Sample Text: For class and subject sub-codes, this is the summary of the use for the sub-code shown in section 2 of [RFC3463]. For enumerated status codes, this is an example of a message that might be sent along with the code.
摘要：或示例文本：对于类和主题子代码，这是[RFC3463]第2节所示子代码的使用摘要。对于枚举状态代码，这是可能随代码一起发送的消息的示例。
Associated Basic Status Code: For enumerated status codes, the basic status code(s) of [RFC2821] with which it is usually associated. This may also have a value such as "Any" or "Not given". NOTE: This is a non-exclusive list. In particular, the entries that list some basic status codes for an Enhanced Status Code might allow for other basic status codes, while the entries denoted "Not given" can be filled in by updating the IANA registry through updates to this document or at the direction of the IESG.
关联的基本状态代码：对于枚举状态代码，[RFC2821]的基本状态代码通常与其关联。这也可能有一个值，如“Any”或“Not given”。注意：这是一个非排他性列表。特别是，列出增强状态代码的一些基本状态代码的条目可能允许其他基本状态代码，而表示为“未给出”的条目可以通过更新本文件或按照IESG的指示更新IANA注册表来填写。
Description: A short description of the code.
描述：代码的简短描述。
Reference: A reference to the document in which the code is defined. This reference should note whether the relevant specification is standards-track, best current practice, or neither, using one of "(Standards track)", "(Best current practice)" or "(Not standards track)".
引用：对定义代码的文档的引用。该参考应注意相关规范是否为标准轨道、最佳现行实践，或两者都不是，使用“（标准轨道）”、“（最佳现行实践）”或“（非标准轨道”中的一种。
Submitter: The identity of the submitter, usually the document author.
提交者：提交者的身份，通常是文档作者。
Change Controller: The identity of the change controller for the specification. This will be "IESG" in the case of IETF-produced documents.
变更控制器：规范的变更控制器的标识。对于IETF生成的文件，这将是“IESG”。
An example of an entry in the enumerated status code table would be:
枚举状态代码表中的条目示例如下：
Code: X.0.0 Sample Text: Other undefined Status Associated basic status code: Any Description: Other undefined status is the only undefined error code. It should be used for all errors for which only the class of the error is known. Reference: RFC 3463 (Standards track) Submitter: G. Vaudreuil Change controller: IESG.
代码：X.0.0示例文本：其他未定义状态关联基本状态代码：任何说明：其他未定义状态是唯一未定义的错误代码。它应该用于所有只知道错误类别的错误。参考：RFC 3463（标准跟踪）提交人：G.沃德鲁伊变更控制员：IESG。
Entries in this registry are expected to follow the "Specification Required" model ([RFC5226]) although, in practice, most entries are expected to derive from standards-track documents. Non-standards-track documents that specify codes to be registered should be readily available. The principal purpose of this registry is to avoid confusion and conflicts among different definitions or uses for the same code.
该注册表中的条目应遵循“所需规范”模型（[RFC5226]），尽管在实践中，大多数条目应来自标准跟踪文档。指定要注册的代码的非标准跟踪文件应随时可用。此注册表的主要目的是避免同一代码的不同定义或使用之间的混淆和冲突。
Standards-track registrations may be updated if the relevant standards are updated as a consequence of that action. Non-standards-track entries may be updated by the listed change controller. Only the entry's short description or references may be modified in this way, not the code or associated text. In exceptional cases, any aspect of any registered entity may be updated at the direction of the IESG (for example, to correct a conflict).
如果相关标准因该行动而更新，则可更新标准跟踪登记。非标准轨道条目可由列出的变更控制员更新。只能以这种方式修改条目的简短描述或引用，而不能修改代码或相关文本。在例外情况下，任何注册实体的任何方面都可以按照IESG的指示进行更新（例如，纠正冲突）。
The initial values for the class and subject sub-code tables are to be populated from section 2 of [RFC3463]. Specifically, these are the values for 2.XXX.YYY, 4.XXX.YYY, and 5.XXX.YYY for the Class Sub-Code table, and the values X.0.YYY, X.1.YYY, X.2.YYY, X.3.YYY, X.4.YYY, X.5.YYY, X.6.YYY, and X.7.YYY for the Subject Sub-Code table. The code, sample text, and description for each entry are to be taken from [RFC3463]. Each entry is to use [RFC3463] as the reference, submitted by G. Vaudreuil, and change controlled by the IESG. There are no associated detail sub-code values for the class and subject sub-code tables.
类别和主题子代码表的初始值将根据[RFC3463]第2节填充。具体而言，这些是类子代码表的2.XXX.YYY、4.XXX.YYY和5.XXX.YYY的值，以及主题子代码表的值X.0.YYY、X.1.YYY、X.2.YYY、X.3.YYY、X.4.YYY、X.5.YYY、X.6.YYY和X.7.YYY。每个条目的代码、示例文本和说明取自[RFC3463]。每个条目将使用[RFC3463]作为参考，由G.Vaudreuil提交，变更由IESG控制。类和主题子代码表没有关联的详细信息子代码值。
The initial values for the Enumerated Status Code table is to be populated from:
枚举状态代码表的初始值将从以下位置填充：
1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through X.4.7, X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 through X.7.7),
1. [RFC3463]第3.1至3.8节，（X.0.0、X.1.0至X.1.8、X.2.0至X.2.4、X.3.0至X.3.5、X.4.0至X.4.7、X.5.0至X.5.5、X.6.0至X.6.5和X.7.0至X.7.7），
2. section 3.3.4 of [RFC3886] (X.1.9),
2. [RFC3886]（X.1.9）第3.3.4节，
3. X.6.6 found in section 5 of [RFC4468], (but not X.7.8 found in the same section),
3. X.6.6见[RFC4468]第5节（但不是同一节中的X.7.8），
4. and X.5.6, X.7.8, X.7.9, X.7.11, and X.7.12, found in section 6 of [RFC4954] (using the text from X.5.6, 5.7.8, 5.7.9, 5.7.11, and 4.7.12).
4. 以及[RFC4954]第6节中的X.5.6、X.7.8、X.7.9、X.7.11和X.7.12（使用X.5.6、5.7.8、5.7.9、5.7.11和4.7.12中的文本）。
Each entry is to be designated as defined in the corresponding RFC, submitted by the corresponding RFC author, and change controlled by the IESG. Each of the above RFCs is a standards-track document.
每个条目应按照相应RFC中的定义指定，由相应RFC作者提交，变更由IESG控制。上述各RFC均为标准跟踪文件。
The initial values for the Associated Basic Status Code for each of the above initial enhanced status codes is given in the following table.
下表给出了上述每个初始增强状态代码的相关基本状态代码的初始值。
As noted above, this table is incomplete. In particular, the entries that have some basic status codes might allow for other detail sub-status codes, while the entries denoted "Not given" can be filled in by updating the IANA registry through updates to this document or at the direction of the IESG.
如上所述，此表不完整。特别是，具有一些基本状态代码的条目可能允许使用其他详细子状态代码，而表示为“未给出”的条目可以通过更新本文件或按照IESG的指示更新IANA注册表来填写。
+--------+---------------+--------+----------+--------+-------------+
| Enh. | Assoc. Basic | Enh. | Assoc. | Enh. | Assoc. |
| Status | Status Code | Status | Basic | Status | Basic |
| Code | | Code | Status | Code | Status Code |
| | | | Code | | |
+--------+---------------+--------+----------+--------+-------------+
| X.0.0 | Any | X.1.0 | Not | X.1.1 | 451, 550 |
| | | | given | | |
| X.1.2 | Not given | X.1.3 | 501 | X.1.4 | Not given |
| X.1.5 | 250 | X.1.6 | Not | X.1.7 | Not given |
| | | | given | | |
| X.1.8 | 451, 501 | X.1.9 | Not | X.2.0 | Not given |
| | | | given | | |
| X.2.1 | Not given | X.2.2 | 552 | X.2.3 | 552 |
| X.2.4 | 450, 452 | X.3.0 | 221, | X.3.1 | 452 |
| | | | 250, | | |
| | | | 421, | | |
| | | | 451, | | |
| | | | 550, 554 | | |
| X.3.2 | 453 | X.3.3 | Not | X.3.4 | 552, 554 |
| | | | given | | |
| X.3.5 | Not given | X.4.0 | Not | X.4.1 | 451 |
| | | | given | | |
| X.4.2 | 421 | X.4.3 | 451, 550 | X.4.4 | Not given |
| X.4.5 | 451 | X.4.6 | Not | X.4.7 | Not given |
| | | | given | | |
| X.5.0 | 220, 250, | X.5.1 | 430, | X.5.2 | 500, 501, |
| | 251, 252, | | 500, | | 502, 550, |
| | 253, 451, | | 501, | | 555 |
| | 452, 454, | | 503, | | |
| | 458, 459, | | 530, | | |
| | 501, 502, | | 550, | | |
| | 503, 554 | | 554, 555 | | |
| X.5.3 | 451 | X.5.4 | 451, | X.5.5 | Not given |
| | | | 501, | | |
| | | | 502, | | |
| | | | 503, | | |
| | | | 504, | | |
| | | | 550, 555 | | |
| X.5.6 | 500 | X.6.0 | Not | X.6.1 | Not given |
| | | | given | | |
| X.6.2 | Not given | X.6.3 | 554 | X.6.4 | 250 |
| X.6.5 | Not given | X.6.6 | 554 | X.7.0 | 220, 235, |
| | | | | | 450, 454, |
| | | | | | 500, 501, |
| | | | | | 503, 504, |
| | | | | | 530, 535, |
| | | | | | 550 |
+--------+---------------+--------+----------+--------+-------------+
| Enh. | Assoc. Basic | Enh. | Assoc. | Enh. | Assoc. |
| Status | Status Code | Status | Basic | Status | Basic |
| Code | | Code | Status | Code | Status Code |
| | | | Code | | |
+--------+---------------+--------+----------+--------+-------------+
| X.0.0 | Any | X.1.0 | Not | X.1.1 | 451, 550 |
| | | | given | | |
| X.1.2 | Not given | X.1.3 | 501 | X.1.4 | Not given |
| X.1.5 | 250 | X.1.6 | Not | X.1.7 | Not given |
| | | | given | | |
| X.1.8 | 451, 501 | X.1.9 | Not | X.2.0 | Not given |
| | | | given | | |
| X.2.1 | Not given | X.2.2 | 552 | X.2.3 | 552 |
| X.2.4 | 450, 452 | X.3.0 | 221, | X.3.1 | 452 |
| | | | 250, | | |
| | | | 421, | | |
| | | | 451, | | |
| | | | 550, 554 | | |
| X.3.2 | 453 | X.3.3 | Not | X.3.4 | 552, 554 |
| | | | given | | |
| X.3.5 | Not given | X.4.0 | Not | X.4.1 | 451 |
| | | | given | | |
| X.4.2 | 421 | X.4.3 | 451, 550 | X.4.4 | Not given |
| X.4.5 | 451 | X.4.6 | Not | X.4.7 | Not given |
| | | | given | | |
| X.5.0 | 220, 250, | X.5.1 | 430, | X.5.2 | 500, 501, |
| | 251, 252, | | 500, | | 502, 550, |
| | 253, 451, | | 501, | | 555 |
| | 452, 454, | | 503, | | |
| | 458, 459, | | 530, | | |
| | 501, 502, | | 550, | | |
| | 503, 554 | | 554, 555 | | |
| X.5.3 | 451 | X.5.4 | 451, | X.5.5 | Not given |
| | | | 501, | | |
| | | | 502, | | |
| | | | 503, | | |
| | | | 504, | | |
| | | | 550, 555 | | |
| X.5.6 | 500 | X.6.0 | Not | X.6.1 | Not given |
| | | | given | | |
| X.6.2 | Not given | X.6.3 | 554 | X.6.4 | 250 |
| X.6.5 | Not given | X.6.6 | 554 | X.7.0 | 220, 235, |
| | | | | | 450, 454, |
| | | | | | 500, 501, |
| | | | | | 503, 504, |
| | | | | | 530, 535, |
| | | | | | 550 |
| X.7.1 | 451, 454, | X.7.2 | 550 | X.7.3 | Not given |
| | 502, 503, | | | | |
| | 533, 550, 551 | | | | |
| X.7.4 | 504 | X.7.5 | Not | X.7.6 | Not given |
| | | | given | | |
| X.7.7 | Not given | X.7.8 | 535, 554 | X.7.9 | 534 |
| X.7.10 | 523 | X.7.11 | 524, 538 | X.7.12 | 422, 432 |
| X.7.13 | 525 | X.7.14 | 535, 554 | | |
+--------+---------------+--------+----------+--------+-------------+
| X.7.1 | 451, 454, | X.7.2 | 550 | X.7.3 | Not given |
| | 502, 503, | | | | |
| | 533, 550, 551 | | | | |
| X.7.4 | 504 | X.7.5 | Not | X.7.6 | Not given |
| | | | given | | |
| X.7.7 | Not given | X.7.8 | 535, 554 | X.7.9 | 534 |
| X.7.10 | 523 | X.7.11 | 524, 538 | X.7.12 | 422, 432 |
| X.7.13 | 525 | X.7.14 | 535, 554 | | |
+--------+---------------+--------+----------+--------+-------------+
Table 1
表1
The following additional definitions have been registered in the enumerated status code table. These entries have been used in the industry without any published specification.
以下附加定义已在枚举状态代码表中注册。这些条目已在行业中使用，但未发布任何规范。
Code: X.7.10 Sample Text: Encryption Needed Associated basic status code: 523 Description: This indicates that an external strong privacy layer is needed in order to use the requested authentication mechanism. This is primarily intended for use with clear text authentication mechanisms. A client that receives this may activate a security layer such as TLS prior to authenticating, or attempt to use a stronger mechanism. Reference: RFC 5248 (Best current practice) Submitter: T. Hansen, J. Klensin Change controller: IESG
代码：X.7.10示例文本：需要加密关联的基本状态代码：523说明：这表示需要外部强隐私层才能使用请求的身份验证机制。这主要用于明文身份验证机制。接收到该消息的客户端可以在身份验证之前激活安全层（如TLS），或者尝试使用更强大的机制。参考：RFC 5248（最佳现行做法）提交人：T.Hansen，J.Klesin变更控制员：IESG
Code: X.7.13 Sample Text: User Account Disabled Associated basic status code: 525 Description: Sometimes a system administrator will have to disable a user's account (e.g., due to lack of payment, abuse, evidence of a break-in attempt, etc.). This error code occurs after a successful authentication to a disabled account. This informs the client that the failure is permanent until the user contacts their system administrator to get the account re-enabled. It differs from a generic authentication failure where the client's best option is to present the passphrase entry dialog in case the user simply mistyped their passphrase. Reference: RFC 5248 (Best current practice) Submitter: T. Hansen, J. Klensin Change controller: IESG
代码：X.7.13示例文本：用户帐户已禁用关联的基本状态代码：525说明：有时系统管理员必须禁用用户帐户（例如，由于缺少付款、滥用、试图闯入的证据等）。成功验证已禁用的帐户后，会出现此错误代码。这会通知客户端，在用户联系其系统管理员以重新启用帐户之前，故障是永久性的。它不同于一般的身份验证失败，在这种情况下，客户端的最佳选择是显示密码短语输入对话框，以防用户简单地键入了他们的密码短语。参考：RFC 5248（最佳现行做法）提交人：T.Hansen，J.Klesin变更控制员：IESG
Code: X.7.14 Sample Text: Trust relationship required Associated basic status code: 535, 554 Description: The submission server requires a configured trust relationship with a third-party server in order to access the message content. This value replaces the prior use of X.7.8 for this error condition, thereby updating [RFC4468]. Reference: RFC 5248 (Best current practice) Submitter: T. Hansen, J. Klensin Change controller: IESG
代码：X.7.14示例文本：需要信任关系关联的基本状态代码：53554说明：提交服务器需要配置与第三方服务器的信任关系才能访问邮件内容。该值取代先前针对该错误条件使用的X.7.8，从而更新[RFC4468]。参考：RFC 5248（最佳现行做法）提交人：T.Hansen，J.Klesin变更控制员：IESG
As stated in [RFC1893], use of enhanced status codes may disclose additional information about how an internal mail system is implemented beyond that available through the SMTP status codes.
如[RFC1893]中所述，使用增强状态代码可能会披露有关如何实现内部邮件系统的附加信息，而不仅仅是通过SMTP状态代码提供的信息。
Many proposed additions to the response code list are security related. Having these registered in one place to prevent collisions will improve their value. Security error responses can leak information to active attackers (e.g., the distinction between "user not found" and "bad password" during authentication). Documents defining security error codes should make it clear when this is the case so SMTP server software subject to such threats can provide appropriate controls to restrict exposure.
许多建议添加到响应代码列表中的内容都与安全相关。将它们注册在一个位置以防止碰撞将提高它们的价值。安全错误响应可能会将信息泄漏给主动攻击者（例如，身份验证期间“未找到用户”和“错误密码”之间的区别）。在这种情况下，定义安全错误代码的文档应明确说明，以便受到此类威胁的SMTP服务器软件可以提供适当的控制来限制暴露。
While the need for this registry should have become clear shortly after [RFC3463] was approved, the growth of the code table through additional documents and work done as part of email internationalization and [RFC2821] updating efforts made the requirement much more clear. The comments of the participants in those efforts are gratefully acknowledged, particularly the members of the ietf-smtp@imc.org mailing list. Chris Newman and Randy Gellens provided useful comments and some text for early versions of the document.
虽然在[RFC3463]获得批准后不久，对该注册中心的需求就应该变得清晰，但作为电子邮件国际化和[RFC2821]更新工作的一部分，通过额外的文档和所做的工作，代码表的增长使需求变得更加清晰。感谢这些努力的参与者的评论，特别是ietf的成员-smtp@imc.org邮件列表。Chris Newman和Randy Gellens为早期版本的文档提供了有用的评论和一些文本。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，2003年1月。
[RFC3886] Allman, E., "An Extensible Message Format for Message Tracking Responses", RFC 3886, September 2004.
[RFC3886]Allman，E.“用于消息跟踪响应的可扩展消息格式”，RFC 3886，2004年9月。
[RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[RFC4468]Newman，C.，“消息提交BURL扩展”，RFC4468，2006年5月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[RFC1893]Vaudreuil，G.，“增强邮件系统状态代码”，RFC1893，1996年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
美国新泽西州米德尔顿劳雷尔大道200号托尼·汉森AT&T实验室，邮编：07748
EMail: tony+mailesc@maillennium.att.com
EMail: tony+mailesc@maillennium.att.com
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛邮编：02140
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
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.