7Internet Engineering Task Force (IETF) M. Kucherawy
8Request for Comments: 6377 Cloudmark
10Category: Best Current Practice
14 DomainKeys Identified Mail (DKIM) and Mailing Lists
18 DomainKeys Identified Mail (DKIM) allows an ADministrative Management
19 Domain (ADMD) to assume some responsibility for a message. Based on
20 deployment experience with DKIM, this document provides guidance for
21 the use of DKIM with scenarios that include Mailing List Managers
26 This memo documents an Internet Best Current Practice.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 BCPs is available in Section 2 of RFC 5741.
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc6377.
40 Copyright (c) 2011 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
58Kucherawy Best Current Practice [Page 1]
60RFC 6377 DKIM and Mailing Lists September 2011
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
67 1.2. MLMs in Infrastructure . . . . . . . . . . . . . . . . . . 4
68 1.3. Feedback Loops and Other Bilateral Agreements . . . . . . 5
69 1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6
70 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
72 2.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 6
73 2.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 6
74 2.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7
75 2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
76 3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 7
77 3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 7
78 3.2. Types of Mailing Lists . . . . . . . . . . . . . . . . . . 8
79 3.3. Current MLM Effects on Signatures . . . . . . . . . . . . 10
80 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
81 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12
82 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 12
83 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13
84 4.4. Wrapping a Non-Participating MLM . . . . . . . . . . . . . 13
85 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
86 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
87 5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14
88 5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15
89 5.4. Exceptions to ADSP Recommendations . . . . . . . . . . . . 15
90 5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 16
91 5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16
92 5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 17
93 5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19
94 5.9. Verification Outcomes at Final Receiving Sites . . . . . . 20
95 5.10. Use with FBLs . . . . . . . . . . . . . . . . . . . . . . 20
96 5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 21
97 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
99 7.1. Security Considerations from DKIM and ADSP . . . . . . . . 22
100 7.2. Authentication Results When Relaying . . . . . . . . . . . 23
101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
102 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
103 8.2. Informative References . . . . . . . . . . . . . . . . . . 23
104 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
105 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 25
106 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 25
107 B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 25
114Kucherawy Best Current Practice [Page 2]
116RFC 6377 DKIM and Mailing Lists September 2011
121 DomainKeys Identified Mail [DKIM] allows an ADministrative Management
122 Domain (ADMD) to take some responsibility for a [MAIL] message. Such
123 responsibility can be taken by an Author's organization, an
124 operational relay (Mail Transfer Agent, or MTA), or one of their
125 agents. Assertion of responsibility is made through a cryptographic
126 signature. Message transit from Author to recipient is through
127 relays that typically make no substantive change to the message
128 content and thus preserve the validity of the DKIM signature.
130 In contrast to relays, there are intermediaries, such as Mailing List
131 Managers (MLMs), that actively take delivery of messages, reformat
132 them, and repost them, often invalidating DKIM signatures. The goal
133 for this document is to explore the use of DKIM for scenarios that
134 include intermediaries and recommend best current practices based on
135 acquired experience. Questions that will be discussed include:
137 o Under what circumstances is it advisable for an Author, or its
138 organization, to apply DKIM to mail sent to mailing lists?
140 o What are the trade-offs regarding having an MLM verify and use
143 o What are the trade-offs regarding having an MLM remove existing
144 DKIM signatures prior to reposting the message?
146 o What are the trade-offs regarding having an MLM add its own DKIM
149 These are open questions for which there may be no definitive
150 answers. However, based on experience since the publication of the
151 original version of [DKIM] and its gradual deployment, there are some
152 views that are useful to consider and some recommended procedures.
154 In general, there are two categories of MLMs in relation to DKIM:
155 participating and non-participating. As each type has its own issues
156 regarding DKIM-signed messages that are either handled or produced by
157 them (or both), the types are discussed in separate sections.
159 The best general recommendation for dealing with MLMs is that the MLM
160 or an MTA in the MLM's domain apply its own DKIM signature to each
161 message it forwards and that assessors on the receiving end consider
162 the MLM's domain signature in making their assessments. (See
163 Section 5, especially Section 5.2.)
170Kucherawy Best Current Practice [Page 3]
172RFC 6377 DKIM and Mailing Lists September 2011
175 With the understanding that this is not always possible or practical
176 and the consideration that it might not always be sufficient, this
177 document provides additional guidance.
181 DKIM signatures permit an agent of the email architecture (see
182 [EMAIL-ARCH]) to make a claim of responsibility for a message by
183 affixing a validated domain-level identifier to the message as it
184 passes through a relay. Although not the only possibility, this is
185 most commonly done as a message passes through a boundary Mail
186 Transport Agent (MTA) as it departs an ADministrative Management
187 Domain (ADMD) across the open Internet.
189 A DKIM signature will fail to verify if a portion of the message
190 covered by one of its hashes is altered. An MLM commonly alters
191 messages to provide information specific to the mailing list for
192 which it is providing service. Common modifications are enumerated
193 and described in Section 3.3. However, note that MLMs vary widely in
194 behavior and often allow subscribers to select individual behaviors.
195 Further, the MTA might make changes that are independent of those
198 The DKIM Signatures specification [DKIM] deliberately rejects the
199 notion of tying the signing domain (the "d=" tag in a DKIM signature)
200 to any other identifier within a message; any ADMD that handles a
201 message could sign it, regardless of its origin or Author domain. In
202 particular, DKIM does not define any meaning to the occurrence of a
203 match between the content of a "d=" tag and the value of, for
204 example, a domain name in the RFC5322.From field, nor is there any
205 obvious degraded value to a signature where they do not match. Since
206 any DKIM signature is merely an assertion of "some" responsibility by
207 an ADMD, a DKIM signature added by an MLM has no more or less meaning
208 than a signature with any other "d=" value.
2101.2. MLMs in Infrastructure
212 An MLM is an autonomous agent that takes delivery of a message and
213 can repost it as a new message or construct a digest of it along with
214 other messages to the members of the list (see [EMAIL-ARCH], Section
215 5.3). However, the fact that the RFC5322.From field of such a
216 message (in the non-digest case) is typically the same as that of the
217 original message, and that recipients perceive the message as "from"
218 the original Author rather than the MLM, creates confusion about
219 responsibility and autonomy for the reposted message. This has
220 important implications for the use of DKIM.
226Kucherawy Best Current Practice [Page 4]
228RFC 6377 DKIM and Mailing Lists September 2011
231 Section 3.3 describes some of the things MLMs commonly do that
232 produce broken signatures, thus reducing the perceived value of DKIM.
234 Further, while there are published standards that are specific to MLM
235 behavior (e.g., [MAIL], [LIST-ID], and [LIST-URLS]), their adoption
236 has been spotty at best. Hence, efforts to specify the use of DKIM
237 in the context of MLMs need to be incremental and value-based.
239 Some MLM behaviors are well-established and their effects on DKIM
240 signature validity can be argued as frustrating wider DKIM adoption.
241 Still, those behaviors are not standards violations. Hence, this
242 memo specifies practices for all parties involved, defining the
243 minimum changes possible to MLMs themselves.
245 A DKIM signature on a message is an expression of some responsibility
246 for the message taken by the signing domain. An open issue that is
247 addressed by this document is the ways a signature might be used by a
248 recipient's evaluation module, after the message has gone through a
249 mailing list and might or might not have been rendered invalid. The
250 document also considers how invalidation might have happened.
252 Note that where in this document there is discussion of an MLM
253 conducting validation of DKIM signatures or Author Domain Signing
254 Practices ([ADSP]) policies, the actual implementation could be one
255 where the validation is done by the MTA or an agent attached to it,
256 and the results of that work are relayed by a trusted channel not
257 specified here. See [AUTH-RESULTS] for a discussion of this. This
258 document does not favor any particular arrangement of these agents
259 over another; it merely talks about the MLM itself doing the work as
260 a matter of simplicity.
2621.3. Feedback Loops and Other Bilateral Agreements
264 A Feedback Loop (FBL) is a bilateral agreement between two parties to
265 exchange reports of abuse. Typically, a sender registers with a
266 receiving site to receive abuse reports from that site for mail
267 coming from the sender.
269 An FBL reporting address (i.e., an address to which FBL reports are
270 sent) is part of this bilateral registration. Some FBLs require DKIM
271 use by the registrant.
273 See Section 6 for additional discussion.
275 FBLs tend to use the [ARF] or the [IODEF] formats.
282Kucherawy Best Current Practice [Page 5]
284RFC 6377 DKIM and Mailing Lists September 2011
2871.4. Document Scope and Goals
289 This document provides discussion on the above issues to improve the
290 handling of possible interactions between DKIM and MLMs. In general,
291 the preference is to impose changes to behavior at the Signer and
292 Verifier rather than at the MLM.
294 Wherever possible, the document's discussion of MLMs is conceptually
295 decoupled from MTAs despite the very tight integration that is
296 sometimes observed in implementation. This is done to emphasize the
297 functional independence of MLM services and responsibilities from
300 Parts of this document explore possible changes to common practice by
301 Signers, Verifiers, and MLMs. The suggested enhancements are largely
302 predictive in nature, taking into account the current email
303 infrastructure, the facilities DKIM can provide as it gains wider
304 deployment, and working group consensus. There is no substantial
305 implementation history upon which these suggestions are based, and
306 their efficacy, performance, and security characteristics have not
307 yet been fully explored.
313 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
314 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
315 "OPTIONAL" in this document are to be interpreted as described in
320 See [EMAIL-ARCH] for a general description of the current messaging
321 architecture and for definitions of various terms used in this
3242.3. DKIM-Specific References
326 Readers are encouraged to become familiar with [DKIM] and [ADSP],
327 which are core specification documents, as well as [DKIM-OVERVIEW]
328 and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents.
338Kucherawy Best Current Practice [Page 6]
340RFC 6377 DKIM and Mailing Lists September 2011
345 The term "DKIM-friendly" is used to describe an email intermediary
346 that, when handling a message, makes no changes to the message that
347 cause valid [DKIM] signatures present on the message on input to fail
350 Various features of MTAs and MLMs seen as helpful to users often have
351 side effects that do render DKIM signatures unverifiable. These
352 would not qualify for this label.
356 A "message stream" identifies a group of messages originating from
357 within an ADMD that are distinct in intent, origin, and/or use and
358 partitions them somehow (e.g., via changing the value in the "d=" tag
359 value in the context of DKIM) so as to keep them associated to users
360 yet distinct in terms of their evaluation and handling by Verifiers
363 A good example might be user mail generated by a company's employees,
364 versus operational or transactional mail that comes from automated
365 sources or marketing or sales campaigns. Each of these could have
366 different sending policies imposed against them, or there might be a
367 desire to insulate one from the other (e.g., a marketing campaign
368 that gets reported by many spam filters could cause the marketing
369 stream's reputation to degrade without automatically punishing the
370 transactional or user streams).
3723. Mailing Lists and DKIM
374 It is important to make some distinctions among different styles of
375 intermediaries, their typical implementations, and the effects they
376 have in a DKIM-aware environment.
3783.1. Roles and Realities
380 Across DKIM activities, there are several key roles in the transit of
381 a message. Most of these are defined in [EMAIL-ARCH] but are
382 reviewed here for quick reference.
384 Author: The agent that provided the content of the message being
385 sent through the system. The Author delivers that content to the
386 Originator in order to begin a message's journey to its intended
387 final recipients. The Author can be a human using an MUA (Mail
388 User Agent) or an automated process that may send mail (for
389 example, the "cron" Unix system utility).
394Kucherawy Best Current Practice [Page 7]
396RFC 6377 DKIM and Mailing Lists September 2011
399 Originator: The agent that accepts a message from the Author,
400 ensures it conforms to the relevant standards such as [MAIL], and
401 then sends it toward its destination(s). This is often referred
402 to as the Mail Submission Agent (MSA).
404 Signer: Any agent that affixes one or more DKIM signature(s) to a
405 message on its way toward its ultimate destination. There is
406 typically a Signer running at the MTA that sits between the
407 Author's ADMD and the general Internet. The Originator and/or
408 Author might also be a Signer.
410 Verifier: Any agent that conducts DKIM signature validation. One is
411 typically running at the MTA that sits between the public Internet
412 and the Receiver's ADMD. Note that any agent that handles a
413 signed message can conduct verification; this document only
414 considers that action and its outcomes either at an MLM or at the
415 Receiver. Filtering decisions could be made by this agent based
416 on verification results.
418 Receiver: The agent that is the final transit relay for the message
419 and performs final delivery to the recipient(s) of the message.
420 Filtering decisions based on results made by the Verifier could be
421 applied by the Receiver. The Verifier and the Receiver could be
422 the same agent. This is sometimes the same as or coupled with the
423 Mail Delivery Agent (MDA).
425 In the case of simple user-to-user mail, these roles are fairly
426 straightforward. However, when one is sending mail to a list and the
427 mail then gets relayed to all of that list's subscribers, the roles
428 are often less clear to the general user as particular agents may
429 hold multiple important but separable roles. The above definitions
430 are intended to enable more precise discussion of the mechanisms
4333.2. Types of Mailing Lists
435 There are four common MLM implementation modes:
437 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
438 that makes no changes to the message itself as it redistributes;
439 any modifications are constrained to changes to the [SMTP]
440 envelope recipient list (RCPT commands) only. There are no
441 changes to the message header or body at all, except for the
442 addition of [MAIL] trace header fields. The output of such an MLM
443 is considered to be a continuation of the Author's original
444 message transit. An example of such an MLM is an address that
450Kucherawy Best Current Practice [Page 8]
452RFC 6377 DKIM and Mailing Lists September 2011
455 expands directly in the MTA, such as a list of local system
456 administrators used for relaying operational or other internal-
457 only messages. See also Section 3.9.2 of [SMTP].
459 resending: A resending MLM (see Sections 5.2 and 5.3 of
460 [EMAIL-ARCH]) is one that may make changes to a message. The
461 output of such an MLM is considered to be a new message; delivery
462 of the original has been completed prior to distribution of the
463 reposted message. Such messages are often reformatted, such as
464 with list-specific header fields or other properties, to
465 facilitate discussion among list subscribers.
467 authoring: An authoring MLM is one that creates the content being
468 sent as well as initiating its transport, rather than basing it on
469 one or more messages received earlier. This is not a "mediator"
470 in terms of [EMAIL-ARCH] since it originates the message, but
471 after creation, its message processing and posting behavior
472 otherwise do match the MLM paradigm. Typically, replies are not
473 generated, or if they are, they go to a specific recipient and not
474 back to the list's full set of recipients. Examples include
475 newsletters and bulk marketing mail.
477 digesting: A special case of the resending MLM is one that sends a
478 single message comprising an aggregation of recent MLM
479 submissions, which might be a message of [MIME] type "multipart/
480 digest" (see [MIME-TYPES]). This is obviously a new message, but
481 it may contain a sequence of original messages that may themselves
482 have been DKIM-signed.
484 In the remainder of this document, we distinguish two relevant steps
485 corresponding to the following SMTP transactions:
487 MLM Input: Originating user is Author; originating ADMD is
488 Originator and Signer; MLM's ADMD is Verifier; MLM's input
489 function is Receiver.
491 MLM Output: MLM (sending its reconstructed copy of the originating
492 user's message) is Author; MLM's ADMD is Originator and Signer;
493 the ADMD of each subscriber of the list is a Verifier; each
494 subscriber is a Receiver.
496 Much of this document focuses on the resending class of MLM as it has
497 the most direct conflict operationally with DKIM.
499 The dissection of the overall MLM operation into these two distinct
500 phases allows the DKIM-specific issues with respect to MLMs to be
501 isolated and handled in a logical way. The main issue is that the
502 repackaging and reposting of a message by an MLM is actually the
506Kucherawy Best Current Practice [Page 9]
508RFC 6377 DKIM and Mailing Lists September 2011
511 construction of a completely new message, and as such, the MLM is
512 introducing new content into the email ecosystem, consuming the
513 Author's copy of the message, and creating its own. When considered
514 in this way, the dual role of the MLM and its ADMD becomes clear.
516 Some issues about these activities are discussed in Section 3.6.4 of
517 [MAIL] and in Section 3.4.1 of [EMAIL-ARCH].
5193.3. Current MLM Effects on Signatures
521 As described above, an aliasing MLM does not affect any existing
522 signature, and an authoring MLM is always creating new content; thus,
523 there is never an existing signature. However, the changes a
524 resending MLM typically makes affect the RFC5322.Subject header
525 field, the addition of some list-specific header fields, and/or the
526 modification of the message body. The effects of each of these on
527 DKIM verification are discussed below.
529 Subject tags: A popular feature of MLMs is the "tagging" of an
530 RFC5322.Subject field by prefixing the field's contents with the
531 name of the list, such as "[example]" for a list called "example".
532 Altering the RFC5322.Subject field on new submissions by adding a
533 list-specific prefix or suffix will invalidate the Signer's
534 signature if that header field was included in the hash when
535 creating that signature. Section 5.5 of [DKIM] lists
536 RFC5322.Subject as one that should be covered as it contains
537 important user-visible text, so this is expected to be an issue
538 for any list that makes such changes.
540 List-specific header fields: Some lists will add header fields
541 specific to list administrative functions such as those defined in
542 [LIST-ID] and [LIST-URLS] or the "Resent-" fields defined in
543 [MAIL]. It is unlikely that a typical MUA would include such
544 fields in an original message, and DKIM is resilient to the
545 addition of header fields in general (see notes about the "h=" tag
546 in Section 3.5 of [DKIM]). Therefore, this is not seen as a
549 Other header fields: Some lists will add or replace header fields
550 such as "Reply-To" or "Sender" in order to establish that the
551 message is being sent in the context of the mailing list, so that
552 the list is identified ("Sender") and any user replies go to the
553 list ("Reply-To"). If these fields were included in the original
554 message, it is possible that one or more of them may have been
555 included in the signature hash, and those signatures will thus be
562Kucherawy Best Current Practice [Page 10]
564RFC 6377 DKIM and Mailing Lists September 2011
567 Minor body changes: Some lists prepend or append a few lines to each
568 message to remind subscribers of an administrative URL for
569 subscription issues, of list policy, etc. Changes to the body
570 will alter the body hash computed at the DKIM Verifier, so these
571 will render any existing signatures that cover those portions of
572 the message body unverifiable. [DKIM] includes the capability to
573 limit the length of the body covered by its body hash so that
574 appended text will not interfere with signature validation, but
575 this has security implications.
577 Major body changes: There are some MLMs that make more substantial
578 changes to message bodies when preparing them for redistribution,
579 such as adding, deleting, reordering, or reformatting [MIME]
580 parts, "flattening" HTML messages into plain text, or inserting
581 headers or footers within HTML messages. Most or all of these
582 changes will invalidate a DKIM signature.
584 MIME part removal: Some MLMs that are MIME-aware will remove large
585 MIME parts from submissions and replace them with URLs to reduce
586 the size of the distributed form of the message and to prevent
587 inadvertent automated malware delivery. Except in some cases
588 where a body length limit is applied in generation of the DKIM
589 signature, the signature will be broken.
591 There reportedly still exist some mailing lists in operation that are
592 actually run manually by a human list manager, whose workings in
593 preparing a message for distribution could include the above or even
596 In general, absent a general movement by MLM developers and operators
597 toward more DKIM-friendly practices, an MLM subscriber cannot expect
598 signatures applied before the message was processed by the MLM to be
599 valid on delivery to a Receiver. Such an evolution is not expected
600 in the short term due to general development and deployment inertia.
601 Moreover, even if an MLM currently passes messages unmodified such
602 that Author signatures validate, it is possible that a configuration
603 change or software upgrade to that MLM will cause that no longer to
6064. Non-Participating MLMs
608 This section contains a discussion of issues regarding sending DKIM-
609 signed mail to or through an MLM that is not DKIM-aware.
610 Specifically, the header fields introduced by [DKIM] and
611 [AUTH-RESULTS] carry no special meaning to such an MLM.
618Kucherawy Best Current Practice [Page 11]
620RFC 6377 DKIM and Mailing Lists September 2011
6234.1. Author-Related Signing
625 In an idealized world, if an Author knows that the MLM to which a
626 message is being sent is a non-participating resending MLM, the
627 Author needs to be cautious when deciding whether or not to send a
628 signed message to the list. The MLM could make a change that would
629 invalidate the Author's signature but not remove it prior to
630 redistribution. Hence, list recipients would receive a message
631 purportedly from the Author but bearing a DKIM signature that would
632 not verify. Some mail filtering software incorrectly penalizes a
633 message containing a DKIM signature that fails verification. This
634 may have detrimental effects outside of the Author's control.
635 (Additional discussion of this is below.) This problem can be
636 compounded if there are Receivers that apply signing policies (e.g.,
637 [ADSP]) and the Author publishes any kind of strict policy, i.e., a
638 policy that requests that Receivers reject or otherwise deal severely
639 with non-compliant messages.
641 For domains that do publish strict ADSP policies, the originating
642 site SHOULD use a separate message stream (see Section 2.5), such as
643 a signing and Author subdomain, for the "personal" mail -- a
644 subdomain that is different from domain(s) used for other mail
645 streams. This allows each to develop an independent reputation, and
646 more stringent policies (including ADSP) can be applied to the mail
647 stream(s) that do not go through mailing lists or perhaps do not get
650 However, all of this presupposes a level of infrastructure
651 understanding that is not expected to be common. Thus, it will be
652 incumbent upon site administrators to consider how support of users
653 wishing to participate in mailing lists might be accomplished as DKIM
654 achieves wider adoption.
656 In general, the stricter practices and policies are likely to be
657 successful only for the mail streams subject to the most end-to-end
658 control by the originating organization. That typically excludes
659 mail going through MLMs. Therefore, site administrators wishing to
660 employ ADSP with a "discardable" setting SHOULD separate the
661 controlled mail stream warranting this handling from other mail
662 streams that are less controlled, such as personal mail that transits
663 MLMs. (See also Section 5.7 below.)
6654.2. Verification Outcomes at Receivers
667 There is no reliable way to determine that a piece of mail arrived
668 via a non-participating MLM. Sites whose users subscribe to non-
669 participating MLMs SHOULD ensure that such user mail streams are not
670 subject to strict DKIM-related handling policies.
674Kucherawy Best Current Practice [Page 12]
676RFC 6377 DKIM and Mailing Lists September 2011
6794.3. Handling Choices at Receivers
681 In order to exempt some mail from the expectation of signature
682 verification, as discussed in Section 4.1, receiving ADMDs would need
683 to register non-participating lists and confirm that mail transited
684 them. However, such an approach requires excessive effort and even
685 then is likely to be unreliable. Hence, it is not a scalable
688 Any treatment of a verification failure as having special meaning is
689 a violation of the basic DKIM Signatures specification [DKIM]. The
690 only valid, standardized basis for going beyond that specification is
691 with specific ADSP direction.
693 Use of restrictive domain policies such as [ADSP] "discardable"
694 presents an additional challenge. In that case, when a message is
695 unsigned or the signature can no longer be verified, discarding of
696 the message is requested. There is no exception in the policy for a
697 message that may have been altered by an MLM, nor is there a reliable
698 way to identify such mail. Therefore, participants SHOULD honor the
699 policy and disallow the message.
7014.4. Wrapping a Non-Participating MLM
703 One approach for adding DKIM support to an otherwise non-
704 participating MLM is to "wrap" the MLM or, in essence, place it
705 between other DKIM-aware components (such as MTAs) that provide some
706 DKIM services. For example, the ADMD operating a non-participating
707 MLM could have its DKIM Verifier act on messages from list
708 subscribers, enforcing some of the features and recommendations of
709 Section 5 on behalf of the MLM, and the MTA or MSA receiving the MLM
710 Output could also add a DKIM signature for the MLM's domain.
714 This section contains a discussion of issues regarding DKIM-signed
715 mail that transits an MLM that is DKIM-aware.
719 Changes that merely add new header fields, such as those specified by
720 [LIST-ID], [LIST-URLS], and [MAIL], are generally the most friendly
721 to a DKIM-participating email infrastructure. Their addition by an
722 MLM will not affect any existing DKIM signatures unless those fields
723 were already present and covered by a signature's hash, or a
724 signature was created specifically to disallow their addition (see
725 the note about "h=" in Section 3.5 of [DKIM]).
730Kucherawy Best Current Practice [Page 13]
732RFC 6377 DKIM and Mailing Lists September 2011
735 However, the practice of applying headers and footers to message
736 bodies is common and not expected to fade regardless of what
737 documents any standards body might produce. This sort of change will
738 invalidate the signature on a message where the body hash covers the
739 entire message. Thus, the following sections also discuss and
740 suggest other processing alternatives.
742 A possible mitigation to this incompatibility is use of the "l=" tag
743 to bound the portion of the body covered by the DKIM body hash, but
744 this is not workable for [MIME] messages; moreover, it has security
745 considerations (see Section 3.5 of [DKIM]). Therefore, its use is
748 Expressions of list-specific policy (e.g., rules for participation,
749 small advertisements, etc.) are often added to outgoing messages by
750 MLM operators. There is currently no header field proposed for
751 relaying such general operational MLM details apart from what
752 [LIST-URLS] already supports. This sort of information is commonly
753 included footer text appended to the body of the message or header
754 text prepended above the original body. It is RECOMMENDED that
755 periodic, automatic mailings to the list are sent to remind
756 subscribers of list policy. It is also RECOMMENDED that standard
757 header fields, rather than body changes, be used to express list
758 operation parameters. These periodic mailings will be repetitive, of
759 course, but by being generally the same each time, they can be easily
7625.2. DKIM Author Domain Signing Practices
764 ADSP presents a particular challenge. An Author domain posting a
765 policy of "discardable" imposes a very tight restriction on the use
766 of mailing lists, essentially constraining that domain's users to
767 lists operated by aliasing MLMs only; any MLM that alters a message
768 from such a domain or removes its signature subjects the message to
769 severe action by Verifiers or Receivers. A resending MLM SHOULD
770 reject outright any mail from an Author whose domain posts such a
771 policy, as those messages are likely to be discarded or rejected by
772 any ADSP-aware recipients. See also the discussion in Section 5.3.
774 Where such rejection of "discardable" mail is not enforced, and such
775 mail arrives to a Verifier that applies ADSP checks that fail, the
776 message SHOULD be either discarded (i.e., accept the message at the
777 [SMTP] level but discard it without delivery) or rejected by
778 returning a 5xx error code. In the latter case, some advice for how
779 to conduct the rejection in a potentially meaningful way can be found
786Kucherawy Best Current Practice [Page 14]
788RFC 6377 DKIM and Mailing Lists September 2011
791 The reason for these recommendations is best illustrated by example.
792 Suppose the following:
794 o users U1 and U2 are subscribers of list L;
796 o U1 is within an ADMD that advertises a "discardable" policy using
799 o L alters submissions prior to resending in a way that invalidates
800 the DKIM signature added by U1's ADMD;
802 o U2's ADMD enforces ADSP at the border by issuing an SMTP error
805 o L is configured to remove subscribers whose mail is bouncing.
807 It follows then that a submission to L from U1 will be received at
808 U2, but since the DKIM signature fails to verify, U2's ADMD will
809 reject it based on the ADSP protocol. That rejection is received at
810 L, which proceeds to remove U2 from the list.
812 See also Appendix B.5 of [ADSP] for further discussion.
816 At subscription time, an ADSP-aware MLM SHOULD check for a published
817 ADSP record for the new subscriber's domain. If the policy specifies
818 "discardable", the MLM SHOULD disallow the subscription or present a
819 warning that the subscriber's submissions to the mailing list might
820 not be deliverable to some recipients because of the published policy
821 of the subscriber's ADMD.
823 Of course, such a policy record could be created after subscription,
824 so this is not a universal solution. An MLM implementation MAY do
825 periodic checks of its subscribers and issue warnings where such a
826 policy is detected or simply check upon each submission.
8285.4. Exceptions to ADSP Recommendations
830 Where an ADMD has established some out-of-band trust agreement with
831 another ADMD such that an Authentication-Results field applied by one
832 is trusted by the other, the above recommendations for MLM operation
833 with respect to ADSP do not apply because it is then possible to
834 establish whether or not a valid Author signature can be inferred
835 even if one is not present on receipt.
842Kucherawy Best Current Practice [Page 15]
844RFC 6377 DKIM and Mailing Lists September 2011
847 For example, suppose domains example.com and example.net have an
848 explicit agreement to trust one another's authentication assertions.
849 Now, consider a message with an RFC5322.From domain of "example.org"
850 that is also bearing a valid DKIM signature by the same domain, which
851 arrives at a mailing list run by example.com. Upon evaluation,
852 example.com validates the signature and adds an [AUTH-RESULTS] field
853 indicating this. However, the MLM also makes changes to the message
854 body that invalidate the signature. The MLM then re-signs the
855 modified message using DKIM and sends it on to the list's
856 subscribers, one of whom is at example.net.
858 On arrival at example.net, the DKIM signature for example.org is no
859 longer valid, so ADSP would generally fail. However, example.net
860 trusts the assertion of example.com's Authentication-Results field
861 that indicated that there was a valid signature from example.org, so
862 the ADSP failure can be ignored.
8645.5. Author-Related Signing
866 An important consideration is that Authors rarely have any direct
867 influence over the management of an MLM. Specifically, the behavior
868 of an intermediary (e.g., an MLM that is not careful about filtering
869 out junk mail or being diligent about unsubscription requests) can
870 trigger recipient complaints that reflect back on those agents that
871 appear to be responsible for the message, in this case an Author via
872 the address found in the RFC5322.From field. In the future, as DKIM
873 signature outputs (i.e., the signing domain) are used as inputs to
874 reputation modules, there may be a desire to insulate one's
875 reputation from influence by the unknown results of sending mail
876 through an MLM. In that case, Authors SHOULD create a mail stream
877 specifically used for generating DKIM signatures when sending traffic
880 This suggestion can be made more general. Mail that is of a
881 transactional or generally end-to-end nature, and not likely to be
882 forwarded around by either MLMs or users, SHOULD be signed with a
883 mail stream identifier different from that used for a stream that
884 serves more varied uses.
8865.6. Verification Outcomes at MLMs
888 MLMs typically attempt to authenticate messages posted through them.
889 They usually do this through the trivial (and insecure) means of
890 verifying the RFC5322.From field email address (or, less frequently,
891 the RFC5321.MailFrom parameter) against a list subscription registry.
892 DKIM enables a stronger form of authentication: the MLM can require
893 that messages using a given RFC5322.From address also have a DKIM
898Kucherawy Best Current Practice [Page 16]
900RFC 6377 DKIM and Mailing Lists September 2011
903 signature with a corresponding "d=" domain. This feature would be
904 somewhat similar to using ADSP, except that the requirement for it
905 would be imposed by the MLM and not the Author's organization.
907 (Note, however, that this goes beyond DKIM's documented semantics.
908 It is presented as a possible workable enhancement.)
910 As described, the MLM might conduct DKIM verification of a signed
911 message to attempt to confirm the identity of the Author. Although
912 it is a common and intuitive conclusion, few signed messages will
913 include an Author signature (see [ADSP]). MLM implementers adding
914 such support would have to accommodate this. For example, an MLM
915 might be designed to accommodate a list of possible signing domains
916 (the "d=" portion of a DKIM signature) for a given Author and
917 determine at verification time if any of those are present. This
918 enables a more reliable method of authentication at the expense of
919 having to store a mapping of authorized signing domains for
920 subscribers and trusting that it will be kept current.
922 A message that cannot be thus authenticated MAY be held for
923 moderation or rejected outright.
925 This logic could apply to any list operation, not just list
926 submission. In particular, this improved authentication MAY apply to
927 subscription, unsubscription, and/or changes to subscriber options
928 that are sent via email rather than through an authenticated,
929 interactive channel such as the web.
931 In the case of verification of signatures on submissions, MLMs SHOULD
932 add an [AUTH-RESULTS] header field to indicate the signature(s)
933 observed on the submission as it arrived at the MLM and what the
934 outcome of the evaluation was. Downstream agents might or might not
935 trust the content of that header field depending on their own a
936 priori knowledge of the operation of the ADMD generating (and,
937 preferably, signing) that header field. See [AUTH-RESULTS] for
9405.7. Signature Removal Issues
942 A message that arrives signed with DKIM means some domain prior to
943 MLM Input has made a claim of some responsibility for the message.
944 An obvious benefit to leaving the input-side signatures intact, then,
945 is to preserve that original assertion of responsibility for the
946 message so that the Receivers of the final message have an
947 opportunity to evaluate the message with that information available
954Kucherawy Best Current Practice [Page 17]
956RFC 6377 DKIM and Mailing Lists September 2011
959 However, if the MLM is configured to make changes to the message
960 prior to reposting that would invalidate the original signature(s),
961 further action is RECOMMENDED to prevent invalidated signatures from
962 arriving at final recipients, possibly triggering unwarranted filter
963 actions. (Note, however, that such filtering actions are plainly
964 wrong; [DKIM] stipulates that an invalid signature is to be treated
965 as no signature at all.)
967 A possible solution would be to:
969 1. Attempt verification of all DKIM signatures present on the input
972 2. Apply local policy to authenticate the identity of the Author;
974 3. Remove all existing [AUTH-RESULTS] fields (optional);
976 4. Add an [AUTH-RESULTS] header field to the message to indicate the
977 results of the above;
979 5. Remove all previously evaluated DKIM signatures;
981 6. Affix a new signature that includes in its hashes the entire
982 message on the output side, including the Authentication-Results
983 header field just added (see Section 5.8).
985 Removing the original signature(s) seems particularly appropriate
986 when the MLM knows it is likely to invalidate any or all of them due
987 to the nature of the reformatting it will do. This avoids false
988 negatives for list subscribers in their roles as Receivers of the
989 message; although [DKIM] stipulates that an invalid signature is the
990 same as no signature, it is anticipated that there will be some
991 implementations that ignore this advice.
993 The MLM could re-evaluate existing signatures after making its
994 message changes to determine whether or not any of them have been
995 invalidated. The cost of this is reduced by the fact that,
996 presumably, the necessary public keys have already been downloaded
997 and one or both of the message hashes could be reused.
999 Per the discussion in [AUTH-RESULTS], a Receiver's choice to put any
1000 faith in the veracity of the header field requires an a priori
1001 assessment of the agent that created it. Absent that assessment, a
1002 Receiver cannot interpret the field as valid. Thus, the final
1003 recipients of the message have no way to verify on their own the
1004 authenticity of the Author's identity on that message. However, if
1005 that field is the only one on the message when the Verifier gets it,
1006 and the Verifier explicitly trusts the Signer that included the
1010Kucherawy Best Current Practice [Page 18]
1012RFC 6377 DKIM and Mailing Lists September 2011
1015 Authentication-Results field in its header hash (in this case, the
1016 MLM), the Verifier is in a position to believe that a valid Author
1017 signature was present on the message.
1019 This can be generalized as follows: a Receiver SHOULD consider only
1020 [AUTH-RESULTS] fields bearing an authserv-id that appears in a list
1021 of sites the Receiver trusts and that is also included in the header
1022 hash of a [DKIM] signature added by a domain in the same trusted
1025 Since an aliasing MLM makes no substantive changes to a message, it
1026 need not consider the issue of signature removal as the original
1027 signatures should at least arrive to the next MTA unmodified. It is
1028 possible that future domain-based reputations would prefer a richer
1029 data set on receipt of a message, and, in that case, signature
1030 removal would be undesirable.
1032 An authoring MLM is closed to outside submitters; thus, much of this
1033 discussion does not apply in that case.
1037 DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own
1038 signatures when distributing messages. The MLM is responsible for
1039 the alterations it makes to the original messages it is resending and
1040 should express this via a signature. This is also helpful for
1041 getting feedback from any FBLs that might be set up so that undesired
1042 list mail can generate appropriate action.
1044 MLM signatures will likely be used by recipient systems to recognize
1045 list mail, and they give the MLM's ADMD an opportunity to develop a
1046 good reputation for the list itself.
1048 A signing MLM, as any other MLM, is free to omit redistribution of a
1049 message if that message was not signed in accordance with its own
1050 local configuration or policy. It could also redistribute but not
1051 sign such mail. However, selective signing is NOT RECOMMENDED;
1052 essentially that would create two message streams from the MLM, one
1053 signed and one not, which can confuse DKIM-aware Verifiers and
1056 A signing MLM could add a List-Post: header field (see [LIST-URLS])
1057 using the DNS domain matching the one used in the "d=" tag of the
1058 DKIM signature that is added by the MLM. This can be used by
1059 Verifiers or Receivers to identify the DKIM signature that was added
1060 by the MLM. This is not required, however; it is believed the
1066Kucherawy Best Current Practice [Page 19]
1068RFC 6377 DKIM and Mailing Lists September 2011
1071 reputation of the Signer will be a more critical data point than this
1072 suggested binding. Furthermore, this is not a binding recognized by
1073 any current specification document.
1075 A DKIM-aware resending MLM SHOULD sign the entire message after the
1076 message is prepared for distribution (i.e., the MLM Output from
1077 Section 3.2). Any other configuration might generate signatures that
1080 DKIM-aware authoring MLMs sign the mail they send according to the
1081 regular signing guidelines given in [DKIM].
1083 One concern is that having an MLM apply its signature to unsigned
1084 mail might cause some Verifiers or Receivers to interpret the
1085 signature as conferring more authority or authenticity to the message
1086 content than is defined by [DKIM]. This is an issue beyond MLMs and
1087 primarily entails receive-side processing outside of the scope of
1088 [DKIM]. It is, nevertheless, worth noting here.
10905.9. Verification Outcomes at Final Receiving Sites
1092 In general, Verifiers and Receivers SHOULD treat a signed message
1093 from an MLM like any other signed message; indeed, it would be
1094 difficult to discern any difference since specifications such as
1095 [LIST-URLS] and [LIST-ID] are not universally deployed and can be
1098 However, because the Author domain will commonly be different from
1099 the MLM's signing domain, there may be a conflict with [ADSP] as
1100 discussed in Sections 4.3 and 5.7, especially where an ADMD has
1105 An FBL operator might wish to act on a complaint from a user about a
1106 message sent to a list. Some FBLs could choose to generate feedback
1107 reports based on DKIM verifications in the subject message. Such
1108 operators SHOULD send a report to each domain with a valid signature
1109 that has an FBL agreement established, as DKIM signatures are claims
1110 of some responsibility for that message. Because Authors generally
1111 have limited control over the operation of a list, this point makes
1112 MLM signing all the more important.
1114 MLM operators SHOULD register with FBLs from major service providers.
1115 In the context of DKIM, there SHOULD be an exchange of information
1116 with the FBL provider including what signing domain the MLM will use,
1122Kucherawy Best Current Practice [Page 20]
1124RFC 6377 DKIM and Mailing Lists September 2011
1127 Where the FBL wishes to be more specific, it MAY act solely on a DKIM
1128 signature where the signing domain matches the DNS domain found in a
1129 List-Post: header field (or similar).
1131 Use of FBLs in this way SHOULD be made explicit to list subscribers.
1132 For example, if it is the policy of the MLM's ADMD to handle an FBL
1133 item by unsubscribing the user that was the apparent sender of the
1134 offending message, advising subscribers of this in advance would help
1135 to avoid surprises later.
1137 A DKIM-signed message sent to an MLM, and then distributed to all of
1138 a list's recipients, could result in a complaint from one of the
1139 final recipients for some reason. This could be an actual complaint
1140 from some subscriber that finds the message abusive or otherwise
1141 undesirable, or it could be an automated complaint such as Receiver
1142 detection of an invalidated DKIM signature or some other condition.
1143 It could also be a complaint that results from antagonistic behavior,
1144 such as is common when a subscriber to a list is having trouble
1145 unsubscribing and then begins issuing complaints about all
1146 submissions to the list. This would result in a complaint being
1147 generated in the context of an FBL report back to the message Author.
1148 However, the original Author has no involvement in operation of the
1149 MLM itself, meaning the FBL report is not actionable and is thus
11525.11. Handling Choices at Receivers
1154 A recipient that explicitly trusts signatures from a particular MLM
1155 MAY wish to extend that trust to an [AUTH-RESULTS] header field
1156 signed by that MLM. The recipient MAY then do additional processing
1157 of the message, using the results recorded in the Authentication-
1158 Results header field instead of the original Author's DKIM signature.
1159 This includes possibly processing the message as per ADSP
1162 Receivers SHOULD ignore or remove all unsigned externally applied
1163 Authentication-Results header fields and those not signed by an ADMD
1164 that can be trusted by the Receiver. See Sections 5 and 7 of
1165 [AUTH-RESULTS] for further discussion.
1167 Upon DKIM and ADSP evaluation during an SMTP session (a common
1168 implementation), an agent MAY decide to reject a message during an
1169 SMTP session. If this is done, [SMTP] stipulates that 550 is the
1170 correct response code. However, if the SMTP server supports
1171 [ENHANCED] status codes, a status code not normally used for "user
1172 unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be
1173 used. If the rejecting SMTP server supports this, it thus makes a
1174 distinction between messages rejected deliberately due to policy
1178Kucherawy Best Current Practice [Page 21]
1180RFC 6377 DKIM and Mailing Lists September 2011
1183 decisions rather than those rejected because of other delivery
1184 issues. In particular, a policy rejection SHOULD be relayed using
1185 the above enhanced status code and some appropriate wording in the
1186 text part of the reply. Those MLMs that automatically attempt to
1187 remove users with prolonged delivery problems (such as account
1188 deletion) SHOULD thus detect the difference between policy rejection
1189 and other delivery failures and act accordingly. It would also be
1190 beneficial for SMTP servers doing so to use appropriate wording in
1191 the text portion of the reply, perhaps explicitly using the string
1192 "ADSP" to facilitate searching for relevant data in logs.
1194 The preceding paragraph does not apply to an [ADSP] policy of
1195 "discardable". In such cases where the submission fails that test,
1196 the Receiver or Verifier SHOULD discard the message but return an
1197 SMTP success code, i.e., accept the message but drop it without
1198 delivery. An SMTP rejection of such mail instead of the requested
1199 discard action causes more harm than good.
1203 As mechanisms become available for reporting forensic details about
1204 DKIM verification failures, MLMs will benefit from their use.
1206 MLMs SHOULD apply DKIM failure-reporting mechanisms as a method for
1207 providing feedback to Signers about issues with DKIM infrastructure.
1208 This is especially important for MLMs that implement DKIM
1209 verification as a mechanism for authentication of list configuration
1210 commands and submissions from subscribers.
12127. Security Considerations
1214 This document provides suggested or best current practices for use
1215 with DKIM and, as such, does not introduce any new technologies for
1216 consideration. However, the following security issues should be
1217 considered when implementing the practices described in this
12207.1. Security Considerations from DKIM and ADSP
1222 Readers should be familiar with the material in the "Security
1223 Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as
1234Kucherawy Best Current Practice [Page 22]
1236RFC 6377 DKIM and Mailing Lists September 2011
12397.2. Authentication Results When Relaying
1241 Section 5 advocates addition of an [AUTH-RESULTS] header field to
1242 indicate authentication status of a message received as MLM Input.
1243 Per Section 7.2 of [AUTH-RESULTS], Receivers generally should not
1244 trust such data without a good reason to do so, such as an a priori
1245 agreement with the MLM's ADMD.
1247 Such agreements are strongly advised to include a requirement that
1248 those header fields be covered by a [DKIM] signature added by the
12538.1. Normative References
1255 [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine,
1256 "DomainKeys Identified Mail (DKIM) Author Domain Signing
1257 Practices (ADSP)", RFC 5617, August 2009.
1260 Kucherawy, M., "Message Header Field for Indicating
1261 Message Authentication Status", RFC 5451, April 2009.
1263 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1264 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
1268 Crocker, D., "Internet Mail Architecture", RFC 5598,
1271 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1272 Requirement Levels", BCP 14, RFC 2119, March 1997.
1274 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
12778.2. Informative References
1279 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
1280 Extensible Format for Email Feedback Reports", RFC 5965,
1284 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
1285 "DomainKeys Identified Mail (DKIM) Development,
1286 Deployment, and Operations", RFC 5863, May 2010.
1290Kucherawy Best Current Practice [Page 23]
1292RFC 6377 DKIM and Mailing Lists September 2011
1296 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
1297 Identified Mail (DKIM) Service Overview", RFC 5585,
1300 [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes",
1301 RFC 3463, January 2003.
1303 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
1304 Object Description Exchange Format", RFC 5070,
1307 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
1308 and Namespace for the Identification of Mailing Lists",
1309 RFC 2919, March 2001.
1312 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
1313 for Core Mail List Commands and their Transport through
1314 Message Header Fields", RFC 2369, July 1998.
1316 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1317 Extensions (MIME) Part One: Format of Internet Message
1318 Bodies", RFC 2045, November 1996.
1321 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1322 Extensions (MIME) Part Two: Media Types", RFC 2046,
1325 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1346Kucherawy Best Current Practice [Page 24]
1348RFC 6377 DKIM and Mailing Lists September 2011
1351Appendix A. Acknowledgements
1353 The author wishes to acknowledge the following individuals for their
1354 review and constructive criticism of this document: Serge Aumont,
1355 Daniel Black, Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear,
1356 Charles Lindsey, John Levine, Jeff Macdonald, S. Moonesamy, Rolf E.
1357 Sonneveld, and Alessandro Vesely.
1359Appendix B. Example Scenarios
1361 This section describes a few MLM-related DKIM scenarios that were
1362 part of the impetus for this work and the recommended resolutions for
1369 o Author ADMD advertises an ADSP policy of "dkim=discardable"
1371 o Author sends DKIM-signed mail to a non-participating MLM, which
1372 invalidates the signature
1374 o Receiver MTA checks DKIM and ADSP at SMTP time and is configured
1375 to reject ADSP failures, so rejects this message
1377 o process repeats a few times, after which the MLM unsubscribes the
1380 Solution: MLMs should refuse mail from domains advertising ADSP
1381 policies of "discardable" unless the MLMs are certain they make no
1382 changes that invalidate DKIM signatures.
1388 o subscriber sends signed mail to a non-participating MLM that does
1389 not invalidate the signature
1391 o a recipient reports the message as spam
1393 o FBL at recipient ADMD sends report to contributor rather than list
1402Kucherawy Best Current Practice [Page 25]
1404RFC 6377 DKIM and Mailing Lists September 2011
1407 Solution: MLMs should sign mail they send and might also strip
1408 existing signatures. FBLs should report to list operators instead of
1409 subscribers where such can be distinguished; otherwise, FBLs should
1410 report to all parties with valid signatures.
1416 128 King St., 2nd Floor
1417 San Francisco, CA 94107
1420 Phone: +1 415 946 3800
1421 EMail: msk@cloudmark.com
1458Kucherawy Best Current Practice [Page 26]