Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6377 Cloudmark
BCP: 167 September 2011
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6377 Cloudmark
BCP: 167 September 2011
Category: Best Current Practice
ISSN: 2070-1721
DomainKeys Identified Mail (DKIM) and Mailing Lists
域密钥标识邮件（DKIM）和邮件列表
Abstract
摘要
DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs).
DomainKeys Identified Mail（DKIM）允许管理域（ADMD）对消息承担一些责任。基于DKIM的部署经验，本文档提供了在包括邮件列表管理器（MLM）的场景中使用DKIM的指南。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6377.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6377.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MLMs in Infrastructure . . . . . . . . . . . . . . . . . . 4
1.3. Feedback Loops and Other Bilateral Agreements . . . . . . 5
1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 6
2.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 6
2.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7
2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 7
3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 7
3.2. Types of Mailing Lists . . . . . . . . . . . . . . . . . . 8
3.3. Current MLM Effects on Signatures . . . . . . . . . . . . 10
4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 12
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13
4.4. Wrapping a Non-Participating MLM . . . . . . . . . . . . . 13
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14
5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Exceptions to ADSP Recommendations . . . . . . . . . . . . 15
5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 16
5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16
5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 17
5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19
5.9. Verification Outcomes at Final Receiving Sites . . . . . . 20
5.10. Use with FBLs . . . . . . . . . . . . . . . . . . . . . . 20
5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 21
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Security Considerations from DKIM and ADSP . . . . . . . . 22
7.2. Authentication Results When Relaying . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 25
B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 25
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MLMs in Infrastructure . . . . . . . . . . . . . . . . . . 4
1.3. Feedback Loops and Other Bilateral Agreements . . . . . . 5
1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 6
2.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 6
2.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7
2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 7
3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 7
3.2. Types of Mailing Lists . . . . . . . . . . . . . . . . . . 8
3.3. Current MLM Effects on Signatures . . . . . . . . . . . . 10
4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 12
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13
4.4. Wrapping a Non-Participating MLM . . . . . . . . . . . . . 13
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14
5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Exceptions to ADSP Recommendations . . . . . . . . . . . . 15
5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 16
5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16
5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 17
5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19
5.9. Verification Outcomes at Final Receiving Sites . . . . . . 20
5.10. Use with FBLs . . . . . . . . . . . . . . . . . . . . . . 20
5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 21
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Security Considerations from DKIM and ADSP . . . . . . . . 22
7.2. Authentication Results When Relaying . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 25
B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 25
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 25
DomainKeys Identified Mail [DKIM] allows an ADministrative Management Domain (ADMD) to take some responsibility for a [MAIL] message. Such responsibility can be taken by an Author's organization, an operational relay (Mail Transfer Agent, or MTA), or one of their agents. Assertion of responsibility is made through a cryptographic signature. Message transit from Author to recipient is through relays that typically make no substantive change to the message content and thus preserve the validity of the DKIM signature.
DomainKeys Identified Mail[DKIM]允许管理域（ADMD）对[Mail]邮件承担一些责任。此类责任可由作者的组织、操作中继（邮件传输代理或MTA）或其代理之一承担。通过加密签名来声明责任。消息从作者到收件人的传输是通过中继进行的，中继通常不会对消息内容进行实质性更改，从而保持DKIM签名的有效性。
In contrast to relays, there are intermediaries, such as Mailing List Managers (MLMs), that actively take delivery of messages, reformat them, and repost them, often invalidating DKIM signatures. The goal for this document is to explore the use of DKIM for scenarios that include intermediaries and recommend best current practices based on acquired experience. Questions that will be discussed include:
与中继不同的是，有一些中介机构，如邮件列表管理器（MLM），它们主动接收邮件、重新格式化邮件并重新发布邮件，通常会使DKIM签名无效。本文档的目标是探索DKIM在包括中介机构在内的场景中的使用，并根据获得的经验推荐当前最佳实践。将讨论的问题包括：
o Under what circumstances is it advisable for an Author, or its organization, to apply DKIM to mail sent to mailing lists?
o 在什么情况下，作者或其组织最好将DKIM应用于发送到邮件列表的邮件？
o What are the trade-offs regarding having an MLM verify and use DKIM identifiers?
o 关于传销验证和使用DKIM标识符，有哪些权衡？
o What are the trade-offs regarding having an MLM remove existing DKIM signatures prior to reposting the message?
o 在重新发布邮件之前，让传销删除现有DKIM签名的权衡是什么？
o What are the trade-offs regarding having an MLM add its own DKIM signature?
o 关于让传销公司添加自己的DKIM签名，有哪些权衡？
These are open questions for which there may be no definitive answers. However, based on experience since the publication of the original version of [DKIM] and its gradual deployment, there are some views that are useful to consider and some recommended procedures.
这些都是开放性问题，可能没有明确的答案。然而，基于原始版本[DKIM]及其逐步部署以来的经验，有一些有用的观点和一些推荐的程序。
In general, there are two categories of MLMs in relation to DKIM: participating and non-participating. As each type has its own issues regarding DKIM-signed messages that are either handled or produced by them (or both), the types are discussed in separate sections.
一般来说，与DKIM有关的传销有两类：参与传销和非参与传销。由于每种类型都有自己的关于DKIM签名消息的问题，这些消息由它们（或两者）处理或生成，因此在单独的部分中讨论这些类型。
The best general recommendation for dealing with MLMs is that the MLM or an MTA in the MLM's domain apply its own DKIM signature to each message it forwards and that assessors on the receiving end consider the MLM's domain signature in making their assessments. (See Section 5, especially Section 5.2.)
处理MLMS的最好的一般建议是MLM域中的MLM或MTA将其自己的DKIM签名应用到它转发的每个消息上，并且接收方的评估者考虑MLM的域签名来进行评估。（见第5节，特别是第5.2节。）
With the understanding that this is not always possible or practical and the consideration that it might not always be sufficient, this document provides additional guidance.
理解到这并不总是可能的或实际的，并且考虑到这可能并不总是足够的，本文件提供了额外的指导。
DKIM signatures permit an agent of the email architecture (see [EMAIL-ARCH]) to make a claim of responsibility for a message by affixing a validated domain-level identifier to the message as it passes through a relay. Although not the only possibility, this is most commonly done as a message passes through a boundary Mail Transport Agent (MTA) as it departs an ADministrative Management Domain (ADMD) across the open Internet.
DKIM签名允许电子邮件体系结构的代理（参见[email-ARCH]）通过在消息通过中继时向消息附加经验证的域级标识符来声明消息的责任。虽然这不是唯一的可能性，但这通常是在邮件通过边界邮件传输代理（MTA）离开开放Internet上的管理管理域（ADMD）时完成的。
A DKIM signature will fail to verify if a portion of the message covered by one of its hashes is altered. An MLM commonly alters messages to provide information specific to the mailing list for which it is providing service. Common modifications are enumerated and described in Section 3.3. However, note that MLMs vary widely in behavior and often allow subscribers to select individual behaviors. Further, the MTA might make changes that are independent of those applied by the MLM.
DKIM签名将无法验证其散列所覆盖的消息部分是否被更改。传销通常会更改邮件，以提供特定于其提供服务的邮件列表的信息。第3.3节列举并描述了常见修改。但是，请注意，传销在行为上有很大差异，通常允许订阅者选择个人行为。此外，MTA可能会做出独立于传销应用的更改。
The DKIM Signatures specification [DKIM] deliberately rejects the notion of tying the signing domain (the "d=" tag in a DKIM signature) to any other identifier within a message; any ADMD that handles a message could sign it, regardless of its origin or Author domain. In particular, DKIM does not define any meaning to the occurrence of a match between the content of a "d=" tag and the value of, for example, a domain name in the RFC5322.From field, nor is there any obvious degraded value to a signature where they do not match. Since any DKIM signature is merely an assertion of "some" responsibility by an ADMD, a DKIM signature added by an MLM has no more or less meaning than a signature with any other "d=" value.
DKIM签名规范[DKIM]故意拒绝将签名域（DKIM签名中的“d=”标记）绑定到消息中任何其他标识符的概念；任何处理邮件的ADMD都可以对邮件进行签名，而不管其来源或作者域如何。特别是，DKIM没有定义“d=”标记的内容与RFC5322.From字段中域名的值（例如）之间匹配的任何含义，也没有任何明显的降级值与不匹配的签名。由于任何DKIM签名仅是ADMD对“某些”责任的断言，因此传销添加的DKIM签名与具有任何其他“d=”值的签名没有多少意义。
An MLM is an autonomous agent that takes delivery of a message and can repost it as a new message or construct a digest of it along with other messages to the members of the list (see [EMAIL-ARCH], Section 5.3). However, the fact that the RFC5322.From field of such a message (in the non-digest case) is typically the same as that of the original message, and that recipients perceive the message as "from" the original Author rather than the MLM, creates confusion about responsibility and autonomy for the reposted message. This has important implications for the use of DKIM.
传销是一种自主代理，它接收消息并可以将其作为新消息重新发布，或将其与其他消息一起构建摘要，发送给列表成员（请参见[EMAIL-ARCH]，第5.3节）。然而，此类邮件的RFC5322.From字段（在非摘要情况下）通常与原始邮件的字段相同，并且收件人将邮件视为“来自”原始作者而不是传销，这一事实造成了对重新发布邮件的责任和自主权的混淆。这对DKIM的使用具有重要意义。
Section 3.3 describes some of the things MLMs commonly do that produce broken signatures, thus reducing the perceived value of DKIM.
第3.3节描述了传销公司通常会做的一些事情，这些事情会产生破碎的签名，从而降低DKIM的感知价值。
Further, while there are published standards that are specific to MLM behavior (e.g., [MAIL], [LIST-ID], and [LIST-URLS]), their adoption has been spotty at best. Hence, efforts to specify the use of DKIM in the context of MLMs need to be incremental and value-based.
此外，尽管已经发布了一些特定于传销行为的标准（例如，[MAIL]、[LIST-ID]和[LIST-URL]），但这些标准的采用充其量也是参差不齐的。因此，在传销背景下规定使用DKIM的努力需要是渐进的和基于价值的。
Some MLM behaviors are well-established and their effects on DKIM signature validity can be argued as frustrating wider DKIM adoption. Still, those behaviors are not standards violations. Hence, this memo specifies practices for all parties involved, defining the minimum changes possible to MLMs themselves.
一些传销行为已经确立，它们对DKIM签名有效性的影响可能会阻碍DKIM的广泛采用。不过，这些行为并非违反标准。因此，本备忘录规定了所有相关方的做法，定义了传销本身可能发生的最小变化。
A DKIM signature on a message is an expression of some responsibility for the message taken by the signing domain. An open issue that is addressed by this document is the ways a signature might be used by a recipient's evaluation module, after the message has gone through a mailing list and might or might not have been rendered invalid. The document also considers how invalidation might have happened.
消息上的DKIM签名表示签名域对消息承担的某种责任。本文档解决的一个公开问题是，在邮件经过邮件列表后，收件人的评估模块可能会使用签名，并且签名可能会或可能不会被视为无效。该文档还考虑了失效可能是如何发生的。
Note that where in this document there is discussion of an MLM conducting validation of DKIM signatures or Author Domain Signing Practices ([ADSP]) policies, the actual implementation could be one where the validation is done by the MTA or an agent attached to it, and the results of that work are relayed by a trusted channel not specified here. See [AUTH-RESULTS] for a discussion of this. This document does not favor any particular arrangement of these agents over another; it merely talks about the MLM itself doing the work as a matter of simplicity.
请注意，在本文档中讨论了传销对DKIM签名或作者域签名实践（[ADSP]）策略进行验证的情况下，实际的实施可能是由MTA或附加到MTA的代理进行验证，并且该工作的结果由此处未指定的受信任通道转发。请参阅[AUTH-RESULTS]了解对此的讨论。本文件不支持这些代理的任何特定安排；它只是简单地谈论传销本身做这项工作。
A Feedback Loop (FBL) is a bilateral agreement between two parties to exchange reports of abuse. Typically, a sender registers with a receiving site to receive abuse reports from that site for mail coming from the sender.
反馈回路（FBL）是双方之间交换虐待报告的双边协议。通常，发件人在接收站点注册，以从该站点接收来自发件人的邮件的滥用报告。
An FBL reporting address (i.e., an address to which FBL reports are sent) is part of this bilateral registration. Some FBLs require DKIM use by the registrant.
FBL报告地址（即FBL报告发送地址）是双边注册的一部分。一些FBL要求注册人使用DKIM。
See Section 6 for additional discussion.
更多讨论见第6节。
FBLs tend to use the [ARF] or the [IODEF] formats.
FBL倾向于使用[ARF]或[IODEF]格式。
This document provides discussion on the above issues to improve the handling of possible interactions between DKIM and MLMs. In general, the preference is to impose changes to behavior at the Signer and Verifier rather than at the MLM.
本文件对上述问题进行了讨论，以改进DKIM和MLM之间可能的交互处理。一般来说，首选在签名者和验证者处而不是传销处对行为进行更改。
Wherever possible, the document's discussion of MLMs is conceptually decoupled from MTAs despite the very tight integration that is sometimes observed in implementation. This is done to emphasize the functional independence of MLM services and responsibilities from those of an MTA.
在可能的情况下，本文件对传销的讨论在概念上与MTA分离，尽管有时在实施过程中会观察到非常紧密的集成。这样做是为了强调传销服务的功能独立性以及与MTA的职责。
Parts of this document explore possible changes to common practice by Signers, Verifiers, and MLMs. The suggested enhancements are largely predictive in nature, taking into account the current email infrastructure, the facilities DKIM can provide as it gains wider deployment, and working group consensus. There is no substantial implementation history upon which these suggestions are based, and their efficacy, performance, and security characteristics have not yet been fully explored.
本文件的部分内容探讨了签名人、验证人和传销管理人对常规做法的可能变更。考虑到当前的电子邮件基础设施、DKIM在获得更广泛部署时可以提供的设施以及工作组的共识，建议的增强在本质上主要是预测性的。这些建议没有实质性的实现历史作为基础，其有效性、性能和安全特性尚未得到充分探讨。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[关键词]中所述进行解释。
See [EMAIL-ARCH] for a general description of the current messaging architecture and for definitions of various terms used in this document.
有关当前消息传递体系结构的一般说明以及本文档中使用的各种术语的定义，请参见[EMAIL-ARCH]。
Readers are encouraged to become familiar with [DKIM] and [ADSP], which are core specification documents, as well as [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents.
鼓励读者熟悉核心规范文档[DKIM]和[ADSP]，以及DKIM的主要教程文档[DKIM-OVERVIEW]和[DKIM-DEPLOYMENT]。
The term "DKIM-friendly" is used to describe an email intermediary that, when handling a message, makes no changes to the message that cause valid [DKIM] signatures present on the message on input to fail to verify on output.
术语“DKIM友好”用于描述一种电子邮件中介，在处理邮件时，不会对邮件进行任何更改，从而导致输入时邮件上存在的有效[DKIM]签名无法在输出时验证。
Various features of MTAs and MLMs seen as helpful to users often have side effects that do render DKIM signatures unverifiable. These would not qualify for this label.
MTA和MLM被视为对用户有用的各种功能通常会产生副作用，使DKIM签名无法验证。这些不符合此标签的要求。
A "message stream" identifies a group of messages originating from within an ADMD that are distinct in intent, origin, and/or use and partitions them somehow (e.g., via changing the value in the "d=" tag value in the context of DKIM) so as to keep them associated to users yet distinct in terms of their evaluation and handling by Verifiers or Receivers.
“消息流”标识源自ADMD的一组消息，这些消息在目的、来源和/或使用上不同，并以某种方式对其进行划分（例如，通过在DKIM上下文中更改“d=”标记值中的值）从而使它们与用户保持关联，但在验证者或接收者对它们的评估和处理方面是不同的。
A good example might be user mail generated by a company's employees, versus operational or transactional mail that comes from automated sources or marketing or sales campaigns. Each of these could have different sending policies imposed against them, or there might be a desire to insulate one from the other (e.g., a marketing campaign that gets reported by many spam filters could cause the marketing stream's reputation to degrade without automatically punishing the transactional or user streams).
一个很好的例子可能是公司员工生成的用户邮件，而不是来自自动化来源或营销或销售活动的操作或事务性邮件。其中每一个都可能有针对它们的不同发送策略，或者可能希望将其中一个与另一个隔离开来（例如，许多垃圾邮件过滤器报告的营销活动可能会导致营销流的声誉下降，而不会自动惩罚交易流或用户流）。
It is important to make some distinctions among different styles of intermediaries, their typical implementations, and the effects they have in a DKIM-aware environment.
区分不同类型的中介体、它们的典型实现以及它们在DKIM感知环境中的作用非常重要。
Across DKIM activities, there are several key roles in the transit of a message. Most of these are defined in [EMAIL-ARCH] but are reviewed here for quick reference.
在DKIM活动中，在消息传输过程中有几个关键角色。其中大多数在[EMAIL-ARCH]中定义，但此处进行了回顾，以供快速参考。
Author: The agent that provided the content of the message being sent through the system. The Author delivers that content to the Originator in order to begin a message's journey to its intended final recipients. The Author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the "cron" Unix system utility).
作者：提供通过系统发送的消息内容的代理。作者将该内容交付给发起者，以便开始一条消息到其预期最终接收者的旅程。作者可以是使用MUA（邮件用户代理）或可能发送邮件的自动化进程（例如，“cron”Unix系统实用程序）的人。
Originator: The agent that accepts a message from the Author, ensures it conforms to the relevant standards such as [MAIL], and then sends it toward its destination(s). This is often referred to as the Mail Submission Agent (MSA).
发起者：从作者处接收消息的代理，确保消息符合相关标准，如[邮件]，然后将消息发送到目的地。这通常被称为邮件提交代理（MSA）。
Signer: Any agent that affixes one or more DKIM signature(s) to a message on its way toward its ultimate destination. There is typically a Signer running at the MTA that sits between the Author's ADMD and the general Internet. The Originator and/or Author might also be a Signer.
签名者：在消息到达最终目的地的途中向消息附加一个或多个DKIM签名的任何代理。通常有一个签名者在MTA上运行，MTA位于作者的ADMD和通用Internet之间。发起人和/或作者也可能是签名人。
Verifier: Any agent that conducts DKIM signature validation. One is typically running at the MTA that sits between the public Internet and the Receiver's ADMD. Note that any agent that handles a signed message can conduct verification; this document only considers that action and its outcomes either at an MLM or at the Receiver. Filtering decisions could be made by this agent based on verification results.
验证者：进行DKIM签名验证的任何代理。一个通常在公共互联网和接收方ADMD之间的MTA上运行。请注意，处理签名消息的任何代理都可以进行验证；本文件仅考虑传销或接收方的行动及其结果。该代理可以根据验证结果做出过滤决策。
Receiver: The agent that is the final transit relay for the message and performs final delivery to the recipient(s) of the message. Filtering decisions based on results made by the Verifier could be applied by the Receiver. The Verifier and the Receiver could be the same agent. This is sometimes the same as or coupled with the Mail Delivery Agent (MDA).
Receiver：作为邮件的最终传输中继并向邮件收件人执行最终传递的代理。接收机可以应用基于验证器所做结果的过滤决策。验证器和接收器可以是同一个代理。这有时与邮件传递代理（MDA）相同或结合使用。
In the case of simple user-to-user mail, these roles are fairly straightforward. However, when one is sending mail to a list and the mail then gets relayed to all of that list's subscribers, the roles are often less clear to the general user as particular agents may hold multiple important but separable roles. The above definitions are intended to enable more precise discussion of the mechanisms involved.
对于简单的用户对用户邮件，这些角色相当简单。然而，当一个人向一个列表发送邮件，然后邮件被转发给该列表的所有订阅者时，普通用户通常不太清楚这些角色，因为特定的代理可能拥有多个重要但可分离的角色。上述定义旨在更准确地讨论所涉及的机制。
There are four common MLM implementation modes:
有四种常见的传销实施模式：
aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one that makes no changes to the message itself as it redistributes; any modifications are constrained to changes to the [SMTP] envelope recipient list (RCPT commands) only. There are no changes to the message header or body at all, except for the addition of [MAIL] trace header fields. The output of such an MLM is considered to be a continuation of the Author's original message transit. An example of such an MLM is an address that
别名：别名传销（见[EMAIL-ARCH]第5.1节）是指在重新分发邮件时不对邮件本身进行更改的传销；任何修改仅限于对[SMTP]信封收件人列表（RCPT命令）的更改。除了添加了[MAIL]跟踪头字段外，消息头或正文完全没有任何更改。这种传销的输出被认为是作者原始信息传输的延续。这种传销的一个例子是
expands directly in the MTA, such as a list of local system administrators used for relaying operational or other internal-only messages. See also Section 3.9.2 of [SMTP].
直接在MTA中展开，例如用于中继操作消息或其他仅限内部消息的本地系统管理员列表。另见[SMTP]第3.9.2节。
resending: A resending MLM (see Sections 5.2 and 5.3 of [EMAIL-ARCH]) is one that may make changes to a message. The output of such an MLM is considered to be a new message; delivery of the original has been completed prior to distribution of the reposted message. Such messages are often reformatted, such as with list-specific header fields or other properties, to facilitate discussion among list subscribers.
重发：重发传销（见[EMAIL-ARCH]第5.2节和第5.3节）是一种可以对消息进行更改的传销。这种传销的输出被认为是新的消息；在分发重新发布的邮件之前，已完成原始邮件的传递。这类消息通常被重新格式化，例如使用特定于列表的头字段或其他属性，以便于列表订阅者之间的讨论。
authoring: An authoring MLM is one that creates the content being sent as well as initiating its transport, rather than basing it on one or more messages received earlier. This is not a "mediator" in terms of [EMAIL-ARCH] since it originates the message, but after creation, its message processing and posting behavior otherwise do match the MLM paradigm. Typically, replies are not generated, or if they are, they go to a specific recipient and not back to the list's full set of recipients. Examples include newsletters and bulk marketing mail.
创作：创作传销是创建正在发送的内容并启动其传输的传销，而不是基于先前收到的一条或多条消息。就[EMAIL-ARCH]而言，这不是一个“调解人”，因为它是邮件的始发者，但在创建之后，它的邮件处理和发布行为与传销模式并不匹配。通常情况下，不会生成回复，或者如果生成了回复，则回复将转到特定的收件人，而不会返回到列表的完整收件人集。示例包括时事通讯和批量营销邮件。
digesting: A special case of the resending MLM is one that sends a single message comprising an aggregation of recent MLM submissions, which might be a message of [MIME] type "multipart/ digest" (see [MIME-TYPES]). This is obviously a new message, but it may contain a sequence of original messages that may themselves have been DKIM-signed.
摘要：重发传销的一种特殊情况是发送一条包含最近传销提交的聚合的消息，该消息可能是[MIME]类型的“multipart/digest”（参见[MIME-TYPES]）。这显然是一条新消息，但它可能包含一系列原始消息，这些消息本身可能已经过DKIM签名。
In the remainder of this document, we distinguish two relevant steps corresponding to the following SMTP transactions:
在本文档的其余部分中，我们将区分与以下SMTP事务相对应的两个相关步骤：
MLM Input: Originating user is Author; originating ADMD is Originator and Signer; MLM's ADMD is Verifier; MLM's input function is Receiver.
传销输入：发起用户为作者；发起ADMD是发起人和签署人；传销的ADMD是验证者；传销的输入功能是接收器。
MLM Output: MLM (sending its reconstructed copy of the originating user's message) is Author; MLM's ADMD is Originator and Signer; the ADMD of each subscriber of the list is a Verifier; each subscriber is a Receiver.
MLM输出：MLM（发送原始用户消息的重构副本）是作者；传销的ADMD是发起人和签署人；列表的每个订户的ADMD是验证器；每个订户都是一个接收者。
Much of this document focuses on the resending class of MLM as it has the most direct conflict operationally with DKIM.
本文档的大部分内容集中在传销的重发类，因为它在操作上与DKIM有最直接的冲突。
The dissection of the overall MLM operation into these two distinct phases allows the DKIM-specific issues with respect to MLMs to be isolated and handled in a logical way. The main issue is that the repackaging and reposting of a message by an MLM is actually the
将整个传销业务分解为这两个不同的阶段，可以隔离并以逻辑方式处理与传销相关的DKIM特定问题。主要问题是，传销对邮件的重新打包和重新发布实际上是最重要的
construction of a completely new message, and as such, the MLM is introducing new content into the email ecosystem, consuming the Author's copy of the message, and creating its own. When considered in this way, the dual role of the MLM and its ADMD becomes clear.
构建一条全新的邮件，因此，传销正在将新内容引入电子邮件生态系统，使用作者的邮件副本，并创建自己的邮件。当以这种方式考虑时，传销及其广告传播的双重作用变得显而易见。
Some issues about these activities are discussed in Section 3.6.4 of [MAIL] and in Section 3.4.1 of [EMAIL-ARCH].
[MAIL]第3.6.4节和[EMAIL-ARCH]第3.4.1节讨论了与这些活动有关的一些问题。
As described above, an aliasing MLM does not affect any existing signature, and an authoring MLM is always creating new content; thus, there is never an existing signature. However, the changes a resending MLM typically makes affect the RFC5322.Subject header field, the addition of some list-specific header fields, and/or the modification of the message body. The effects of each of these on DKIM verification are discussed below.
如上所述，别名传销不影响任何现有签名，创作传销始终在创建新内容；因此，从来没有一个现有的签名。然而，重发传销通常所做的更改会影响RFC5322.Subject报头字段、某些列表特定报头字段的添加和/或消息正文的修改。以下讨论了每种方法对DKIM验证的影响。
Subject tags: A popular feature of MLMs is the "tagging" of an RFC5322.Subject field by prefixing the field's contents with the name of the list, such as "[example]" for a list called "example". Altering the RFC5322.Subject field on new submissions by adding a list-specific prefix or suffix will invalidate the Signer's signature if that header field was included in the hash when creating that signature. Section 5.5 of [DKIM] lists RFC5322.Subject as one that should be covered as it contains important user-visible text, so this is expected to be an issue for any list that makes such changes.
主题标记：MLMs的一个常见功能是通过在字段内容前加上列表名称来“标记”RFC5322.Subject字段，例如“示例”列表中的“[example]”。通过添加特定于列表的前缀或后缀来更改新提交的RFC5322.Subject字段，如果在创建签名时该头字段包含在哈希中，则签名人的签名将无效。[DKIM]第5.5节将RFC5322.主题列为应涵盖的主题，因为它包含重要的用户可见文本，因此这对于任何进行此类更改的列表来说都是一个问题。
List-specific header fields: Some lists will add header fields specific to list administrative functions such as those defined in [LIST-ID] and [LIST-URLS] or the "Resent-" fields defined in [MAIL]. It is unlikely that a typical MUA would include such fields in an original message, and DKIM is resilient to the addition of header fields in general (see notes about the "h=" tag in Section 3.5 of [DKIM]). Therefore, this is not seen as a concern.
列表特定的标题字段：一些列表将添加特定于列表管理功能的标题字段，如[List-ID]和[List-URL]中定义的标题字段或[MAIL]中定义的“Recent-”字段。典型的MUA不太可能在原始消息中包含这样的字段，而DKIM通常能够适应添加头字段（参见[DKIM]第3.5节中关于“h=”标记的注释）。因此，这不被视为一个问题。
Other header fields: Some lists will add or replace header fields such as "Reply-To" or "Sender" in order to establish that the message is being sent in the context of the mailing list, so that the list is identified ("Sender") and any user replies go to the list ("Reply-To"). If these fields were included in the original message, it is possible that one or more of them may have been included in the signature hash, and those signatures will thus be broken.
其他标题字段：一些列表将添加或替换标题字段，如“回复到”或“发件人”，以确定邮件是在邮件列表的上下文中发送的，以便识别列表（“发件人”），并将任何用户回复转到列表（“回复到”）。如果这些字段包含在原始消息中，则其中一个或多个字段可能已包含在签名哈希中，因此这些签名将被破坏。
Minor body changes: Some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, of list policy, etc. Changes to the body will alter the body hash computed at the DKIM Verifier, so these will render any existing signatures that cover those portions of the message body unverifiable. [DKIM] includes the capability to limit the length of the body covered by its body hash so that appended text will not interfere with signature validation, but this has security implications.
较小的正文更改：一些列表在每条消息前加上或附加几行，以提醒订阅者订阅问题的管理URL、列表策略等。对正文的更改将改变DKIM验证器计算的正文哈希，因此，这些将使覆盖消息体这些部分的任何现有签名无法验证。[DKIM]包括限制正文散列所覆盖正文长度的功能，以便附加的文本不会干扰签名验证，但这会带来安全隐患。
Major body changes: There are some MLMs that make more substantial changes to message bodies when preparing them for redistribution, such as adding, deleting, reordering, or reformatting [MIME] parts, "flattening" HTML messages into plain text, or inserting headers or footers within HTML messages. Most or all of these changes will invalidate a DKIM signature.
主要正文更改：有些MLM在准备重新分发消息正文时对其进行更大的更改，例如添加、删除、重新排序或重新格式化[MIME]部分，“将HTML消息展平为纯文本”，或在HTML消息中插入页眉或页脚。大多数或所有这些更改都将使DKIM签名无效。
MIME part removal: Some MLMs that are MIME-aware will remove large MIME parts from submissions and replace them with URLs to reduce the size of the distributed form of the message and to prevent inadvertent automated malware delivery. Except in some cases where a body length limit is applied in generation of the DKIM signature, the signature will be broken.
MIME部分删除：一些具有MIME意识的MLM将从提交中删除大型MIME部分，并将其替换为URL，以减小消息的分布式形式的大小，并防止意外的恶意软件自动传递。除非在生成DKIM签名时应用了正文长度限制，否则签名将被破坏。
There reportedly still exist some mailing lists in operation that are actually run manually by a human list manager, whose workings in preparing a message for distribution could include the above or even some other changes.
据报道，仍有一些正在运行的邮件列表实际上是由人工列表管理器手动运行的，其在准备分发邮件时的工作可能包括上述或甚至一些其他更改。
In general, absent a general movement by MLM developers and operators toward more DKIM-friendly practices, an MLM subscriber cannot expect signatures applied before the message was processed by the MLM to be valid on delivery to a Receiver. Such an evolution is not expected in the short term due to general development and deployment inertia. Moreover, even if an MLM currently passes messages unmodified such that Author signatures validate, it is possible that a configuration change or software upgrade to that MLM will cause that no longer to be true.
一般来说，由于传销开发商和运营商没有朝着更为DKIM友好的实践方向发展，传销订户不能期望在传销处理消息之前应用的签名在传递给接收者时有效。由于总体开发和部署惯性，短期内预计不会出现这种演变。此外，即使传销当前未经修改地传递消息，以使作者签名生效，也有可能对该传销进行配置更改或软件升级，从而导致该消息不再正确。
This section contains a discussion of issues regarding sending DKIM-signed mail to or through an MLM that is not DKIM-aware. Specifically, the header fields introduced by [DKIM] and [AUTH-RESULTS] carry no special meaning to such an MLM.
本节讨论了有关将DKIM签名邮件发送至或通过不知道DKIM的传销公司的问题。具体而言，[DKIM]和[AUTH-RESULTS]引入的标题字段对此类传销没有特殊意义。
In an idealized world, if an Author knows that the MLM to which a message is being sent is a non-participating resending MLM, the Author needs to be cautious when deciding whether or not to send a signed message to the list. The MLM could make a change that would invalidate the Author's signature but not remove it prior to redistribution. Hence, list recipients would receive a message purportedly from the Author but bearing a DKIM signature that would not verify. Some mail filtering software incorrectly penalizes a message containing a DKIM signature that fails verification. This may have detrimental effects outside of the Author's control. (Additional discussion of this is below.) This problem can be compounded if there are Receivers that apply signing policies (e.g., [ADSP]) and the Author publishes any kind of strict policy, i.e., a policy that requests that Receivers reject or otherwise deal severely with non-compliant messages.
在理想化的世界中，如果作者知道消息发送到的传销是非参与重发传销，那么作者在决定是否向列表发送签名消息时需要谨慎。传销可以做出改变，使作者的签名无效，但不能在重新分发之前删除。因此，列表收件人将收到据称来自作者的消息，但带有无法验证的DKIM签名。某些邮件过滤软件会错误地惩罚包含DKIM签名但未通过验证的邮件。这可能会产生作者无法控制的有害影响。（下文对这一问题进行了补充讨论。）如果有接收者应用签名策略（例如[ADSP]），并且作者发布了任何类型的严格策略，即要求接收者拒绝或以其他方式严重处理不符合要求的消息的策略，则此问题可能会变得更加复杂。
For domains that do publish strict ADSP policies, the originating site SHOULD use a separate message stream (see Section 2.5), such as a signing and Author subdomain, for the "personal" mail -- a subdomain that is different from domain(s) used for other mail streams. This allows each to develop an independent reputation, and more stringent policies (including ADSP) can be applied to the mail stream(s) that do not go through mailing lists or perhaps do not get signed at all.
对于发布严格ADSP策略的域，发起站点应为“个人”邮件使用单独的消息流（参见第2.5节），例如签名和作者子域，该子域不同于用于其他邮件流的域。这允许每个人建立独立的声誉，并且可以对不通过邮件列表或可能根本没有签名的邮件流应用更严格的策略（包括ADSP）。
However, all of this presupposes a level of infrastructure understanding that is not expected to be common. Thus, it will be incumbent upon site administrators to consider how support of users wishing to participate in mailing lists might be accomplished as DKIM achieves wider adoption.
然而，所有这些都需要对基础设施有一定程度的了解，而这种了解并不常见。因此，网站管理员将有责任考虑如何支持希望参与邮件列表的用户的支持，因为DKIM实现了更广泛的采用。
In general, the stricter practices and policies are likely to be successful only for the mail streams subject to the most end-to-end control by the originating organization. That typically excludes mail going through MLMs. Therefore, site administrators wishing to employ ADSP with a "discardable" setting SHOULD separate the controlled mail stream warranting this handling from other mail streams that are less controlled, such as personal mail that transits MLMs. (See also Section 5.7 below.)
一般来说，更严格的做法和策略可能只适用于受发起组织最端到端控制的邮件流。这通常不包括通过传销的邮件。因此，希望使用具有“可丢弃”设置的ADSP的站点管理员应将保证此处理的受控邮件流与控制较少的其他邮件流（例如传输传销的个人邮件）分开。（另见下文第5.7节。）
There is no reliable way to determine that a piece of mail arrived via a non-participating MLM. Sites whose users subscribe to non-participating MLMs SHOULD ensure that such user mail streams are not subject to strict DKIM-related handling policies.
没有可靠的方法确定邮件是通过非参与传销到达的。用户订阅非参与传销的网站应确保此类用户邮件流不受严格的DKIM相关处理策略的约束。
In order to exempt some mail from the expectation of signature verification, as discussed in Section 4.1, receiving ADMDs would need to register non-participating lists and confirm that mail transited them. However, such an approach requires excessive effort and even then is likely to be unreliable. Hence, it is not a scalable solution.
如第4.1节所述，为了使某些邮件免于进行签名验证，接收ADMD需要注册非参与名单，并确认邮件通过了这些名单。然而，这种方法需要付出过多的努力，即使这样也可能不可靠。因此，它不是一个可伸缩的解决方案。
Any treatment of a verification failure as having special meaning is a violation of the basic DKIM Signatures specification [DKIM]. The only valid, standardized basis for going beyond that specification is with specific ADSP direction.
任何将验证失败视为具有特殊意义的处理都违反了基本DKIM签名规范[DKIM]。超越该规范的唯一有效、标准化基础是特定的ADSP方向。
Use of restrictive domain policies such as [ADSP] "discardable" presents an additional challenge. In that case, when a message is unsigned or the signature can no longer be verified, discarding of the message is requested. There is no exception in the policy for a message that may have been altered by an MLM, nor is there a reliable way to identify such mail. Therefore, participants SHOULD honor the policy and disallow the message.
使用限制性域策略，如[ADSP]“可丢弃”带来了另一个挑战。在这种情况下，当消息未签名或签名无法再验证时，将请求丢弃消息。对于可能被传销更改的邮件，政策中没有例外，也没有可靠的方法来识别此类邮件。因此，参与者应遵守政策，不允许传递信息。
One approach for adding DKIM support to an otherwise non-participating MLM is to "wrap" the MLM or, in essence, place it between other DKIM-aware components (such as MTAs) that provide some DKIM services. For example, the ADMD operating a non-participating MLM could have its DKIM Verifier act on messages from list subscribers, enforcing some of the features and recommendations of Section 5 on behalf of the MLM, and the MTA or MSA receiving the MLM Output could also add a DKIM signature for the MLM's domain.
将DKIM支持添加到其他未参与传销的传销中的一种方法是“包装”传销，或者本质上，将其放置在提供某些DKIM服务的其他DKIM感知组件（如MTA）之间。例如，运营非参与传销的ADMD可以让其DKIM验证器处理来自列表订阅者的消息，代表传销实施第5节的一些功能和建议，接收传销输出的MTA或MSA也可以为传销的域添加DKIM签名。
This section contains a discussion of issues regarding DKIM-signed mail that transits an MLM that is DKIM-aware.
本节讨论有关DKIM签名邮件的问题，该邮件传输具有DKIM意识的传销。
Changes that merely add new header fields, such as those specified by [LIST-ID], [LIST-URLS], and [MAIL], are generally the most friendly to a DKIM-participating email infrastructure. Their addition by an MLM will not affect any existing DKIM signatures unless those fields were already present and covered by a signature's hash, or a signature was created specifically to disallow their addition (see the note about "h=" in Section 3.5 of [DKIM]).
仅添加新标题字段的更改，如[LIST-ID]、[LIST-URL]和[MAIL]指定的字段，通常对DKIM参与电子邮件基础结构最为友好。传销对其添加不会影响任何现有DKIM签名，除非这些字段已经存在并包含在签名的哈希中，或者专门创建了一个签名来禁止添加（请参见[DKIM]第3.5节中的“h=”注释）。
However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents any standards body might produce. This sort of change will invalidate the signature on a message where the body hash covers the entire message. Thus, the following sections also discuss and suggest other processing alternatives.
但是，将页眉和页脚应用于消息正文的做法很常见，无论任何标准正文可能生成什么文档，都不会褪色。这种更改将使正文哈希覆盖整个消息的消息上的签名无效。因此，以下各节还将讨论并建议其他处理方案。
A possible mitigation to this incompatibility is use of the "l=" tag to bound the portion of the body covered by the DKIM body hash, but this is not workable for [MIME] messages; moreover, it has security considerations (see Section 3.5 of [DKIM]). Therefore, its use is discouraged.
对这种不兼容性的一种可能的缓解方法是使用“l=”标记来绑定DKIM body散列所覆盖的正文部分，但这对于[MIME]消息是不可行的；此外，还考虑了安全因素（见[DKIM]第3.5节）。因此，不鼓励使用它。
Expressions of list-specific policy (e.g., rules for participation, small advertisements, etc.) are often added to outgoing messages by MLM operators. There is currently no header field proposed for relaying such general operational MLM details apart from what [LIST-URLS] already supports. This sort of information is commonly included footer text appended to the body of the message or header text prepended above the original body. It is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy. It is also RECOMMENDED that standard header fields, rather than body changes, be used to express list operation parameters. These periodic mailings will be repetitive, of course, but by being generally the same each time, they can be easily filtered if desired.
传销运营商通常会在发送的消息中添加特定于列表的策略（例如，参与规则、小广告等）。除了[LIST-URL]已经支持的内容外，目前还没有提议用于中继此类一般运营传销详细信息的标题字段。这类信息通常包括附加到消息正文的页脚文本或原始正文上方的页眉文本。建议定期向列表发送自动邮件，以提醒订阅者列表策略。还建议使用标准标题字段而不是正文更改来表示列表操作参数。当然，这些定期邮件将是重复的，但由于每次都是相同的，如果需要，它们可以很容易地被过滤。
ADSP presents a particular challenge. An Author domain posting a policy of "discardable" imposes a very tight restriction on the use of mailing lists, essentially constraining that domain's users to lists operated by aliasing MLMs only; any MLM that alters a message from such a domain or removes its signature subjects the message to severe action by Verifiers or Receivers. A resending MLM SHOULD reject outright any mail from an Author whose domain posts such a policy, as those messages are likely to be discarded or rejected by any ADSP-aware recipients. See also the discussion in Section 5.3.
ADSP提出了一个特殊的挑战。发布“可丢弃”策略的作者域对邮件列表的使用施加了非常严格的限制，本质上限制了该域的用户仅使用别名传销操作的列表；任何改变来自此类域的消息或删除其签名的传销都会使消息受到验证者或接收者的严厉行动。重发传销应完全拒绝来自其域发布此类策略的作者的任何邮件，因为这些邮件可能会被任何ADSP意识到的收件人丢弃或拒绝。另见第5.3节中的讨论。
Where such rejection of "discardable" mail is not enforced, and such mail arrives to a Verifier that applies ADSP checks that fail, the message SHOULD be either discarded (i.e., accept the message at the [SMTP] level but discard it without delivery) or rejected by returning a 5xx error code. In the latter case, some advice for how to conduct the rejection in a potentially meaningful way can be found in Section 5.11.
如果不强制拒绝“可丢弃”邮件，且该邮件到达应用ADSP检查失败的验证器，则应丢弃该邮件（即，在[SMTP]级别接受邮件，但在未送达的情况下丢弃该邮件），或通过返回5xx错误代码来拒绝该邮件。在后一种情况下，关于如何以潜在有意义的方式进行拒绝的一些建议可在第5.11节中找到。
The reason for these recommendations is best illustrated by example. Suppose the following:
这些建议的理由最好用例子来说明。假设如下：
o users U1 and U2 are subscribers of list L;
o 用户U1和U2是列表L的订户；
o U1 is within an ADMD that advertises a "discardable" policy using ADSP;
o U1位于使用ADSP发布“可丢弃”策略的ADMD内；
o L alters submissions prior to resending in a way that invalidates the DKIM signature added by U1's ADMD;
o L在重新发送之前更改提交内容，使U1的ADMD添加的DKIM签名无效；
o U2's ADMD enforces ADSP at the border by issuing an SMTP error code; and
o U2的ADMD通过发出SMTP错误代码在边界强制执行ADSP；和
o L is configured to remove subscribers whose mail is bouncing.
o L配置为删除邮件正在跳转的订阅者。
It follows then that a submission to L from U1 will be received at U2, but since the DKIM signature fails to verify, U2's ADMD will reject it based on the ADSP protocol. That rejection is received at L, which proceeds to remove U2 from the list.
随后U2将收到U1提交给L的文件，但由于DKIM签名无法验证，U2的ADMD将根据ADSP协议拒绝该文件。该拒绝在L接收，L继续从列表中删除U2。
See also Appendix B.5 of [ADSP] for further discussion.
进一步讨论请参见[ADSP]的附录B.5。
At subscription time, an ADSP-aware MLM SHOULD check for a published ADSP record for the new subscriber's domain. If the policy specifies "discardable", the MLM SHOULD disallow the subscription or present a warning that the subscriber's submissions to the mailing list might not be deliverable to some recipients because of the published policy of the subscriber's ADMD.
在订阅时，具有ADSP意识的传销商应检查新订户域的已发布ADSP记录。如果策略指定“可丢弃”，传销经理应禁止订阅或发出警告，指出由于订阅人的ADMD的已发布策略，订阅人向邮件列表提交的内容可能无法交付给某些收件人。
Of course, such a policy record could be created after subscription, so this is not a universal solution. An MLM implementation MAY do periodic checks of its subscribers and issue warnings where such a policy is detected or simply check upon each submission.
当然，这样的策略记录可以在订阅后创建，因此这不是一个通用的解决方案。传销实施可以定期检查其订阅者，并在检测到此类策略时发出警告，或者只是在每次提交时进行检查。
Where an ADMD has established some out-of-band trust agreement with another ADMD such that an Authentication-Results field applied by one is trusted by the other, the above recommendations for MLM operation with respect to ADSP do not apply because it is then possible to establish whether or not a valid Author signature can be inferred even if one is not present on receipt.
如果一个ADMD与另一个ADMD建立了带外信任协议，这样一个ADMD应用的身份验证结果字段就可以被另一个ADMD信任，上述关于ADSP传销业务的建议不适用，因为这样就可以确定是否可以推断出有效的作者签名，即使收到时没有签名。
For example, suppose domains example.com and example.net have an explicit agreement to trust one another's authentication assertions. Now, consider a message with an RFC5322.From domain of "example.org" that is also bearing a valid DKIM signature by the same domain, which arrives at a mailing list run by example.com. Upon evaluation, example.com validates the signature and adds an [AUTH-RESULTS] field indicating this. However, the MLM also makes changes to the message body that invalidate the signature. The MLM then re-signs the modified message using DKIM and sends it on to the list's subscribers, one of whom is at example.net.
例如，假设域example.com和example.net有一个明确的协议来信任彼此的身份验证断言。现在，考虑一个带有RCF5322的消息，从“示例.org”的域中，该域也承载同一域的有效DKIM签名，它到达由Excel。com运行的邮件列表。评估后，example.com将验证签名，并添加一个[AUTH-RESULTS]字段，表明这一点。但是，传销还对消息体进行更改，使签名无效。传销然后使用DKIM重新签署修改后的消息，并将其发送给列表的订阅者，其中一名订阅者位于example.net。
On arrival at example.net, the DKIM signature for example.org is no longer valid, so ADSP would generally fail. However, example.net trusts the assertion of example.com's Authentication-Results field that indicated that there was a valid signature from example.org, so the ADSP failure can be ignored.
到达example.net后，example.org的DKIM签名不再有效，因此ADSP通常会失败。但是，example.net信任example.com的Authentication Results字段的断言，该字段指示example.org中存在有效的签名，因此可以忽略ADSP失败。
An important consideration is that Authors rarely have any direct influence over the management of an MLM. Specifically, the behavior of an intermediary (e.g., an MLM that is not careful about filtering out junk mail or being diligent about unsubscription requests) can trigger recipient complaints that reflect back on those agents that appear to be responsible for the message, in this case an Author via the address found in the RFC5322.From field. In the future, as DKIM signature outputs (i.e., the signing domain) are used as inputs to reputation modules, there may be a desire to insulate one's reputation from influence by the unknown results of sending mail through an MLM. In that case, Authors SHOULD create a mail stream specifically used for generating DKIM signatures when sending traffic to MLMs.
一个重要的考虑是，作者很少对传销的管理有任何直接影响。具体而言，中间人的行为（例如，不小心过滤垃圾邮件的传销公司或对退订请求不闻不问的传销公司）可能会引发收件人投诉，反映似乎对邮件负责的代理，在这种情况下，作者通过RFC5322.发件人字段中的地址。未来，由于DKIM签名输出（即签名域）被用作声誉模块的输入，因此可能希望将个人声誉与通过传销发送邮件的未知结果隔离开来。在这种情况下，作者应该创建一个邮件流，专门用于在向MLM发送流量时生成DKIM签名。
This suggestion can be made more general. Mail that is of a transactional or generally end-to-end nature, and not likely to be forwarded around by either MLMs or users, SHOULD be signed with a mail stream identifier different from that used for a stream that serves more varied uses.
这个建议可以更笼统一些。具有事务性或通常为端到端性质且不可能被传销商或用户转发的邮件，应使用不同于服务于更多种用途的邮件流标识符的邮件流标识符进行签名。
MLMs typically attempt to authenticate messages posted through them. They usually do this through the trivial (and insecure) means of verifying the RFC5322.From field email address (or, less frequently, the RFC5321.MailFrom parameter) against a list subscription registry. DKIM enables a stronger form of authentication: the MLM can require that messages using a given RFC5322.From address also have a DKIM
传销管理系统通常尝试对通过传销发布的消息进行身份验证。他们通常通过简单（且不安全）的方法来验证列表订阅注册表中的RFC5322.From字段电子邮件地址（或RFC5321.MailFrom参数，频率较低）。DKIM支持一种更强大的身份验证形式：MLM可以要求使用给定RFC5322.From地址的消息也具有DKIM
signature with a corresponding "d=" domain. This feature would be somewhat similar to using ADSP, except that the requirement for it would be imposed by the MLM and not the Author's organization.
具有相应“d=”域的签名。这一特点与使用ADSP有些相似，只是要求它是由传销而不是作者的组织强加的。
(Note, however, that this goes beyond DKIM's documented semantics. It is presented as a possible workable enhancement.)
（然而，请注意，这超出了DKIM的文档语义。它是作为一种可能可行的增强提供的。）
As described, the MLM might conduct DKIM verification of a signed message to attempt to confirm the identity of the Author. Although it is a common and intuitive conclusion, few signed messages will include an Author signature (see [ADSP]). MLM implementers adding such support would have to accommodate this. For example, an MLM might be designed to accommodate a list of possible signing domains (the "d=" portion of a DKIM signature) for a given Author and determine at verification time if any of those are present. This enables a more reliable method of authentication at the expense of having to store a mapping of authorized signing domains for subscribers and trusting that it will be kept current.
如上所述，传销组织可能会对签名的消息进行DKIM验证，以尝试确认作者的身份。尽管这是一个常见且直观的结论，但很少有经过签名的消息会包含作者签名（请参见[ADSP]）。传销实施者添加这样的支持将不得不适应这一点。例如，传销可以设计为容纳给定作者的可能签名域列表（DKIM签名的“d=”部分），并在验证时确定其中是否存在。这可以实现更可靠的身份验证方法，但代价是必须为订阅者存储授权签名域的映射，并相信该映射将保持最新。
A message that cannot be thus authenticated MAY be held for moderation or rejected outright.
无法通过身份验证的消息可能会被保留以进行审核，也可能会被彻底拒绝。
This logic could apply to any list operation, not just list submission. In particular, this improved authentication MAY apply to subscription, unsubscription, and/or changes to subscriber options that are sent via email rather than through an authenticated, interactive channel such as the web.
这种逻辑可以应用于任何列表操作，而不仅仅是列表提交。特别地，这种改进的认证可应用于通过电子邮件而不是通过经认证的交互式渠道（如web）发送的订阅、取消订阅和/或对订户选项的更改。
In the case of verification of signatures on submissions, MLMs SHOULD add an [AUTH-RESULTS] header field to indicate the signature(s) observed on the submission as it arrived at the MLM and what the outcome of the evaluation was. Downstream agents might or might not trust the content of that header field depending on their own a priori knowledge of the operation of the ADMD generating (and, preferably, signing) that header field. See [AUTH-RESULTS] for further discussion.
在验证提交文件上的签名的情况下，传销经理应添加[AUTH-RESULTS]标题字段，以指示在提交文件到达传销经理时观察到的签名以及评估结果。下游代理可能信任也可能不信任该报头字段的内容，这取决于他们自己对生成（最好是签名）该报头字段的ADMD操作的先验知识。有关进一步的讨论，请参见[AUTH-RESULTS]。
A message that arrives signed with DKIM means some domain prior to MLM Input has made a claim of some responsibility for the message. An obvious benefit to leaving the input-side signatures intact, then, is to preserve that original assertion of responsibility for the message so that the Receivers of the final message have an opportunity to evaluate the message with that information available to them.
使用DKIM签名的消息到达意味着传销输入之前的某个域已声明对该消息负有某些责任。因此，保持输入端签名完好无损的一个明显好处是保留消息责任的原始断言，以便最终消息的接收者有机会使用可用信息评估消息。
However, if the MLM is configured to make changes to the message prior to reposting that would invalidate the original signature(s), further action is RECOMMENDED to prevent invalidated signatures from arriving at final recipients, possibly triggering unwarranted filter actions. (Note, however, that such filtering actions are plainly wrong; [DKIM] stipulates that an invalid signature is to be treated as no signature at all.)
但是，如果传销被配置为在重新发布之前对邮件进行更改，从而使原始签名无效，则建议采取进一步措施，以防止无效签名到达最终收件人，从而可能触发不必要的筛选操作。（但是，请注意，此类过滤操作显然是错误的；[DKIM]规定，无效签名将被视为完全没有签名。）
A possible solution would be to:
一个可能的解决办法是：
1. Attempt verification of all DKIM signatures present on the input message;
1. 尝试验证输入消息上存在的所有DKIM签名；
2. Apply local policy to authenticate the identity of the Author;
2. 应用本地策略来验证作者的身份；
3. Remove all existing [AUTH-RESULTS] fields (optional);
3. 删除所有现有的[AUTH-RESULTS]字段（可选）；
4. Add an [AUTH-RESULTS] header field to the message to indicate the results of the above;
4. 在消息中添加[AUTH-RESULTS]标题字段，以指示上述操作的结果；
5. Remove all previously evaluated DKIM signatures;
5. 删除所有先前评估过的DKIM签名；
6. Affix a new signature that includes in its hashes the entire message on the output side, including the Authentication-Results header field just added (see Section 5.8).
6. 附加一个新的签名，该签名在输出端的散列中包含整个消息，包括刚刚添加的身份验证结果标头字段（参见第5.8节）。
Removing the original signature(s) seems particularly appropriate when the MLM knows it is likely to invalidate any or all of them due to the nature of the reformatting it will do. This avoids false negatives for list subscribers in their roles as Receivers of the message; although [DKIM] stipulates that an invalid signature is the same as no signature, it is anticipated that there will be some implementations that ignore this advice.
删除原始签名似乎特别合适，因为传销知道，由于重新格式化的性质，可能会使任何或所有签名无效。这避免了列表订阅者作为消息接收者的角色出现误报；尽管[DKIM]规定无效签名与无签名相同，但预计会有一些实现忽略此建议。
The MLM could re-evaluate existing signatures after making its message changes to determine whether or not any of them have been invalidated. The cost of this is reduced by the fact that, presumably, the necessary public keys have already been downloaded and one or both of the message hashes could be reused.
传销公司可以在更改消息后重新评估现有签名，以确定其中是否有任何签名已失效。这样做的成本降低了，因为可能已经下载了必要的公钥，并且可以重用一个或两个消息哈希。
Per the discussion in [AUTH-RESULTS], a Receiver's choice to put any faith in the veracity of the header field requires an a priori assessment of the agent that created it. Absent that assessment, a Receiver cannot interpret the field as valid. Thus, the final recipients of the message have no way to verify on their own the authenticity of the Author's identity on that message. However, if that field is the only one on the message when the Verifier gets it, and the Verifier explicitly trusts the Signer that included the
根据[AUTH-RESULTS]中的讨论，接收者选择信任头字段的准确性需要对创建它的代理进行先验评估。如果没有这种评估，接收者无法将字段解释为有效。因此，邮件的最终收件人无法自行验证该邮件上作者身份的真实性。但是，如果当验证器获取该字段时，该字段是消息上的唯一字段，并且验证器明确信任包含该字段的签名者
Authentication-Results field in its header hash (in this case, the MLM), the Verifier is in a position to believe that a valid Author signature was present on the message.
在其头散列（在本例中为MLM）中的Authentication Results字段中，验证器能够相信消息上存在有效的作者签名。
This can be generalized as follows: a Receiver SHOULD consider only [AUTH-RESULTS] fields bearing an authserv-id that appears in a list of sites the Receiver trusts and that is also included in the header hash of a [DKIM] signature added by a domain in the same trusted list.
这可以概括如下：接收者应该只考虑[ Auth-Reals]字段，该字段承载在接收方信任的站点列表中出现的AuthServ ID，并且也包含在由相同信任列表中的域添加的[dim]签名的标题散列中。
Since an aliasing MLM makes no substantive changes to a message, it need not consider the issue of signature removal as the original signatures should at least arrive to the next MTA unmodified. It is possible that future domain-based reputations would prefer a richer data set on receipt of a message, and, in that case, signature removal would be undesirable.
由于混叠的MLM对消息没有实质性的改变，所以它不需要考虑签名移除的问题，因为原始签名至少应该到达下一个MTA未修改的位置。未来基于域的声誉可能会希望在收到消息时使用更丰富的数据集，在这种情况下，删除签名是不可取的。
An authoring MLM is closed to outside submitters; thus, much of this discussion does not apply in that case.
创作传销对外部提交者关闭；因此，这种讨论的大部分内容并不适用于这种情况。
DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own signatures when distributing messages. The MLM is responsible for the alterations it makes to the original messages it is resending and should express this via a signature. This is also helpful for getting feedback from any FBLs that might be set up so that undesired list mail can generate appropriate action.
DKIM感知的重发传销和创作传销应在分发邮件时附上自己的签名。传销经理负责对其重新发送的原始信息进行更改，并应通过签名表示。这也有助于从可能设置的任何FBL获取反馈，以便不需要的列表邮件可以生成适当的操作。
MLM signatures will likely be used by recipient systems to recognize list mail, and they give the MLM's ADMD an opportunity to develop a good reputation for the list itself.
传销签名很可能会被收件人系统用来识别名单邮件，它们给传销的ADMD提供了一个为名单本身建立良好声誉的机会。
A signing MLM, as any other MLM, is free to omit redistribution of a message if that message was not signed in accordance with its own local configuration or policy. It could also redistribute but not sign such mail. However, selective signing is NOT RECOMMENDED; essentially that would create two message streams from the MLM, one signed and one not, which can confuse DKIM-aware Verifiers and Receivers.
签名传销和任何其他传销一样，如果消息未按照其自身的本地配置或策略进行签名，则可以自由忽略消息的重新分发。它还可以重新分发但不签署此类邮件。但是，不建议选择性签名；从本质上说，这将从传销中创建两个消息流，一个是有签名的，另一个是无签名的，这可能会混淆DKIM感知的验证器和接收者。
A signing MLM could add a List-Post: header field (see [LIST-URLS]) using the DNS domain matching the one used in the "d=" tag of the DKIM signature that is added by the MLM. This can be used by Verifiers or Receivers to identify the DKIM signature that was added by the MLM. This is not required, however; it is believed the
签名传销可以使用与传销添加的DKIM签名的“d=”标记中使用的DNS域相匹配的DNS域添加列表Post:header字段（请参见[List-URL]）。这可以被验证者或接收者用来识别传销添加的DKIM签名。然而，这不是必需的；据信
reputation of the Signer will be a more critical data point than this suggested binding. Furthermore, this is not a binding recognized by any current specification document.
签名者的信誉将是比建议的绑定更关键的数据点。此外，这不是任何当前规范文档都认可的绑定。
A DKIM-aware resending MLM SHOULD sign the entire message after the message is prepared for distribution (i.e., the MLM Output from Section 3.2). Any other configuration might generate signatures that will not validate.
DKIM感知重发传销应在消息准备分发（即第3.2节传销输出）后对整个消息进行签名。任何其他配置都可能生成无法验证的签名。
DKIM-aware authoring MLMs sign the mail they send according to the regular signing guidelines given in [DKIM].
支持DKIM的创作传销商根据[DKIM]中给出的常规签名准则对其发送的邮件进行签名。
One concern is that having an MLM apply its signature to unsigned mail might cause some Verifiers or Receivers to interpret the signature as conferring more authority or authenticity to the message content than is defined by [DKIM]. This is an issue beyond MLMs and primarily entails receive-side processing outside of the scope of [DKIM]. It is, nevertheless, worth noting here.
一个担忧是，传销商将其签名应用于未签名邮件可能会导致一些验证者或接收者将签名解释为赋予消息内容比[DKIM]定义的更大的权限或真实性。这是MLM之外的问题，主要涉及[DKIM]范围之外的接收端处理。然而，在这里值得注意。
In general, Verifiers and Receivers SHOULD treat a signed message from an MLM like any other signed message; indeed, it would be difficult to discern any difference since specifications such as [LIST-URLS] and [LIST-ID] are not universally deployed and can be trivially spoofed.
一般来说，验证者和接收者应该像对待任何其他签名消息一样对待来自传销的签名消息；事实上，由于[LIST-URL]和[LIST-ID]等规范并不是普遍部署的，而且可能会被欺骗，因此很难区分任何差异。
However, because the Author domain will commonly be different from the MLM's signing domain, there may be a conflict with [ADSP] as discussed in Sections 4.3 and 5.7, especially where an ADMD has misused ADSP.
但是，由于作者域通常不同于传销的签名域，因此可能与第4.3节和第5.7节中讨论的[ADSP]存在冲突，特别是当ADMD滥用ADSP时。
An FBL operator might wish to act on a complaint from a user about a message sent to a list. Some FBLs could choose to generate feedback reports based on DKIM verifications in the subject message. Such operators SHOULD send a report to each domain with a valid signature that has an FBL agreement established, as DKIM signatures are claims of some responsibility for that message. Because Authors generally have limited control over the operation of a list, this point makes MLM signing all the more important.
FBL操作员可能希望对用户关于发送到列表的消息的投诉采取行动。一些FBL可以选择根据主题消息中的DKIM验证生成反馈报告。此类运营商应向每个域发送一份报告，报告中应包含已建立FBL协议的有效签名，因为DKIM签名声称对该消息负有一定责任。由于作者通常对列表的操作控制有限，这一点使得传销签名变得更加重要。
MLM operators SHOULD register with FBLs from major service providers. In the context of DKIM, there SHOULD be an exchange of information with the FBL provider including what signing domain the MLM will use, if any.
传销运营商应向主要服务提供商的FBL注册。在DKIM的情况下，应与FBL提供商交换信息，包括传销将使用的签名域（如有）。
Where the FBL wishes to be more specific, it MAY act solely on a DKIM signature where the signing domain matches the DNS domain found in a List-Post: header field (or similar).
如果FBL希望更具体，它可以仅对DKIM签名进行操作，其中签名域与列表Post:头字段（或类似字段）中的DNS域匹配。
Use of FBLs in this way SHOULD be made explicit to list subscribers. For example, if it is the policy of the MLM's ADMD to handle an FBL item by unsubscribing the user that was the apparent sender of the offending message, advising subscribers of this in advance would help to avoid surprises later.
以这种方式使用FBL应明确列出订阅者。例如，如果传销广告部的政策是通过取消订阅显然是违规消息发送者的用户来处理FBL项目，那么提前通知订阅者将有助于避免以后的意外。
A DKIM-signed message sent to an MLM, and then distributed to all of a list's recipients, could result in a complaint from one of the final recipients for some reason. This could be an actual complaint from some subscriber that finds the message abusive or otherwise undesirable, or it could be an automated complaint such as Receiver detection of an invalidated DKIM signature or some other condition. It could also be a complaint that results from antagonistic behavior, such as is common when a subscriber to a list is having trouble unsubscribing and then begins issuing complaints about all submissions to the list. This would result in a complaint being generated in the context of an FBL report back to the message Author. However, the original Author has no involvement in operation of the MLM itself, meaning the FBL report is not actionable and is thus undesirable.
DKIM签名邮件发送给传销，然后分发给列表的所有收件人，可能会导致最终收件人之一出于某种原因提出投诉。这可能是一些订阅者发现消息滥用或不受欢迎的实际投诉，也可能是自动投诉，如接收器检测到无效的DKIM签名或其他情况。它也可能是由敌对行为引起的投诉，例如当列表的订阅者在取消订阅时遇到问题，然后开始对列表的所有提交内容发出投诉时，这种情况很常见。这将导致在FBL报告的上下文中生成投诉，并返回给消息作者。然而，原作者没有参与传销本身的运作，这意味着FBL的报告是不可起诉的，因此是不可取的。
A recipient that explicitly trusts signatures from a particular MLM MAY wish to extend that trust to an [AUTH-RESULTS] header field signed by that MLM. The recipient MAY then do additional processing of the message, using the results recorded in the Authentication-Results header field instead of the original Author's DKIM signature. This includes possibly processing the message as per ADSP requirements.
明确信任特定传销签名的收件人可能希望将该信任扩展到该传销签名的[AUTH-RESULTS]头字段。然后，收件人可以使用“身份验证结果”标题字段中记录的结果（而不是原始作者的DKIM签名）对邮件进行附加处理。这可能包括按照ADSP要求处理消息。
Receivers SHOULD ignore or remove all unsigned externally applied Authentication-Results header fields and those not signed by an ADMD that can be trusted by the Receiver. See Sections 5 and 7 of [AUTH-RESULTS] for further discussion.
接收方应忽略或删除所有未签名的外部应用身份验证结果标头字段，以及那些未经接收方可信任的ADMD签名的字段。有关进一步的讨论，请参见[AUTH-RESULTS]的第5节和第7节。
Upon DKIM and ADSP evaluation during an SMTP session (a common implementation), an agent MAY decide to reject a message during an SMTP session. If this is done, [SMTP] stipulates that 550 is the correct response code. However, if the SMTP server supports [ENHANCED] status codes, a status code not normally used for "user unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be used. If the rejecting SMTP server supports this, it thus makes a distinction between messages rejected deliberately due to policy
在SMTP会话（一种常见的实现）期间对DKIM和ADSP进行评估后，代理可能会决定在SMTP会话期间拒绝邮件。如果这样做，[SMTP]规定550是正确的响应代码。但是，如果SMTP服务器支持[增强型]状态代码，则首选通常不用于“用户未知”（5.1.1）的状态代码；因此，应使用5.7.0代码。如果拒绝SMTP服务器支持这一点，那么它将区分由于策略而故意拒绝的邮件
decisions rather than those rejected because of other delivery issues. In particular, a policy rejection SHOULD be relayed using the above enhanced status code and some appropriate wording in the text part of the reply. Those MLMs that automatically attempt to remove users with prolonged delivery problems (such as account deletion) SHOULD thus detect the difference between policy rejection and other delivery failures and act accordingly. It would also be beneficial for SMTP servers doing so to use appropriate wording in the text portion of the reply, perhaps explicitly using the string "ADSP" to facilitate searching for relevant data in logs.
决定，而不是因为其他交付问题而被拒绝的决定。特别是，应使用上述增强的状态代码和回复文本部分中的一些适当措辞传达保单拒绝。因此，自动尝试删除存在长期交付问题（如帐户删除）的用户的传销应检测策略拒绝和其他交付失败之间的差异，并采取相应的行动。对于SMTP服务器来说，在回复的文本部分使用适当的措辞也是有益的，可能会显式地使用字符串“ADSP”以便于在日志中搜索相关数据。
The preceding paragraph does not apply to an [ADSP] policy of "discardable". In such cases where the submission fails that test, the Receiver or Verifier SHOULD discard the message but return an SMTP success code, i.e., accept the message but drop it without delivery. An SMTP rejection of such mail instead of the requested discard action causes more harm than good.
前款不适用于“可放弃”的[ADSP]保单。在提交未通过该测试的情况下，接收方或验证者应丢弃邮件，但返回SMTP成功代码，即接受邮件，但在未送达的情况下丢弃邮件。SMTP拒绝此类邮件而不是请求的放弃操作会造成弊大于利。
As mechanisms become available for reporting forensic details about DKIM verification failures, MLMs will benefit from their use.
随着报告DKIM验证失败的法医细节的机制变得可用，传销管理系统将从中受益。
MLMs SHOULD apply DKIM failure-reporting mechanisms as a method for providing feedback to Signers about issues with DKIM infrastructure. This is especially important for MLMs that implement DKIM verification as a mechanism for authentication of list configuration commands and submissions from subscribers.
MLMs应采用DKIM故障报告机制，作为向签名者提供DKIM基础设施问题反馈的方法。这对于实现DKIM验证的MLM尤其重要，因为DKIM验证是对列表配置命令和来自订阅者的提交进行身份验证的机制。
This document provides suggested or best current practices for use with DKIM and, as such, does not introduce any new technologies for consideration. However, the following security issues should be considered when implementing the practices described in this document.
本文件提供了与DKIM一起使用的建议或最佳当前实践，因此不引入任何新技术供考虑。但是，在实施本文档中描述的实践时，应考虑以下安全问题。
Readers should be familiar with the material in the "Security Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as appropriate.
读者应熟悉[DKIM]、[ADSP]和[AUTH-RESULTS]中“安全注意事项”部分的内容（视情况而定）。
Section 5 advocates addition of an [AUTH-RESULTS] header field to indicate authentication status of a message received as MLM Input. Per Section 7.2 of [AUTH-RESULTS], Receivers generally should not trust such data without a good reason to do so, such as an a priori agreement with the MLM's ADMD.
第5节主张添加[AUTH-RESULTS]头字段，以指示作为传销输入接收的消息的身份验证状态。根据[AUTH-RESULTS]第7.2节，如果没有充分的理由，例如事先与传销公司的ADMD达成协议，接收者通常不应信任此类数据。
Such agreements are strongly advised to include a requirement that those header fields be covered by a [DKIM] signature added by the MLM's ADMD.
强烈建议此类协议包含一项要求，即这些标题字段必须由传销ADMD添加的[DKIM]签名覆盖。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[ADSP]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[AUTH-RESULTS]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 54512009年4月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[ARF]Shafranovich，Y.，Levine，J.，和M.Kucherawy，“电子邮件反馈报告的可扩展格式”，RFC 59652010年8月。
[DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
[DKIM-DEPLOYMENT]Hansen，T.，Siegel，E.，Hallam Baker，P.，和D.Crocker，“域密钥识别邮件（DKIM）开发、部署和运营”，RFC 58632010年5月。
[DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[DKIM-概述]Hansen，T.，Crocker，D.，和P.Hallam Baker，“域密钥识别邮件（DKIM）服务概述”，RFC 55852009年7月。
[ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[ENHANCED]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，2003年1月。
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[IODEF]Danyliw，R.，Meijer，J.，和Y.Demchenko，“事件对象描述交换格式”，RFC 50702007年12月。
[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[LIST-ID]Chandhok，R.和G.Wenger，“列表ID：用于识别邮件列表的结构化字段和名称空间”，RFC 2919，2001年3月。
[LIST-URLS] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[LIST-URL]Neufeld，G.和J.Baer，“URL作为核心邮件列表命令的元语法的使用及其通过消息头字段的传输”，RFC 2369，1998年7月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME-TYPES]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
The author wishes to acknowledge the following individuals for their review and constructive criticism of this document: Serge Aumont, Daniel Black, Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and Alessandro Vesely.
作者希望感谢以下个人对本文件的审查和建设性批评：谢尔盖·奥蒙特、丹尼尔·布莱克、戴夫·克罗克、J.D.福尔克、托尼·汉森、艾略特·李尔、查尔斯·林赛、约翰·莱文、杰夫·麦克唐纳、S.穆内萨米、罗尔夫·E.索内维尔德和亚历山德罗·维斯利。
This section describes a few MLM-related DKIM scenarios that were part of the impetus for this work and the recommended resolutions for each.
本节描述了一些与传销相关的DKIM场景，这些场景是推动这项工作的一部分，并为每种场景推荐了解决方案。
Problem:
问题:
o Author ADMD advertises an ADSP policy of "dkim=discardable"
o 作者ADMD宣传“dkim=discardable”的ADSP策略
o Author sends DKIM-signed mail to a non-participating MLM, which invalidates the signature
o 作者将DKIM签名邮件发送给未参与传销的传销，从而使签名无效
o Receiver MTA checks DKIM and ADSP at SMTP time and is configured to reject ADSP failures, so rejects this message
o 接收方MTA在SMTP时间检查DKIM和ADSP，并配置为拒绝ADSP故障，因此拒绝此邮件
o process repeats a few times, after which the MLM unsubscribes the Receiver
o 该过程重复几次，之后传销取消对接收者的订阅
Solution: MLMs should refuse mail from domains advertising ADSP policies of "discardable" unless the MLMs are certain they make no changes that invalidate DKIM signatures.
解决方案：传销商应该拒绝来自广告ADSP策略为“可丢弃”的域的邮件，除非传销商确定他们没有做出使DKIM签名无效的更改。
Problem:
问题:
o subscriber sends signed mail to a non-participating MLM that does not invalidate the signature
o 订阅者将签名邮件发送给未参与传销的传销，该传销不会使签名无效
o a recipient reports the message as spam
o 收件人将邮件报告为垃圾邮件
o FBL at recipient ADMD sends report to contributor rather than list manager
o 收件人ADMD处的FBL将报告发送给贡献者而不是列表管理器
Solution: MLMs should sign mail they send and might also strip existing signatures. FBLs should report to list operators instead of subscribers where such can be distinguished; otherwise, FBLs should report to all parties with valid signatures.
解决方案：传销商应该对他们发送的邮件进行签名，并且可能会删除现有的签名。FBL应向名单运营商报告，而不是向可以区分的订阅者报告；否则，FBL应以有效签名向所有各方报告。
Author's Address
作者地址
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA
Murray S. Kucherawy CuldM标记128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
Phone: +1 415 946 3800
EMail: msk@cloudmark.com