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 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). 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. 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. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Kucherawy Best Current Practice [Page 1] RFC 6377 DKIM and Mailing Lists September 2011 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 Kucherawy Best Current Practice [Page 2] RFC 6377 DKIM and Mailing Lists September 2011 1. Introduction 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. 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: o Under what circumstances is it advisable for an Author, or its organization, to apply DKIM to mail sent to mailing lists? o What are the trade-offs regarding having an MLM verify and use DKIM identifiers? o What are the trade-offs regarding having an MLM remove existing DKIM signatures prior to reposting the message? o What are the trade-offs regarding having an MLM add its own DKIM signature? 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. 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. 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.) Kucherawy Best Current Practice [Page 3] RFC 6377 DKIM and Mailing Lists September 2011 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. 1.1. Background 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. 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. 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. 1.2. MLMs in Infrastructure 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. Kucherawy Best Current Practice [Page 4] RFC 6377 DKIM and Mailing Lists September 2011 Section 3.3 describes some of the things MLMs commonly do that produce broken signatures, thus reducing the perceived value of 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. 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. 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. 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. 1.3. Feedback Loops and Other Bilateral Agreements 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. 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. See Section 6 for additional discussion. FBLs tend to use the [ARF] or the [IODEF] formats. Kucherawy Best Current Practice [Page 5] RFC 6377 DKIM and Mailing Lists September 2011 1.4. Document Scope and Goals 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. 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. 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. 2. Definitions 2.1. Key Words 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]. 2.2. Messaging Terms See [EMAIL-ARCH] for a general description of the current messaging architecture and for definitions of various terms used in this document. 2.3. DKIM-Specific References 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. Kucherawy Best Current Practice [Page 6] RFC 6377 DKIM and Mailing Lists September 2011 2.4. 'DKIM-Friendly' 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. 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. 2.5. Message Streams 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. 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). 3. Mailing Lists and DKIM 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. 3.1. Roles and Realities 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. 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). Kucherawy Best Current Practice [Page 7] RFC 6377 DKIM and Mailing Lists September 2011 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). 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. 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. 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). 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. 3.2. Types of Mailing Lists 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 Kucherawy Best Current Practice [Page 8] RFC 6377 DKIM and Mailing Lists September 2011 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]. 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. 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. 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. In the remainder of this document, we distinguish two relevant steps corresponding to the following SMTP transactions: MLM Input: Originating user is Author; originating ADMD is Originator and Signer; MLM's ADMD is Verifier; MLM's input function is Receiver. 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. Much of this document focuses on the resending class of MLM as it has the most direct conflict operationally with 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 Kucherawy Best Current Practice [Page 9] RFC 6377 DKIM and Mailing Lists September 2011 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]. 3.3. Current MLM Effects on Signatures 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. 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. 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. 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. Kucherawy Best Current Practice [Page 10] RFC 6377 DKIM and Mailing Lists September 2011 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. 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. 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. 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. 4. Non-Participating MLMs 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. Kucherawy Best Current Practice [Page 11] RFC 6377 DKIM and Mailing Lists September 2011 4.1. Author-Related Signing 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. 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. 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. 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.) 4.2. Verification Outcomes at Receivers 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. Kucherawy Best Current Practice [Page 12] RFC 6377 DKIM and Mailing Lists September 2011 4.3. Handling Choices at Receivers 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. 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. 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. 4.4. Wrapping a Non-Participating MLM 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. 5. Participating MLMs This section contains a discussion of issues regarding DKIM-signed mail that transits an MLM that is DKIM-aware. 5.1. General Changes that merely add new header fields, such as those specified by