Network Working Group                                          M. Thomas
Request for Comments: 5016                                 Cisco Systems
Category: Informational                                     October 2007
        
Network Working Group                                          M. Thomas
Request for Comments: 5016                                 Cisco Systems
Category: Informational                                     October 2007
        

Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol

域密钥识别邮件(DKIM)签名实践协议的要求

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Abstract

摘要

DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD).

DomainKeys Identified Mail(DKIM)为域提供了一种加密机制,用于声明对其处理的消息的责任。一个相关的机制将允许管理员发布关于其DKIM签名实践的各种声明。本文件定义了该机制的要求,区分了必须满足的要求(必须)和非常需要的要求(应该)。

Table of Contents

目录

   1. Introduction ....................................................2
   2. Definitions and Requirements Language ...........................3
   3. SSP Problem Scenarios ...........................................4
      3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
      3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
   4. SSP Deployment Considerations ...................................6
      4.1. Deployment Consideration 1: Outsourced Signing .............6
      4.2. Deployment Consideration 2: Subdomain Coverage .............6
      4.3. Deployment Consideration 3: Resent Original Mail ...........7
      4.4. Deployment Consideration 4: Incremental Deployment
           of Signing .................................................7
      4.5. Deployment Consideration 5: Performance and Caching ........8
      4.6. Deployment Consideration 6: Human Legibility of Practices ..8
      4.7. Deployment Consideration 7: Extensibility ..................8
      4.8. Deployment Consideration 8: Security .......................8
   5. Requirements ....................................................9
      5.1. Discovery Requirements .....................................9
      5.2. SSP Transport Requirements ................................10
      5.3. Practice and Expectation Requirements .....................10
      5.4. Extensibility and Forward Compatibility Requirements ......13
   6. Requirements for SSP Security ..................................13
   7. Security Considerations ........................................13
   8. Acknowledgments ................................................13
   9. References .....................................................14
      9.1. Normative References ......................................14
        
   1. Introduction ....................................................2
   2. Definitions and Requirements Language ...........................3
   3. SSP Problem Scenarios ...........................................4
      3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
      3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
   4. SSP Deployment Considerations ...................................6
      4.1. Deployment Consideration 1: Outsourced Signing .............6
      4.2. Deployment Consideration 2: Subdomain Coverage .............6
      4.3. Deployment Consideration 3: Resent Original Mail ...........7
      4.4. Deployment Consideration 4: Incremental Deployment
           of Signing .................................................7
      4.5. Deployment Consideration 5: Performance and Caching ........8
      4.6. Deployment Consideration 6: Human Legibility of Practices ..8
      4.7. Deployment Consideration 7: Extensibility ..................8
      4.8. Deployment Consideration 8: Security .......................8
   5. Requirements ....................................................9
      5.1. Discovery Requirements .....................................9
      5.2. SSP Transport Requirements ................................10
      5.3. Practice and Expectation Requirements .....................10
      5.4. Extensibility and Forward Compatibility Requirements ......13
   6. Requirements for SSP Security ..................................13
   7. Security Considerations ........................................13
   8. Acknowledgments ................................................13
   9. References .....................................................14
      9.1. Normative References ......................................14
        
1. Introduction
1. 介绍

DomainKeys Identified Mail [RFC4871] defines a message level signing and verification mechanism for email. While a DKIM signed message speaks for itself, there is ambiguity if a message doesn't have a valid first party signature (i.e., on behalf of the [RFC2822].From address): is this to be expected or not? For email, this is an especially difficult problem since there is no expectation of a priori knowledge of a sending domain's practices. This ambiguity can be used to mount a bid down attack that is inherent with systems like email that allow optional authentication: if a receiver doesn't know otherwise, it should not assume that the lack of a valid signature is exceptional without other information. Thus, an attacker can take advantage of the ambiguity and simply not sign messages. If a protocol could be developed for a domain to publish its DKIM signing practices, a message verifier could take that into account when it receives an unsigned piece of email.

DomainKeys Identified Mail[RFC4871]定义了电子邮件的消息级签名和验证机制。虽然DKIM签名的消息本身就说明了问题,但如果消息没有有效的第一方签名(即代表[RFC2822].From地址),则存在歧义:这是预期的还是预期的?对于电子邮件来说,这是一个特别困难的问题,因为不需要预先了解发送域的实践。这种模糊性可用于发起一种出价下降攻击,这种攻击是允许可选身份验证的电子邮件等系统固有的:如果接收者不知道其他情况,则不应假定缺少有效签名是例外的,没有其他信息。因此,攻击者可以利用这种模糊性而不在消息上签名。如果可以为域开发一个协议来发布其DKIM签名实践,那么消息验证器可以在收到未签名的电子邮件时考虑到这一点。

This document defines the requirements for a mechanism that permits the publication of Sender Signing Practices (SSP). The document is organized into two main sections: first, a Problem and Deployment Scenario section that describes the problems that SSP is intended to address as well as the deployment issues surrounding the base problems, and the second section is the Requirements that arise because of those scenarios.

本文件定义了允许发布发件人签名实践(SSP)的机制的要求。本文档分为两个主要部分:第一,问题和部署场景部分,描述SSP计划解决的问题以及围绕基本问题的部署问题,第二部分是由于这些场景而产生的需求。

2. Definitions and Requirements Language
2. 定义和要求语言

o Domain Holder: the entity that controls the contents of the DNS subtree starting at the domain, either directly or by delegation via NS records it controls.

o 域持有者:控制从域开始的DNS子树内容的实体,可以直接控制,也可以通过其控制的NS记录进行授权。

o First Party Address: for DKIM, a first party address is defined to be the [RFC2822].From address in the message header; a first party address is also known as an Author address.

o 第一方地址:对于DKIM,第一方地址定义为消息头中的[RFC2822]。发件人地址;第一方地址也称为作者地址。

o First Party Signature: a first party signature is a valid signature where the signing identity (the d= tag or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [RFC4871].

o 第一方签名:第一方签名是签名标识(d=标记或更具体的标识i=标记)与第一方地址匹配的有效签名。[RFC4871]中定义了此上下文中的“匹配项”。

o Third Party Signature: a third party signature is a valid signature that does not qualify as a first party signature. Note that a DKIM third party signature is not required to correspond to a header field address such as the contents of Sender or List-Id, etc.

o 第三方签名:第三方签名是不符合第一方签名条件的有效签名。请注意,DKIM第三方签名不需要对应于标头字段地址,例如发件人或列表Id的内容等。

o Practice: a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends.

o 实践:根据[RFC2822]的规定,域持有者在其发送的电子邮件中有可外部验证的行为。

o Expectation: an expectation combines with a practice to convey what the domain holder considers the likely survivability of the practice for a receiver, in particular receivers that may be more than one SMTP hop away.

o 期望:期望与实践相结合,以传达域持有者认为对于接收者,尤其是可能在一个以上SMTP跃点之外的接收者,实践的可能生存性。

o DKIM Signing Complete: a practice where the domain holder asserts that all legitimate mail will be sent with a valid first party signature.

o DKIM签名完成:域名持有者声明所有合法邮件将使用有效的第一方签名发送的做法。

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]中所述进行解释。

3. SSP Problem Scenarios
3. SSP问题场景

The email world is a diverse place with many deployment considerations. This section outlines expected usage scenarios where DKIM signing/verifying will take place, and how a new protocol might help to clarify the relevance of DKIM-signed mail.

电子邮件世界是一个多样化的地方,有许多部署方面的考虑。本节概述了DKIM签名/验证的预期使用场景,以及新协议如何帮助澄清DKIM签名邮件的相关性。

3.1. Problem Scenario 1: Is All Mail Signed with DKIM?
3.1. 问题场景1:是否所有邮件都使用DKIM签名?

After auditing their outgoing mail and deploying DKIM signing for all of their legitimate outgoing mail, a domain could be said to be DKIM signing complete. That is, the domain has, to the best of its ability, ensured that all legitimate mail purporting to have come from that domain contains a valid DKIM signature.

在审核其发送邮件并为其所有合法发送邮件部署DKIM签名后,可以说域已完成DKIM签名。也就是说,域已尽其所能确保所有声称来自该域的合法邮件都包含有效的DKIM签名。

A receiver in the general case doesn't know what the practices are for a given domain. Thus, the receiver is at a disadvantage in not knowing whether or not it should expect all mail to be signed from a given domain. This knowledge gap leads to a trivially exploitable bid-down attack where the attacker merely sends unsigned mail; since the receiver doesn't know the practices of the signing domain, it cannot treat the message any more harshly for lack of a valid signature.

一般情况下,接收者不知道给定域的实践是什么。因此,接收者在不知道是否应该期望所有邮件都来自给定域时处于劣势。这种知识差距导致了一种可利用的低价攻击,攻击者只发送未签名邮件;因为接收者不知道签名域的实践,所以不能因为缺少有效的签名而更加严厉地对待消息。

An information service that allows a receiver to query for the practices and expectations of the first party domain when no valid first party signature is found could be useful in closing this gap. A receiver could use this information to treat such questionable mail with varying degrees of prejudice.

当没有找到有效的第一方签名时,允许接收者查询第一方域的实践和期望的信息服务可能有助于缩小这一差距。接收者可以利用这些信息以不同程度的偏见对待此类可疑邮件。

Note that, for the foreseeable future, unrestricted use patterns of mail (e.g., where users may be members of mailing lists, etc.) will likely suffer occasional, non-malicious signature failure in transit. While probably not a large percentage of total traffic, this kind of breakage may be a significant concern for those usage patterns. This scenario defines where the sender cannot set any expectation as to whether an individual message will arrive intact.

请注意,在可预见的未来,邮件的无限制使用模式(例如,用户可能是邮件列表的成员等)可能会在传输过程中偶尔出现非恶意签名故障。虽然可能不占总流量的很大比例,但这种破坏可能是这些使用模式的一个重要问题。此场景定义了发送者不能设置任何期望,以确定单个邮件是否会完整到达。

Even without that expectation, a receiver may be able to take advantage of the knowledge that the domain's practice is to sign all mail and bias its filters against unsigned or damaged in transit mail. This information should not be expected to be used in a binary yes/no fashion, but instead as a data point among others in a filtering system.

即使没有这种期望,接收者也可以利用域的做法是对所有邮件进行签名的知识,并将其过滤器与未签名或损坏的在途邮件相比较。该信息不应以二进制是/否的方式使用,而是作为过滤系统中的数据点。

The following exchange illustrates problem scenario 1.

下面的交换说明了问题场景1。

1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken DKIM first party signature from Alice.

1. 带有[RFC2822]的邮件从域Alice发送到域Bob,其中包含Alice丢失或损坏的DKIM第一方签名。

2. Domain Bob would like to know whether that is an expected state of affairs.

2. 域Bob想知道这是否是预期的情况。

3. Domain Alice provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature.

3. DomainAlice提供了它对所有发送邮件进行签名的信息,但并不期望邮件到达时会有完整的第一方签名。

4. Domain Bob could use this information to bias its filters to examine the message with some suspicion.

4. 域Bob可以使用此信息使其过滤器产生偏差,从而带着一些怀疑来检查消息。

3.2. Problem Scenario 2: Illegitimate Domain Name Use
3.2. 问题场景2:非法使用域名

A class of mail typified by transactional mail from high-value domains is currently the target of phishing attacks. In particular, many phishing scams forge the [RFC2822].From address in addition to spoofing much of the content to trick unsuspecting users into revealing sensitive information. Domain holders sending this mail would like the ability to give an enhanced guarantee that mail sent with their domain name should always arrive with the proof that the domain holder consented to its transmission. That is, the message should contain a valid first party signature as defined above.

以来自高价值域的事务性邮件为代表的一类邮件目前是网络钓鱼攻击的目标。特别是,许多网络钓鱼欺诈除了欺骗大部分内容之外,还伪造[RFC2822].From地址,诱骗毫无戒心的用户泄露敏感信息。发送此邮件的域名持有人希望能够提供增强的保证,即使用其域名发送的邮件应始终带有域名持有人同意其传输的证明。也就是说,消息应该包含上面定义的有效第一方签名。

From a receiver's standpoint, knowing that a domain not only signs all of its mail, but places a very high value on the receipt of a valid first party signature from that domain is helpful. Hence, a receiver knows that the sending domain signs all its mail, and that the sending domain considers mail from this domain particularly sensitive in some sense, and is asking the receiver to be more suspicious than it otherwise might be of a broken or missing first-party signature. A receiver with the knowledge of the sender's expectations in hand might choose to process messages not conforming to the published practices in a special manner. Note that the ability to state an enhanced guarantee of a valid signature means that senders should expect mail that traverses modifying intermediaries (e.g., mailing lists, etc.) will likely be quarantined or deleted; thus, this scenario is more narrow than problem scenario 1.

从接收者的角度来看,知道域不仅对其所有邮件进行签名,而且对从该域收到有效的第一方签名具有很高的价值是很有帮助的。因此,接收者知道发送域对其所有邮件进行签名,并且发送域认为来自该域的邮件在某种意义上特别敏感,并且要求接收者比其他情况下更加怀疑第一方签名是否损坏或丢失。了解发送者期望的接收者可能会选择以特殊方式处理不符合已发布实践的消息。请注意,声明有效签名的增强保证的能力意味着发件人应该期望通过修改的中介(例如邮件列表等)的邮件可能会被隔离或删除;因此,这个场景比问题场景1更窄。

Informative Note: a receiving filter may choose to treat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is very wrong.

资料性说明:接收过滤器可能会选择比场景1更严厉地对待场景2;场景1看起来很奇怪,场景2看起来很不对劲。

1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken first party DKIM signature from domain Alice.

1. 带有[RFC2822]的邮件从域Alice发送到域Bob,其中包含域Alice丢失或损坏的第一方DKIM签名。

2. Domain Bob would like to know whether that is an expected state of affairs.

2. 域Bob想知道这是否是预期的情况。

3. Domain Alice provides information that it signs all outgoing mail, and furthermore places an expectation that it should arrive with an intact first party signature, and that the receiver should be much more wary if it does not.

3. Domain Alice提供的信息表明,它对所有发出的邮件都进行了签名,并且期望邮件到达时带有完整的第一方签名,如果没有,接收者应该更加小心。

4. Domain Bob could use this information to bias its filters such that it examines the message with great suspicion.

4. 域Bob可以使用此信息对其过滤器进行偏移,从而以极大的怀疑来检查消息。

4. SSP Deployment Considerations
4. SSP部署注意事项

Given the problems enumerated above for which we'd like SSP to provide information to recipients, there are a number of scenarios that are not related to the problems that are to be solved, per se, but the actual mechanics of implementing/deploying the information service that SSP would provide.

鉴于上面列举的问题,我们希望SSP向接收者提供信息,因此有许多场景与需要解决的问题本身无关,而是与SSP将提供的信息服务的实际实现/部署机制有关。

4.1. Deployment Consideration 1: Outsourced Signing
4.1. 部署考虑事项1:外包签名

Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable for a domain holder to have the ability to delegate to other entities the ability to sign for the domain holder. One obvious use scenario is a domain holder from a small domain that needs to have the ability for their outgoing ISP to sign all of their mail on behalf of the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions, such as insurance benefits, etc.

许多域不运行自己的邮件基础设施,或者可能将部分邮件基础设施外包给第三方。域持有者最好能够将为域持有者签名的能力委托给其他实体。一个明显的使用场景是来自一个小域名的域名持有者需要有能力让他们的ISP代表域名持有者签署他们所有的邮件。其他使用场景包括为营销活动外包大量邮件,以及外包各种业务功能,如保险福利等。

4.2. Deployment Consideration 2: Subdomain Coverage
4.2. 部署考虑事项2:子域覆盖

An SSP client will perform lookups on incoming mail streams to provide the information as proposed in the problem scenarios. The domain part of the first address of the [RFC2822].From will form the basis to fetch the published information. A trivial attack to circumvent finding the published information can be mounted by simply using a subdomain of the parent domain that doesn't have published information. This attack is called the subdomain attack: that is, a domain wants to not only publish a policy for a given DNS label it controls, but it would also like to protect all subdomains of that label as well. If this characteristic is not met, an attacker would need only create a possibly fictitious subdomain that was not covered

SSP客户端将对传入邮件流执行查找,以提供问题场景中建议的信息。[RFC2822].From的第一个地址的域部分将构成获取已发布信息的基础。通过简单地使用没有发布信息的父域的子域,可以装载绕过查找已发布信息的普通攻击。这种攻击称为子域攻击:也就是说,域不仅要为其控制的给定DNS标签发布策略,而且还要保护该标签的所有子域。如果不满足此特征,攻击者只需创建一个可能虚构的未覆盖子域

by the SSP's information service. Thus, it would be advantageous for SSP to not only cover a given domain, but all subdomains of that domain as well.

由单一共享平台的信息服务提供。因此,SSP不仅覆盖给定域,而且还覆盖该域的所有子域是有利的。

4.3. Deployment Consideration 3: Resent Original Mail
4.3. 部署注意事项3:重新发送原始邮件

Resent mail is a common occurrence in many scenarios in the email world of today. For example, domain Alice sends a DKIM-signed message with a published practice of signing all messages to domain Bob's mailing list. Bob, being a good net citizen, wants to be able to take his part of the responsibility of the message in question, so he DKIM signs the message, perhaps corresponding to the Sender address.

在当今电子邮件世界的许多场景中,重新发送邮件是常见的现象。例如,domain Alice发送一条DKIM签名的消息,该消息具有将所有消息签名到domain Bob邮件列表的已发布实践。Bob是一名优秀的网络公民,他希望能够承担起自己对相关消息的部分责任,因此他在消息上签名,可能与发件人地址相对应。

Note that this scenario is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wants to assert his part in the chain of accountability for the benefit of the ultimate receivers. It would be useful for this practice to be encouraged as it gives a more accurate view of who handled the message. It also has the side benefit that remailers that break DKIM first party signatures can be potentially assessed by the receiver based on the receiver's opinion of the signing domains that actually survived.

请注意,这个场景与Alice的签名是否在Bob的邮件列表中幸存完全正交:Bob只想为了最终接收者的利益在责任链中维护自己的角色。鼓励这种做法是有益的,因为它能更准确地了解谁处理了这一信息。它还有一个副作用,即接收方可以根据接收方对实际幸存的签名域的意见,对破坏DKIM第一方签名的剩余者进行潜在评估。

4.4. Deployment Consideration 4: Incremental Deployment of Signing
4.4. 部署注意事项4:签名的增量部署

As a practical matter, it may be difficult for a domain to roll out DKIM signing such that they can publish the DKIM Signing Complete practice given the complexities of the user population, the outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail, such as in Problem Scenario 2, must be classified to the least common denominator of the published practices. It would be desirable to allow a domain holder to publish a list of exceptions that would have a more restrictive practices statement. NB: this consideration has been deemed met by the mechanisms provided by the base DKIM signing mechanism; it is merely documented here as having been an issue.

实际上,考虑到用户群体的复杂性、外包供应商代表其发送的邮件等,域可能很难推出DKIM签名,以便发布完整的DKIM签名实践。这留下了一个利用高价值邮件的漏洞,例如在问题场景2中,必须分类为已发布实践的最小公分母。最好允许域名持有人公布一份例外情况清单,其中包含一份更具限制性的惯例声明。注:基本DKIM签署机制提供的机制已被视为满足了这一考虑;这里只记录了这是一个问题。

For example, bigbank.example.com might be ready to say that statements@bigbank.example.com is always signed, but the rest of the domain, say, is not. Another situation is that the practices of some address local parts in a given domain are not the same as practices of other local parts. Using the same example of statements@bigbank.example.com being a transactional kind of email that would like to publish very strong practices, mixed in with the rest of the user population local parts, which may go through mailing lists, etc., for which a less strong statement is appropriate.

例如,bigbank.example.com可能已经准备好这么说了statements@bigbank.example.com始终是有签名的,但域的其余部分(例如)不是。另一种情况是,给定域中某些地址本地部分的实践与其他本地部分的实践不同。使用相同的示例statements@bigbank.example.com作为一种事务性的电子邮件,它希望发布非常强大的实践,与其他用户群体的本地部分混合在一起,这些部分可能会通过邮件列表等,因此不太强大的声明是合适的。

It should be said that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in order to publish a strong practice, one only has to segregate those cases into different subdomains. For example: accounts.bigbank.example.com would publish constrained practices, while corporateusers.bigbank.example.com might publish more permissive practices.

应该说,通过使用子域,DKIM已经能够支持这种差异化。也就是说,为了发布一个强大的实践,只需将这些案例划分为不同的子域。例如:accounts.bigbank.example.com将发布受约束的实践,而corporateesers.bigbank.example.com可能会发布更宽松的实践。

4.5. Deployment Consideration 5: Performance and Caching
4.5. 部署考虑事项5:性能和缓存

Email service provides an any-any mesh of potential connections: all that is required is the publication of an MX record and an SMTP listener to receive mail. Thus, the use of SSP is likely to fall into two main scenarios, the first of which are large, well-known domains that are in constant contact with one another. In this case, caching of records is essential for performance, including the caching of the non-existence of records (i.e., negative caching).

电子邮件服务提供了一个任意网状的潜在连接:只需发布一条MX记录和一个SMTP侦听器即可接收邮件。因此,SSP的使用可能分为两个主要场景,第一个场景是彼此经常接触的大型知名领域。在这种情况下,缓存记录对性能至关重要,包括缓存不存在的记录(即负缓存)。

The second main scenario is when a domain exchanges mail with a much smaller volume domain. This scenario can be both perfectly normal as with the case of vanity domains, and unfortunately, a vector for those sending mail for anti-social reasons. In this case, we'd like the message exchange burden to SSP querier to be low, since many of the lookups will not provide a useful answer. Likewise, it would be advantageous to have upstream caching here as well so that, say, a mailing list exploder on a small domain does not result in an explosion of queries back at the root and authoritative server for the small domain.

第二个主要场景是域与体积小得多的域交换邮件。这种情况可能与虚荣域名的情况完全正常,但不幸的是,对于那些出于反社会原因发送邮件的人来说,这是一种载体。在这种情况下,我们希望SSP querier的消息交换负担较低,因为许多查找不会提供有用的答案。同样,在这里使用上游缓存也是有利的,这样,比如说,一个小型域上的邮件列表爆炸器不会导致小型域的根服务器和权威服务器上的查询爆炸。

4.6. Deployment Consideration 6: Human Legibility of Practices
4.6. 部署考虑6:实践的人类易读性

While SSP records are likely to be primarily consumed by an automaton, for the foreseeable future they are also likely to be inspected by hand. It would be nice to have the practices stated in a fashion that is also intuitive to the human inspectors.

虽然SSP记录可能主要由自动机使用,但在可预见的未来,它们也可能由人工检查。最好能以一种对人类检查员来说也是直观的方式来说明这些实践。

4.7. Deployment Consideration 7: Extensibility
4.7. 部署考虑7:可扩展性

While this document pertains only to requirements surrounding DKIM signing practices, it would be beneficial for the protocol to be able to extend to other protocols.

虽然本文件仅适用于DKIM签署实践的相关要求,但该协议能够扩展到其他协议将是有益的。

4.8. Deployment Consideration 8: Security
4.8. 部署考虑8:安全

SSP must be able to withstand life in a hostile, open-Internet environment. These include DoS attacks, and especially DoS attacks that leverage themselves through amplification inherent in the protocol. In addition, while a useful protocol may be built without

SSP必须能够承受在敌对、开放的互联网环境中的生活。这些攻击包括DoS攻击,尤其是通过协议固有的放大作用来利用自身的DoS攻击。此外,虽然可以构建一个有用的协议,但是

strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols.

信息服务提供的强源身份验证,协议或底层协议应提供指向强源身份验证的路径。

5. Requirements
5. 要求

This section defines the requirements for SSP. As with most requirements documents, these requirements define the MINIMUM requirements that a candidate protocol must provide. It should also be noted that SSP must fulfill all of the requirements.

本节定义了SSP的要求。与大多数需求文档一样,这些需求定义了候选协议必须提供的最低要求。还应注意,SSP必须满足所有要求。

5.1. Discovery Requirements
5.1. 发现要求

Receivers need a means of obtaining information about a sender's DKIM practices. This requires a means of discovering where the information is and what it contains.

接收者需要一种获取发送者DKIM实践信息的方法。这需要一种发现信息所在位置及其包含内容的方法。

1. The author is the first-party sender of a message, as specified in the [RFC2822].From field. SSP's information is associated with the author's domain name, and is published subordinate to that domain name.

1. 作者是消息的第一方发件人,如[RFC2822].From字段中所指定。SSP的信息与作者的域名关联,并从属于该域名发布。

2. In order to limit the cost of its use, any query service supplying SSP's information MUST provide a definitive response within a small, deterministic number of message exchanges under normal operational conditions.

2. 为了限制其使用成本,任何提供SSP信息的查询服务都必须在正常操作条件下,在少量确定数量的消息交换中提供最终响应。

Informative Note: this, for all intents and purposes is a prohibition on anything that might produce loops or result in extended delays and overhead; also though "deterministic" doesn't specify how many exchanges, the expectation is "few".

资料性说明:出于所有意图和目的,禁止任何可能产生循环或导致延长延迟和开销的行为;此外,虽然“确定性”没有指定交换的数量,但期望值是“很少”。

Refs: Deployment Considerations, Sections 4.2 and 4.5.

参考:部署注意事项,第4.2节和第4.5节。

3. SSP's publishing mechanism MUST be defined such that it does not lead to multiple resource records of the same type for different protocols residing at the same location.

3. 必须定义SSP的发布机制,以确保它不会导致位于同一位置的不同协议的相同类型的多个资源记录。

Informative note: an example is multiple resource record of the same type within a common DNS leaf. Hence, uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous referencing.

资料性说明:一个示例是公共DNS叶中相同类型的多个资源记录。因此,唯一定义的叶名称或唯一定义的资源记录类型将确保明确的引用。

Refs: Deployment Consideration, Section 4.2.

参考:部署考虑,第4.2节。

4. SSP retrieval SHOULD provide coverage for not only a given domain but all of its subdomains as well. It is recognized that there is some reasonable doubt about the feasibility of a widely accepted solution to this requirement. If the working group does not achieve rough consensus on a solution, it MUST document the relevant security considerations in the protocol specification.

4. SSP检索不仅应覆盖给定域,还应覆盖其所有子域。人们认识到,对于这一要求的广泛接受的解决方案的可行性存在一些合理的怀疑。如果工作组未能就解决方案达成大致共识,则必须在协议规范中记录相关安全注意事项。

Refs: Deployment Considerations, Sections 4.2 and 4.5.

参考:部署注意事项,第4.2节和第4.5节。

5.2. SSP Transport Requirements
5.2. SSP运输要求

The publication and query mechanism will operate as an internet-based message exchange. There are multiple requirements for this lower-layer service:

发布和查询机制将作为基于互联网的信息交换机制运作。此低层服务有多种要求:

1. The exchange SHOULD have existing widespread deployment of the transport layer, especially if riding on top of a true transport layer (e.g., TCP, UDP).

1. 交换应该有传输层的现有广泛部署,特别是在真正的传输层(例如TCP、UDP)之上的情况下。

Refs: Deployment Considerations, Sections 4.5 and 4.7.

参考:部署注意事项,第4.5节和第4.7节。

2. The query/response in terms of latency time and the number of messages involved MUST be low (less than three message exchanges not counting retransmissions or other exceptional conditions).

2. 就延迟时间和涉及的消息数量而言,查询/响应必须较低(少于三次消息交换,不包括重传或其他异常情况)。

Refs: Deployment Consideration, Section 4.5.

参考:部署考虑,第4.5节。

3. If the infrastructure doesn't provide caching (a la DNS), the records retrieved MUST provide initiators the ability to maintain their own cache. The existing caching infrastructure is, however, highly desirable.

3. 如果基础设施不提供缓存(la DNS),则检索到的记录必须为启动器提供维护自己缓存的能力。然而,现有的缓存基础设施非常理想。

Refs: Deployment Consideration, Section 4.5.

参考:部署考虑,第4.5节。

4. Multiple geographically and topologically diverse servers MUST be supported for high availability.

4. 为了实现高可用性,必须支持多个地理位置和拓扑结构不同的服务器。

Refs: Deployment Considerations, Sections 4.5 and 4.7.

参考:部署注意事项,第4.5节和第4.7节。

5.3. Practice and Expectation Requirements
5.3. 实践和期望要求

As stated in the definitions section, a practice is a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. As an example, a practice might be defined such that all email messages will contain a DKIM signature corresponding to the [RFC2822].From address. Since there is a possibility of alteration between what a sender sends and a receiver examines, an expectation combines with a practice to

如定义部分所述,实践是根据[RFC2822]的声明,由域持有者在其发送的电子邮件中提供外部可验证行为。例如,可以定义一种做法,使所有电子邮件包含与[RFC2822].From地址相对应的DKIM签名。由于发送者发送的内容和接收者检查的内容之间有可能发生变化,因此期望与实践相结合,以

convey what the [RFC2822].From domain considers the likely outcome of the survivability of the practice at a receiver. For example, a practice that a valid DKIM for the [RFC2822].From address is present when it is sent from the domain, and an expectation that it will remain present and valid for all receivers whether topologically adjacent or not.

传达域[RFC2822]所考虑的接收方实践生存能力的可能结果。例如,一种做法是[RFC2822].From地址的有效DKIM在从域发送时存在,并且期望它将保持存在并对所有接收器有效,无论是否在拓扑上相邻。

1. SSP MUST be able to make practices and expectation assertions about the domain part of a [RFC2822].From address in the context of DKIM. SSP will not make assertions about other addresses for DKIM at this time.

1. SSP必须能够在DKIM上下文中对[RFC2822].From地址的域部分进行实践和期望断言。SSP此时不会断言DKIM的其他地址。

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

参考:问题场景1和2,第3.1节和第3.2节。

2. SSP MUST provide a concise linkage between the [RFC2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a first party signature.

2. SSP必须在[RFC2822].From和DKIM i=标记中的标识之间提供简洁的链接,如果签名中缺少该标识,则为默认标识。也就是说,SSP必须精确定义第一方签名的语义。

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

参考:问题场景1和2,第3.1节和第3.2节。

3. SSP MUST be able to publish a practice that the domain's signing behavior is "DKIM Signing Complete". That is, all messages were transmitted with a valid first party signature.

3. SSP必须能够发布域的签名行为为“DKIM签名完成”的实践。也就是说,所有消息都使用有效的第一方签名进行传输。

Refs: Problem Scenario 1, Section 3.1.

参考:问题场景1,第3.1节。

4. SSP MUST be able to publish an expectation that a verifiable first party DKIM signature should be expected on receipt of a message.

4. SSP必须能够发布一个预期,即在收到消息时预期会有可验证的第一方DKIM签名。

Refs: Problem Scenario 2, Section 3.2.

参考:问题场景2,第3.2节。

5. Practices and expectations MUST be presented in SSP syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown.

5. 必须使用尽可能直观的描述符,以SSP语法呈现实践和期望。例如,p=?最好表示为p=未知。

Refs: Deployment Consideration, Section 4.6.

参考:部署考虑,第4.6节。

6. Because DKIM uses DNS to store selectors, there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to an affiliated party of the domain holder's choosing. That is, the domain holder may set an NS record for _domainkey.example.com to delegate to an email provider who manages the entire namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com

6. 由于DKIM使用DNS存储选择器,因此域持有者始终能够将_domainkey子域的全部或部分委托给域持有者选择的关联方。也就是说,域持有者可以为_domainkey.example.com设置NS记录,以委托给管理整个命名空间的电子邮件提供商。域持有者还可以将其命名空间划分为子域,以进一步约束第三方。例如,域名持有者只能委托_domainkey.benefits.example.com

to a third party to constrain the third party to only be able to produce valid signatures in the benefits.example.com subdomain. Last, a domain holder can even use CNAME's to delegate individual leaf nodes. Given the above considerations, SSP need not invent a different means of allowing affiliated parties to sign on a domain's behalf at this time.

限制第三方只能在benefits.example.com子域中生成有效签名。最后,域持有者甚至可以使用CNAME来委托单个叶节点。鉴于上述考虑,SSP此时无需发明另一种允许关联方代表域签名的方式。

Refs: Deployment Consideration, Section 4.4.

参考:部署考虑,第4.4节。

7. Practices and expectations MUST be presented as an information service from the signing domain to be consumed as an added factor to the receiver's local policy. In particular, a practice or expectation MUST NOT mandate any disposition stance on the receiver.

7. 实践和期望必须作为来自签名域的信息服务呈现,作为接收方本地政策的附加因素使用。特别是,实践或期望不得强制要求接收人采取任何处置立场。

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

参考:问题场景1和2,第3.1节和第3.2节。

8. There is no requirement that SSP publish practices of any/all third parties that MUST NOT sign on the domain holder's behalf. This should be considered out of scope.

8. 不要求SSP发布任何/所有不得代表域名持有人签署的第三方的实践。这应被视为超出范围。

INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.

信息性说明:这实质上是说,协议本身不必考虑成为黑名单存储库。

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

参考:问题场景1和2,第3.1节和第3.2节。

9. SSP MUST NOT be required to be invoked if a valid first party signature is found.

9. 如果找到有效的第一方签名,则不得要求调用SSP。

Refs: Deployment Consideration, Section 4.2.

参考:部署考虑,第4.2节。

10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers.

10. SSP不得提供质疑消息中是否存在非第一方签名的机制。这一要求的必然结果是,协议不得将第一方签字人的做法与第三方签字人的做法联系起来。

INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver.

资料性说明:该要求的主旨是,实践只应针对发布者控制的内容发布,而不应干预接收者的本地政策。

Refs: Deployment Consideration, Section 4.3.

参考:部署考虑,第4.3节。

5.4. Extensibility and Forward Compatibility Requirements
5.4. 扩展性和前向兼容性要求

1. SSP MUST NOT extend to any protocol other than DKIM for email at this time. SSP SHOULD be extensible for protocols other than DKIM.

1. SSP此时不得扩展到DKIM以外的任何电子邮件协议。SSP应可扩展用于DKIM以外的协议。

Refs: Deployment Consideration, Section 4.7.

参考:部署考虑,第4.7节。

2. SSP MUST be able to add new practices and expectations within the existing discovery/transport/practices in a backward compatible fashion.

2. SSP必须能够以向后兼容的方式在现有发现/传输/实践中添加新的实践和期望。

Refs: Deployment Consideration, Section 4.7.

参考:部署考虑,第4.7节。

6. Requirements for SSP Security
6. SSP安全要求

1. SSP for a high-value domain is potentially a high-value DoS target, especially since the unavailability of SSP's record could make unsigned messages less suspicious.

1. 高值域的SSP可能是高值DoS目标,特别是因为SSP记录的不可用性会降低未签名邮件的可疑性。

2. SSP MUST NOT make highly leveraged amplification or make-work attacks possible. In particular, the work and message exchanges involved MUST be order of a constant.

2. SSP不得使高杠杆放大或使工作攻击成为可能。特别是,所涉及的工作和消息交换必须是一个常数的顺序。

Refs: Deployment Consideration, Section 4.8.

参考:部署考虑,第4.8节。

3. SSP MUST have the ability for a domain holder to provide SSP's data such that a receiver can determine that it is authentically from the domain holder with a large degree of certainty. SSP may provide means that provide less certainty in trade off for ease of deployment.

3. SSP必须具备域持有人提供SSP数据的能力,以便接收者能够以很大程度的确定性确定该数据真实来自域持有人。单一共享平台可能会提供一些方法,以减少为便于部署而进行权衡的确定性。

Refs: Deployment Consideration, Section 4.8.

参考:部署考虑,第4.8节。

7. Security Considerations
7. 安全考虑

This document defines requirements for a new protocol and the security related requirements are defined above. Since it is expected that the new protocol will use the DNS as a basis for the published SSP information, most if not all of the threats described in [RFC4686] will be applicable.

本文件定义了新协议的要求,上述定义了与安全相关的要求。由于预计新协议将使用DNS作为已发布SSP信息的基础,因此[RFC4686]中描述的大部分(如果不是全部的话)威胁都将适用。

8. Acknowledgments
8. 致谢

Dave Crocker and Jim Fenton provided substantial review of this document. Thanks also to Vijay Gurbani and David Harrington for their helpful last call reviews.

Dave Crocker和Jim Fenton对本文件进行了实质性审查。还要感谢Vijay Gurbani和David Harrington对上次通话的评论。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[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月。

[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.

[RFC2822]Resnick,P.,Ed.,“互联网信息格式”,RFC 2822,2001年4月。

[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.

[RFC4686]Fenton,J.,“驱动域密钥识别邮件(DKIM)的威胁分析”,RFC4686,2006年9月。

[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.

[RFC4871]Allman,E.,Callas,J.,Delany,M.,Libbey,M.,Fenton,J.,和M.Thomas,“域密钥识别邮件(DKIM)签名”,RFC 48712007年5月。

Author's Address

作者地址

Michael Thomas Cisco Systems 606 Sanchez St San Francisco, California 94114 USA

米迦勒托马斯思科系统606桑切斯ST旧金山,加利福尼亚94114美国

   Phone: +1-408-525-5386
   Fax:   +1-408-525-5386
   EMail: mat@cisco.com
        
   Phone: +1-408-525-5386
   Fax:   +1-408-525-5386
   EMail: mat@cisco.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

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.