Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 6729 Brandenburg InternetWorking
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 Cloudmark, Inc.
September 2012
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 6729 Brandenburg InternetWorking
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 Cloudmark, Inc.
September 2012
Indicating Email Handling States in Trace Fields
指示跟踪字段中的电子邮件处理状态
Abstract
摘要
This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues.
本文档注册了一个跟踪字段子句，用于指示处理队列或处理状态之间的转换，包括执行主机间和主机内消息转换。这可能包括邮件隔离、邮件列表调节、定时传递、排队等待进一步分析、内容转换或其他类似原因，以及可选地识别正常处理队列。
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/rfc6729.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6729.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Key Words .......................................................3
3. Trace Clause ....................................................3
4. Discussion ......................................................6
5. Granularity .....................................................6
6. IANA Considerations .............................................7
6.1. MAIL Parameters Additional-registered-clauses
Sub-Registry ...............................................7
6.2. MAIL Parameters Registered-states Sub-Registry .............7
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. Trace Field Examples .................................11
A.1. Typical Delivery without Obvious Extra Handling ...........11
A.2. Delivery with Moderation ..................................11
Appendix B. Acknowledgements .....................................12
1. Introduction ....................................................2
2. Key Words .......................................................3
3. Trace Clause ....................................................3
4. Discussion ......................................................6
5. Granularity .....................................................6
6. IANA Considerations .............................................7
6.1. MAIL Parameters Additional-registered-clauses
Sub-Registry ...............................................7
6.2. MAIL Parameters Registered-states Sub-Registry .............7
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. Trace Field Examples .................................11
A.1. Typical Delivery without Obvious Extra Handling ...........11
A.2. Delivery with Moderation ..................................11
Appendix B. Acknowledgements .....................................12
[SMTP] defines the content of email message trace fields, commonly the "Received" header field. These are typically used to record an audit trail of the path a message follows from origin to destination, with one such field added each time a message moves from one host to the next.
[SMTP]定义电子邮件跟踪字段的内容，通常为“已接收”标题字段。这些字段通常用于记录消息从源到目标的路径的审核跟踪，每次消息从一个主机移动到下一个主机时，都会添加一个这样的字段。
Section 3.7.2 of that document mentions that "the most important use of Received: lines is for debugging mail faults [...]".
该文件的第3.7.2节提到“Received:lines最重要的用途是调试邮件故障[…]”。
There are some cases where there may be large time gaps between trace fields. Though this might be caused by transient communication issues, they might also be caused by policy decisions or special processing regarding the content of the message, authorization of some identity on the message, or transitions between major software components. Common examples include message quarantines (filters that cause a message to be held pending further evaluation or delivery of a message pending manual operator action), pending content analysis, or mailing list servers that impose moderation rules (mailing list owner action required regarding mail from authors not subscribed to those lists).
在某些情况下，跟踪字段之间可能存在较大的时间间隔。虽然这可能是由暂时的通信问题引起的，但也可能是由有关消息内容的策略决定或特殊处理、消息上某些标识的授权或主要软件组件之间的转换引起的。常见的示例包括邮件隔离（导致邮件在等待进一步评估或传递邮件时被保留的过滤器，等待手动操作员操作）、等待内容分析，或强制实施审核规则的邮件列表服务器（对于未订阅这些列表的作者的邮件，需要邮件列表所有者操作）。
This document registers a new optional clause that can be used in trace fields to indicate that a message entered such a special processing queue or state for some period. This allows inspection of the trace information to reveal that the cause for a time gap in trace fields was imposed by additional processing rather than one caused by transient technical difficulties.
此文档注册了一个新的可选子句，可在跟踪字段中使用该子句来指示消息在一段时间内进入这样一个特殊的处理队列或状态。这允许对跟踪信息进行检查，以揭示跟踪场中时间间隔的原因是附加处理造成的，而不是由瞬态技术困难造成的。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
This specification defines a clause, called "state", which MAY be used when creating a Received header field (see Section 4.4 of [SMTP]) to indicate the nature of additional handling imposed on the relaying of a message toward its recipient(s). It is followed by a single keyword that provides that detail. A Mail Transfer Agent (MTA) or other handling agent that determines a message has entered a state other than normal queuing of messages for relaying or delivery MAY generate a trace field including one of these clauses. That is, the presence of this clause on a trace field is an indication of the entry of the message into that state; a later trace field added would indicate its departure from that state.
本规范定义了一个称为“state”的子句，可在创建接收头字段时使用该子句（请参见[SMTP]第4.4节），以指示在将邮件转发给收件人时施加的附加处理的性质。它后面是一个提供该细节的关键字。邮件传输代理（MTA）或其他处理代理（确定邮件已进入正常邮件队列以外的状态以进行中继或传递）可能会生成包含以下子句之一的跟踪字段。也就是说，跟踪字段上出现此子句表示消息进入该状态；稍后添加的跟踪字段将指示其偏离该状态。
An MTA implementing this specification SHOULD add a Received field as described whenever:
实施本规范的MTA应在以下情况下添加所述的接收字段：
a. It determines that a special handling condition will occur and places it into that condition; or
a. 确定将发生特殊处理条件，并将其置于该条件下；或
b. It determines that no special handling is required and prepares it for relay to the next handling agent.
b. 它确定不需要特殊处理，并准备将其转发给下一个处理代理。
An MTA need not add a Received field indicating preparation for normal handoff to the next handling agent if it has already added a Received field for some other reason. Trace data added by the next handling agent will imply the message's exit from the special handling condition.
如果MTA因其他原因已添加接收字段，则无需添加指示准备正常切换到下一个处理代理的接收字段。由下一个处理代理添加的跟踪数据将暗示消息退出特殊处理条件。
If a single MTA processes a message through multiple special handling conditions, it MAY add a Received field for each distinct condition.
如果单个MTA通过多个特殊处理条件处理邮件，它可能会为每个不同的条件添加一个Received字段。
For example, presume a message will be injected into MTA-1, then travel to MTA-3 via MTA-2, and then MTA-3 will enact final delivery. At MTA-2, it is determined that some action will be taken that will cause the message to undergo some handling change that is outside of typical message flow. In this case:
例如，假设邮件将被注入MTA-1，然后通过MTA-2传送到MTA-3，然后MTA-3将执行最终传递。在MTA-2上，确定将采取一些操作，以使邮件经历一些典型邮件流之外的处理更改。在这种情况下：
1. MTA-1 adds a typical Received field and relays it to MTA-2.
1. MTA-1添加一个典型的接收字段，并将其中继到MTA-2。
2. MTA-2 determines that the atypical handling will occur and adds a Received field using the extension specified here.
2. MTA-2确定将进行非典型处理，并使用此处指定的扩展名添加接收字段。
3. On completion of the atypical handling, MTA-2 relays the message to MTA-3.
3. 完成非典型处理后，MTA-2将消息转发给MTA-3。
4. MTA-3 adds a typical Received field and enacts final delivery of the message.
4. MTA-3添加了一个典型的Received字段，并执行邮件的最终传递。
Appropriate use of this mechanism does not include associating meta-data with the message, such as categorizing the message (e.g., the notions of "is spam" or "was 8-bit, converted to 7-bit"). Processing agents also cannot reliably use this mechanism to determine anything about the message content, since there is no guarantee that all agents in the chain of handling made such annotations to allow correct conclusions. The sole purpose here is to allow one to determine the point(s) in the chain of custody of a message at which the message was subjected to handling outside of normal message routing and queuing.
该机制的适当使用不包括将元数据与消息相关联，例如对消息进行分类（例如，“是垃圾邮件”或“是8位的，转换为7位的”）。处理代理也不能可靠地使用此机制来确定有关消息内容的任何内容，因为无法保证处理链中的所有代理都进行了这样的注释以允许正确的结论。此处的唯一目的是允许确定消息保管链中的点，在该点，消息在正常消息路由和队列之外进行处理。
The following state keywords are defined in this document; extensions may define other registered keywords (see Section 6.2):
本文档中定义了以下状态关键字：；扩展可以定义其他注册关键字（参见第6.2节）：
auth: The message entered a queue pending authentication of some identifier in the message.
auth：消息进入队列，等待消息中某个标识符的身份验证。
content: The message entered a queue pending content analysis, such as scanning for spam or viruses.
内容：邮件进入队列等待内容分析，如扫描垃圾邮件或病毒。
convert: The message entered a queue pending content conversion.
convert：消息进入了一个等待内容转换的队列。
moderation: The message entered a hold pending mailing list moderator action.
审核：邮件输入了等待邮件列表审核人操作的保留。
normal: The message is not in an administrative hold and is queued for or is being handed off to the next handling agent (which may be local delivery). This is the default interpretation when no "state" clause is present.
正常：邮件不在管理保留中，正在排队等待或被传递给下一个处理代理（可能是本地传递）。这是不存在“状态”条款时的默认解释。
other: The message entered a hold or queue for reasons not covered by other keywords in this list and not for transient technology issues.
其他：消息进入等待或队列的原因不在此列表中的其他关键字所涵盖，也不属于暂时性技术问题。
outbound: The message entered a queue for outbound relaying. This is typically the last case added for a single host, and the next Received header field is expected to be added by some other host.
outbound（出站）：消息进入出站中继队列。这通常是为单个主机添加的最后一个案例，下一个接收到的头字段预计将由其他主机添加。
quarantine: The message entered a hold in an isolation queue pending operator action for local policy reasons.
隔离：由于本地策略原因，消息在等待操作员操作的隔离队列中输入了保留。
timed: The message entered a hold in order to meet a requested delivery window, such as is defined in [FUTURERELEASE].
定时：为满足所请求的传递窗口（如[FUTURERELEASE]中的定义），邮件输入了等待。
In Section 6, the "state" clause is added to the Additional-Registered-Clauses IANA sub-registry. The ABNF for this clause is:
在第6节中，“国家”条款被添加到IANA子注册处的附加注册条款中。本条款的ABNF为：
State = CFWS "state" FWS queue-state-keyword [ "/" value ]
State=CFWS“State”FWS队列状态关键字[“/”值]
queue-state-keyword = ( reg-state-keyword / unreg-state-keyword )
queue-state-keyword = ( reg-state-keyword / unreg-state-keyword )
reg-state-keyword = ( "auth" / "content" / "convert" /
"moderation" / "normal" / "other" /
"outbound" / "quarantine" / "timed" /
additional-state-keyword )
reg-state-keyword = ( "auth" / "content" / "convert" /
"moderation" / "normal" / "other" /
"outbound" / "quarantine" / "timed" /
additional-state-keyword )
additional-state-keyword = token ; MUST be registered; see ; "IANA Considerations" below
附加状态关键字=令牌；必须注册；看见“IANA注意事项”见下文
value = token
value = token
unreg-state-keyword = token
unreg-state-keyword = token
"FWS" and "CFWS" are defined in [MAIL]. "token" is defined in [MIME].
[MAIL]中定义了“FWS”和“CFW”。“令牌”在[MIME]中定义。
A transfer agent making use of this extension MAY also include header field comments to provide additional information.
使用此扩展的传输代理还可以包括标题字段注释以提供附加信息。
The "value" is available for providing additional labels as explanation for the state transition. Examples could include:
“值”可用于提供附加标签，作为状态转换的解释。例如：
o convert/unicode2ascii
o convert/unicode2ascii
o moderation/not-subscribed
o 适度/未订阅
o quarantine/spam
o 隔离/垃圾邮件
Handling agents are not expected to implement or support all of these. Indeed, recording trace information for all of the states described above could make the header of a message inordinately large. Rather, an agent is encouraged to apply state annotations when a message enters a handling queue where a significant condition occurs or where significant additional processing or delay is possible, and especially when a handoff has occurred between two different, independent agents.
地勤代理不应实施或支持所有这些措施。事实上，记录上述所有状态的跟踪信息可能会使消息的标头过大。相反，鼓励代理在消息进入处理队列时应用状态注释，在处理队列中出现重大情况或可能出现重大额外处理或延迟，尤其是在两个不同的独立代理之间发生切换时。
For example, an MTA receiving a message, doing message authentication, scanning for viruses and spam, and then putting it in an outbound queue could add four Received header fields denoting each of these states. However, where they are all done as part of a single system process, in a single pass, doing so would be considered unusual (and extremely verbose). This method SHOULD NOT be applied except when doing detailed analysis of a single component to identify performance issues with those steps.
例如，MTA接收邮件、进行邮件身份验证、扫描病毒和垃圾邮件，然后将其放入出站队列，可以添加四个接收到的头字段，表示每个状态。但是，如果它们都是作为单个系统进程的一部分在单个过程中完成的，那么这样做将被认为是不寻常的（而且非常冗长）。除非对单个组件进行详细分析以确定这些步骤中的性能问题，否则不应应用此方法。
Rather, an agent that wishes to make a state annotation SHOULD add only a single Received header field including such annotation, thus indicating (a) the time of completion of its handling of the message via the date portion of the field and (b) the final disposition of that message relative to that agent. For example, an MTA receiving a message that performs various checks on the message before immediately handing it off to a Mailing List Manager (MLM) would only record a "normal" state, assuming it passes those checks. The MLM would then evaluate the message and record its own state once it decides what the next step will be for the handling of that message.
相反，希望进行状态注释的代理应仅添加一个包含此类注释的接收头字段，从而指示（a）通过该字段的日期部分完成对消息的处理的时间，以及（b）该消息相对于该代理的最终处置。例如，如果MTA收到一封邮件，在立即将其发送给邮件列表管理器（MLM）之前对该邮件执行各种检查，则MTA只会记录“正常”状态，前提是该邮件通过了这些检查。传销然后将评估消息，并在决定下一步处理该消息时记录自己的状态。
The degree of granularity -- and therefore the degree of verbosity -- recorded through the use of this additional trace clause is likely to vary depending on circumstances. It will typically be the case that use of this clause will be limited to "unusual" transitions, such as when a message requires additional scrutiny or other processing or needs to be quarantined.
通过使用这个附加的trace子句记录的粒度（因此也就是详细程度）可能会根据具体情况而有所不同。通常情况下，本条款的使用仅限于“异常”转换，例如，当消息需要额外审查或其他处理或需要隔离时。
Somewhat greater granularity might also include transitions of administrative responsibility, such as between a Mail Transfer Agent (MTA) operator and a Mailing List Manager (MLM) operator. This could be further enhanced to note some transitions that are interesting only when other transitions have occurred, such as noting entry to the outbound queue only when the message is originating from an "interesting" source, like an MLM, since an MLM can introduce significant changes to the message or delivery delay and it could be
更大的粒度还可能包括管理职责的转换，例如邮件传输代理（MTA）操作员和邮件列表管理器（MLM）操作员之间的转换。这可以进一步增强，以注意到只有在发生其他转换时才感兴趣的一些转换，例如仅当消息来自“感兴趣”源（如传销）时才注意到出站队列的入口，因为传销可以对消息或传递延迟引入重大更改，并且可能会导致延迟
useful to know when it completed its processing, as distinct from the subsequent processing by the originating MTA. In circumstances needing very fine-grained trace information, fields might be created to note all of these "significant" network architecture transitions.
了解其何时完成处理非常有用，这与原始MTA的后续处理不同。在需要非常细粒度的跟踪信息的情况下，可以创建字段来记录所有这些“重要的”网络体系结构转换。
One should note, however, when choosing higher levels of granularity, that the Received header fields present on a message could be counted by MTAs when trying to decide whether or not a message routing loop is in effect. A message with an abundance of these might cause an incorrect determination that the message is in a delivery loop, causing it to be removed from the mail stream. See Section 6.3 of [SMTP] for further discussion.
但是，在选择更高的粒度级别时，应该注意，当MTA试图确定邮件路由循环是否有效时，邮件上存在的接收头字段可以由MTA计数。包含大量这些内容的消息可能会导致错误地确定该消息处于传递循环中，从而导致将其从邮件流中删除。有关进一步的讨论，请参见[SMTP]的第6.3节。
This document adds the following entry to the "Additional-registered-clauses" sub-registry of the "MAIL Parameters" registry, created by [SMTP]:
本文档将以下条目添加到[SMTP]创建的“邮件参数”注册表的“附加注册条款”子注册表中：
Clause name: state
条款名称：州
Description: Indicates entry into a special queue state
描述：表示进入特殊队列状态的条目
Syntax Summary: state <state-name>
Syntax Summary: state <state-name>
Reference: [RFC6729]
参考文献：[RFC6729]
The "MAIL Parameters" registry at IANA has been updated by the creation of the "Registered-states" sub-registry to contain valid state keywords for use with this specification. Updates to this registry are governed by the First Come, First Served rules of [IANA] for new registrations. Changes to the status of existing entries are limited to the original registrant or IESG approval.
IANA的“邮件参数”注册表已通过创建“注册状态”子注册表进行更新，以包含与本规范一起使用的有效状态关键字。此注册表的更新受[IANA]新注册的先到先得规则管辖。对现有条目状态的更改仅限于原始注册人或IESG批准。
Discussion of all registry updates is encouraged via one or more IETF mailing lists that typically cover email-related subjects prior to approval of the change, as a way of documenting the work. The ietf-smtp@ietf.org list is suggested.
鼓励通过一个或多个IETF邮件列表讨论所有注册表更新，这些邮件列表通常包括变更批准前的电子邮件相关主题，作为记录工作的一种方式。ietf-smtp@ietf.org建议列出清单。
Note that only registrations of queue state keywords are permitted. The registry is not to be used for specifying secondary information (i.e., the "value" part of the ABNF in Section 3).
请注意，只允许注册队列状态关键字。注册表不用于指定辅助信息（即第3节中ABNF的“值”部分）。
Registrations are to include the following entries:
注册应包括以下条目：
Name: The name of the state keyword being defined or updated, which conforms to the ABNF shown in Section 3.
名称：定义或更新的状态关键字的名称，符合第3节中所示的ABNF。
Description: A brief description of the keyword's meaning.
描述：对关键字含义的简要描述。
Specification: The specification document that defines the queue state being registered, or if no stable reference exists, a more detailed explanation of the queue state than is in the "Description", sufficient to allow interoperability.
规范：定义正在注册的队列状态的规范文档，或者如果不存在稳定引用，则提供比“说明”中更详细的队列状态说明，足以实现互操作性。
Use: One of "current" (the state keyword is in current use), "deprecated" (the state keyword is in use but not recommended for new implementations), or "historic" (the state keyword is no longer in substantial current use).
用法：“当前”（state关键字当前正在使用）、“已弃用”（state关键字正在使用，但不建议用于新的实现）或“历史”（state关键字当前不再大量使用）。
The initial registration set is as follows:
初始注册集如下所示：
+------------+------------------------+-----------------+---------+
| Name | Description | Specification | Use |
+------------+------------------------+-----------------+---------+
| auth | Held for message | [RFC6729] | current |
| | authentication | | |
+------------+------------------------+-----------------+---------+
| content | Held for message | [RFC6729] | current |
| | content analysis | | |
+------------+------------------------+-----------------+---------+
| convert | Held for message | [RFC6729] | current |
| | content conversion | | |
+------------+------------------------+-----------------+---------+
| moderation | Held for list | [RFC6729] | current |
| | moderation | | |
+------------+------------------------+-----------------+---------+
| normal | Message is not being | [RFC6729] | current |
| | held other than to | | |
| | accommodate typical | | |
| | relaying handling | | |
+------------+------------------------+-----------------+---------+
| other | Held for causes not | [RFC6729] | current |
| | covered by other | | |
| | registered state | | |
| | keywords | | |
+------------+------------------------+-----------------+---------+
| outbound | Message placed in | [RFC6729] | current |
| | outbound queue | | |
+------------+------------------------+-----------------+---------+
| quarantine | Held for operator | [RFC6729] | current |
| | action due to content | | |
| | analysis or local | | |
| | policy | | |
+------------+------------------------+-----------------+---------+
| timed | Held to accommodate a | [RFC6729] | current |
| | specific requested | | |
| | delivery window | | |
+------------+------------------------+-----------------+---------+
+------------+------------------------+-----------------+---------+
| Name | Description | Specification | Use |
+------------+------------------------+-----------------+---------+
| auth | Held for message | [RFC6729] | current |
| | authentication | | |
+------------+------------------------+-----------------+---------+
| content | Held for message | [RFC6729] | current |
| | content analysis | | |
+------------+------------------------+-----------------+---------+
| convert | Held for message | [RFC6729] | current |
| | content conversion | | |
+------------+------------------------+-----------------+---------+
| moderation | Held for list | [RFC6729] | current |
| | moderation | | |
+------------+------------------------+-----------------+---------+
| normal | Message is not being | [RFC6729] | current |
| | held other than to | | |
| | accommodate typical | | |
| | relaying handling | | |
+------------+------------------------+-----------------+---------+
| other | Held for causes not | [RFC6729] | current |
| | covered by other | | |
| | registered state | | |
| | keywords | | |
+------------+------------------------+-----------------+---------+
| outbound | Message placed in | [RFC6729] | current |
| | outbound queue | | |
+------------+------------------------+-----------------+---------+
| quarantine | Held for operator | [RFC6729] | current |
| | action due to content | | |
| | analysis or local | | |
| | policy | | |
+------------+------------------------+-----------------+---------+
| timed | Held to accommodate a | [RFC6729] | current |
| | specific requested | | |
| | delivery window | | |
+------------+------------------------+-----------------+---------+
The use of this trace information can reveal hints as to local policy that was in effect at the time of message handling.
使用此跟踪信息可以揭示消息处理时生效的本地策略的提示。
Further discussion about trace field security can be found in Section 7.6 of [SMTP].
有关跟踪字段安全性的进一步讨论，请参见[SMTP]的第7.6节。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service Extension for Future Message Release", RFC 4865, May 2007.
[FUTURERELEASE]White，G.和G.Vaudreuil，“未来邮件发布的SMTP提交服务扩展”，RFC 4865，2007年5月。
This section includes a sample of the new trace field clause in use.
本节包括正在使用的新跟踪字段子句的示例。
Typical message delivery
典型的消息传递
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929
for <recipient@example.net>;
Fri, Feb 15 2002 17:19:22 -0800
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <recipient@example.net>;
Fri, Feb 15 2002 17:19:08 -0800
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929
for <recipient@example.net>;
Fri, Feb 15 2002 17:19:22 -0800
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <recipient@example.net>;
Fri, Feb 15 2002 17:19:08 -0800
Example 1: Typical message delivery with no appreciable extra handling; only Received header fields shown
示例1：典型的消息传递，没有明显的额外处理；仅显示接收的标题字段
Message delivery after moderation
调整后的邮件传递
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929
for <recipient@example.net>;
Fri, Feb 15 2002 18:33:29 -0800
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <secret-list@example.com>
state moderation (sender not subscribed);
Fri, Feb 15 2002 17:19:08 -0800
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929
for <recipient@example.net>;
Fri, Feb 15 2002 18:33:29 -0800
Received: from internal.example.com
(internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134
for <secret-list@example.com>
state moderation (sender not subscribed);
Fri, Feb 15 2002 17:19:08 -0800
Example 2: Message held for moderation; only Received header fields shown
示例2：为缓和而保存的消息；仅显示接收的标题字段
The message passed from internal.example.com to newyork.example.com intended for a mailing list hosted at the latter. For list administrative reasons, the message is held there for moderation. It
从internal.example.com传递到newyork.example.com的消息，用于在后者托管的邮件列表。出于管理方面的原因，邮件保存在那里以供审核。信息技术
is finally released over an hour later and passed to the next host. A comment after the state expression indicates the actual cause for the administrative hold.
一个多小时后终于发布并传递给下一个主机。状态表达式后的注释指示管理暂停的实际原因。
The authors wish to acknowledge the following for their reviews and constructive criticisms of this proposal: Tony Finch, Ned Freed, Carl S. Gutenkunst, John Levine, Bill McQuillan, S. Moonesamy, Alexey Melnikov, Robert A. Rosenberg, Hector Santos, Rolf Sonneveld, and Mykyta Yevstifeyev.
作者希望感谢以下对该提案的评论和建设性批评：托尼·芬奇、内德·弗里德、卡尔·S·古腾昆斯特、约翰·莱文、比尔·麦克基伦、S·穆内萨米、阿列克谢·梅尔尼科夫、罗伯特·罗森博格、赫克托·桑托斯、罗尔夫·索内维尔德和米基塔·叶夫斯蒂耶夫。
Authors' Addresses
作者地址
D. Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale 94086 USA
D.Crocker-Brandenburg互联675云杉Sunnyvale博士美国94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 USA
MurayS.KuCaWaWy CuldMax公司，128国王圣，第二楼旧金山，CA 94107美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com