Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7410 December 2014
Updates: 7001
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7410 December 2014
Updates: 7001
Category: Standards Track
ISSN: 2070-1721
A Property Types Registry for the Authentication-Results Header Field
验证结果标头字段的属性类型注册表
Abstract
摘要
This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.
本文档通过在电子邮件身份验证工作中使用的“身份验证结果”标题字段中为属性类型创建注册表来更新RFC 7001，而不是限制参与者使用原始的固定值集。
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/rfc7410.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7410.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Updated "ptype" Definition . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Updated "ptype" Definition . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
[RFC7001] defines the email Authentication-Results header field that presents the results of an authentication effort in a machine-readable format. The header field creates a place to collect the output from authentication processes that are disjoint from later processes that might use the output, such as analysis, filtering, or sorting mechanisms.
[RFC7001]定义电子邮件身份验证结果标题字段，该字段以机器可读格式显示身份验证工作的结果。header字段创建一个位置来收集来自身份验证过程的输出，这些过程与以后可能使用该输出的过程（如分析、筛选或排序机制）不相交。
The specification in that document enumerated a small set of types of properties that can be reported using this mechanism. There has emerged a desire to report types of properties about a message through this mechanism. Accordingly, this document updates the specification to allow for additional property types ("ptypes") beyond the original set and creates a registry where new ones can be listed and their defining documents referenced.
该文档中的规范列举了一小部分可以使用此机制报告的属性类型。人们希望通过这种机制报告消息的属性类型。因此，本文档更新了规范，以允许在原始集合之外添加其他属性类型（“ptype”），并创建一个注册表，其中可以列出新的属性类型并引用它们的定义文档。
Advanced Backus Naur Form (ABNF) is defined in [RFC5234].
[RFC5234]中定义了高级巴科斯诺尔表（ABNF）。
The ABNF in Section 2.2 of [RFC7001] is updated as follows:
[RFC7001]第2.2节中的ABNF更新如下：
ptype = Keyword
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of
; the message body, or was some other property evaluated by
; the receiving Message Transfer Agent (MTA)
ptype = Keyword
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of
; the message body, or was some other property evaluated by
; the receiving Message Transfer Agent (MTA)
The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321].
[RFC5321]第4.1.2节定义了ABNF标记“关键字”。
Legal values of "ptype" are as defined in the IANA "Email Authentication Property Types" registry (see Section 3). The initial values are as follows, matching those defined in [RFC7001]:
“ptype”的法定值在IANA“电子邮件身份验证属性类型”注册表中定义（见第3节）。初始值如下所示，与[RFC7001]中定义的值相匹配：
body: Indicates information that was extracted from the body of the message. This might be an arbitrary string of bytes, a hash of a string of bytes, a Uniform Resource Identifier, or some other content of interest.
正文：表示从邮件正文中提取的信息。这可能是一个任意的字节字符串、一个字节字符串的散列、一个统一的资源标识符或其他感兴趣的内容。
header: Indicates information that was extracted from the header of the message. This might be the value of a header field or some portion of a header field.
header：表示从消息头提取的信息。这可能是标题字段的值或标题字段的某些部分。
policy: A local policy mechanism was applied that augments or overrides the result returned by the authentication mechanism. See Section 2.3 of [RFC7001].
策略：应用了一个本地策略机制，用于增强或覆盖身份验证机制返回的结果。参见[RFC7001]第2.3节。
smtp: Indicates information that was extracted from an SMTP command that was used to relay the message.
smtp：表示从用于中继邮件的smtp命令中提取的信息。
When a consumer of this header field encounters a "ptype" that it does not understand, it ignores the result reported with that "ptype".
当此标题字段的使用者遇到不理解的“ptype”时，它将忽略该“ptype”报告的结果。
IANA has created the "Email Authentication Property Types" sub-registry within the existing "Email Authentication Parameters" registry. Entries in this registry are subject to the Expert Review rules as described in [RFC5226]. Each entry in the registry requires the following values:
IANA已在现有的“电子邮件身份验证参数”注册表中创建了“电子邮件身份验证属性类型”子注册表。此注册表中的条目受[RFC5226]中所述的专家评审规则的约束。注册表中的每个条目都需要以下值：
o The "ptype" token to be registered, which must fit within the ABNF described in Section 2.
o 要注册的“ptype”令牌，必须符合第2节所述的ABNF。
o A brief description of what sort of information this "ptype" is meant to cover.
o 简要说明此“ptype”要包含的信息类型。
o An optional reference to the defining document. This is recommended, but not required.
o 对定义文档的可选引用。这是建议的，但不是必需的。
The initial entries in this table are as follows, taken from [RFC7001]:
此表中的初始条目如下所示，取自[RFC7001]：
+--------+-------------+----------------------------------------+
| ptype | Definition | Description |
+--------+-------------+----------------------------------------+
| body | RFC 7001 | The property being reported was found |
| | Section 2.2 | in the body of the message. |
+--------+-------------+----------------------------------------+
| header | RFC 7001 | The property being reported was found |
| | Section 2.2 | in a header field of the message. |
+--------+-------------+----------------------------------------+
| policy | RFC 7001 | The property being reported relates to |
| | Section 2.3 | a locally defined policy. |
+--------+-------------+----------------------------------------+
| smtp | RFC 7001 | The property being reported is a |
| | Section 2.2 | parameter to an SMTP command used to |
| | | relay the message. |
+--------+-------------+----------------------------------------+
+--------+-------------+----------------------------------------+
| ptype | Definition | Description |
+--------+-------------+----------------------------------------+
| body | RFC 7001 | The property being reported was found |
| | Section 2.2 | in the body of the message. |
+--------+-------------+----------------------------------------+
| header | RFC 7001 | The property being reported was found |
| | Section 2.2 | in a header field of the message. |
+--------+-------------+----------------------------------------+
| policy | RFC 7001 | The property being reported relates to |
| | Section 2.3 | a locally defined policy. |
+--------+-------------+----------------------------------------+
| smtp | RFC 7001 | The property being reported is a |
| | Section 2.2 | parameter to an SMTP command used to |
| | | relay the message. |
+--------+-------------+----------------------------------------+
For new entries, the Designated Expert needs to assure that the description provided for the new entry adequately describes the intended use. An example would be helpful to include in the entry's defining document, if any, although entries in the "Email Authentication Methods" registry or the "Email Authentication Result Names" registry might also serve as examples of intended use.
对于新条目，指定专家需要确保为新条目提供的说明充分描述了预期用途。在条目的定义文档（如果有的话）中包含一个示例会很有帮助，尽管“电子邮件身份验证方法”注册表或“电子邮件身份验证结果名称”注册表中的条目也可以作为预期用途的示例。
It is unknown how legacy code, which expects one of a fixed set of "ptype" tokens, will handle new tokens as they begin to appear. There are typically two options: prevent delivery of the message, or ignore those portions of the field that use unknown "ptype" tokens and allow processing of the message to continue.
遗留代码需要一组固定的“ptype”标记中的一个，但它在新标记开始出现时如何处理这些标记尚不清楚。通常有两个选项：阻止传递消息，或忽略字段中使用未知“ptype”标记的部分，并允许继续处理消息。
The choice comes down to whether the consumer considers it a threat when there are unknown "ptypes" present. The semantics of the report are unknown; the report might be indicating the message is authentic, fraudulent, or that a test failed to complete. The report itself is not actionable because it cannot be understood, and only its presence is certain.
当存在未知的“P类型”时，选择取决于消费者是否认为这是一种威胁。报告的语义未知；报告可能表明消息是真实的、欺诈的，或者测试未能完成。报告本身无法采取行动，因为它无法理解，只有它的存在是确定的。
Generally, the advice in this situation is to ignore unknown "ptypes". It is anticipated that a new property type evaluated by earlier handling agents would also result in the filtering of messages by those agents until consumers can be updated to interpret them.
一般来说，这种情况下的建议是忽略未知的“p类型”。预计由早期处理代理评估的新属性类型也会导致这些代理过滤消息，直到消费者可以更新以解释它们。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>.
[RFC7001]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 70012013年9月<http://www.rfc-editor.org/info/rfc7001>.
Acknowledgements
致谢
The author wishes to acknowledge the following for their review and constructive criticism of this update: Dave Crocker, Tim Draegen, Scott Kitterman, and Franck Martin.
作者希望感谢以下对本更新的评论和建设性批评：戴夫·克罗克、蒂姆·德雷根、斯科特·基特曼和弗兰克·马丁。
Author's Address
作者地址
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States
Murray S. Kucherawy 270高地驱动旧金山，CA 94127美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com