Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7073 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7073 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
A Reputation Response Set for Email Identifiers
电子邮件标识符的信誉响应集
Abstract
摘要
This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.
本文档定义了一个响应集，用于描述信誉服务提供商可以对电子邮件标识符做出的断言，以用于生成信誉。
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/rfc7073.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7073.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Terminology and Definitions .....................................2
2.1. Key Words ..................................................2
2.2. Email Definitions ..........................................2
2.3. Other Definitions ..........................................3
3. Discussion ......................................................3
3.1. Assertions .................................................3
3.2. Response Set Extensions ....................................4
3.3. Identifiers ................................................4
3.4. Query Extensions ...........................................5
4. IANA Considerations .............................................5
4.1. Registration of 'email-id' Reputation Application ..........5
5. Security Considerations .........................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Appendix A. Positive vs. Negative Assertions .......................8
Appendix B. Acknowledgments ........................................8
1. Introduction ....................................................2
2. Terminology and Definitions .....................................2
2.1. Key Words ..................................................2
2.2. Email Definitions ..........................................2
2.3. Other Definitions ..........................................3
3. Discussion ......................................................3
3.1. Assertions .................................................3
3.2. Response Set Extensions ....................................4
3.3. Identifiers ................................................4
3.4. Query Extensions ...........................................5
4. IANA Considerations .............................................5
4.1. Registration of 'email-id' Reputation Application ..........5
5. Security Considerations .........................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Appendix A. Positive vs. Negative Assertions .......................8
Appendix B. Acknowledgments ........................................8
This document specifies a response set for describing the reputation of an email identifier. A "response set" in this context is defined in [RFC7070] and is used to describe assertions a reputation service provider can make about email identifiers as well as metadata that can be included in such a reply beyond the base set specified there.
此文档指定用于描述电子邮件标识符信誉的响应集。[RFC7070]中定义了此上下文中的“响应集”，并用于描述声誉服务提供商可对电子邮件标识符以及可包含在此类响应中的元数据（超出此处指定的基本集）做出的断言。
An atomic reputation response is called a "reputon", defined in [RFC7071]. That document also defines a media type to contain a reputon for transport, and creates a registry for reputation applications and the interesting parameters of each.
原子信誉响应称为“信誉”，定义见[RFC7071]。该文档还定义了一个媒体类型以包含用于传输的reputon，并为reputation应用程序和每个应用程序的有趣参数创建了一个注册表。
This section defines terms used in the rest of the document.
本节定义了文档其余部分中使用的术语。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Commonly used definitions describing entities in the email architecture are defined and discussed in [EMAIL-ARCH].
描述电子邮件体系结构中实体的常用定义在[email-ARCH]中进行了定义和讨论。
Other terms of importance in this document are defined in [RFC7070], the base document for the reputation services work.
本文件中的其他重要术语在[RFC7070]中定义，该文件是声誉服务工作的基础文件。
The expression of reputation about an email identifier requires extensions of the base set defined in [RFC7070]. This document defines and registers some common assertions about an entity found in a piece of [MAIL].
有关电子邮件标识符的信誉表达式需要扩展[RFC7070]中定义的基集。本文档定义并注册了一些关于[邮件]中实体的常见断言。
The "email-id" reputation application recognizes the following assertions:
“电子邮件id”信誉应用程序识别以下断言：
abusive: The subject identifier is associated with sending or handling email of a personally abusive, threatening, or otherwise harassing nature
辱骂性：主题标识符与发送或处理具有个人辱骂、威胁或其他骚扰性质的电子邮件有关
fraud: The subject identifier is associated with the sending or handling of fraudulent email, such as "phishing" (some good discussion on this topic can be found in [IODEF-PHISHING])
欺诈：主题标识符与欺诈电子邮件的发送或处理相关，如“网络钓鱼”（有关此主题的一些良好讨论可在[IODEF-phishing]中找到）
invalid-recipients: The subject identifier is associated with delivery attempts to nonexistent recipients
无效收件人：主题标识符与对不存在的收件人的传递尝试相关联
malware: The subject identifier is associated with the sending or handling of malware via email
恶意软件：主题标识符与通过电子邮件发送或处理恶意软件相关
spam: The subject identifier is associated with the sending or handling of unwanted bulk email
垃圾邮件：主题标识符与发送或处理不需要的批量电子邮件相关
For all assertions, the "rating" scale is linear: a value of 0.0 means there is no data to support the assertion, a value of 1.0 means all accumulated data support the assertion, and the intervening values have a linear relationship (i.e., a score of "x" is twice as strong of an assertion as a value of "x/2").
对于所有断言，“评级”量表是线性的：值0.0表示没有数据支持断言，值1.0表示所有累积数据支持断言，并且中间值具有线性关系（即，“x”的分数是断言值“x/2”的两倍）。
The "email-id" reputation application recognizes the following OPTIONAL extensions to the basic response set defined in [RFC7071]:
“电子邮件id”信誉应用程序识别[RFC7071]中定义的基本响应集的以下可选扩展：
email-id-identity: A token indicating the source of the identifier; that is, where the subject identifier was found in the message. This MUST be one of:
电子邮件id标识：指示标识符来源的令牌；即，在消息中找到主题标识符的位置。这必须是以下情况之一：
dkim: The signing domain, i.e., the value of the "d=" tag, found on a valid DomainKeys Identified Mail [DKIM] signature in the message
dkim：签名域，即消息中有效的域密钥标识邮件[dkim]签名上的“d=”标记的值
ipv4: The IPv4 address of the client
ipv4：客户端的ipv4地址
ipv6: The IPv6 address of the client
ipv6：客户端的ipv6地址
rfc5321.helo: The RFC5321.HELO value used by the client (see [SMTP])
rfc5321.helo：客户端使用的rfc5321.helo值（请参阅[SMTP]）
rfc5321.mailfrom: The RFC5321.MailFrom value of the envelope of the message (see [SMTP])
rfc5321.mailfrom：邮件信封的rfc5321.mailfrom值（请参阅[SMTP]）
rfc5322.from: The RFC5322.From field of the message (see [MAIL])
rfc5322.from：消息的rfc5322.from字段（请参阅[邮件]）
spf: The domain name portion of the identifier (RFC5321.MailFrom or RFC5321.HELO) verified by [SPF]
spf：由[spf]验证的标识符（RFC5321.MailFrom或RFC5321.HELO）的域名部分
sources: A token relating a count of the number of sources of data that contributed to the reported reputation. This is in contrast to the "sample-size" parameter, which indicates the total number of reports across all reporting sources.
来源：一个标记，用于记录对报告的声誉有贡献的数据源的数量。这与“样本大小”参数不同，该参数表示所有报告源中的报告总数。
A reply that does not contain the "identity" or "sources" extensions is making a non-specific statement about how the reputation returned was developed. A client can use or ignore such a reply at its discretion.
一个不包含“身份”或“来源”扩展的回复是关于返回的声誉是如何形成的非特定声明。客户可以自行决定使用或忽略此类回复。
In evaluating an email message on the basis of reputation, there can be more than one identifier in the message needing to be validated. For example, a message may have different email addresses in the RFC5321.MailFrom parameter and the RFC5322.From header field. The RFC5321.Helo identifier will obviously be different. Consequently, the software evaluating the email message may need to query for the reputation of more than one identifier.
在根据信誉评估电子邮件时，邮件中可能有多个标识符需要验证。例如，在RFC5321.MailFrom参数和RFC5322.From标头字段中，消息可能具有不同的电子邮件地址。RFC5321.Helo标识符将明显不同。因此，评估电子邮件消息的软件可能需要查询多个标识符的信誉。
The purpose of including the identity in the reply is to expose to the client the context in which the identifier was extracted from the message under evaluation. In particular, several of the items listed are extracted verbatim from the message and have not been subjected to any kind of validation, while a domain name present in a valid DKIM signature has some more reliable semantics associated with it. Computing or using reputation information about unauthenticated identifiers has substantially reduced value, but can sometimes be useful when combined. For example, a reply that indicates a message contained one of these low-value identifiers with a high "spam" rating might not be worthy of notice, but a reply that indicates a message contained several of them could be grounds for suspicion.
在回复中包含标识的目的是向客户机公开从正在评估的消息中提取标识符的上下文。特别是，列出的几个项目是从消息中逐字提取的，没有经过任何形式的验证，而有效DKIM签名中的域名具有更可靠的语义。计算或使用有关未经验证的标识符的信誉信息会大大降低其价值，但有时在结合使用时会很有用。例如，一个回复表示包含这些低值标识符中的一个具有高“垃圾邮件”评级的消息可能不值得注意，但一个回复表示包含其中几个标识符的消息可能会引起怀疑。
A client interested in checking these weaker identifiers would issue a query about each of them using the same assertion (e.g., "spam"), and then collate the results to determine which ones and how many of them came back with ratings indicating content of concern, and take action accordingly. For stronger identifiers, decisions can typically be made based on a few or even just one of them.
对检查这些较弱的标识符感兴趣的客户将使用相同的断言（例如，“垃圾邮件”）对它们中的每一个发出查询，然后整理结果，以确定哪些结果以及其中有多少返回了表示关注内容的评级，并采取相应的措施。对于更强的标识符，通常可以根据其中的几个甚至一个做出决策。
A query within this application can include the OPTIONAL query parameter "identity" to indicate which specific identity is of interest to the query. Legal values are the same as those listed in Section 3.2.
此应用程序中的查询可以包括可选的查询参数“identity”，以指示查询感兴趣的特定标识。法定值与第3.2节中列出的值相同。
This memo presents one action for IANA, namely the registration of the reputation application "email-id".
此备忘录介绍了IANA的一项操作，即注册声誉应用程序“电子邮件id”。
This section registers the "email-id" reputation application, as per the IANA Considerations section of [RFC7071]. The registration parameters are as follows:
本节根据[RFC7071]的IANA注意事项部分注册“电子邮件id”声誉应用程序。注册参数如下：
o Application symbolic name: email-id
o 应用程序符号名称：电子邮件id
o Short description: Evaluates DNS domain names or IP addresses found in email identifiers
o 简短描述：评估在电子邮件标识符中找到的DNS域名或IP地址
o Defining document: [RFC7073]
o 定义文档：[RFC7073]
o Status: current
o 状态：当前
o Subject: A string appropriate to the identifier of interest (see Section 3.2 of this document)
o 主题：适用于感兴趣标识符的字符串（见本文件第3.2节）
o Application-specific query parameters:
o 特定于应用程序的查询参数：
identity: (current) as defined in Section 3.4 of this document
身份：（当前）如本文件第3.4节所定义
o Application-specific assertions:
o 特定于应用程序的断言：
abusive: (current) as defined in Section 3.1 of this document
滥用：（当前）如本文件第3.1节所定义
fraud: (current) as defined in Section 3.1 of this document
欺诈：（当前）如本文件第3.1节所定义
invalid-recipients: (current) as defined in Section 3.1 of this document
无效收件人：（当前）如本文件第3.1节所定义
malware: (current) as defined in Section 3.1 of this document
本文件第3.1节定义的恶意软件：（当前）
spam: (current) as defined in Section 3.1 of this document
垃圾邮件：（当前）如本文件第3.1节所定义
o Application-specific response set extensions:
o 特定于应用程序的响应集扩展：
identity: (current) as defined in Section 3.2 of this document
身份：（当前）如本文件第3.2节所定义
This document is primarily an IANA action and doesn't describe any protocols or protocol elements that might introduce new security concerns.
本文档主要是一个IANA操作，不描述任何可能引入新安全问题的协议或协议元素。
Security considerations relevant to email and email authentication can be found in most of the documents listed in the References sections below. Information specific to use of reputation services can be found in [CONSIDERATIONS].
与电子邮件和电子邮件身份验证相关的安全注意事项可以在以下参考资料部分列出的大多数文档中找到。有关使用声誉服务的特定信息，请参见[注意事项]。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011.
[DKIM]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年9月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[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月。
[RFC7070] Borenstein, N., Kucherawy, M., and A. Sullivan, "An Architecture for Reputation Reporting", RFC 7070, November 2013.
[RFC7070]Borenstein，N.，Kucherawy，M.和A.Sullivan，“声誉报告架构”，RFC 70702013年11月。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, November 2013.
[RFC7071]Borenstein，N.和M.Kucherawy，“声誉交换的媒体类型”，RFC 7071，2013年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[CONSIDERATIONS] Kucherawy, M., "Operational Considerations Regarding Reputation Services", Work in Progress, May 2013.
[考虑]Kucherawy，M.“声誉服务的运营考虑”，正在进行的工作，2013年5月。
[IODEF-PHISHING] Cain, P. and D. Jevans, "Extensions to the IODEF-Document Class for Reporting Phishing", RFC 5901, July 2010.
[IODEF-PHISHING]Cain，P.和D.Jevans，“报告网络钓鱼的IODEF文档类的扩展”，RFC 5901，2010年7月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[CONSIDERATIONS] some current theories about reputation, namely that it will possibly have more impact to develop positive reputations and focus on giving preferential treatment to content or sources that earn those. However, the assertions defined in this document are all clearly negative in nature.
[考虑]目前关于声誉的一些理论，即发展积极的声誉可能会产生更大的影响，并侧重于对获得这些声誉的内容或来源给予优惠待遇。然而，本文档中定义的断言本质上都是否定的。
In effect, this document is recording current use of reputation and of this framework in particular. It is expected that, in the future, the application being registered here will be augmented, and other applications registered, that focus more on positive assertions rather than negative ones.
实际上，本文件记录了声誉的当前使用情况，尤其是本框架的使用情况。预计在将来，这里注册的应用程序将得到扩展，其他注册的应用程序将更加关注积极的断言，而不是消极的断言。
The authors wish to acknowledge the contributions of the following to this specification: Scott Hollenbeck, Scott Kitterman, Peter Koch, John Levine, Danny McPherson, S. Moonesamy, Doug Otis, and David F. Skoll.
作者希望感谢以下人员对本规范的贡献：斯科特·霍伦贝克、斯科特·基特曼、彼得·科赫、约翰·莱文、丹尼·麦克弗森、S.穆内萨米、道格·奥蒂斯和大卫·F.斯科尔。
Authors' Addresses
作者地址
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
美国马萨诸塞州沃尔瑟姆新月街203号303室Nathaniel Borenstein Mimecast 02453
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
Murray S. Kucherawy 270高地驱动旧金山，CA 94127美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com