diff options
Diffstat (limited to 'doc/rfc/rfc6377.txt')
| -rw-r--r-- | doc/rfc/rfc6377.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc6377.txt b/doc/rfc/rfc6377.txt new file mode 100644 index 0000000..da91e17 --- /dev/null +++ b/doc/rfc/rfc6377.txt @@ -0,0 +1,1459 @@ + + + + + + +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 + [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]). + + + + +Kucherawy Best Current Practice [Page 13] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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. + + 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. + +5.2. DKIM Author Domain Signing Practices + + 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. + + 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. + + + + + +Kucherawy Best Current Practice [Page 14] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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 is within an ADMD that advertises a "discardable" policy using + ADSP; + + o L alters submissions prior to resending in a way that invalidates + the DKIM signature added by U1's ADMD; + + o U2's ADMD enforces ADSP at the border by issuing an SMTP error + code; and + + o L is configured to remove subscribers whose mail is bouncing. + + 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. + + See also Appendix B.5 of [ADSP] for further discussion. + +5.3. Subscriptions + + 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. + + 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. + +5.4. Exceptions to ADSP Recommendations + + 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. + + + + + + +Kucherawy Best Current Practice [Page 15] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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. + + 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. + +5.5. Author-Related Signing + + 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. + + 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. + +5.6. Verification Outcomes at MLMs + + 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 + + + + +Kucherawy Best Current Practice [Page 16] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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. + + (Note, however, that this goes beyond DKIM's documented semantics. + It is presented as a possible workable enhancement.) + + 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. + + 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. + + 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. + +5.7. Signature Removal Issues + + 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. + + + + + +Kucherawy Best Current Practice [Page 17] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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.) + + A possible solution would be to: + + 1. Attempt verification of all DKIM signatures present on the input + message; + + 2. Apply local policy to authenticate the identity of the Author; + + 3. Remove all existing [AUTH-RESULTS] fields (optional); + + 4. Add an [AUTH-RESULTS] header field to the message to indicate the + results of the above; + + 5. Remove all previously evaluated DKIM signatures; + + 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). + + 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. + + 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 + + + +Kucherawy Best Current Practice [Page 18] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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. + + 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. + + 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. + + An authoring MLM is closed to outside submitters; thus, much of this + discussion does not apply in that case. + +5.8. MLM Signatures + + 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. + + 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. + + 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. + + 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 + + + + + +Kucherawy Best Current Practice [Page 19] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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-aware authoring MLMs sign the mail they send according to the + regular signing guidelines given in [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. + +5.9. Verification Outcomes at Final Receiving Sites + + 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. + + 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. + +5.10. Use with FBLs + + 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. + + 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. + + + + +Kucherawy Best Current Practice [Page 20] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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). + + 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. + + 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. + +5.11. Handling Choices at Receivers + + 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. + + 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. + + 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 + + + +Kucherawy Best Current Practice [Page 21] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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. + + 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. + +6. DKIM Reporting + + As mechanisms become available for reporting forensic details about + DKIM verification failures, MLMs will benefit from their use. + + 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. + +7. Security Considerations + + 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. + +7.1. Security Considerations from DKIM and ADSP + + Readers should be familiar with the material in the "Security + Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as + appropriate. + + + + + + + + + +Kucherawy Best Current Practice [Page 22] + +RFC 6377 DKIM and Mailing Lists September 2011 + + +7.2. Authentication Results When Relaying + + 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. + + 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. + +8. References + +8.1. Normative References + + [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, + "DomainKeys Identified Mail (DKIM) Author Domain Signing + Practices (ADSP)", RFC 5617, August 2009. + + [AUTH-RESULTS] + Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 5451, April 2009. + + [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, + September 2011. + + [EMAIL-ARCH] + Crocker, D., "Internet Mail Architecture", RFC 5598, + July 2009. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + +8.2. Informative References + + [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An + Extensible Format for Email Feedback Reports", RFC 5965, + August 2010. + + [DKIM-DEPLOYMENT] + Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, + "DomainKeys Identified Mail (DKIM) Development, + Deployment, and Operations", RFC 5863, May 2010. + + + +Kucherawy Best Current Practice [Page 23] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + [DKIM-OVERVIEW] + Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys + Identified Mail (DKIM) Service Overview", RFC 5585, + July 2009. + + [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", + RFC 3463, January 2003. + + [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident + Object Description Exchange Format", RFC 5070, + December 2007. + + [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-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. + + [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [MIME-TYPES] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + + + + + + + + + + + + + + + + + + +Kucherawy Best Current Practice [Page 24] + +RFC 6377 DKIM and Mailing Lists September 2011 + + +Appendix A. Acknowledgements + + 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. + +Appendix B. Example Scenarios + + This section describes a few MLM-related DKIM scenarios that were + part of the impetus for this work and the recommended resolutions for + each. + +B.1. MLMs and ADSP + + Problem: + + o Author ADMD advertises an ADSP policy of "dkim=discardable" + + o Author sends DKIM-signed mail to a non-participating MLM, which + invalidates the signature + + o Receiver MTA checks DKIM and ADSP at SMTP time and is configured + to reject ADSP failures, so rejects this message + + o process repeats a few times, after which the MLM unsubscribes the + Receiver + + 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. + +B.2. MLMs and FBLs + + Problem: + + o subscriber sends signed mail to a non-participating MLM that does + not invalidate the signature + + o a recipient reports the message as spam + + o FBL at recipient ADMD sends report to contributor rather than list + manager + + + + + + + +Kucherawy Best Current Practice [Page 25] + +RFC 6377 DKIM and Mailing Lists September 2011 + + + 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. + +Author's Address + + Murray S. Kucherawy + Cloudmark + 128 King St., 2nd Floor + San Francisco, CA 94107 + USA + + Phone: +1 415 946 3800 + EMail: msk@cloudmark.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Best Current Practice [Page 26] + |