idnits 2.17.00 (12 Aug 2021) /tmp/idnits33909/draft-ietf-dkim-mailinglists-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (April 25, 2011) is 4043 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 5617 (ref. 'ADSP') ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) ** Downref: Normative reference to an Informational RFC: RFC 5598 (ref. 'EMAIL-ARCH') -- Obsolete informational reference (is this intentional?): RFC 5070 (ref. 'IODEF') (Obsoleted by RFC 7970) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: BCP April 25, 2011 5 Expires: October 27, 2011 7 DKIM And Mailing Lists 8 draft-ietf-dkim-mailinglists-07 10 Abstract 12 DomainKeys Identified Mail (DKIM) allows an administrative mail 13 domain (ADMD) to assume some responsibility for a message. Based on 14 deployment experience with DKIM, this Best Current Practices document 15 provides guidance for the use of DKIM with scenarios that include 16 Mailing List Managers (MLMs). {DKIM 12} 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 27, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Notes to Editor and Reviewers . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 5 56 2.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 6 57 2.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 8 61 3.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 8 62 3.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 8 63 3.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 8 64 4. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 9 66 4.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 10 67 4.3. Current MLM Effects On Signatures . . . . . . . . . . . . 11 68 5. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 14 69 5.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 14 70 5.2. Verification Outcomes at Receivers . . . . . . . . . . . . 15 71 5.3. Handling Choices at Receivers . . . . . . . . . . . . . . 15 72 5.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15 73 6. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16 74 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16 76 6.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17 77 6.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 17 78 6.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 17 79 6.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 18 80 6.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 19 81 6.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 20 82 6.9. Verification Outcomes at Final Receiving Sites . . . . . . 22 83 6.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22 84 6.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23 85 7. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 25 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 88 9.1. Security Considerations from DKIM and ADSP . . . . . . . . 27 89 9.2. Authentication Results When Relaying . . . . . . . . . . . 27 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 93 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30 94 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 31 95 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 31 96 B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 31 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 1. Notes to Editor and Reviewers 101 This version of the memo contains notations such as "{DKIM 2}". 102 These correspond to DKIM working group issue tracker items. They 103 should be deleted prior to publication. 105 2. Introduction 107 DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail 108 Domain to take some responsibility for a [MAIL] message. This can be 109 an author's organization, an operational relay (Mail Transfer Agent, 110 or MTA) or one of their agents. Assertion of responsibility is made 111 through a cryptographic signature. Message transit from author to 112 recipient is through relays that typically make no substantive change 113 to the message content and thus preserve the validity of the DKIM 114 signature. 116 In contrast to relays, there are intermediaries, such as mailing list 117 managers (MLMs), that actively take delivery of messages, re-format 118 them, and re-post them, often invalidating DKIM signatures. The goal 119 for this document is to explore the use of DKIM for scenarios that 120 include intermediaries, and recommend Best Current Practices based on 121 acquired experience. Questions that will be discussed include: 123 o Under what circumstances is it advisable for an author, or its 124 organization, to apply DKIM to mail sent to mailing lists? 126 o What are the tradeoffs regarding having an MLM verify and use DKIM 127 identifiers? 129 o What are the tradeoffs regarding having an MLM remove existing 130 DKIM signatures prior to re-posting the message? 132 o What are the tradeoffs regarding having an MLM add its own DKIM 133 signature? 135 These and others are open questions for which there may be no 136 definitive answers. However, based on experience since the 137 publication of [DKIM] and its gradual deployment, there are some 138 views that are useful to consider and some recommended procedures. 140 In general there are, in relation to DKIM, two categories of MLMs: 141 participating and non-participating. As each type has its own issues 142 regarding DKIM-signed messages that are either handled or produced by 143 them (or both), the types are discussed in separate sections. 145 2.1. Background 147 DKIM signatures permit an agent of the email architecture (see 148 [EMAIL-ARCH]) to make a claim of responsibility for a message by 149 affixing a validated domain-level identifier to the message as it 150 passes through a relay. {DKIM 12} Although not the only possibility, 151 this is most commonly done as a message passes through a boundary 152 Mail Transport Agent (MTA) as it departs an Administrative Mail 153 Domain (ADMD) across the open Internet. {DKIM 12} 155 A DKIM signature will fail to verify if a portion of the message 156 covered by one of its hashes is altered. An MLM commonly alters 157 messages to provide information specific to the mailing list for 158 which it is providing service. Common modifications are enumerated 159 and described in Section 4.3. However, note that MLMs vary widely in 160 behaviour as well as often allowing subscribers to select individual 161 behaviours. Further, the MTA might make changes that are independent 162 of those applied by the MLM. {DKIM 12} 164 The DKIM signing specification deliberately rejects the notion of 165 tying the signing {DKIM 12} domain (the "d=" tag in a DKIM signature) 166 to any other identifier {DKIM 12} within a message; any ADMD that 167 handles a message could sign it, regardless of its origin or author 168 domain. In particular, DKIM does not define any meaning to the 169 occurrence of a match between the content of a "d=" tag and the value 170 of, for example, a domain name in the RFC5322.From field, nor is 171 there any obvious degraded value to a signature where they do not 172 match. Since any DKIM signature is merely an assertion of "some" 173 responsibility by an ADMD, a DKIM signature added by an MLM has no 174 more, nor less, meaning than a signature with any other "d=" value. 176 2.2. MLMs In Infrastructure 178 An MLM is an autonomous agent that takes delivery of a message and 179 can re-post it as a new message, or construct a digest of it along 180 with other messages to the members of the list (see [EMAIL-ARCH], 181 Section 5.3). However, the fact that the RFC5322.From field of such 182 a message (in the non-digest case) is typically the same as that of 183 the original message, and that recipients perceive the message as 184 "from" the original author rather than the MLM, creates confusion 185 about responsibility and autonomy for the re-posted message. This 186 has important implications for use of DKIM. {DKIM 12} 188 Section 4.3 describes some of the things MLMs commonly do that 189 produce broken signatures, thus reducing the perceived value of DKIM. 191 Further, while there are published standards that are specific to MLM 192 behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption 193 has been spotty at best. Hence, efforts to specify the use of DKIM 194 in the context of MLMs needs to be incremental and value-based. 196 Some MLM behaviours are well-established and their effects on DKIM 197 signature validity can be argued as frustrating wider DKIM adoption. 198 Still, those behaviors are not standards violations. Hence, the best 199 approach for a BCP effort is to specify practices for all parties 200 involved, defining the minimum changes possible to MLMs themselves. 202 {DKIM 12} 204 A DKIM signature on a message is an expression of some responsibility 205 for the message taken by the signing domain. An open issue that is 206 addressed by this document is the ways a signature might be used by a 207 recipient's evaluation module, after the message has gone through a 208 mailing list and might or might not have been rendered invalid. The 209 document also considers how invalidation might have happened. {DKIM 210 12} 212 Note that where in this document there is discussion of an MLM 213 conducting validation of DKIM signatures or ADSP policies, the actual 214 implementation could be one where the validation is done by the MTA 215 or an agent attached to it, and the results of that work are relayed 216 by a trusted channel not specified here. See [AUTH-RESULTS] for a 217 discussion of this. This document does not favour any particular 218 arrangement of these agents over another, but merely talks about the 219 MLM itself doing the work as a matter of simplicity. 221 2.3. Feedback Loops And Other Bi-Lateral Agreements 223 A Feedback Loop (FBL) is a bi-lateral agreement between two parties 224 to exchange reports of abuse. Typically, a sender registers with a 225 receiving site to receive abuse reports from that site for mail 226 coming from the sender. 228 An FBL reporting address (i.e., an address to which FBL reports are 229 sent) is part of this bi-lateral registration. Some FBLs require 230 DKIM use by the registrant. 232 See Section 7 for additional discussion. 234 FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) formats. 235 {DKIM 12} 237 2.4. Document Scope and Goals 239 This document provides discussion on the above issues, to improve the 240 handling of possible interactions between DKIM and MLMs. In general, 241 the preference is to impose changes to behaviour at the signer and 242 verifier rather than at the MLM. {DKIM 12} 244 Wherever possible, the document's discussion of MLMs is conceptually 245 decoupled from MTAs despite the very tight integration that is 246 sometimes observed in implementation. This is done to emphasize the 247 functional independence of MLM services and responsibilities from 248 those of an MTA. {DKIM 12} 249 Parts of this document explore possible changes to common practice by 250 signers, verifiers and MLMs. The suggested enhancements are largely 251 predictive {DKIM 12} in nature, taking into account the current email 252 infrastructure, the facilities DKIM can provide as it gains wider 253 deployment, and working group consensus. There is no substantial 254 implementation history upon which these suggestions are based, and 255 the efficacy, performance and security characteristics of them have 256 not yet been fully explored. 258 3. Definitions 260 3.1. Key Words 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 264 document are to be interpreted as described in [KEYWORDS]. {DKIM 15} 266 3.2. Messaging Terms 268 See [EMAIL-ARCH] for a general description of the current messaging 269 architecture, and for definitions of various terms used in this 270 document. 272 3.3. DKIM-Specific References 274 Readers are encouraged to become familiar with [DKIM] and [ADSP], 275 which are core specification documents, as well as [DKIM-OVERVIEW] 276 and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents. 278 3.4. 'DKIM-Friendly' 280 The term "DKIM-Friendly" is used to describe an email intermediary 281 that, when handling a message, makes no changes to that message which 282 cause valid [DKIM] signatures present on the message on input to fail 283 to verify on output. 285 Various features of MTAs and MLMs seen as helpful to users often have 286 side effects that do render DKIM signatures unverifiable. These 287 would not qualify for this label. 289 3.5. Message Streams 291 A "message stream" identifies a group of messages originating from 292 within an {DKIM 12} ADMD that are distinct in intent, origin and/or 293 use, and partitions them somehow (i.e., via {DKIM 12} changing the 294 value in the "d=" tag value in the context of DKIM) so as to keep 295 them associated to users yet distinct in terms of their evaluation 296 and handling by verifiers or receivers. 298 A good example might be user mail generated by a company's employees, 299 versus operational or transactional mail that comes from automated 300 sources, versus marketing or sales campaigns. Each of these could 301 have different security policies imposed against them, or there might 302 be a desire to insulate one from the other (e.g., a marketing 303 campaign that gets reported by many spam filters could cause the 304 marketing stream's reputation to degrade without automatically 305 punishing the transactional or user streams). 307 4. Mailing Lists and DKIM 309 It is important to make some distinctions among different styles of 310 intermediaries, their typical implementations, and the effects they 311 have in a DKIM-aware environment. {DKIM 12} 313 4.1. Roles and Realities 315 Across DKIM activities, there are several key roles {DKIM 12} in the 316 transit of a message. Most of these are defined in [EMAIL-ARCH], but 317 are reviewed here for quick reference. {DKIM 12} 319 author: The agent that provided the content of the message being 320 sent through the system. The author delivers that content to the 321 originator in order to begin a message's journey to its intended 322 final recipients. The author can be a human using an MUA (Mail 323 User Agent) or a common system utility such as "cron", etc. {DKIM 324 12} 326 originator: The agent that accepts a message from the author, 327 ensures it conforms to the relevant standards such as [MAIL], and 328 then sends {DKIM 12} it toward its destination(s). This is often 329 referred to as the Mail Submission Agent (MSA). 331 signer: Any agent that affixes one or more DKIM signature(s) to a 332 message on its way toward its ultimate destination. There is 333 typically a signer running at the MTA that sits between the 334 author's ADMD and the general Internet. The originator and/or 335 author might also be a signer. 337 verifier: Any agent that conducts DKIM signature analysis. One is 338 typically running at the MTA that sits between the public Internet 339 {DKIM 12} and the receiver's ADMD. Note that any agent that 340 handles a signed message can conduct verification; {DKIM 12} this 341 document only considers that action and its outcomes either at an 342 MLM or at the receiver. Filtering decisions could be made by this 343 agent based on verification results. 345 receiver: The agent that is the final transit relay for the message 346 and performs final delivery to {DKIM 12} the recipient(s) of the 347 message. Filtering decisions based on results made by the 348 verifier could be applied by the receiver. The verifier and the 349 receiver could be the same agent. 351 In the case of simple user-to-user mail, these roles are fairly 352 straightforward. However, when one is sending mail to a list, which 353 then gets relayed to all of that list's subscribers, the roles are 354 often less clear to the general user as particular agents may hold 355 multiple important but separable roles. The above definitions are 356 intended to enable more precise discussion of the mechanisms 357 involved. 359 4.2. Types Of Mailing Lists 361 There are four common MLM implementation modes: 363 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 364 that makes no changes to the message itself as it redistributes; 365 any modifications are constrained to changes to the [SMTP] {DKIM 366 12} envelope recipient list (RCPT commands) only. There are no 367 changes to the message header or body at all, except for the 368 addition of [MAIL] trace header fields. {DKIM 12} The output of 369 such an MLM is considered to be a continuation of the author's 370 original message transit. {DKIM 12} An example of such an MLM is 371 an address that expands directly in the {DKIM 12} MTA, such as a 372 list of local system administrators used for relaying operational 373 or other internal-only messages. See also Section 3.9.2 of 374 [SMTP]. 376 resending: A resending MLM (see Sections 5.2 and 5.3 of 377 [EMAIL-ARCH]) is one that may make changes to a message. The 378 output of such an MLM is considered to be a new message; delivery 379 of the original has been completed prior to distribution of the 380 re-posted message. Such messages are often re-formatted, such as 381 with list-specific header fields or other properties, to 382 facilitate discussion among list subscribers. 384 authoring: An authoring MLM is one that creates the content being 385 sent as well as initiating its transport, rather than basing it on 386 one or more messages received earlier. This is not a "mediator" 387 in terms of [EMAIL-ARCH] since it originates the message, but 388 after creation, its message processing and posting behavior 389 otherwise do match the MLM paradigm. Typically {DKIM 12} replies 390 are not generated, or if they are, they go to a specific recipient 391 and not back to the list's full set of recipients. Examples 392 include newsletters and bulk marketing mail. 394 digesting: A special case of the resending MLM is one that sends a 395 single message comprising an aggregation of recent MLM 396 submissions, which might be a message of [MIME] type "multipart/ 397 digest" (see [MIME-TYPES]). This is obviously a new message but 398 it may contain a sequence of original messages that may themselves 399 have been DKIM-signed. 401 In the remainder of this document we distinguish two relevant steps, 402 corresponding to the following SMTP transactions: 404 MLM Input: Originating user is author; originating ADMD is 405 originator and signer; MLM's ADMD is verifier; MLM's input 406 function is receiver. 408 MLM Output: MLM (sending its reconstructed copy of the originating 409 user's message) is author; MLM's ADMD is originator and signer; 410 the ADMD of each subscriber of the list is a verifier; each 411 subscriber is a receiver. 413 Much of this document focuses on the resending class of MLM as it has 414 the most direct conflict operationally with DKIM. 416 The dissection of the overall MLM operation into these two distinct 417 phases allows the DKIM-specific {DKIM 12} issues with respect to MLMs 418 to be isolated and handled in a logical way. The main issue is that 419 the repackaging and reposting of a message by an MLM is actually the 420 construction of a completely new message, and as such the MLM is 421 introducing new content into the email ecosystem, consuming the 422 author's copy of the message and creating its own. When considered 423 in this way, the dual role of the MLM and its ADMD becomes clear. 425 Some issues about these activities are discussed in Section 3.6.4 of 426 [MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. 428 4.3. Current MLM Effects On Signatures 430 As described above, an aliasing MLM does not affect any existing 431 signature, and an authoring MLM is always creating new content and 432 thus there is never an existing signature. However, the changes a 433 resending MLM typically make affect {DKIM 12} the RFC5322.Subject 434 header field, addition of some list-specific header fields, and/or 435 modification of the message body. The effects of each of these {DKIM 436 12} on DKIM verification are discussed below. 438 Subject tags: A popular feature of MLMs is the "tagging" of an 439 RFC5322.Subject field by prefixing the field's contents with the 440 name of the list, such as "[example]" for a list called "example". 441 Altering the RFC5322.Subject field on new submissions by adding a 442 list-specific prefix or suffix will invalidate the signer's 443 signature if that header field was included in the hash when 444 creating that signature. Section 5.5 of [DKIM] lists 445 RFC5322.Subject as one that should be covered as it contains 446 important user-visible text, so this is expected to be an issue 447 for any list that makes such changes. {DKIM 12} 449 List-specific header fields: Some lists will add header fields 450 specific to list administrative functions such as those defined in 451 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 452 [MAIL]. It is unlikely that a typical MUA would include such 453 fields in an original message, and DKIM is resilient to the 454 addition of header fields in general (see notes about the "h=" tag 455 in Section 3.5 of [DKIM]). Therefore not seen as a concern. {DKIM 456 12} 458 Other header fields: Some lists will add or replace header fields 459 such as "Reply-To" or "Sender" in order to establish that the 460 message is being sent in the context of the mailing list, so that 461 the list is identified ("Sender") and any user replies go to the 462 list ("Reply-To"). If these fields were included in the original 463 message, it is possible that one or more of them may have been 464 included in the signature hash, and those {DKIM 12} signatures 465 will thus be broken. 467 Minor body changes: Some lists prepend or append a few lines to each 468 message to remind subscribers of an administrative URL for 469 subscription issues, or of list policy, etc. Changes to the body 470 will alter the body hash computed at the DKIM verifier, so these 471 will render any existing signatures that cover those portions of 472 the message body unverifiable. [DKIM] includes the capability to 473 limit the length of the body covered by its body hash so that 474 appended text will not interfere with signature validation, but 475 this has security implications. {DKIM 12} 477 Major body changes: There are some MLMs that make more substantial 478 changes to message bodies when preparing them for re-distribution, 479 such as adding, deleting, reordering, or reformatting [MIME] 480 parts, "flattening" HTML messages into plain text, or inserting 481 {DKIM 9} headers or footers within HTML messages. Most or all of 482 these changes will invalidate a DKIM signature. 484 MIME part removal: Some MLMs that are MIME-aware will remove large 485 MIME parts from submissions and replace them with URLs to reduce 486 the size of the distributed form of the message and to prevent 487 inadvertent automated malware delivery. Except in some cases 488 where {DKIM 12} a body length limit is applied in generation of 489 the DKIM signature, the signature will be broken. 491 There reportedly still exist some {DKIM 12} mailing lists in 492 operation that are actually run manually by a human list manager, 493 whose workings in preparing a message for distribution could include 494 the above or even some other changes. 496 In general, absent a general movement by MLM developers and operators 497 toward more DKIM-friendly practices, an MLM subscriber cannot expect 498 signatures applied before the message was processed by the MLM to be 499 valid on delivery to a receiver. Such an evolution is not expected 500 in the short term due to general development and deployment inertia. 501 Moreover, even if an MLM currently passes messages unmodified such 502 that author signatures validate, it is possible that a configuration 503 change or software upgrade to that MLM will cause that no longer to 504 be true. 506 5. Non-Participating MLMs 508 This section contains a discussion of issues regarding sending DKIM- 509 signed mail to or through an MLM that is not DKIM-aware. 510 Specifically, the header fields introduced by [DKIM] and 511 [AUTH-RESULTS] carry no special meaning to such an MLM. 513 5.1. Author-Related Signing 515 In an idealized world, if an author knows that the MLM to which a 516 message {DKIM 12} is being sent is a non-participating resending MLM, 517 the author SHOULD be cautious when deciding whether or not to send a 518 signed message to the list {DKIM 9}. The MLM could make a change 519 that would invalidate the author's signature but not remove it prior 520 to re-distribution. Hence, list recipients would receive a message 521 purportedly from the author but bearing a DKIM signature that would 522 not verify. Some mail filtering software incorrectly penalizes a 523 message containing a DKIM signature that fails verification. This 524 may have {DKIM 12} detrimental effects outside of the author's 525 control. (Additional discussion of this is below.) This problem can 526 be compounded if there are receivers that apply signing {DKIM 12} 527 policies (e.g., [ADSP]) and the author publishes any kind of strict 528 policy, i.e., a policy that requests that receivers reject or 529 otherwise deal severely with non-compliant messages. {DKIM 12} 531 For domains that do publish strict ADSP policies, the originating 532 site SHOULD use a separate message stream (see Section 3.5), such as 533 a signing and author subdomain {DKIM 12}, for the "personal" mail -- 534 a subdomain that is different from domain(s) used for other mail 535 streams. This allows each to develop an independent reputation, and 536 more stringent policies (including ADSP) can be applied to the mail 537 stream(s) that do not go through mailing lists or perhaps do not get 538 signed at all. 540 However, all of this presupposes a level of infrastructure 541 understanding that is not expected to be common. Thus, it will be 542 incumbent upon site administrators to consider how support of users 543 wishing to participate in mailing lists might be accomplished as DKIM 544 achieves wider adoption. 546 In general, the more strict practices and policies are likely to be 547 successful only for the mail streams subject to the most end-to-end 548 control by the originating organization. That typically excludes 549 mail going through MLMs. Therefore, site administrators wishing to 550 employ ADSP with a "discardable" setting SHOULD separate the 551 controlled mail stream warranting this handling from other mail 552 streams that are less controlled, such as personal mail that transits 553 MLMs. (See also in Section 6.7 below.) {DKIM 12} 555 5.2. Verification Outcomes at Receivers 557 There is no reliable way to {DKIM 12} determine that a piece of mail 558 arrived via a non-participating MLM. Sites whose users subscribe to 559 non-participating MLMs SHOULD ensure that such user mail streams are 560 not subject to strict DKIM-related handling policies. {DKIM 12} 562 5.3. Handling Choices at Receivers 564 In order to exempt some mail from the expectation of signature 565 verification, as discussed in Section 5.1, receiving ADMDs would need 566 to register non-participating lists and confirm that mail transited 567 them. However, such an approach requires excessive effort and even 568 then is likely to be unreliable. Hence, it is not a scalable 569 solution. {DKIM 12} 571 Any treatment of a verification failure as having special meaning is 572 a violation of the basic DKIM signing specification. The only valid, 573 standardized basis for going beyond that specification is with 574 specific ADSP direction. {DKIM 12} 576 Use of restrictive domain policies such as [ADSP] "discardable" 577 presents an additional challenge. In that case, when a message is 578 unsigned or the signature can no longer be verified, discarding of 579 the message is requested. There is no exception in the policy for a 580 message that may have been altered by an MLM, nor is there a reliable 581 way to identify such mail. Therefore, participants SHOULD honour the 582 policy and disallow the message. 584 5.4. Wrapping A Non-Participating MLM 586 One approach for adding DKIM support to an otherwise non- 587 participating MLM is to "wrap" the MLM, or in essence place it 588 between other DKIM-aware components (such as MTAs) that provide some 589 DKIM services. For example, the ADMD operating a non-participating 590 MLM could have its DKIM verifier act on messages from list 591 subscribers, enforcing some of the features and recommendations of 592 Section 6 on behalf of the MLM, and the MTA or MSA receiving the MLM 593 Output could also add a DKIM signature for the MLM's domain. {DKIM 594 12} 596 6. Participating MLMs 598 This section contains a discussion of issues regarding DKIM-signed 599 mail that transits an MLM which is DKIM-aware. 601 6.1. General 603 Changes that merely add new header fields, such as those specified by 604 [LIST-ID], [LIST-URLS] and [MAIL], are generally the most friendly to 605 a DKIM-participating email infrastructure. Their addition by an MLM 606 {DKIM 12} will not affect any existing DKIM signatures unless those 607 fields were already present and covered by a signature's hash, or a 608 signature {DKIM 12} was created specifically to disallow their 609 addition (see the note about "h=" in Section 3.5 of [DKIM]). 611 However, the practice of applying headers and footers to message 612 bodies is common and not expected to fade regardless of what 613 documents this or any standards body might produce. This sort of 614 change will invalidate the signature on a message where the body hash 615 covers the entire message. Thus, the following sections also discuss 616 and suggest other processing alternatives. 618 A possible mitigation to this incompatibility is use of the "l=" tag 619 to bound the portion of the body covered by the DKIM body hash, but 620 this is not workable for [MIME] messages; moreover, it has security 621 considerations (see Section 3.5 of [DKIM]). Its use is therefore 622 discouraged. 624 Expressions of list-specific policy (e.g., rules for participation, 625 small advertisements, etc.) are often added to outgoing messages by 626 MLM operators. There is currently no header field proposed for 627 relaying such general operational MLM details apart from what 628 [LIST-URLS] already supports. This sort of information is commonly 629 included footer text appended to the body of the message, or header 630 text prepended above the original body {DKIM 9}. It is RECOMMENDED 631 that periodic, automatic mailings to the list to remind subscribers 632 of list policy, and it is otherwise RECOMMENDED that the use of 633 standard header fields to express list operation parameters be 634 applied rather than body changes. {DKIM 12} These periodic mailings 635 will be repetitive, of course, but by being generally the same each 636 time they can be easily filtered if desired. 638 6.2. DKIM Author Domain Signing Practices 640 ADSP {DKIM 9} presents a particular challenge. An author domain 641 posting a policy of "discardable" imposes a very tight restriction on 642 the use of mailing lists, essentially constraining that domain's 643 users to lists operated by aliasing MLMs only; any MLM that alters a 644 message from such a domain or removes its signature subjects the 645 message to severe action by verifiers or receivers. A resending 646 {DKIM 12} MLM SHOULD reject outright any mail from an author whose 647 domain posts such a policy, as those messages likely to be discarded 648 or rejected by any ADSP-aware recipients. See also the discussion in 649 Section 6.3. {DKIM 9} 651 Where such rejection of "discardable" mail is not enforced, and such 652 mail arrives to a {DKIM 12} verifier that applies ADSP checks which 653 fail, the message SHOULD either be discarded (i.e. accept the message 654 at the [SMTP] level but discard it without delivery) or rejected by 655 returning a 5xx error code. In the latter case, some advice for how 656 to conduct the rejection in a potentially meaningful way can be found 657 in Section 6.11. 659 See also Appendix B.5 of [ADSP] for further discussion. 661 6.3. Subscriptions 663 At subscription time, an ADSP-aware MLM SHOULD check for a published 664 ADSP record for the new subscriber's domain. If the policy specifies 665 "discardable", the MLM SHOULD disallow the subscription or present a 666 warning that the subscriber's submissions to the mailing list might 667 not be deliverable to some recipients because of the subscriber's 668 ADMD's published policy. 670 Of course, such a policy record could be created {DKIM 12} after 671 subscription, so this is not a universal solution. An MLM 672 implementation MAY do periodic checks of its subscribers and issue 673 warnings where such a policy is detected, or simply check upon each 674 submission. 676 6.4. Exceptions To ADSP Recommendations 678 Where an ADMD has established some out-of-band trust agreement with 679 another ADMD such that an Authentication-Results field applied by one 680 is trusted by the other, the above recommendations for MLM operation 681 with respect to ADSP do not apply because it is then possible to 682 establish whether or not a valid author signature can be inferred 683 even if one is not present on receipt. 685 6.5. Author-Related Signing 687 An important consideration is that authors rarely have any direct 688 influence over the management of an MLM. Specifically, the behavior 689 of an intermediary (e.g., an MLM that is not careful about filtering 690 out junk mail or being diligent about unsubscription requests) can 691 trigger recipient complaints that reflect back on those agents that 692 appear to be responsible for the message, in this case an author via 693 the address found in the RFC5322.From field. In the future, as DKIM 694 signature outputs (i.e., the signing domain) are used as inputs to 695 reputation modules, there may be a desire to insulate one's 696 reputation from influence by the unknown results of sending mail 697 through an MLM. In that case, authors SHOULD create a mail stream 698 specifically used for generating signatures when sending traffic to 699 MLMs. {DKIM 12} 701 This suggestion can be made more general. Mail that is of a 702 transactional or generally end-to-end nature, and not likely to be 703 forwarded around either by MLMs or users, SHOULD be signed with a 704 different mail stream identifier from a stream that serves more 705 varied uses. {DKIM 12} 707 6.6. Verification Outcomes at MLMs 709 MLMs typically attempt to authenticate messages posted through them. 710 They usually do this through the trivial (and insecure) means of 711 verifying the RFC5322.From field email address (or, less frequently, 712 the RFC5321.MailFrom parameter) against a list subscription registry. 713 {DKIM 12} DKIM enables a stronger form of authentication: {DKIM 9} 714 The MLM can require that messages using a given RFC5322.From address 715 also have a DKIM signature with a corresponding "d=" domain. This 716 feature would be somewhat similar to using ADSP, except that the 717 requirement for it would be imposed by the MLM and not the author's 718 organization. 720 (Note, however, that this goes beyond DKIM's documented semantics. 721 It is presented as a possible workable enhancement.) {DKIM 12} 723 As described, the MLM might conduct DKIM verification of a signed 724 message to attempt to confirm the identity of the author. Although 725 it is a common and intuitive conclusion, few signed messages will 726 include an author {DKIM 12} signature (see [ADSP]). MLM implementers 727 adding such support would have accommodate this. For example, an MLM 728 might be designed to accommodate a list of possible signing domains 729 (the "d=" portion of a DKIM signature) for a given author, and 730 determine at verification time if any of those are present. This 731 enables a more reliable method of authentication at the expense of 732 having to store a mapping of authorized signing domains for 733 subscribers and trusting that it will be kept current. {DKIM 12} 735 A message that cannot be thus authenticated MAY be held for 736 moderation or rejected outright. 738 This logic could apply to any list operation, not just list 739 submission. In particular, this improved authentication MAY apply to 740 subscription, unsubscription, and/or changes to subscriber options 741 that are sent via email rather than through an authenticated, 742 interactive channel such as the web. 744 In the case of verification of signatures on submissions, MLMs SHOULD 745 add an [AUTH-RESULTS] header field to indicate the signature(s) 746 observed on the submission as it arrived at the MLM and what the 747 outcome of the evaluation was. Downstream agents might or might not 748 trust the content of that header {DKIM 12} field depending on their 749 own a priori knowledge of the operation of the ADMD generating (and, 750 preferably, signing) that header field. See [AUTH-RESULTS] for 751 further discussion. 753 6.7. Signature Removal Issues 755 A message that arrives signed with DKIM means some domain prior to 756 MLM Input has made a claim of some responsibility for the message. 757 An obvious benefit to leaving the input-side signatures intact, then, 758 is to preserve that original assertion of responsibility for the 759 message so that the receivers of the final message have an 760 opportunity to evaluate the message with that information available 761 to them. {DKIM 12} 763 However, if the MLM is configured to make changes to the message 764 prior to re-posting that would invalidate the original signature(s), 765 further action is RECOMMENDED to prevent invalidated signatures from 766 arriving at final recipients, possibly triggering unwarranted filter 767 actions. (Note, however, that such filtering actions are plainly 768 wrong; [DKIM] stipulates that an invalid signature is to be treated 769 as no signature at all.) 771 A possible solution would be to: 773 1. Attempt verification of all DKIM signatures present on the input 774 message; 776 2. Apply local policy to authenticate the identity of the author; 778 3. Remove all existing [AUTH-RESULTS] fields (optional); 780 4. Add an [AUTH-RESULTS] header field to the message to indicate the 781 results of the above; 783 5. Remove all previously-evaluated DKIM signatures; 785 6. Affix a new signature that covers the entire message on the 786 output side, including the Authentication-Results header field 787 just added (see Section 6.8). 789 Removing the original signature(s) seems particularly appropriate 790 when the MLM knows it is likely to invalidate any or all of them due 791 to the nature of the reformatting it will do. This avoids false 792 negatives at the list's subscribers in their roles as receivers of 793 the message; although [DKIM] stipulates that an invalid signature is 794 the same as no signature, it is anticipated that there will be some 795 implementations that ignore this advice. 797 The MLM could re-evaluate existing signatures after making its 798 message changes to determine whether or not any of them have been 799 invalidated. The cost of this is reduced by the fact that, 800 presumably, the necessary public keys have already been downloaded 801 and one or both of the message hashes could be reused. 803 Per the discussion in [AUTH-RESULTS], a receiver's choice to put any 804 faith in the veracity of that header field requires an a priori 805 assessment of the agent that created it. Absent that assessment, a 806 receiver cannot interpret the field as valid. Thus, the final 807 recipients of the {DKIM 12} message have no way to verify on their 808 own the authenticity of the author's identity on that message. 809 However, if that field is the only one on the message when the 810 verifier gets it, and the verifier explicitly trusts the signer that 811 included the Authentication-Results field in its header hash (in this 812 case, the MLM), the verifier is in a position to believe that a valid 813 author signature was present on the message. {DKIM 12} 815 This can be generalized as follows: A receiver SHOULD consider only 816 [AUTH-RESULTS] fields bearing an authserv-id that appears in a list 817 of sites the receiver trusts and which is also included in the header 818 hash of a [DKIM] signature added by a domain in the same trusted 819 list. 821 Since an aliasing MLM makes no substantive changes to a message, it 822 need not consider the issue of signature removal as the original 823 signatures should arrive at least to the next MTA unmodified. It is 824 possible that future domain-based reputations would prefer a more 825 rich data set on receipt of a message, and in that case signature 826 removal would be undesirable. 828 An authoring MLM is closed to outside submitters, thus much of this 829 discussion does not apply in that case. 831 6.8. MLM Signatures 833 DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own 834 signatures when distributing messages. The MLM is responsible for 835 the alterations it makes to the original messages it is re-sending, 836 and should express this via a signature. This is also helpful for 837 getting feedback from any FBLs that might be set up so that undesired 838 list mail can generate appropriate action. 840 MLM signatures will likely be used by recipient systems to recognize 841 list mail, and they give the MLM's ADMD an opportunity to develop a 842 good reputation for the list itself. 844 A signing MLM is, as any other MLM, free to omit redistribution of a 845 message if that message was not signed in accordance with its own 846 local configuration or policy. It could also redistribute but not 847 sign such mail. However, selective signing is NOT RECOMMENDED; 848 essentially that would create two message streams from the MLM, one 849 signed and one not, which can confuse DKIM-aware verifiers and 850 receivers. 852 A signing MLM could add a List-Post: {DKIM 12} header field (see 853 [LIST-URLS]) using that DNS domain matching the one used in the "d=" 854 tag of the DKIM signature that is added by the MLM. This can be used 855 by {DKIM 12} verifiers or receivers to identify the DKIM signature 856 that was added by the MLM. This is not required, however; it is 857 believed the reputation of the signer will be a more critical data 858 point rather than this suggested binding. Furthermore, this is not a 859 binding recognized by any current specification document. 861 Section 5.5 of [DKIM] includes a list of header fields that a 862 signature SHOULD include in its header hash and discusses reasons for 863 doing so. MLMs that sign MUST adhere to those guidelines, extended 864 as follows: {DKIM 12} 866 o Any [AUTH-RESULTS] fields added by the MLM; 868 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 870 o Any [MAIL] fields, especially Sender and Reply-To, added or 871 replaced by the MLM. 873 A DKIM-aware resending MLM SHOULD sign the entire message after the 874 message is prepared for distribution (i.e. the "MLM Output" from 875 Section 4.2). Any other configuration might generate signatures that 876 will not validate. {DKIM 12} As with any other DKIM signing 877 operation, the choice of what portions of the header and body of the 878 output message should include those parts of the header and body for 879 which the MLM wishes to assert responsibility. 881 DKIM-aware authoring MLMs MUST sign the mail they send according to 882 the regular signing guidelines given in [DKIM]. 884 One concern is that having an MLM apply its signature to unsigned 885 mail might cause some verifiers or receivers to interpret the 886 signature as conferring more authority or authenticity to the message 887 content than is defined by [DKIM]. This is an issue beyond MLMs and 888 primarily entails receive-side processing outside of the scope of 889 [DKIM]. It is nevertheless worth noting here. {DKIM 12} 891 6.9. Verification Outcomes at Final Receiving Sites 893 In general, verifiers and receivers SHOULD treat a signed message 894 from an MLM like any other signed message; indeed, it would be 895 difficult to discern any difference since specifications such as 896 [LIST-URLS] and [LIST-ID] are not universally deployed and can be 897 trivially spoofed. 899 However, because the author domain will commonly be different from 900 the MLM's signing domain, there may be a conflict with [ADSP] as 901 discussed in Section 5.3 and Section 6.7, especially where an ADMD 902 has misused ADSP. 904 6.10. Use With FBLs 906 An FBL operator might wish to act on a complaint from a user about a 907 message sent to a list. Some {DKIM 12} FBLs could choose to generate 908 feedback reports based on DKIM verifications in the subject message. 909 Such operators SHOULD send a report to each domain with a valid 910 signature that has an FBL agreement established, as DKIM signatures 911 are claims of some responsibility for that message. Because authors 912 generally have limited control over the operation of a list, this 913 point makes MLM signing all the more important. 915 MLM operators SHOULD register with FBLs from major service providers. 916 In the context of DKIM, there SHOULD be an exchange of information 917 with the FBL provider including what signing domain the MLM will use, 918 if any. {DKIM 12} 920 Where the FBL wishes to be more specific, it MAY act solely on a DKIM 921 signature where the signing domain matches the DNS domain found in a 922 List-Post: header field (or similar). 924 Use of FBLs in this way SHOULD be made explicit to list subscribers. 925 For example, if it is the policy of the MLM's ADMD to handle an FBL 926 item by unsubscribing the user that was the apparent sender of the 927 offending message, advising subscribers of this in advance would help 928 to avoid surprises later. 930 A DKIM-signed message sent to an MLM, and then distributed to all of 931 a list's recipients, could result in a complaint from one of the 932 final recipients for some reason. This could be an actual complaint 933 from some subscriber that finds the message abusive or otherwise 934 undesirable, or it {DKIM 12} could be an automated complaint such as 935 receiver detection of an invalidated DKIM signature or some other 936 condition. It could also be a complaint that results from 937 antagonistic behaviour, such as is common when a subscriber to a list 938 is having trouble unsubscribing, and then begins issuing complaints 939 about all submissions to the list. This would result in a complaint 940 being generated in the context of an FBL report back to the message 941 author. However, the original author has no involvement in operation 942 of the MLM itself, meaning the FBL report is not actionable, and is 943 thus undesirable. {DKIM 9, DKIM 12} 945 6.11. Handling Choices at Receivers 947 A recipient that explicitly trusts signatures from a particular MLM 948 MAY wish to extend that trust to an [AUTH-RESULTS] header field 949 signed by that MLM. The recipient MAY then do additional processing 950 of the message, using the results recorded in the Authentication- 951 Results header field instead of the original author's DKIM signature. 952 This includes possibly processing the message as per ADSP 953 requirements. 955 Receivers SHOULD ignore or remove all unsigned externally-applied 956 Authentication-Results header fields, and those not signed by an ADMD 957 that can be trusted by the receiver. See Section 5 and Section 7 of 958 [AUTH-RESULTS] for further discussion. 960 Upon DKIM and ADSP evaluation during an SMTP session (a common 961 implementation), an agent MAY decide to reject a message during an 962 SMTP session. If this is done, use of an [SMTP] failure code not 963 normally used for "user unknown" (550) is preferred; therefore, 554 964 SHOULD be used. {DKIM 12} If the rejecting SMTP server supports 965 [ENHANCED] status codes, it SHOULD make a distinction between 966 messages rejected deliberately due to policy decisions rather than 967 those rejected because of other delivery issues {DKIM 9}. In 968 particular, a policy rejection SHOULD be relayed using a 5.7.1 969 enhanced status code and some appropriate wording in the text part of 970 the reply, in contrast to a code of 5.1.1 indicating the user does 971 not exist. Those MLMs that automatically attempt to remove users 972 with prolonged delivery problems (such as account deletion) SHOULD 973 thus detect the difference between policy rejection and other 974 delivery failures, and act accordingly. SMTP servers doing so SHOULD 975 also use appropriate wording in the text portion of the reply, 976 perhaps explicitly using the string "ADSP" to facilitate searching of 977 relevant data in logs. 979 The preceding paragraph does not apply to an [ADSP] policy of 980 "discardable". In such cases where the submission fails that test, 981 the receiver or verifier SHOULD discard the message but return an 982 SMTP success code, i.e. accept the message but drop it without 983 delivery. An SMTP rejection of such mail instead of the requested 984 discard action causes more harm than good. 986 7. DKIM Reporting 988 As mechanisms become available for reporting forensic details about 989 DKIM verification failures, MLMs will benefit from their use. {DKIM 990 12} 992 MLMs SHOULD apply DKIM failure reporting mechanisms as a method for 993 providing feedback to signers about issues with DKIM infrastructure. 994 This is especially important for MLMs that implement DKIM 995 verification as a mechanism for authentication of list configuration 996 commands and submissions from subscribers. 998 8. IANA Considerations 1000 This document includes no IANA actions. 1002 9. Security Considerations 1004 This document provides suggested or best current practices for use 1005 with DKIM, and as such does not introduce any new technologies for 1006 consideration. However, the following security issues should be 1007 considered when implementing the above practices. 1009 9.1. Security Considerations from DKIM and ADSP 1011 Readers should be familiar with the material in the Security 1012 Considerations in [DKIM], [ADSP] and [AUTH-RESULTS] as appropriate. 1013 {DKIM 9} 1015 9.2. Authentication Results When Relaying 1017 Section 6 advocates addition of an [AUTH-RESULTS] header field to 1018 indicate authentication status of a message received as MLM Input. 1019 Per Section 7.2 of [AUTH-RESULTS], receivers generally should not 1020 trust such data without a good reason to do so, such as an a priori 1021 agreement with the MLM's ADMD. 1023 Such agreements are strongly advised to include a requirement that 1024 those header fields be covered by a [DKIM] signature added by the 1025 MLM's ADMD. 1027 10. References 1029 10.1. Normative References 1031 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 1032 Sender Signing Practises", RFC 5617, August 2009. 1034 [AUTH-RESULTS] 1035 Kucherawy, M., "Message Header Field for Indicating 1036 Message Authentication Status", RFC 5451, April 2009. 1038 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1039 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1040 Signatures", RFC 4871, May 2007. 1042 [EMAIL-ARCH] 1043 Crocker, D., "Internet Mail Architecture", RFC 5598, 1044 July 2009. 1046 [KEYWORDS] 1047 Bradner, S., "Key words for use in RFCs to Indicate 1048 Requirement Levels", BCP 14, RFC 2119, March 1997. 1050 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 1051 October 2008. 1053 10.2. Informative References 1055 [DKIM-DEPLOYMENT] 1056 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1057 "DomainKeys Identified Mail (DKIM) Development, Deployment 1058 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 1059 January 2010. 1061 [DKIM-OVERVIEW] 1062 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1063 Identified Mail (DKIM) Service Overview", RFC 5585, 1064 July 2009. 1066 [ENHANCED] 1067 Vaudreuil, G., "Enhanced Mail System Status Codes", 1068 RFC 3463, January 2003. 1070 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1071 Object Description Exchange Format", RFC 5070, 1072 December 2007. 1074 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1075 and Namespace for the Identification of Mailing Lists", 1076 RFC 2919, March 2001. 1078 [LIST-URLS] 1079 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1080 for Core Mail List Commands and their Transport through 1081 Message Header Fields", RFC 2369, July 1998. 1083 [MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 1084 Extensible Format for Email Feedback Reports", RFC 5965, 1085 August 2010. 1087 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1088 Extensions (MIME) Part One: Format of Internet Message 1089 Bodies", RFC 2045, November 1996. 1091 [MIME-TYPES] 1092 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1093 Extensions (MIME) Part Two: Media Types", RFC 2046, 1094 November 1996. 1096 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1097 October 2008. 1099 Appendix A. Acknowledgements 1101 The author wishes to acknowledge the following for their review and 1102 constructive criticism of this document: Serge Aumont, Daniel Black, 1103 Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear, Charles Lindsey, 1104 John Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and 1105 Alessandro Vesely. 1107 Appendix B. Example Scenarios 1109 This section describes a few MLM-related DKIM scenarios that were 1110 part of the impetus for this work, and the recommended resolutions 1111 for each. 1113 B.1. MLMs and ADSP 1115 Problem: 1117 o author ADMD advertises an ADSP policy of "dkim=discardable" 1119 o author sends DKIM-signed mail to a non-participating MLM, which 1120 invalidates the signature 1122 o receiver MTA checks DKIM and ADSP at SMTP time, and is configured 1123 to reject ADSP failures, so rejects this message 1125 o process repeats a few times, after which the MLM unsubscribes the 1126 receiver 1128 Solution: MLMs should refuse mail from domains advertising ADSP 1129 policies of "discardable" unless the MLMs are certain they make no 1130 changes that invalidate DKIM signatures. 1132 B.2. MLMs and FBLs 1134 Problem: 1136 o subscriber sends signed mail to a non-participating MLM that does 1137 not invalidate the signature 1139 o a recipient reports the message as spam 1141 o FBL at recipient ADMD sends report to contributor rather than list 1142 manager 1144 Solution: MLMs should sign mail they send and might also strip 1145 existing signatures; FBLs should report to list operators instead of 1146 subscribers where such can be distinguished, otherwise to all parties 1147 with valid signatures. 1149 Author's Address 1151 Murray S. Kucherawy 1152 Cloudmark 1153 128 King St., 2nd Floor 1154 San Francisco, CA 94107 1155 US 1157 Phone: +1 415 946 3800 1158 Email: msk@cloudmark.com