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