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