Internet Engineering Task Force (IETF)                         T. Hansen
Request for Comments: 5863                             AT&T Laboratories
Category: Informational                                        E. Siegel
ISSN: 2070-1721                                               Consultant
                                                         P. Hallam-Baker
                                             Default Deny Security, Inc.
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                                May 2010
Internet Engineering Task Force (IETF)                         T. Hansen
Request for Comments: 5863                             AT&T Laboratories
Category: Informational                                        E. Siegel
ISSN: 2070-1721                                               Consultant
                                                         P. Hallam-Baker
                                             Default Deny Security, Inc.
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                                May 2010

DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations




DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM.

DomainKeys Identified Mail(DKIM)允许组织以可由收件人验证的方式声明传输消息的责任。组织可以是作者、原始发送站点、中间人或其代理人之一。一封邮件可以包含多个签名,这些签名来自与该邮件相关的相同或不同的组织。DKIM为电子邮件定义了一个域级数字签名身份验证框架,使用公钥加密技术,并使用域名服务作为其密钥服务器技术。这允许验证责任组织以及消息内容的完整性。DKIM还将提供一种机制,允许潜在的电子邮件签名者发布有关其电子邮件签名实践的信息;这将允许电子邮件接收者对邮件进行额外的评估。DKIM的电子邮件身份验证可以帮助全球控制“垃圾邮件”和“网络钓鱼”。本文档提供了DKIM的实现、部署、操作和迁移注意事项。

Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非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


Copyright Notice


Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents


   1. Introduction ....................................................4
   2. Using DKIM as Part of Trust Assessment ..........................4
      2.1. A Systems View of Email Trust Assessment ...................4
      2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
      2.3. Choosing the Signing Domain Name ...........................8
      2.4. Recipient-Based Assessments ...............................10
      2.5. Filtering .................................................12
   3. DKIM Key Generation, Storage, and Management ...................15
      3.1. Private Key Management: Deployment and Ongoing
           Operations ................................................16
      3.2. Storing Public Keys: DNS Server Software Considerations ...17
      3.3. Per-User Signing Key Management Issues ....................18
      3.4. Third-Party Signer Key Management and Selector
           Administration ............................................19
      3.5. Key Pair / Selector Life Cycle Management .................19
   1. Introduction ....................................................4
   2. Using DKIM as Part of Trust Assessment ..........................4
      2.1. A Systems View of Email Trust Assessment ...................4
      2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
      2.3. Choosing the Signing Domain Name ...........................8
      2.4. Recipient-Based Assessments ...............................10
      2.5. Filtering .................................................12
   3. DKIM Key Generation, Storage, and Management ...................15
      3.1. Private Key Management: Deployment and Ongoing
           Operations ................................................16
      3.2. Storing Public Keys: DNS Server Software Considerations ...17
      3.3. Per-User Signing Key Management Issues ....................18
      3.4. Third-Party Signer Key Management and Selector
           Administration ............................................19
      3.5. Key Pair / Selector Life Cycle Management .................19
   4. Signing ........................................................21
      4.1. DNS Records ...............................................21
      4.2. Signing Module ............................................21
      4.3. Signing Policies and Practices ............................22
   5. Verifying ......................................................23
      5.1. Intended Scope of Use .....................................23
      5.2. Signature Scope ...........................................23
      5.3. Design Scope of Use .......................................24
      5.4. Inbound Mail Filtering ....................................24
      5.5. Messages Sent through Mailing Lists and Other
           Intermediaries ............................................25
      5.6. Generation, Transmission, and Use of Results Headers ......25
   6. Taxonomy of Signatures .........................................26
      6.1. Single Domain Signature ...................................26
      6.2. Parent Domain Signature ...................................27
      6.3. Third-Party Signature .....................................27
      6.4. Using Trusted Third-Party Senders .........................29
      6.5. Multiple Signatures .......................................30
   7. Example Usage Scenarios ........................................31
      7.1. Author's Organization - Simple ............................32
      7.2. Author's Organization - Differentiated Types of Mail ......32
      7.3. Author Domain Signing Practices ...........................32
      7.4. Delegated Signing .........................................34
      7.5. Independent Third-Party Service Providers .................35
      7.6. Mail Streams Based on Behavioral Assessment ...............35
      7.7. Agent or Mediator Signatures ..............................36
   8. Usage Considerations ...........................................36
      8.1. Non-Standard Submission and Delivery Scenarios ............36
      8.2. Protection of Internal Mail ...............................37
      8.3. Signature Granularity .....................................38
      8.4. Email Infrastructure Agents ...............................39
      8.5. Mail User Agent ...........................................40
   9. Security Considerations ........................................41
   10. Acknowledgements ..............................................41
   11. References ....................................................42
      11.1. Normative References .....................................42
      11.2. Informative References ...................................42
   Appendix A.  Migration Strategies .................................43
     A.1.  Migrating from DomainKeys .................................43
     A.2.  Migrating Hash Algorithms .................................48
     A.3.  Migrating Signing Algorithms ..............................49
   Appendix B.  General Coding Criteria for Cryptographic
                Applications .........................................50
   4. Signing ........................................................21
      4.1. DNS Records ...............................................21
      4.2. Signing Module ............................................21
      4.3. Signing Policies and Practices ............................22
   5. Verifying ......................................................23
      5.1. Intended Scope of Use .....................................23
      5.2. Signature Scope ...........................................23
      5.3. Design Scope of Use .......................................24
      5.4. Inbound Mail Filtering ....................................24
      5.5. Messages Sent through Mailing Lists and Other
           Intermediaries ............................................25
      5.6. Generation, Transmission, and Use of Results Headers ......25
   6. Taxonomy of Signatures .........................................26
      6.1. Single Domain Signature ...................................26
      6.2. Parent Domain Signature ...................................27
      6.3. Third-Party Signature .....................................27
      6.4. Using Trusted Third-Party Senders .........................29
      6.5. Multiple Signatures .......................................30
   7. Example Usage Scenarios ........................................31
      7.1. Author's Organization - Simple ............................32
      7.2. Author's Organization - Differentiated Types of Mail ......32
      7.3. Author Domain Signing Practices ...........................32
      7.4. Delegated Signing .........................................34
      7.5. Independent Third-Party Service Providers .................35
      7.6. Mail Streams Based on Behavioral Assessment ...............35
      7.7. Agent or Mediator Signatures ..............................36
   8. Usage Considerations ...........................................36
      8.1. Non-Standard Submission and Delivery Scenarios ............36
      8.2. Protection of Internal Mail ...............................37
      8.3. Signature Granularity .....................................38
      8.4. Email Infrastructure Agents ...............................39
      8.5. Mail User Agent ...........................................40
   9. Security Considerations ........................................41
   10. Acknowledgements ..............................................41
   11. References ....................................................42
      11.1. Normative References .....................................42
      11.2. Informative References ...................................42
   Appendix A.  Migration Strategies .................................43
     A.1.  Migrating from DomainKeys .................................43
     A.2.  Migrating Hash Algorithms .................................48
     A.3.  Migrating Signing Algorithms ..............................49
   Appendix B.  General Coding Criteria for Cryptographic
                Applications .........................................50
1. Introduction
1. 介绍

DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. This document provides practical tips for those who are developing DKIM software, mailing list managers, filtering strategies based on the output from DKIM verification, and DNS servers; those who are deploying DKIM software, keys, mailing list software, and migrating from DomainKeys [RFC4870]; and those who are responsible for the ongoing operations of an email infrastructure that has deployed DKIM.

DomainKeys Identified Mail(DKIM)允许组织以可由收件人验证的方式声明传输消息的责任。本文档为开发DKIM软件、邮件列表管理器、基于DKIM验证输出的过滤策略以及DNS服务器的人员提供了实用技巧;部署DKIM软件、密钥、邮件列表软件以及从域密钥[RFC4870]迁移的人员;以及负责部署了DKIM的电子邮件基础设施的日常运营的人员。

The reader is encouraged to read the DKIM Service Overview document [RFC5585] before this document. More detailed guidance about DKIM and Author Domain Signing Practices (ADSP) can also be found in the protocol specifications [RFC4871], [RFC5617], and [RFC5672].


The document is organized around the key concepts related to DKIM. Within each section, additional considerations specific to development, deployment, or ongoing operations are highlighted where appropriate. The possibility of the use of DKIM results as input to a local reputation database is also discussed.


2. Using DKIM as Part of Trust Assessment
2. 使用DKIM作为信任评估的一部分
2.1. A Systems View of Email Trust Assessment
2.1. 电子邮件信任评估的系统视图

DKIM participates in a trust-oriented enhancement to the Internet's email service, to facilitate message handling decisions, such as for delivery and for content display. Trust-oriented message handling has substantial differences from the more established approaches that consider messages in terms of risk and abuse. With trust, there is a collaborative exchange between a willing participant along the sending path and a willing participant at a recipient site. In contrast, the risk model entails independent, unilateral action by the recipient site, in the face of a potentially unknown, hostile, and deceptive sender. This translates into a very basic technical difference: in the face of unilateral action by the recipient and even antagonistic efforts by the sender, risk-oriented mechanisms are based on heuristics, that is, on guessing. Guessing produces statistical results with some false negatives and some false positives. For trust-based exchanges, the goal is the deterministic exchange of information. For DKIM, that information is the one identifier that represents a stream of mail for which an independent assessment is sought (by the signer).


A trust-based service is built upon a validated Responsible Identifier that labels a stream of mail and is controlled by an identity (role, person, or organization). The identity is acknowledging some degree of responsibility for the message stream. Given a basis for believing that an identifier is being used in an authorized manner, the recipient site can make and use an assessment of the associated identity. An identity can use different identifiers, on the assumption that the different streams might produce different assessments. For example, even the best-run marketing campaigns will tend to produce some complaints that can affect the reputation of the associated identifier, whereas a stream of transactional messages is likely to have a more pristine reputation.


Determining that the identifier's use is valid is quite different from determining that the content of a message is valid. The former means only that the identifier for the responsible role, person, or organization has been legitimately associated with a message. The latter means that the content of the message can be believed and, typically, that the claimed author of the content is correct. DKIM validates only the presence of the identifier used to sign the message. Even when this identifier is validated, DKIM carries no implication that any of the message content, including the RFC5322.From field [RFC5322], is valid. Surprisingly, this limit to the semantics of a DKIM signature applies even when the validated signing identifier is the same domain name as is used in the RFC5322.From field! DKIM's only claim about message content is that the content cited in the DKIM-Signature: field's h= tag has been delivered without modification. That is, it asserts message content integrity -- between signing and verifying -- not message content validity.


As shown in Figure 1, this enhancement is a communication between a responsible role, person, or organization that signs the message and a recipient organization that assesses its trust in the signer. The recipient then makes handling decisions based on a collection of assessments, of which the DKIM mechanism is only a part. In this model, as shown in Figure 1, validation is an intermediary step, having the sole task of passing a validated Responsible Identifier to the Identity Assessor. The communication is of a single Responsible Identifier that the Responsible Identity wishes to have used by the Identity Assessor. The Identifier is the sole, formal input and output value of DKIM signing. The Identity Assessor uses this single, provided Identifier for consulting whatever assessment databases are deemed appropriate by the assessing entity. In turn, output from the Identity Assessor is fed into a Handling Filter


engine that considers a range of factors, along with this single output value. The range of factors can include ancillary information from the DKIM validation.


Identity Assessment covers a range of possible functions. It can be as simple as determining whether the identifier is a member of some list, such as authorized operators or participants in a group that might be of interest for recipient assessment. Equally, it can indicate a degree of trust (reputation) that is to be afforded the actor using that identifier. The extent to which the assessment affects the handling of the message is, of course, determined later, by the Handling Filter.


     +------+------+                            +------+------+
     |   Author    |                            |  Recipient  |
     +------+------+                            +------+------+
            |                                          ^
            |                                          |
            |                                   +------+------+
            |                                -->|  Handling   |<--
            |                                -->|   Filter    |<--
            |                                   +-------------+
            |                                          ^
            V                  Responsible             |
     +-------------+           Identifier       +------+------+
     | Responsible |. .       . . . . . . . . .>|  Identity   |
     |  Identity   |  .       .                 |  Assessor   |
     +------+------+  .       .                 +-------------+
            |         V       .                       ^ ^
            V         .       .                       | |
   +------------------.-------.--------------------+  | |
   | +------+------+  . . . > .   +-------------+  |  | |  +-----------+
   | | Identifier  |              | Identifier  +--|--+ +--+ Assessment|
   | |   Signer    +------------->| Validator   |  |       | Databases |
   | +-------------+              +-------------+  |       +-----------+
   |                 DKIM Service                  |
     +------+------+                            +------+------+
     |   Author    |                            |  Recipient  |
     +------+------+                            +------+------+
            |                                          ^
            |                                          |
            |                                   +------+------+
            |                                -->|  Handling   |<--
            |                                -->|   Filter    |<--
            |                                   +-------------+
            |                                          ^
            V                  Responsible             |
     +-------------+           Identifier       +------+------+
     | Responsible |. .       . . . . . . . . .>|  Identity   |
     |  Identity   |  .       .                 |  Assessor   |
     +------+------+  .       .                 +-------------+
            |         V       .                       ^ ^
            V         .       .                       | |
   +------------------.-------.--------------------+  | |
   | +------+------+  . . . > .   +-------------+  |  | |  +-----------+
   | | Identifier  |              | Identifier  +--|--+ +--+ Assessment|
   | |   Signer    +------------->| Validator   |  |       | Databases |
   | +-------------+              +-------------+  |       +-----------+
   |                 DKIM Service                  |

Figure 1: Actors in a Trust Sequence Using DKIM


2.2. Choosing a DKIM Tag for the Assessment Identifier
2.2. 为评估标识符选择DKIM标记

The signer of a message needs to be able to provide precise data and know what that data will mean upon delivery to the Assessor. If there is ambiguity in the choice that will be made on the recipient side, then the sender cannot know what basis for assessment will be used. DKIM has three values that specify identification information and it is easy to confuse their use, although only one defines the


formal input and output of DKIM, with the other two being used for internal protocol functioning and adjunct purposes, such as auditing and debugging.


The salient values include the s=, d= and i= parameters in the DKIM-Signature: header field. In order to achieve the end-to-end determinism needed for this collaborative exchange from the signer to the assessor, the core model needs to specify what the signer is required to provide to the assessor. The update to RFC 4871 [RFC5672] specifies:

显著值包括DKIM Signature:header字段中的s=、d=和i=参数。为了实现从签名者到评估者的这种协作交换所需的端到端的确定性,核心模型需要指定签名者需要向评估者提供什么。RFC 4871[RFC5672]的更新规定:

      DKIM's primary task is to communicate from the Signer to a
      recipient-side Identity Assessor a single Signing Domain
      Identifier (SDID) that refers to a responsible identity.  DKIM MAY
      optionally provide a single responsible Agent or User Identifier
      (AUID)...  A receive-side DKIM verifier MUST communicate the
      Signing Domain Identifier (d=) to a consuming Identity Assessor
      module and MAY communicate the User Agent Identifier (i=) if
      present....  To the extent that a receiver attempts to intuit any
      structured semantics for either of the identifiers, this is a
      heuristic function that is outside the scope of DKIM's
      specification and semantics.
      DKIM's primary task is to communicate from the Signer to a
      recipient-side Identity Assessor a single Signing Domain
      Identifier (SDID) that refers to a responsible identity.  DKIM MAY
      optionally provide a single responsible Agent or User Identifier
      (AUID)...  A receive-side DKIM verifier MUST communicate the
      Signing Domain Identifier (d=) to a consuming Identity Assessor
      module and MAY communicate the User Agent Identifier (i=) if
      present....  To the extent that a receiver attempts to intuit any
      structured semantics for either of the identifiers, this is a
      heuristic function that is outside the scope of DKIM's
      specification and semantics.

The single, mandatory value that DKIM supplies as its output is:


d= This specifies the "domain of the signing entity". It is a domain name and is combined with the selector to form a DNS query. A receive-side DKIM verifier needs to communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and can also communicate the User Agent Identifier (i=) if present.


The adjunct values are:


s= This tag specifies the selector. It is used to discriminate among different keys that can be used for the same d= domain name. As discussed in Section 4.3 of [RFC5585], "If verifiers were to employ the selector as part of an assessment mechanism, then there would be no remaining mechanism for making a transition from an old, or compromised, key to a new one". Consequently, the selector is not appropriate for use as part or all of the identifier used to make assessments.


i= This tag is optional and provides the "[t]he Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility" [RFC5672]. The identity can be in the syntax


of an entire email address or only a domain name. The domain name can be the same as for d= or it can be a sub-name of the d= name.


NOTE: Although the i= identity has the syntax of an email address, it is not required to have those semantics. That is, "the identity of the user" need not be the same as the user's mailbox. For example, the signer might wish to use i= to encode user-related audit information, such as how they were accessing the service at the time of message posting. Therefore, it is not possible to conclude anything from the i= string's (dis)similarity to email addresses elsewhere in the header.


So, i= can have any of these properties:


* Be a valid domain when it is the same as d=

* 如果与d相同,则为有效域=

* Appear to be a subdomain of d= but might not even exist

* 似乎是d=的子域,但可能不存在

* Look like a mailbox address but might have different semantics and therefore not function as a valid email address

* 看起来像邮箱地址,但可能具有不同的语义,因此不能用作有效的电子邮件地址

* Be unique for each message, such as indicating access details of the user for the specific posting

* 对于每条消息都必须是唯一的,例如指明特定帖子的用户访问详细信息

This underscores why the tag needs to be treated as being opaque, since it can represent any semantics, known only to the signer.


Hence, i= serves well as a token that is usable like a Web cookie, for return to the signing Administrative Management Domain (ADMD) -- such as for auditing and debugging. Of course in some scenarios the i= string might provide a useful adjunct value for additional (heuristic) processing by the Handling Filter.

因此,i=很好地充当了一个令牌,它可以像Web cookie一样使用,以返回到签名管理域(ADMD)——例如用于审核和调试。当然,在某些情况下,i=字符串可能会为处理过滤器的附加(启发式)处理提供有用的附加值。

2.3. Choosing the Signing Domain Name
2.3. 选择签名域名

A DKIM signing entity can serve different roles, such as being the author of content, the operator of the mail service, or the operator of a reputation service that also provides signing services on behalf of its customers. In these different roles, the basis for distinguishing among portions of email traffic can vary. For an entity creating DKIM signatures, it is likely that different portions of its mail will warrant different levels of trust. For example:


* Mail is sent for different purposes, such as marketing versus transactional, and recipients demonstrate different patterns of acceptance between these.

* 邮件发送的目的不同,比如营销和交易,收件人表现出不同的接受模式。

* For an operator of an email service, there often are distinct sub-populations of users warranting different levels of trust or privilege, such as paid versus free users, or users engaged in direct correspondence versus users sending bulk mail.

* 对于电子邮件服务的运营商来说,通常会有不同的子用户群,他们保证不同级别的信任或特权,例如付费用户与免费用户,或者直接通信用户与发送批量邮件的用户。

* Mail originating outside an operator's system, such as when it is redistributed by a mailing-list service run by the operator, will warrant a different reputation from mail submitted by users authenticated with the operator.

* 来自运营商系统之外的邮件,例如,当由运营商运行的邮件列表服务重新分发时,将保证与经运营商认证的用户提交的邮件不同的信誉。

It is therefore likely to be useful for a signer to use different d= subdomain names, for different message traffic streams, so that receivers can make differential assessments. However, too much differentiation -- that is, too fine a granularity of signing domains -- makes it difficult for the receiver to discern a sufficiently stable pattern of traffic for developing an accurate and reliable assessment. So the differentiation needs to achieve a balance. Generally, in a trust system, legitimate signers have an incentive to pick a small stable set of identities, so that recipients and others can attribute reputations to them. The set of these identities a receiver trusts is likely to be quite a bit smaller than the set it views as risky.


The challenge in using additional layers of subdomains is whether the extra granularity will be useful for the Assessor. In fact, excessive levels invite ambiguity: if the Assessor does not take advantage of the added granularity in the entire domain name that is provided, they might unilaterally decide to use only some rightmost part of the identifier. The signer cannot know what portion will be used. That ambiguity would move the use of DKIM back to the realm of heuristics, rather than the deterministic processing that is its goal.


Hence, the challenge is to determine a useful scheme for labeling different traffic streams. The most obvious choices are among different types of content and/or different types of authors. Although stability is essential, it is likely that the choices will change, over time, so the scheme needs to be flexible.


For those originating message content, the most likely choice of subdomain naming scheme will by based upon type of content, which can use content-oriented labels or service-oriented labels. For example:


where the choices are best dictated by whether they provide the Identity Assessor with the ability to discriminate usefully among streams of mail that demonstrate significantly different degrees of recipient acceptance or safety. Again, the danger in providing too fine a granularity is that related message streams that are labeled separately will not benefit from an aggregate reputation.


For those operating messaging services on behalf of a variety of customers, an obvious scheme to use has a different subdomain label for each customer. For example:


However, it can also be appropriate to label by the class of service or class of customer, such as:


Prior to using domain names for distinguishing among sources of data, IP Addresses have been the basis for distinction. Service operators typically have done this by dedicating specific outbound IP Addresses to specific mail streams -- typically to specific customers. For example, a university might want to distinguish mail from the administration, versus mail from the student dorms. In order to make the adoption of a DKIM-based service easier, it can be reasonable to translate the same partitioning of traffic, using domain names in place of the different IP Addresses.


2.4. Recipient-Based Assessments
2.4. 基于接受者的评估

DKIM gives the recipient site's Identity Assessor a verifiable identifier to use for analysis. Although the mechanism does not make claims that the signer is a Good Actor or a Bad Actor, it does make


it possible to know that use of the identifier is valid. This is in marked contrast with schemes that do not have authentication. Without verification, it is not possible to know whether the identifier -- whether taken from the RFC5322.From field, the RFC5321.MailFrom command, or the like -- is being used by an authorized agent. DKIM solves this problem. Hence, with DKIM, the Assessor can know that two messages with the same DKIM d= identifier are, in fact, signed by the same person or organization. This permits a far more stable and accurate assessment of mail traffic using that identifier.

可以知道标识符的使用是有效的。这与没有身份验证的方案形成鲜明对比。未经验证,无法知道授权代理是否正在使用该标识符(无论是从RFC5322.from字段、RFC5321.MailFrom命令等获取的)。DKIM解决了这个问题。因此,使用DKIM,评估员可以知道具有相同DKIM d=标识符的两条消息实际上是由同一个人或组织签署的。这允许使用该标识符对邮件流量进行更加稳定和准确的评估。

DKIM is distinctive, in that it provides an identifier that is not necessarily related to any other identifier in the message. Hence, the signer might be the author's ADMD, one of the operators along the transit path, or a reputation service being used by one of those handling services. In fact, a message can have multiple signatures, possibly by any number of these actors.


As discussed above, the choice of identifiers needs to be based on differences that the signer thinks will be useful for the recipient Assessor. Over time, industry practices establish norms for these choices.


Absent such norms, it is best for signers to distinguish among streams that have significant differences, while consuming the smallest number of identifiers possible. This will limit the burden on recipient Assessors.


A common view about a DKIM signature is that it carries a degree of assurance about some or all of the message contents, and in particular, that the RFC5322.From field is likely to be valid. In fact, DKIM makes assurances only about the integrity of the data and not about its validity. Still, presumptions of the RFC5322.From field validity remain a concern. Hence, a signer using a domain name that is unrelated to the domain name in the RFC5322.From field can reasonably expect that the disparity will warrant some curiosity, at least until signing by independent operators has produced some established practice among recipient Assessors.


With the identifier(s) supplied by DKIM, the Assessor can consult an independent assessment service about the entity associated with the identifier(s). Another possibility is that the Assessor can develop its own reputation rating for the identifier(s). That is, over time, the Assessor can observe the stream of messages associated with the identifier(s) developing a reaction to associated content. For example, if there is a high percentage of user complaints regarding


signed mail with a d= value of "", the Assessor might include that fact in the vector of data it provides to the Handling Filter. This is also discussed briefly in Section 5.4.


2.5. Filtering
2.5. 过滤

The assessment of the signing identifier is given to a Handling Filter that is defined by local policies, according to a potentially wide range of different factors and weightings. This section discusses some of the kinds of choices and weightings that are plausible and the differential actions that might be performed. Because authenticated domain names represent a collaborative sequence between signer and Assessor, actions can sometimes reasonably include contacting the signer.


The discussion focuses on variations in Organizational Trust versus Message Stream Risk, that is, the degree of positive assessment of a DKIM-signing organization, and the potential danger present in the message stream signed by that organization. While it might seem that higher trust automatically means lower risk, the experience with real-world operations provides examples of every combination of the two factors, as shown in Figure 2. For each axis, only three levels of granularity are listed, in order to keep discussion manageable. In real-world filtering engines, finer-grained distinctions are typically needed, and there typically are more axes. For example, there are different types of risk, so that an engine might distinguish between spam risk versus virus risk and take different actions based on which type of problematic content is present. For spam, the potential damage from a false negative is small, whereas the damage from a false positive is high. For a virus, the potential danger from a false negative is extremely high, while the likelihood of a false positive when using modern detection tools is extremely low. However, for the discussion here, "risk" is taken as a single construct.


The DKIM d= identifier is independent of any other identifier in a message and can be a subdomain of the name owned by the signer. This permits the use of fine-grained and stable distinctions between different types of message streams, such as between transactional messages and marketing messages from the same organization. Hence, the use of DKIM might permit a richer filtering model than has typically been possible for mail-receiving engines.

DKIM d=标识符独立于消息中的任何其他标识符,可以是签名者拥有的名称的子域。这允许在不同类型的消息流之间使用细粒度和稳定的区别,例如来自同一组织的事务消息和营销消息之间的区别。因此,与邮件接收引擎相比,DKIM的使用可能允许更丰富的过滤模型。

Note that the realities of today's public Internet Mail environment necessitate having a baseline handling model that is quite suspicious. Hence, "strong" filtering rules really are the starting point, as indicated for the UNKNOWN cell.


The table indicates differential handling for each combination, such as how aggressive or broad-based the filtering could be. Aggressiveness affects the types of incorrect assessments that are likely. So, the table distinguishes various characteristics, including: 1) whether an organization is unknown, known to be good actors, or known to be bad actors; and 2) the assessment of messages. It includes advice about the degree of filtering that might be done, and other message disposition. Perhaps unexpectedly, it also lists a case in which the receiving site might wish to deliver problematic mail, rather than redirecting or deleting it. The site might also wish to contact the signing organization and seek resolution of the problem.


      | S T R E A M *   O R G A N I Z A T I O N A L   T R U S T     |
      | R I S K     *     Low            Medium           High      |
      |             +***************+***************+***************+
      | Low         * BENIGN:       | DILIGENT:     | PRISTINE      |
      |             *    Moderate   |    Mild       |    Accept     |
      |             *    filter     |    filter     |               |
      |             +---------------+---------------+---------------+
      | Medium      * UNKNOWN:      | TYPICAL:      | PROTECTED:    |
      |             *    Strong     |    Targeted   |    Accept &   |
      |             *    filter     |    filter     |    Contact    |
      |             +---------------+---------------+---------------+
      | High        * MALICIOUS:    | NEGLIGENT:    | COMPROMISED:  |
      |             *    Block &    |    Block      |    Block &    |
      |             *    Counter    |               |    Contact    |
      | S T R E A M *   O R G A N I Z A T I O N A L   T R U S T     |
      | R I S K     *     Low            Medium           High      |
      |             +***************+***************+***************+
      | Low         * BENIGN:       | DILIGENT:     | PRISTINE      |
      |             *    Moderate   |    Mild       |    Accept     |
      |             *    filter     |    filter     |               |
      |             +---------------+---------------+---------------+
      | Medium      * UNKNOWN:      | TYPICAL:      | PROTECTED:    |
      |             *    Strong     |    Targeted   |    Accept &   |
      |             *    filter     |    filter     |    Contact    |
      |             +---------------+---------------+---------------+
      | High        * MALICIOUS:    | NEGLIGENT:    | COMPROMISED:  |
      |             *    Block &    |    Block      |    Block &    |
      |             *    Counter    |               |    Contact    |

Figure 2: Trust versus Risk Handling Tradeoffs Example






Stream Risk: This is a measure of the recent history of a message stream and the severity of problems it has presented.


Organizational Trust: This combines longer-term history about possible stream problems from that organization, and its responsiveness to problem handling.


CELLS (indicating reasonable responses)


Labels for the cells are meant as a general assessment of an organization producing that type of mail stream under that circumstance.


Benign: There is some history of sending good messages, with very few harmful messages having been received. This stream warrants filtering that does not search for problems very aggressively, in order to reduce the likelihood of false positives.


Diligent: The stream has had a limited degree of problems and the organization is consistently successful at controlling their abuse issues and in a timely manner.


Pristine: There is a history of a clean message stream with no problems, from an organization with an excellent reputation. So, the filter primarily needs to ensure that messages are delivered; catching stray problem messages is a lesser concern. In other words, the paramount concern, here, is false positives.



Unknown: There is no history with the organization. Apply an aggressive level of "naive" filtering, given the nature of the public email environment.


Typical: The stream suffers significant abuse issues and the organization has demonstrated a record of having difficulties resolving them in a timely manner, in spite of legitimate efforts. Unfortunately, this is the typical case for service providers with an easy and open subscription policy.


Protected: An organization with a good history and/or providing an important message stream for the receiving site is subject to a local policy that messages are not allowed to be blocked, but the stream is producing a problematic stream. The receiver delivers messages, but works quickly with the organization to resolve the matter.



Malicious: A persistently problematic message stream is coming from an organization that appears to contribute to the problem. The stream will be blocked, but the organization's role is sufficiently troubling to warrant following up with others in the anti-abuse or legal communities, to constrain or end their impact.


Negligent: A persistently problematic message stream is coming from an organization that does not appear to be contributing to the problem, but also does not appear to be working to eliminate it. At the least, the stream needs to be blocked.


Compromised: An organization with a good history has a stream that changes and becomes too problematic to be delivered. The receiver blocks the stream and works quickly with the organization to resolve the matter.


3. DKIM Key Generation, Storage, and Management
3. DKIM密钥生成、存储和管理

By itself, verification of a digital signature only allows the verifier to conclude with a very high degree of certainty that the signature was created by a party with access to the corresponding private signing key. It follows that a verifier requires means to (1) obtain the public key for the purpose of verification and (2) infer useful attributes of the key holder.


In a traditional Public Key Infrastructure (PKI), the functions of key distribution and key accreditation are separated. In DKIM [RFC4871], these functions are both performed through the DNS.


In either case, the ability to infer semantics from a digital signature depends on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In a traditional PKI, a Trusted Third Party (TTP) vouches that the key holder has been validated with respect to a specified set of attributes. The range of attributes that can be attested in such a scheme is thus limited only to the type of attributes that a TTP can establish effective processes for validating. In DKIM, TTPs are not employed and the functions of key distribution and accreditation are combined.


Consequently, there are only two types of inference that a signer can make from a key published in a DKIM key record:


1. That a party with the ability to control DNS records within a DNS zone intends to claim responsibility for messages signed using the corresponding private signature key.

1. 有能力控制DNS区域内DNS记录的一方打算声明对使用相应私有签名密钥签名的消息负责。

2. That use of a specific key is restricted to the particular subset of messages identified by the selector.

2. 特定键的使用仅限于选择器标识的消息的特定子集。

The ability to draw any useful conclusion from verification of a digital signature relies on the assumption that the corresponding private key is only accessible to a party with a particular set of


attributes. In the case of DKIM, this means that the party that created the corresponding DKIM key record in the specific zone intended to claim responsibility for the signed message.


Ideally, we would like to draw a stronger conclusion, that if we obtain a DKIM key record from the DNS zone, that the legitimate holder of the DNS zone claims responsibility for the signed message. In order for this conclusion to be drawn, it is necessary for the verifier to assume that the operational security of the DNS zone and corresponding private key are adequate.

理想情况下,我们希望得出一个更有力的结论,即如果我们从DNS zone example.com获得DKIM密钥记录,则DNS zone example.com的合法持有人声称对签名消息负责。为了得出这一结论,验证者必须假设DNS区域的操作安全性和相应的私钥是足够的。

3.1. Private Key Management: Deployment and Ongoing Operations
3.1. 私钥管理:部署和正在进行的操作

Access to signing keys needs to be carefully managed to prevent use by unauthorized parties and to minimize the consequences if a compromise were to occur.


While a DKIM signing key is used to sign messages on behalf of many mail users, the signing key itself needs to be under direct control of as few key holders as possible. If a key holder were to leave the organization, all signing keys held by that key holder need to be withdrawn from service and, if appropriate, replaced.


If key management hardware support is available, it needs to be used. If keys are stored in software, appropriate file control protections need to be employed, and any location in which the private key is stored in plaintext form needs to be excluded from regular backup processes and is best not accessible through any form of network including private local area networks. Auditing software needs to be used periodically to verify that the permissions on the private key files remain secure.


Wherever possible, a signature key needs to exist in exactly one location and be erased when no longer used. Ideally, a signature key pair needs to be generated as close to the signing point as possible, and only the public key component transferred to another party. If this is not possible, the private key needs to be transported in an encrypted format that protects the confidentiality of the signing key. A shared directory on a local file system does not provide adequate security for distribution of signing keys in plaintext form.


Key escrow schemes are not necessary and are best not used. In the unlikely event of a signing key becoming lost, a new signature key pair can be generated as easily as recovery from a key escrow scheme.


To enable accountability and auditing:


o Responsibility for the security of a signing key needs to ultimately vest in a single named individual.

o 签名密钥的安全责任最终需要归属于一个指定的个人。

o Where multiple parties are authorized to sign messages, each signer needs to use a different key to enable accountability and auditing.

o 如果授权多方对消息进行签名,则每个签名者需要使用不同的密钥来启用责任和审核。

Best practices for management of cryptographic keying material require keying material to be refreshed at regular intervals, particularly where key management is achieved through software. While this practice is highly desirable, it is of considerably less importance than the requirement to maintain the secrecy of the corresponding private key. An operational practice in which the private key is stored in tamper-proof hardware and changed once a year is considerably more desirable than one in which the signature key is changed on an hourly basis but maintained in software.


3.2. Storing Public Keys: DNS Server Software Considerations
3.2. 存储公钥:DNS服务器软件注意事项

In order to use DKIM, a DNS domain holder requires (1) the ability to create the necessary DKIM DNS records and (2) sufficient operational security controls to prevent insertion of spurious DNS records by an attacker.

为了使用DKIM,DNS域持有者需要(1)能够创建必要的DKIM DNS记录,以及(2)足够的操作安全控制,以防止攻击者插入虚假DNS记录。

DNS record management is often operated by an administrative staff that is different from those who operate an organization's email service. In order to ensure that DKIM DNS records are accurate, this imposes a requirement for careful coordination between the two operations groups. If the best practices for private key management described above are observed, such deployment is not a one-time event; DNS DKIM selectors will be changed over time as signing keys are terminated and replaced.

DNS记录管理通常由不同于运营组织电子邮件服务的管理人员进行。为了确保DKIM DNS记录准确,这就要求两个操作组之间进行仔细协调。如果遵守上述私钥管理的最佳实践,则此类部署不是一次性事件;随着签名密钥的终止和替换,DNS DKIM选择器将随着时间的推移而更改。

At a minimum, a DNS server that handles queries for DKIM key records needs to allow the server administrators to add free-form TXT records. It would be better if the DKIM records could be entered using a structured form, supporting the DKIM-specific fields.


Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the case that NextSECure version 3 (NSEC3) [RFC5155] records are employed to prevent insertion attack, the OPT-OUT flag needs to be clear. (See [RFC5155] section 6 for details.)


3.2.1. Assignment of Selectors
3.2.1. 选择器的分配

Selectors are assigned according to the administrative needs of the signing domain, such as for rolling over to a new key or for the delegation of the right to authenticate a portion of the namespace to a TTP. Examples include:




It is intended that assessments of DKIM identities be based on the domain name, and not include the selector. While past practice of a signer can permit a verifier to infer additional properties of particular messages from the structure DKIM key selector, unannounced administrative changes such as a change of signing software can cause such heuristics to fail at any time.


3.3. Per-User Signing Key Management Issues
3.3. 每用户签名密钥管理问题

While a signer can establish business rules, such as the issue of individual signature keys for each end-user, DKIM makes no provision for communicating these to other parties. Out-of-band distribution of such business rules is outside the scope of DKIM. Consequently, there is no means by which external parties can make use of such keys to attribute messages with any greater granularity than a DNS domain.


If per-user signing keys are assigned for internal purposes (e.g., authenticating messages sent to an MTA (Mail Transfer Agent) for distribution), the following issues need to be considered before using such signatures as an alternative to traditional edge signing at the outbound MTA:


External verifiers will be unable to make use of the additional signature granularity without access to additional information passed out of band with respect to [RFC4871].


If the number of user keys is large, the efficiency of local caching of key records by verifiers will be lower.


A large number of end users is be less likely to do an adequate job of managing private key data securely on their personal computers than is an administrator running an edge MTA.

与运行edge MTA的管理员相比,大量最终用户不太可能在其个人计算机上安全地管理私钥数据。

3.4. Third-Party Signer Key Management and Selector Administration
3.4. 第三方签名者密钥管理和选择器管理

A DKIM key record only asserts that the holder of the corresponding domain name makes a claim of responsibility for messages signed under the corresponding key. In some applications, such as bulk mail delivery, it is desirable to delegate use of the key. That is, to allow a third party to sign on behalf of the domain holder. The trust relationship is still established between the domain holder and the verifier, but the private signature key is held by a third party.


Signature keys used by a third-party signer need to be kept entirely separate from those used by the domain holder and other third-party signers. To limit potential exposure of the private key, the signature key pair needs to be generated by the third-party signer and the public component of the key transmitted to the domain holder, rather than have the domain holder generate the key pair and transmit the private component to the third-party signer.


Domain holders needs to adopt a least-privilege approach and grant third-party signers the minimum access necessary to perform the desired function. Limiting the access granted to third-party signers serves to protect the interests of both parties. The domain holder minimizes its security risk and the TTP signer avoids unnecessary liability.


In the most restrictive case, domain holders maintain full control over the creation of key records. They can employ appropriate key record restrictions to enforce limits on the messages for which the third-party signer is able to sign. If such restrictions are impractical, the domain holder needs to delegate a DNS subzone for publishing key records to the third-party signer. It is best that the domain holder NOT allow a third-party signer unrestricted access to its DNS service for the purpose of publishing key records.


3.5. Key Pair / Selector Life Cycle Management
3.5. 密钥对/选择器生命周期管理

Deployments need to establish, document, and observe processes for managing the entire life cycle of an asymmetric key pair.


3.5.1. Example Key Deployment Process
3.5.1. 示例密钥部署过程

When it is determined that a new key pair is required:


1. A Key Pair is generated by the signing device.

1. 签名设备生成密钥对。

2. A proposed key selector record is generated and transmitted to the DNS administration infrastructure.

2. 生成建议的密钥选择器记录并将其传输到DNS管理基础设施。

3. The DNS administration infrastructure verifies the authenticity of the key selector registration request. If accepted:

3. DNS管理基础结构验证密钥选择器注册请求的真实性。如果接受:

1. A key selector is assigned.

1. 将指定一个键选择器。

2. The corresponding key record is published in the DNS.

2. 相应的密钥记录在DNS中发布。

3. Wait for DNS updates to propagate (if necessary).

3. 等待DNS更新传播(如有必要)。

4. Report assigned key selector to signing device.

4. 将分配的密钥选择器报告给签名设备。

4. The signer verifies correct registration of the key record.

4. 签名者验证密钥记录的正确注册。

5. The signer begins generating signatures using the new key pair.

5. 签名者开始使用新密钥对生成签名。

6. The signer terminates any private keys that are no longer required due to issue of replacement.

6. 签名者终止由于替换问题而不再需要的任何私钥。

3.5.2. Example Key Termination Process
3.5.2. 密钥终止过程示例

When it is determined that a private signature key is no longer required:


1. The signer stops using the private key for signature operations.

1. 签名者停止使用私钥进行签名操作。

2. The signer deletes all records of the private key, including in-memory copies at the signing device.

2. 签名者删除私钥的所有记录,包括签名设备上的内存副本。

3. The signer notifies the DNS administration infrastructure that the signing key is withdrawn from service and that the corresponding key records can be withdrawn from service at a specified future date.

3. 签名者通知DNS管理基础结构签名密钥已从服务中撤回,并且相应的密钥记录可在指定的未来日期从服务中撤回。

4. The DNS administration infrastructure verifies the authenticity of the key selector termination request. If accepted,

4. DNS管理基础结构验证密钥选择器终止请求的真实性。如果接受,

1. The key selector is scheduled for deletion at a future time determined by site policy.

1. 密钥选择器计划在站点策略确定的未来时间删除。

2. Wait for deletion time to arrive.

2. 等待删除时间到达。

3. The signer either publishes a revocation key selector with an empty public-key data (p=) field, or deletes the key selector record entirely.

3. 签名者发布带有空公钥数据(p=)字段的吊销密钥选择器,或者完全删除密钥选择器记录。

5. As far as the verifier is concerned, there is no functional difference between verifying against a key selector with an empty p= field, and verifying against a missing key selector: both

5. 就验证器而言,针对具有空p=字段的键选择器进行验证与针对缺少的键选择器进行验证之间没有功能上的区别:两者都有

result in a failed signature and the signature needs to be treated as if it had not been there. However, there is a minor semantic difference: with the empty p= field, the signer is explicitly stating that the key has been revoked. The empty p= record provides a gravestone for an old selector, making it less likely that the selector might be accidentally reused with a different public key.


4. Signing
4. 签字

Creating messages that have one or more DKIM signatures requires support in only two outbound email service components:


o A DNS Administrative interface that can create and maintain the relevant DNS names -- including names with underscores -- and resource records (RR).

o 可以创建和维护相关DNS名称(包括带下划线的名称)和资源记录(RR)的DNS管理接口。

o A trusted module, called the signing module, which is within the organization's outbound email handling service and which creates and adds the DKIM-Signature: header field(s) to the message.

o 一个受信任的模块,称为签名模块,位于组织的出站电子邮件处理服务中,创建DKIM签名:头字段并将其添加到邮件中。

If the module creates more than one signature, there needs to be the appropriate means of telling it which one(s) to use. If a large number of names are used for signing, it will help to have the administrative tool support a batch-processing mode.


4.1. DNS Records
4.1. DNS记录

A receiver attempting to verify a DKIM signature obtains the public key that is associated with the signature for that message. The DKIM-Signature: header in the message contains the d= tag with the basic domain name doing the signing and serving as output to the Identity Assessor and the s= tag with the selector that is added to the name, for finding the specific public key. Hence, the relevant <selector>._domainkey.<domain-name> DNS record needs to contain a DKIM-related RR that provides the public key information.

试图验证DKIM签名的接收方获得与该消息的签名相关联的公钥。消息中的DKIM Signature:header包含进行签名并作为身份评估器输出的基本域名的d=标记和添加到名称中的选择器的s=标记,用于查找特定公钥。因此,相关的<selector>\u domainkey.<domain name>DNS记录需要包含提供公钥信息的DKIM相关RR。

The administrator of the zone containing the relevant domain name adds this information. Initial DKIM DNS information is contained within TXT RRs. DNS administrative software varies considerably in its abilities to support DKIM names, such as with underscores, and to add new types of DNS information.

包含相关域名的区域的管理员将添加此信息。初始DKIM DNS信息包含在TXT RRs中。DNS管理软件在支持DKIM名称(如带下划线)和添加新类型DNS信息的能力方面差异很大。

4.2. Signing Module
4.2. 签名模块

The module doing signing can be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); obvious choices include department-level posting agents, as well as


outbound boundary MTAs to the open Internet. However, any other module, including the author's MUA (Mail User Agent), is potentially acceptable, as long as the signature survives any remaining handling within the ADMD. Hence, the choice among the modules depends upon software development, administrative overhead, security exposures, and transit-handling tradeoffs. One perspective that helps to resolve this choice is the difference between the increased flexibility, from placement at (or close to) the MUA, versus the streamlined administration and operation that is more easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure, such as at its boundary MTA.


Note the discussion in Section 2.2 concerning the use of the i= tag.


The signing module uses the appropriate private key to create one or more signatures. (See Section 6.5 for a discussion of multiple signatures.) The means by which the signing module obtains the private key(s) is not specified by DKIM. Given that DKIM is intended for use during email transit, rather than for long-term storage, it is expected that keys will be changed regularly. For administrative convenience, it is best not to hard-code key information into software.


4.3. Signing Policies and Practices
4.3. 签署政策和做法

Every organization (ADMD) will have its own policies and practices for deciding when to sign messages (message stream) and with what domain name, selector, and key. Examples of particular message streams include all mail sent from the ADMD versus mail from particular types of user accounts versus mail having particular types of content. Given this variability, and the likelihood that signing practices will change over time, it will be useful to have these decisions represented through run-time configuration information, rather than being hard-coded into the signing software.


As noted in Section 2.3, the choice of signing name granularity requires balancing administrative convenience and utility for recipients. Too much granularity is higher administrative overhead and might well attempt to impose more differential analysis on the recipient than they wish to support. In such cases, they are likely to use only a super-name -- right-hand substring -- of the signing name. When this occurs, the signer will not know what portion is being used; this then moves DKIM back to the non-deterministic world of heuristics, rather than the mechanistic world of signer/recipient collaboration that DKIM seeks.


5. Verifying
5. 验证

A message recipient can verify a DKIM signature to determine if a claim of responsibility has been made for the message by a trusted domain.


Access control requires two components: authentication and authorization. By design, verification of a DKIM signature only provides the authentication component of an access control decision and needs to be combined with additional sources of information such as reputation data to arrive at an access control decision.


5.1. Intended Scope of Use
5.1. 预期使用范围

DKIM requires that a message with a signature that is found to be invalid is to be treated as if the message had not been signed at all.


If a DKIM signature fails to verify, it is entirely possible that the message is valid and that either there is a configuration error in the signer's system (e.g., a missing key record) or that the message was inadvertently modified in transit. It is thus undesirable for mail infrastructure to treat messages with invalid signatures less favorably than those with no signatures whatsoever. Contrariwise, creation of an invalid signature requires a trivial amount of effort on the part of an attacker. If messages with invalid signatures were to be treated preferentially to messages with no signatures whatsoever, attackers will simply add invalid signature blocks to gain the preferential treatment. It follows that messages with invalid signatures need to be treated no better and no worse than those with no signature at all.


5.2. Signature Scope
5.2. 签名范围

As with any other digital signature scheme, verifiers need to consider only the part of the message that is inside the scope of the message as being authenticated by the signature.


For example, if the l= option is employed to specify a content length for the scope of the signature, only the part of the message that is within the scope of the content signature would be considered authentic.


5.3. Design Scope of Use
5.3. 设计使用范围

Public key cryptography provides an exceptionally high degree of assurance, bordering on absolute certainty, that the party that created a valid digital signature had access to the private key corresponding to the public key indicated in the signature.


In order to make useful conclusions from the verification of a valid digital signature, the verifier is obliged to make assumptions that fall far short of absolute certainty. Consequently, mere validation of a DKIM signature does not represent proof positive that a valid claim of responsibility was made for it by the indicated party, that the message is authentic, or that the message is not abusive. In particular:


o The legitimate private key holder might have lost control of its private key.

o 合法私钥持有人可能已失去对其私钥的控制。

o The legitimate domain holder might have lost control of the DNS server for the zone from which the key record was retrieved.

o 合法域持有者可能已失去对从中检索密钥记录的区域的DNS服务器的控制。

o The key record might not have been delivered from the legitimate DNS server for the zone from which the key record was retrieved.

o 对于从中检索密钥记录的区域,密钥记录可能未从合法DNS服务器传递。

o Ownership of the DNS zone might have changed.

o DNS区域的所有权可能已更改。

In practice, these limitations have little or no impact on the field of use for which DKIM is designed, but they can have a bearing if use is made of the DKIM message signature format or key retrieval mechanism in other specifications.


In particular, the DKIM key retrieval mechanism is designed for ease of use and deployment rather than to provide a high assurance Public Key Infrastructure suitable for purposes that require robust non-repudiation such as establishing legally binding contracts. Developers seeking to extend DKIM beyond its design application need to consider replacing or supplementing the DNS key retrieval mechanism with one that is designed to meet the intended purposes.


5.4. Inbound Mail Filtering
5.4. 入站邮件过滤

DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources. Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message.


Mail sources can be determined to be trusted by means of previously observed behavior and/or reference to external reputation or accreditation services. The precise means by which this is accomplished is outside the scope of DKIM.


5.4.1. Non-Verifying Adaptive Spam Filtering Systems
5.4.1. 非验证自适应垃圾邮件过滤系统

Adaptive (or learning) spam filtering mechanisms that are not capable of verifying DKIM signatures need to, at minimum, be configured to ignore DKIM header data entirely.


5.5. Messages Sent through Mailing Lists and Other Intermediaries
5.5. 通过邮件列表和其他中介发送的邮件

Intermediaries, such as mailing lists, pose a particular challenge for DKIM implementations, as the message processing steps performed by the intermediary can cause the message content to change in ways that prevent the signature passing verification.


Such intermediaries are strongly encouraged to deploy DKIM signing so that a verifiable claim of responsibility remains available to parties attempting to verify the modified message.


5.6. Generation, Transmission, and Use of Results Headers
5.6. 结果标题的生成、传输和使用

In many deployments, it is desirable to separate signature verification from the application relying on the verification. A system can choose to relay information indicating the results of its message authentication efforts using various means; adding a "results header" to the message is one such mechanism [RFC5451]. For example, consider the cases where:


o The application relying on DKIM signature verification is not capable of performing the verification.

o 依赖DKIM签名验证的应用程序无法执行验证。

o The message can be modified after the signature verification is performed.

o 执行签名验证后,可以修改消息。

o The signature key cannot be available by the time that the message is read.

o 在读取邮件时,签名密钥无法使用。

In such cases, it is important that the communication link between the signature verifier and the relying application be sufficiently secure to prevent insertion of a message that carries a bogus results header.


An intermediary that generates results headers need to ensure that relying applications are able to distinguish valid results headers issued by the intermediary from those introduced by an attacker. For


example, this can be accomplished by signing the results header. At a minimum, results headers on incoming messages need to be removed if they purport to have been issued by the intermediary but cannot be verified as authentic.


Further discussion on trusting the results as relayed from a verifier to something downstream can be found in [RFC5451].


6. Taxonomy of Signatures
6. 签名分类

As described in Section 2.1, a DKIM signature tells the signature verifier that the owner of a particular domain name accepts some responsibility for the message. It does not, in and of itself, provide any information about the trustworthiness or behavior of that identity. What it does provide is a verified identity to which such behavioral information can be associated, so that those who collect and use such information can be assured that it truly pertains to the identity in question.


This section lays out a taxonomy of some of the different identities, or combinations of identities, that might usefully be represented by a DKIM signature.


6.1. Single Domain Signature
6.1. 单域签名

Perhaps the simplest case is when an organization signs its own outbound email using its own domain in the SDID [RFC5672] of the signature. For example, Company A would sign the outbound mail from its employees with d=companyA.example.


In the most straightforward configuration, the addresses in the RFC5322.From field would also be in the companyA.example domain, but that direct correlation is not required.


A special case of the single domain signature is an author signature as defined by the Author Domain Signing Practices specification [RFC5617]. Author signatures are signatures from an author's organization that have an SDID value that matches that of an RFC5322.From address of the signed message.


Although an author signature might, in some cases, be proof against spoofing the domain name of the RFC5322.From address, it is important to note that the DKIM and ADSP validation apply only to the exact address string and not to look-alike addresses or to the human-friendly "display-name" or names and addresses used within the body of the message. That is, it only protects against the misuse of a precise address string within the RFC5322.From field and nothing else. For example, a message from bob@domain.example with a valid


signature where d=d0main.example would fail an ADSP check because the signature domain, however similar, is distinct; however, a message from bob@d0main.example with a valid signature where d=d0main.example would pass an ADSP check, even though to a human it might be obvious that d0main.example is likely a malicious attempt to spoof the domain domain.example. This example highlights that ADSP, like DKIM, is only able to validate a signing identifier: it still requires some external process to attach a meaningful reputation to that identifier.


6.2. Parent Domain Signature
6.2. 父域签名

Another approach that might be taken by an organization with multiple active subdomains is to apply the same (single) signature domain to mail from all subdomains. In this case, the signature chosen would usually be the signature of a parent domain common to all subdomains. For example, mail from marketing.domain.example, sales.domain.example, and engineering.domain.example might all use a signature where d=domain.example.


This approach has the virtue of simplicity, but it is important to consider the implications of such a choice. As discussed in Section 2.3, if the type of mail sent from the different subdomains is significantly different or if there is reason to believe that the reputation of the subdomains would differ, then it can be a good idea to acknowledge this and provide distinct signatures for each of the subdomains (d=marketing.domain.example, sales.domain.example, etc.). However, if the mail and reputations are likely to be similar, then the simpler approach of using a single common parent domain in the signature can work well.


Another approach to distinguishing the streams using a single DKIM key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM signature to differentiate the mail streams. For example, marketing email would be signed with i=@marketing.domain.example and d=domain.example.


It's important to remember, however, that under core DKIM semantics, the AUID is opaque to receivers. That means that it will only be an effective differentiator if there is an out-of-band agreement about the i= semantics.


6.3. Third-Party Signature
6.3. 第三方签字

A signature whose domain does not match the domain of the RFC5322.From address is sometimes referred to as a third-party signature. In certain cases, even the parent domain signature


described above would be considered a third-party signature because it would not be an exact match for the domain in the RFC5322.From address.


Although there is often heated debate about the value of third party signatures, it is important to note that the DKIM specification attaches no particular significance to the identity in a DKIM signature ([RFC4871], [RFC5672]). The identity specified within the signature is the identity that is taking responsibility for the message, and it is only the interpretation of a given receiver that gives one identity more or less significance than another. In particular, most independent reputation services assign trust based on the specific identifier string, not its "role": in general they make no distinction between, for example, an author signature and a third-party signature.


For some, a signature unrelated to the author domain (the domain in the RFC5322.From address) is less valuable because there is an assumption that the presence of an author signature guarantees that the use of the address in the RFC5322.From header is authorized.


For others, that relevance is tied strictly to the recorded behavioral data assigned to the identity in question, i.e., its trust assessment or reputation. The reasoning here is that an identity with a good reputation is unlikely to maintain that good reputation if it is in the habit of vouching for messages that are unwanted or abusive; in fact, doing so will rapidly degrade its reputation so that future messages will no longer benefit from it. It is therefore low risk to facilitate the delivery of messages that contain a valid signature of a domain with a strong positive reputation, independent of whether or not that domain is associated with the address in the RFC5322.From header field of the message.


Third-party signatures encompass a wide range of identities. Some of the more common are:


Service Provider: In cases where email is outsourced to an Email Service Provider (ESP), Internet Service Provider (ISP), or other type of service provider, that service provider can choose to DKIM-sign outbound mail with either its own identifier -- relying on its own, aggregate reputation -- or with a subdomain of the provider that is unique to the message author but still part of the provider's aggregate reputation. Such service providers can also encompass delegated business functions such as benefit management, although these will more often be treated as trusted third-party senders (see below).


Parent Domain: As discussed above, organizations choosing to apply a parent-domain signature to mail originating from subdomains can have their signatures treated as third party by some verifiers, depending on whether or not the "t=s" tag is used to constrain the parent signature to apply only to its own specific domain. The default is to consider a parent-domain signature valid for its subdomains.


Reputation Provider: Another possible category of third-party signature would be the identity of a third-party reputation provider. Such a signature would indicate to receivers that the message was being vouched for by that third party.


6.4. Using Trusted Third-Party Senders
6.4. 使用受信任的第三方发件人

For most of the cases described so far, there has been an assumption that the signing agent was responsible for creating and maintaining its own DKIM signing infrastructure, including its own keys, and signing with its own identity.


A different model arises when an organization uses a trusted third-party sender for certain key business functions, but still wants that email to benefit from the organization's own identity and reputation. In other words, the mail would come out of the trusted third party's mail servers, but the signature applied would be that of the controlling organization.


This can be done by having the third party generate a key pair that is designated uniquely for use by that trusted third party and publishing the public key in the controlling organization's DNS domain, thus enabling the third party to sign mail using the signature of the controlling organization. For example, if Company A outsources its employee benefits to a third party, it can use a special key pair that enables the benefits company to sign mail as "companyA.example". Because the key pair is unique to that trusted third party, it is easy for Company A to revoke the authorization if necessary by simply removing the public key from the companyA.example DNS.

这可以通过让第三方生成唯一指定供该可信第三方使用的密钥对,并在控制组织的DNS域中发布公钥来实现,从而使第三方能够使用控制组织的签名对邮件进行签名。例如,如果A公司将其员工福利外包给第三方,它可以使用一个特殊的密钥对,使福利公司能够将邮件签名为“companyA.example”。由于密钥对是受信任的第三方所独有的,因此公司A很容易在必要时通过从companyA.example DNS中删除公钥来撤销授权。

A more cautious approach would be to create a dedicated subdomain (e.g., benefits.companyA.example) to segment the outsourced mail stream, and to publish the public key there; the signature would then use d=benefits.companyA.example.


6.4.1. DNS Delegation
6.4.1. DNS授权

Another possibility for configuring trusted third-party access, as discussed in Section 3.4, is to have Company A use DNS delegation and have the designated subdomain managed directly by the trusted third party. In this case, Company A would create a subdomain benefits.companya.example, and delegate the DNS management of that subdomain to the benefits company so it could maintain its own key records. When revocation becomes necessary, Company A could simply remove the DNS delegation record.


6.5. Multiple Signatures
6.5. 多重签名

A simple configuration for DKIM-signed mail is to have a single signature on a given message. This works well for domains that manage and send all of their own email from single sources, or for cases where multiple email streams exist but each has its own unique key pair. It also represents the case in which only one of the participants in an email sequence is able to sign, no matter whether it represents the author or one of the operators.


The examples thus far have considered the implications of using different identities in DKIM signatures, but have used only one such identity for any given message. In some cases, it can make sense to have more than one identity claiming responsibility for the same message.


There are a number of situations where applying more than one DKIM signature to the same message might make sense. A few examples are:


Companies with multiple subdomain identities: A company that has multiple subdomains sending distinct categories of mail might choose to sign with distinct subdomain identities to enable each subdomain to manage its own identity. However, it might also want to provide a common identity that cuts across all of the distinct subdomains. For example, Company A can sign mail for its sales department with a signature where d=sales.companya.example and a second signature where d=companya.example


Service Providers: A service provider can, as described above, choose to sign outbound messages with either its own identity or an identity unique to each of its clients (possibly delegated). However, it can also do both: sign each outbound message with its own identity as well as with the identity of each individual client. For example, ESP A might sign mail for its client Company B with its service provider signature d=espa.example, and a second client-specific signature where d= either companyb.example or companyb.espa.example. The existence of the service provider

服务提供者:如上所述,服务提供者可以选择使用自己的身份或每个客户端(可能是委托的)唯一的身份对出站消息进行签名。但是,它也可以同时完成这两项工作:使用自己的身份以及每个客户端的身份对每个出站消息进行签名。例如,ESP A可以使用其服务提供商签名d=espa.example为其客户公司B的邮件签名,以及第二个特定于客户的签名,其中d=companyb.example或companyb.espa.example。服务提供者的存在

signature could, for example, help cover a new client while it establishes its own reputation, or help a very small volume client who might never reach a volume threshold sufficient to establish an individual reputation.


Forwarders: Forwarded mail poses a number of challenges to email authentication. DKIM is relatively robust in the presence of forwarders as long as the signature is designed to avoid message parts that are likely to be modified; however, some forwarders do make modifications that can invalidate a DKIM signature.


Some forwarders such as mailing lists or "forward article to a friend" services might choose to add their own signatures to outbound messages to vouch for them having legitimately originated from the designated service. In this case, the signature would be added even in the presence of a preexisting signature, and both signatures would be relevant to the verifier.


Any forwarder that modifies messages in ways that will break preexisting DKIM signatures needs to sign its forwarded messages.


Reputation Providers: Although third-party reputation providers today use a variety of protocols to communicate their information to receivers, it is possible that they, or other organizations willing to put their "seal of approval" on an email stream, might choose to use a DKIM signature to do it. In nearly all cases, this "reputation" signature would be in addition to the author or originator signature.


One important caveat to the use of multiple signatures is that there is currently no clear consensus among receivers on how they plan to handle them. The opinions range from ignoring all but one signature (and the specification of which of them is verified differs from receiver to receiver), to verifying all signatures present and applying a weighted blend of the trust assessments for those identifiers, to verifying all signatures present and simply using the identifier that represents the most positive trust assessment. It is likely that the industry will evolve to accept multiple signatures using either the second or third of these, but it can take some time before one approach becomes pervasive.


7. Example Usage Scenarios
7. 示例使用场景

Signatures are created by different types of email actors, based on different criteria, such as where the actor operates in the sequence from author to recipient, whether they want different messages to be evaluated under the same reputation or a different one, and so on.


This section provides some examples of usage scenarios for DKIM deployments; the selection is not intended to be exhaustive but to illustrate a set of key deployment considerations.


7.1. Author's Organization - Simple
7.1. 作者组织-简单

The simplest DKIM configuration is to have some mail from a given organization (Company A) be signed with the same d= value (e.g., d=companya.example). If there is a desire to associate additional information, the AUID [RFC5672] value can become uniqueID@companya.example, or @uniqueID.companya.example.


In this scenario, Company A need only generate a single signing key and publish it under their top-level domain (companya.example); the signing module would then tailor the AUID value as needed at signing time.


7.2. Author's Organization - Differentiated Types of Mail
7.2. 作者组织-不同类型的邮件

A slight variation of the one signature case is where Company A signs some of its mail, but it wants to differentiate among categories of its outbound mail by using different identifiers. For example, it might choose to distinguish marketing, billing or transactional, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, respectively, where each category is assigned a unique subdomain and unique signing keys.


7.3. Author Domain Signing Practices
7.3. 作者域签名实践
7.3.1. Introduction
7.3.1. 介绍

Some domains might decide to sign all of their outgoing mail. If all of the legitimate mail for a domain is signed, recipients can be more aggressive in their filtering of mail that uses the domain but does not have a valid signature from the domain; in such a configuration, the absence of a signature would be more significant than for the general case. It might be desirable for such domains to be able to advertise their intent to other receivers: this is the topic of Author Domain Signing Practices (ADSP).


Note that ADSP is not for everyone. Sending domains that do not control all legitimate outbound mail purporting to be from their domain (i.e., with an RFC5322.From address in their domain) are likely to experience delivery problems with some percentage of that mail. Administrators evaluating ADSP for their domains needs to carefully weigh the risk of phishing attacks against the likelihood of undelivered mail.


This section covers some examples of ADSP usage. For the complete specification, see [RFC5617].


7.3.2. A Few Definitions
7.3.2. 一些定义

In the ADSP specification, an address in the RFC5322.From header field of a message is defined as an "Author Address", and an "Author Domain" is defined as anything to the right of the '@' in an author address.


An "Author Signature" is thus any valid signature where the value of the SDID matches an author domain in the message.


It is important to note that unlike the DKIM specification, which makes no correlation between the signature domain and any message headers, the ADSP specification applies only to the author domain. In essence, under ADSP, any non-author signatures are ignored (treated as if they are not present).


Signers wishing to publish an Author Domain Signing Practices (ADSP) [RFC5617] record describing their signing practices will thus want to include an author signature on their outbound mail to avoid ADSP verification failures.


7.3.3. Some ADSP Examples
7.3.3. 一些ADSP示例

An organization (Company A) can specify its signing practices by publishing an ADSP record with "dkim=all" or "dkim=discardable". In order to avoid misdelivery of its mail at receivers that are validating ADSP, Company A needs to first have done an exhaustive analysis to determine all sources of outbound mail from its domain (companyA.example) and ensure that they all have valid author signatures from that domain.


For example, email with an RFC5322.From address of bob@ companyA.example needs to have an author signature where the SDID value is "companyA.example" or it will fail an ADSP validation.


Note that once an organization publishes an ADSP record using dkim=all or dkim=discardable, any email with an RFC5322.From address that uses the domain where the ADSP record is published that does not have a valid author signature is at risk of being misdelivered or discarded. For example, if a message with an RFC5322.From address of newsletter@companyA.example has a signature with d=marketing.companyA.example, that message will fail the ADSP check because the signature would not be considered a valid author signature.


Because the semantics of an ADSP author signature are more constrained than the semantics of a "pure" DKIM signature, it is important to make sure the nuances are well understood before deploying an ADSP record. The ADSP specification [RFC5617] provides some fairly extensive lookup examples (in Appendix A) and usage examples (in Appendix B).


In particular, in order to prevent mail from being negatively impacted or even discarded at the receiver, it is essential to perform a thorough survey of outbound mail from a domain before publishing an ADSP policy of anything stronger than "unknown". This includes mail that might be sent from external sources that might not be authorized to use the domain signature, as well as mail that risks modification in transit that might invalidate an otherwise valid author signature (e.g., mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body).


7.4. Delegated Signing
7.4. 委托签字

An organization might choose to outsource certain key services to an independent company. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email.


If Company A wants to ensure that all of the mail sent on its behalf through the benefits providers email servers shares the Company A reputation, as discussed in Section 6.4, it can either publish keys designated for the use of the benefits provider under companyA.example (preferably under a designated subdomain of companyA.example), or it can delegate a subdomain (e.g., benefits.companyA.example) to the provider and enable the provider to generate the keys and manage the DNS for the designated subdomain.


In both of these cases, mail would be physically going out of the benefit provider's mail servers with a signature of, e.g., d=benefits.companya.example. Note that the RFC5322.From address is not constrained: it could be affiliated with either the benefits company (e.g., benefits-admin@benefitprovider.example, or benefits-provider@benefits.companya.example) or the companyA domain.


Note that in both of the above scenarios, as discussed in Section 3.4, security concerns dictate that the keys be generated by the organization that plans to do the signing so that there is no need to transfer the private key. In other words, the benefits provider would generate keys for both of the above scenarios.


7.5. Independent Third-Party Service Providers
7.5. 独立第三方服务提供商

Another way to manage the service provider configuration would be to have the service provider sign the outgoing mail on behalf of its client, Company A, with its own (provider) identifier. For example, an Email Service Provider (ESP A) might want to share its own mailing reputation with its clients, and might sign all outgoing mail from its clients with its own d= domain (e.g., d=espa.example).


When the ESP wants to distinguish among its clients, it has two options:


o Share the SDID domain and use the AUID value to distinguish among the clients, e.g., a signature on behalf of client A would have d=espa.example and i=@clienta.espa.example (or i=clienta@espa.example).

o 共享SDID域并使用AUID值区分客户端,例如,代表客户端a的签名将具有d=espa.example和i=@clienta.espa.example(或i=clienta@espa.example).

o Extend the SDID domain, so there is a unique value (and subdomain) for each client, e.g., a signature on behalf of client A would have d=clienta.espa.example.

o 扩展SDID域,使每个客户端都有一个唯一的值(和子域),例如,代表客户端a的签名将具有d=clienta.espa.example。

Note that this scenario and the delegation scenario are not mutually exclusive. In some cases, it can be desirable to sign the same message with both the ESP and the ESP client identities.


7.6. Mail Streams Based on Behavioral Assessment
7.6. 基于行为评估的邮件流

An ISP (ISP A) might want to assign signatures to outbound mail from its users according to each user's past sending behavior (reputation). In other words, the ISP would segment its outbound traffic according to its own assessment of message quality, to aid recipients in differentiating among these different streams. Since the semantics of behavioral assessments are not valid AUID values, ISP A (ispa.example) can configure subdomains corresponding to the assessment categories (e.g., good.ispa.example, neutral.ispa.example, bad.ispa.example), and use these subdomains in the d= value of the signature.

ISP(ISP A)可能希望根据每个用户过去的发送行为(信誉)为其用户的出站邮件分配签名。换句话说,ISP将根据自己对消息质量的评估对其出站流量进行分段,以帮助收件人区分这些不同的流。由于行为评估的语义不是有效的AUID值,ISP A(ispa.example)可以配置与评估类别相对应的子域(例如good.ispa.example、neutral.ispa.example、bad.ispa.example),并在签名的d=值中使用这些子域。

The signing module can also set the AUID value to have a unique user ID (distinct from the local-part of the user's email address), for example, user3456@neutral.domain.example. Using a user ID that is distinct from a given email alias is useful in environments where a single user might register multiple email aliases.

签名模块还可以将AUID值设置为具有唯一的用户ID(不同于用户电子邮件地址的本地部分),例如,user3456@neutral.domain.example. 在单个用户可能注册多个电子邮件别名的环境中,使用不同于给定电子邮件别名的用户ID非常有用。

Note that in this case, the AUID values are only partially stable. They are stable in the sense that a given i= value will always represent the same identity, but they are unstable in the sense that


a given user can migrate among the assessment subdomains depending on their sending behavior (i.e., the same user might have multiple AUID values over the lifetime of a single account).


In this scenario, ISP A can generate as many keys as there are assessment subdomains (SDID values), so that each assessment subdomain has its own key. The signing module would then choose its signing key based on the assessment of the user whose mail was being signed, and if desired, include the user ID in the AUID of the signature. As discussed earlier, the per-user granularity of the AUID can be ignored by verifiers; so organizations choosing to use it ought not rely on its use for receiver side filtering results. However, some organizations might also find the information useful for their own purposes in processing bounces or abuse reports.


7.7. Agent or Mediator Signatures
7.7. 代理人或调解人签名

Another scenario is that of an agent, usually a re-mailer of some kind, that signs on behalf of the service or organization that it represents. Some examples of agents might be a mailing list manager, or the "forward article to a friend" service that many online publications offer. In most of these cases, the signature is asserting that the message originated with, or was relayed by, the service asserting responsibility. In general, if the service is configured in such a way that its forwarding would break existing DKIM signatures, it needs to always add its own signature.


8. Usage Considerations
8. 使用注意事项
8.1. Non-Standard Submission and Delivery Scenarios
8.1. 非标准提交和交付场景

The robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules have access to the designated private key. This has the side effect that email submission and delivery scenarios that originate or relay messages from outside the domain of the authorized signing module will not have access to that protected private key, and thus will be unable to attach the expected domain signature to those messages. Such scenarios include mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by traveling users, and other paths that could add or modify headers, or modify the message body.


For example, assume Joe works for Company A and has an email address joe@companya.example. Joe also has an ISP-1 account, and he uses ISP-1's multiple address feature to attach his work email address, joe@companya.example, to email from his ISP-1 account. When Joe sends email from his ISP-1 account and uses joe@companya.example as his designated RFC5322.From address,

例如,假设Joe为A公司工作,并且有一个电子邮件地址joe@companya.example. 乔也有一个ISP-1帐户,他使用ISP-1的多地址功能附加他的工作电子邮件地址,joe@companya.example,通过他的ISP-1帐户发送电子邮件。当Joe从他的ISP-1帐户发送电子邮件并使用joe@companya.example作为其指定的RFC5322.发件人地址,

that email cannot have a signature with d=companya.example because the ISP-1 servers have no access to Company A's private key. In ISP-1's case, it will have an ISP-1 signature, but for some other mail clients offering the same multiple address feature there might be no signature at all on the message.


Another example might be the use of a forward article to a friend service. Most instances of these services today allow someone to send an article with their email address in the RFC5322.From to their designated recipient. If Joe used either of his two addresses (joe@companya.example or, the forwarder would be equally unable to sign with a corresponding domain. As in the mail client case, the forwarder can either sign as its own domain or put no signature on the message.


A third example is the use of privately configured forwarding. Assume that Joe has another account at ISP-2,, but he'd prefer to read his ISP-2 mail from his ISP-1 account. He sets up his ISP-2 account to forward all incoming mail to Assume alice@companyb.example sends an email. Depending on how companyb.example configured its signature, and depending on whether or not ISP-2 modifies messages that it forwards, it is possible that when Alice's message is received in Joe's ISP-1 account, the original signature will fail verification.

第三个例子是使用私有配置的转发。假设Joe在ISP-2有另一个帐户,,但他更喜欢从他的ISP-1帐户读取他的ISP-2邮件。他设置他的ISP-2帐户,将所有收到的邮件转发给 假定alice@companyb.example发送joe@isp-2.example.com电子邮件。根据companyb.example如何配置其签名,以及ISP-2是否修改其转发的消息,当Alice的消息在Joe的ISP-1帐户中收到时,原始签名可能无法验证。

8.2. Protection of Internal Mail
8.2. 内部邮件的保护

One identity is particularly amenable to easy and accurate assessment: the organization's own identity. Members of an organization tend to trust messages that purport to be from within that organization. However, Internet Mail does not provide a straightforward means of determining whether such mail is, in fact, from within the organization. DKIM can be used to remedy this exposure. If the organization signs all of its mail, then its boundary MTAs can look for mail purporting to be from the organization that does not contain a verifiable signature.


Such mail can, in most cases, be presumed to be spurious. However, domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g., MTAs at hotels, hotspot networks used by traveling users, and other scenarios described in the previous section). Such breakage is particularly relevant in the presence of Author Domain Signing Practices.


8.3. Signature Granularity
8.3. 签名粒度

Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer subdomains or otherwise adjust signatures in a way that supports per-user identification. This user-level granularity can be specified in two ways: either by sharing the signing identity and specifying an extension to the i= value that has a per-user granularity or by creating and signing with unique per-user keys.


A subdomain or local part in the i= tag needs to be treated as an opaque identifier and thus need not correspond directly to a DNS subdomain or be a specific user address.


The primary way to sign with per-user keys requires each user to have a distinct DNS (sub)domain, where each distinct d= value has a key published. (It is possible, although not advised, to publish the same key in more than one distinct domain.)


It is technically possible to publish per-user keys within a single domain or subdomain by utilizing different selector values. This is not advised and is unlikely to be treated uniquely by Assessors: the primary purpose of selectors is to facilitate key management, and the DKIM specification recommends against using them in determining or assessing identities.


In most cases, it would be impractical to sign email on a per-user granularity. Such an approach would be


likely to be ignored: In most cases today, if receivers are verifying DKIM signatures, they are in general taking the simplest possible approach. In many cases, maintaining reputation information at a per-user granularity is not interesting to them, in large part because the per-user volume is too small to be useful or interesting. So even if senders take on the complexity necessary to support per-user signatures, receivers are unlikely to retain anything more than the base domain reputation.


difficult to manage: Any scheme that involves maintenance of a significant number of public keys might require infrastructure enhancements or extensive administrative expertise. For domains of any size, maintaining a valid per-user keypair, knowing when keys need to be revoked or added due to user attrition or onboarding, and the overhead of having the signing engine constantly swapping keys can create significant and often unnecessary management complexity. It is also important to note


that there is no way within the scope of the DKIM specification for a receiver to infer that a sender intends a per-user granularity.


As mentioned before, what might make sense, however, is to use the infrastructure that enables finer granularity in signatures to identify segments smaller than a domain but much larger than a per-user segmentation. For example, a university might want to segment student, staff, and faculty mail into three distinct streams with differing reputations. This can be done by creating separate subdomains for the desired segments, and either specifying the subdomains in the i= tag of the DKIM Signature or by adding subdomains to the d= tag and assigning and signing with different keys for each subdomain.


For those who choose to represent user-level granularity in signatures, the performance and management considerations above suggest that it would be more effective to do so by specifying a local part or subdomain extension in the i= tag rather than by extending the d= domain and publishing individual keys.


8.4. Email Infrastructure Agents
8.4. 电子邮件基础架构代理

It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service, such as a department or a boundary MTA. What follows are some general recommendations for the Email Infrastructure.


Outbound: An MSA (Mail Submission Agent) or an outbound MTA used for mail submission needs to ensure that the message sent is in compliance with the advertised email sending policy. It needs to also be able to generate an operator alert if it determines that the email messages do not comply with the published DKIM sending policy.


An MSA needs to be aware that some MUAs might add their own signatures. If the MSA needs to perform operations on a message to make it comply with its email sending policy, if at all possible, it needs to do so in a way that would not break those signatures.


MUAs equipped with the ability to sign ought not to be encouraged. In terms of security, MUAs are generally not under the direct control of those in responsible roles within an organization and are thus more vulnerable to attack and compromise, which would expose private signing keys to intruders and thus jeopardize the integrity and reputation of the organization.


Inbound: When an organization deploys DKIM, it needs to make sure that its email infrastructure components that do not have primary roles in DKIM handling do not modify message in ways that prevent subsequent verification.


An inbound MTA or an MDA can incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].


Intermediaries: An email intermediary is both an inbound and outbound MTA. Each of the requirements outlined in the sections relating to MTAs apply. If the intermediary modifies a message in a way that breaks the signature, the intermediary.


+ needs to deploy abuse filtering measures on the inbound mail, and

+ 需要在入站邮件上部署滥用筛选措施,以及

+ probably also needs to remove all signatures that will be broken.

+ 可能还需要删除所有将被破坏的签名。

In addition, the intermediary can:


+ verify the message signature prior to modification.

+ 在修改之前验证消息签名。

+ incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].

+ 将验证结果的指示合并到消息中,例如使用验证结果标头字段[RFC5451]。

+ sign the modified message including the verification results (e.g., the Authentication-Results header field).

+ 签署修改后的消息,包括验证结果(例如,身份验证结果标题字段)。

8.5. Mail User Agent
8.5. 邮件用户代理

The DKIM specification is expected to be used primarily between Boundary MTAs, or other infrastructure components of the originating and receiving ADMDs. However, there is nothing in DKIM that is specific to those venues. In particular, MUAs can also support DKIM signing and verifying directly.


Outbound: An MUA can support signing even if mail is to be relayed through an outbound MSA. In this case, the signature applied by the MUA will be in addition to any signature added by the MSA. However, the warnings in the previous section need to be taken into consideration.


Some user software goes beyond simple user functionality and also performs MSA and MTA functions. When this is employed for sending directly to a receiving ADMD, the user software needs to be considered an outbound MTA.


Inbound: An MUA can rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/ MDA path (e.g., an Authentication-Results header field), or an MUA can perform DKIM signature verification directly. A verifying MUA needs to allow for the case where mail has been modified in the inbound MTA path; if a signature fails, the message is to be treated the same as a message that does not have a signature.


An MUA that looks for an Authentication-Results header field needs to be configurable to choose which Authentication-Results header fields are considered trustable. The MUA developer is encouraged to re-read the Security Considerations of [RFC5451].


DKIM requires that all verifiers treat messages with signatures that do not verify as if they are unsigned.


If verification in the client is to be acceptable to users, it is essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned. The mere presence of a verified DKIM signature cannot be used by itself by an MUA to indicate that a message is to be treated better than a message without a verified DKIM signature. However, the fact that a DKIM signature was verified can be used as input into a reputation system (i.e., a whitelist of domains and users) for presentation of such indicators.


It is common for components of an ADMD's email infrastructure to do violence to a message, such that a DKIM signature might be rendered invalid. Hence, users of MUAs that support DKIM signing and/or verifying need a basis for knowing that their associated email infrastructure will not break a signature.


9. Security Considerations
9. 安全考虑

The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871].


10. Acknowledgements
10. 致谢

The effort of the DKIM Working Group is gratefully acknowledged.


11. References
11. 工具书类
11.1. Normative References
11.1. 规范性引用文件

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

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.


[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.

[RFC5451]Kucherawy,M.,“用于指示消息身份验证状态的消息头字段”,RFC 5451,2009年4月。

[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.

[RFC5585]Hansen,T.,Crocker,D.,和P.Hallam Baker,“域密钥识别邮件(DKIM)服务概述”,RFC 55852009年7月。

[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.

[RFC5617]Allman,E.,Fenton,J.,Delany,M.,和J.Levine,“域密钥识别邮件(DKIM)作者域签名实践(ADSP)”,RFC 56172009年8月。

[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.

[RFC5672]Crocker,D.,“RFC 4871域密钥识别邮件(DKIM)签名——更新”,RFC 56722009年8月。

11.2. Informative References
11.2. 资料性引用

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[RFC4034]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全扩展的资源记录”,RFC 40342005年3月。

[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.

[RFC4870]Delany,M.,“使用DNS中公布的公钥进行基于域的电子邮件身份验证(域密钥)”,RFC 4870,2007年5月。

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.

[RFC5155]Laurie,B.,Sisson,G.,Arends,R.,和D.Blacka,“DNS安全(DNSSEC)哈希认证拒绝存在”,RFC 51552008年3月。

Appendix A. Migration Strategies

There are three migration occasions worth noting in particular for DKIM:


1. Migrating from DomainKeys to DKIM.

1. 从域密钥迁移到DKIM。

2. Migrating from a current hash algorithm to a new standardized hash algorithm.

2. 从当前哈希算法迁移到新的标准化哈希算法。

3. Migrating from a current signing algorithm to a new standardized signing algorithm.

3. 从当前签名算法迁移到新的标准化签名算法。

The case of deploying a new key selector record is described elsewhere (Section 3.5).


As with any migration, the steps required will be determined by who is doing the migration and their assessment of:


o the users of what they are generating, or

o 用户正在生成的内容,或

o the providers of what they are consuming.

o 他们消费的东西的提供者。

Signers and verifiers have different considerations.


A.1. Migrating from DomainKeys
A.1. 从域密钥迁移

DKIM replaces the earlier DomainKeys (DK) specification. Selector files are mostly compatible between the two specifications.


A.1.1. Signers
A.1.1. 签名者

A signer that currently signs with DK will go through various stages as it migrates to using DKIM, not all of which are required for all signers. The real questions that a signer needs to ask are:


1. how many receivers or what types of receivers are *only* looking at the DK signatures and not the DKIM signatures, and

1. 有多少个接收者或什么类型的接收者*仅*查看DK签名而不是DKIM签名,以及

2. how much does the signer care about those receivers?

2. 签名者对这些接收者有多关心?

If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if all "large players" are looking at DKIM in addition to or instead of DK, a signer can choose to stop signing with DK.


With respect to signing policies, a reasonable, initial approach is to use DKIM signatures in the same way that DomainKeys signatures are already being used. In particular, the same selectors and DNS key records can be used for both, after verifying that they are compatible as discussed below.


Each secondary step in all of the following scenarios is to be prefaced with the gating factor "test, then when comfortable with the previous step's results, continue".


One migration strategy is to:


o ensure that the current selector DNS key record is compatible with both DK and DKIM

o 确保当前选择器DNS密钥记录与DK和DKIM兼容

o sign messages with both DK and DKIM signatures

o 使用DK和DKIM签名对消息进行签名

o when it's decided that DK signatures are no longer necessary, stop signing with DK

o 当决定不再需要DK签名时,停止与DK签名

Another migration strategy is to:


o add a new selector DNS key record only for DKIM signatures

o 仅为DKIM签名添加新的选择器DNS密钥记录

o sign messages with both DK (using the old DNS key record) and DKIM signatures (using the new DNS key record)

o 使用DK(使用旧DNS密钥记录)和DKIM签名(使用新DNS密钥记录)对消息进行签名

o when it's decided that DK signatures are no longer necessary, stop signing with DK

o 当决定不再需要DK签名时,停止与DK签名

o eventually remove the old DK selector DNS record

o 最终删除旧的DK选择器DNS记录

A combined migration strategy is to:


o ensure that the current selector DNS key record is compatible with both DK and DKIM

o 确保当前选择器DNS密钥记录与DK和DKIM兼容

o start signing messages with both DK and DKIM signatures

o 开始使用DK和DKIM签名对邮件进行签名

o add a new selector DNS key record for DKIM signatures

o 为DKIM签名添加新的选择器DNS密钥记录

o switch the DKIM signatures to use the new selector

o 切换DKIM签名以使用新选择器

o when it's decided that DK signatures are no longer necessary, stop signing with DK

o 当决定不再需要DK签名时,停止与DK签名

o eventually remove the old DK selector DNS record

o 最终删除旧的DK选择器DNS记录

Another migration strategy is to:


o add a new selector DNS key record for DKIM signatures

o 为DKIM签名添加新的选择器DNS密钥记录

o do a flash cut and replace the DK signatures with DKIM signatures

o 进行闪光切割,并用DKIM签名替换DK签名

o eventually remove the old DK selector DNS record

o 最终删除旧的DK选择器DNS记录

Another migration strategy is to:


o ensure that the current selector DNS key record is compatible with both DK and DKIM

o 确保当前选择器DNS密钥记录与DK和DKIM兼容

o do a flash cut and replace the DK signatures with DKIM signatures

o 进行闪光切割,并用DKIM签名替换DK签名

Note that when you have separate key records for DK and DKIM, you can use the same public key for both.


A.1.1.1. DNS Selector Key Records
A.1.1.1. DNS选择器键记录

The first step in some of the above scenarios is ensuring that the selector DNS key records are compatible for both DK and DKIM. The format of the DNS key record was intentionally meant to be backwardly compatible between the two systems, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one critical difference between DK and DKIM DNS key records. The definitions of the "g" fields:

上述一些场景中的第一步是确保选择器DNS密钥记录与DK和DKIM兼容。DNS密钥记录的格式有意在两个系统之间向后兼容,但不一定向上兼容。DKIM通过添加几个可选参数增强了DK DNS密钥记录格式,DK需要忽略这些参数。但是,DK和DKIM DNS密钥记录之间有一个关键区别。“g”字段的定义:

g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. DKIM allows wildcards where DK does not. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. In DKIM, both a missing value and "g=*;" mean to allow any sending address.


Also, in DomainKeys, the "g" field is required to match the address in "From:"/"Sender:", while in DKIM, it is required to match i=. This might or might not affect transition.


If your DK DNS key record has an empty "g" field in it ("g=;"), your best course of action is to modify the record to remove the empty field. In that way, the DK semantics will remain the same, and the DKIM semantics will match.

如果您的DK DNS密钥记录中有一个空的“g”字段(“g=;”),那么最好的做法是修改该记录以删除该空字段。这样,DK语义将保持不变,DKIM语义将匹配。

If your DNS key record does not have an empty "g" field in it ("g=;"), it's probable that the record can be left alone. But the best course of action would still be to make sure that it has a "v" field. When the decision is made to stop supporting DomainKeys and to only support DKIM, it is important to verify that the "g" field is compatible with DKIM, and typically having "v=DKIM1;" in it. It is strongly encouraged that if use of an empty "g" field in the DKIM selector, include the "v" field.


A.1.1.2. Removing DomainKeys Signatures
A.1.1.2. 删除域密钥签名

The principal use of DomainKeys is at boundary MTAs. Because no operational transition is ever instantaneous, it is advisable to continue performing DomainKeys signing until it is determined that DomainKeys receive-side support is no longer used, or is sufficiently reduced. That is, a signer needs to add a DKIM signature to a message that also has a DomainKeys signature and keep it there until they decide it is deemed no longer useful. The signer can do its transitions in a straightforward manner, or more gradually. Note that because digital signatures are not free, there is a cost to performing both signing algorithms, so signing with both algorithms ought not be needlessly prolonged.


The tricky part is deciding when DK signatures are no longer necessary. The real questions are: how many DomainKeys verifiers are there that do *not* also do DKIM verification, which of those are important, and how can you track their usage? Most of the early adopters of DK verification have added DKIM verification, but not all yet. If a verifier finds a message with both DK and DKIM, it can choose to verify both signatures, or just one or the other.


Many DNS services offer tracking statistics so it can be determined how often a DNS record has been accessed. By using separate DNS selector key records for your signatures, you can chart the use of your records over time, and watch the trends. An additional distinguishing factor to track would take into account the verifiers that verify both the DK and DKIM signatures, and discount those from counts of DK selector usage. When the number for DK selector access reaches a low-enough level, that's the time to consider discontinuing signing with DK.


Note, this level of rigor is not required. It is perfectly reasonable for a DK signer to decide to follow the "flash cut" scenario described above.


A.1.2. Verifiers
A.1.2. 验证者

As a verifier, several issues need to be considered:


A.1.2.1. Ought DK signature verification be performed?
A.1.2.1. 是否应该执行DK签名验证?

At the time of writing, there is still a significant number of sites that are only producing DK signatures. Over time, it is expected that this number will go to zero, but it might take several years. So it would be prudent for the foreseeable future for a verifier to look for and verify both DKIM and DK signatures.


A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single message?

A.1.2.2. DK和DKIM签名是否应该在单个消息上进行评估?

For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message that has both types of signatures can verify both signatures, or just one. One disadvantage of verifying both signatures is that signers will have a more difficult time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails.


A.1.2.3. DNS Selector Key Records
A.1.2.3. DNS选择器键记录

The format of the DNS key record was intentionally meant to be backwardly compatible between DK and DKIM, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one key difference between DK and DKIM DNS key records. The definitions of the g fields:

DNS密钥记录的格式有意在DK和DKIM之间向后兼容,但不一定向上兼容。DKIM通过添加几个可选参数增强了DK DNS密钥记录格式,DK需要忽略这些参数。但是,DK和DKIM DNS密钥记录之间有一个关键区别。g字段的定义:

g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part.


v= version of the selector It is advised that a DKIM selector have "v=DKIM1;" at its beginning, but it is not required.


If a DKIM verifier finds a selector record that has an empty "g" field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its beginning, it is faced with deciding if this record was:


1. from a DK signer that transitioned to supporting DKIM but forgot to remove the "g" field (so that it could be used by both DK and DKIM verifiers); or

1. 来自一个DK签名者,该签名者转换为支持DKIM,但忘记删除“g”字段(以便DK和DKIM验证器都可以使用该字段);或

2. from a DKIM signer that truly meant to use the empty "g" field but forgot to put in the "v" field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a "g" field in the record.

2. 来自一个DKIM签名者,他真的想使用空的“g”字段,但忘了输入“v”字段。建议您使用第一种解释来处理此类记录,并将此类记录视为签名人在记录中没有“g”字段。

A.2. Migrating Hash Algorithms
A.2. 迁移散列算法

[RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256. The security of all hash algorithms is constantly under attack, and SHA-1 has already shown weaknesses as of this writing. Migrating from SHA-1 to SHA-256 is not an issue, because all verifiers are already required to support SHA-256. But when it becomes necessary to replace SHA-256 with a more secure algorithm, there will be a migratory period. In the following, "NEWHASH" is used to represent a new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this scenario.


A.2.1. Signers
A.2.1. 签名者

As with migrating from DK to DKIM, migrating hash algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing hash algorithms are considered and how important that is to the signers.


One strategy is to wait until it's determined that there is a large enough base of verifiers available that support NEWHASH, and then flash cut to the new algorithm.


Another strategy is to sign with both the old and new hash algorithms for a period of time. This is particularly useful for testing the new code to support the new hash algorithm, as verifiers will continue to accept the signature for the older hash algorithm and ought to ignore any signature that fails because the code is slightly wrong. Once the signer has determined that the new code is correct AND it's determined that there is a large enough base of verifiers available that support NEWHASH, the signer can flash cut to the new algorithm.


One advantage migrating hash algorithms has is that the selector can be completely compatible for all hash algorithms. The key selector has an optional "h=" field that can be used to list the hash algorithms being used; it also is used to limit the algorithms that a


verifier will accept. If the signer is not currently using the key selector "h=" field, no change is required. If the signer is currently using the key selector "h=" field, NEWHASH will need to be added to the list, as in "h=sha256:NEWHASH;". (When the signer is no longer using SHA-256, it can be removed from the "h=" list.)


A.2.2. Verifiers
A.2.2. 验证者

When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.


A.3. Migrating Signing Algorithms
A.3. 迁移签名算法

[RFC4871] defines the use of the RSA signing algorithm. Similar to hashes, signing algorithms are constantly under attack, and when it becomes necessary to replace RSA with a newer signing algorithm, there will be a migratory period. In the following, "NEWALG" is used to represent a new signing algorithm.


A.3.1. Signers
A.3.1. 签名者

As with the other migration issues discussed above, migrating signing algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing signing algorithms are considered and how important that is to the signers.


As before, the two basic strategies are to 1) wait until there is sufficient base of verifiers available that support NEWALG and then do a flash cut to NEWALG, and 2) use a phased approach by signing with both the old and new algorithms before removing support for the old algorithm.


It is unlikely that a new algorithm would be able to use the same public key as "rsa", so using the same selector DNS record for both algorithms' keys is ruled out. Therefore, in order to use the new algorithm, a new DNS selector record would need to be deployed in parallel with the existing DNS selector record for the existing algorithm. The new DNS selector record would specify a different "k=" value to reflect the use of NEWALG.


A.3.2. Verifiers
A.3.2. 验证者

When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.


Appendix B. General Coding Criteria for Cryptographic Applications

NOTE: This section could possibly be changed into a reference to something else, such as another RFC.


Correct implementation of a cryptographic algorithm is a necessary but not a sufficient condition for the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications.


In addition to the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers need to pay close attention to management of cryptographic private keys and session keys, ensuring that these are correctly initialized and disposed of.


Operating system mechanisms that permit the confidentiality of private keys to be protected against other processes ought to be used when available. In particular, great care needs to be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes.


Certain implementations of public key algorithms such as RSA can be vulnerable to a timing analysis attack.


Support for cryptographic hardware providing key management capabilities is strongly encouraged. In addition to offering performance benefits, many cryptographic hardware devices provide robust and verifiable management of private keys.


Fortunately, appropriately designed and coded cryptographic libraries are available for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic libraries is strongly encouraged. These have been extensively tested, reduce development time and support a wide range of cryptographic hardware.


Authors' Addresses


Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA



Ellen Siegel Consultant



Phillip Hallam-Baker Default Deny Security, Inc.

Phillip Hallam Baker默认拒绝安全公司。


Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA

Dave Crocker Brandenburg互联网675 Spruce Dr.Sunnyvale,加利福尼亚州,美国94086