idnits 2.17.00 (12 Aug 2021) /tmp/idnits27573/draft-ietf-dkim-mailinglists-03.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 (October 4, 2010) is 4246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5672 (ref. 'DKIM-UPDATE') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5070 (ref. 'IODEF') (Obsoleted by RFC 7970) Summary: 2 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: Informational October 4, 2010 5 Expires: April 7, 2011 7 DKIM And Mailing Lists 8 draft-ietf-dkim-mailinglists-03 10 Abstract 12 DomainKeys Identified Mail (DKIM) allows an administrative mail 13 domain (ADMD) to assume some responsibility for a message. As the 14 industry has now gained some deployment experience, the goal for this 15 document is to explore the use of DKIM for scenarios that include 16 intermediaries, such as 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 April 7, 2011. 35 Copyright Notice 37 Copyright (c) 2010 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. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7 60 2.3. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7 61 2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7 62 3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8 64 3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9 65 3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10 66 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 12 67 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12 68 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13 69 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13 70 4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 13 71 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14 74 5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15 75 5.4. Author-Related Signing . . . . . . . . . . . . . . . . . . 15 76 5.5. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16 77 5.6. Pros and Cons of Signature Removal . . . . . . . . . . . . 16 78 5.7. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18 79 5.8. Verification Outcomes at Final Receiving Sites . . . . . . 19 80 5.9. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 19 81 5.10. Handling Choices at Receivers . . . . . . . . . . . . . . 20 82 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 8.1. Authentication Results When Relaying . . . . . . . . . . . 24 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 89 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 90 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 28 91 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 28 92 B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 28 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 1. Introduction 97 DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail 98 Domain to take some responsibility for a [MAIL] message. This can be 99 an author's organization, an operational relay (Mail Transfer Agent, 100 or MTA) or one of their agents. Assertion of responsibility is made 101 through a cryptographic signature. Message transit from author to 102 recipient is through relays that typically make no substantive change 103 to the message content and thus preserve the validity of the DKIM 104 signature. 106 In contrast to relays, there are intermediaries, such as mailing list 107 managers (MLMs), that actively take delivery of messages, re-format 108 them, and re-post them, often invalidating DKIM signatures. The goal 109 for this document is to explore the use of DKIM for scenarios that 110 include intermediaries. Questions that will be discussed include: 112 o Under what circumstances is it advisable for an author, or its 113 organization, to apply DKIM to mail sent to mailing lists? 115 o What are the tradeoffs regarding having an MLM verify and use DKIM 116 identifiers? 118 o What are the tradeoffs regarding having an MLM remove exisiting 119 DKIM signatures prior to re-posting the message? 121 o What are the tradeoffs regarding having an MLM add its own DKIM 122 signature? 124 These and others are open questions for which there may be no 125 definitive answers. However, based on experience since the 126 publication of [DKIM] and its gradual deployment, there are some 127 views that are useful to consider. 129 This document explores changes to common practice by the signers, the 130 verifiers and the MLMs. 132 In general there are, in relation to DKIM, two categories of MLMs: 133 participating and non-participating. As each types has its own 134 issues regarding DKIM-signed messages that are either handled or 135 produced by them (or both), the types are discussed in separate 136 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 gateway. Although not the only possibility, this is 144 most commonly done as a message passes through a Mail Transport Agent 145 (MTA) as it departs an Administrative Mail Domain (ADMD) toward the 146 general 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, this does not consider changes the MTA might 155 make independent of what changes the MLM chooses to apply. 157 The DKIM specification document deliberately refrains from the notion 158 of tying the signing domain (the "d=" tag in a DKIM signature) to any 159 identifier within a message; any ADMD that handles a message could 160 sign it, regardless of its origin or author domain. In particular, 161 DKIM does not define any meaning to the occurrence of a match between 162 the content of a "d=" tag and the value of, for example, a domain 163 name in the RFC5322.From field, nor is there any obvious degraded 164 value to a signature where they do not match. Since any DKIM 165 signature is merely an assertion of "some" responsibility by an ADMD, 166 a DKIM signature added by an MLM has no more, nor less, meaning than 167 a signature with any other "d=" value. 169 1.2. MLMs In Infrastructure 171 The previous section describes some of the things MLMs commonly do 172 that produce broken signatures and thus reducing the perceived value 173 of DKIM. 175 Further, while the advent of standards that are specific to MLM 176 behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption 177 has been spotty at best. Hence, efforts to specify the use of DKIM 178 in the context of MLMs needs to be incremental and value-based. 180 MLM behaviors are well-established. Although it can be argued that 181 they frustrate widespread DKIM adoption, it cannot be said that such 182 behaviours are not standards compliant. Thus, the best approach is 183 to provide these best practices to all parties involved, imposing the 184 minimum requirements possible to MLMs themselves. 186 An MLM is an autonomous agent that takes delivery of a message and 187 can re-post it as a new message, or construct a digest of it along 188 with other messages to the members of the list (see [EMAIL-ARCH], 189 Section 5.3). However, the fact that the RFC5322.From field of such 190 a message is typically the same as that of the original message and 191 that recipients perceive the message as "from" the original author 192 rather than the MLM creates confusion about responsibility and 193 autonomy for the re-posted message. This has important implications 194 for use of DKIM. 196 A DKIM signature on a message is an expression of some responsibility 197 for the message taken by the signing domain. An open issue, and one 198 this document intends to address, is some idea of how such a 199 signature might be used by a recipient's evaluation module after the 200 message has gone through a mailing list and may or may not have been 201 invalidated, and if it has, where the invalidation may have happened. 203 Note that where in this document there is discussion of an MLM 204 conducting validation of DKIM signatures or ADSP policies, the actual 205 implementation could be one where the validation is done by the MTA 206 or an agent attached to it, and the results of that work are relayed 207 by a trusted channel not specified here. See [AUTH-RESULTS] for a 208 discussion of this. This document does not favour any particular 209 arrangement of these agents over another, but merely talks about the 210 MLM itself doing the work as a matter of simplicity. 212 1.3. Feedback Loops And Other Bi-Lateral Agreements 214 A Feedback Loop (FBL) is a bi-lateral agreement between two parties 215 to exchange reports of abuse. Typically, a sender registers with a 216 receiving site to receive abuse reports from that site for mail 217 coming from the sender. 219 An FBL reporting address (i.e., an address to which FBL reports are 220 sent) is part of this bi-lateral registration. Some FBLs require 221 DKIM use by the registrant. Messages signed and sent by a registrant 222 through an MLM can therefore result in having abuse reports sent to 223 the original author when the actual problem pertains to the operation 224 of the MLM. However, the original author has no involvement in 225 operation of the MLM, meaning the FBL report is not actionable and 226 thus is undesirable. 228 See Section 6 for additional discussion. 230 FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) format. 232 1.4. Document Scope and Goals 234 This document provides discussion on the above issues, to improve the 235 handling of possible interactions between DKIM and MLMs. In general, 236 consensus shows a preference toward imposing changes to behaviour at 237 the signer and verifier rather than at the MLM. 239 Wherever possible, MLMs will be conceptually decoupled from MTAs 240 despite the very tight integration that is sometimes observed in 241 implementation. This is done to emphasize the functional 242 independence of MLM services and responsibilities from those of an 243 MTA. 245 2. Definitions 247 2.1. Other Terms 249 See [EMAIL-ARCH] for a general description of the current messaging 250 architecture, and for definitions of various terms used in this 251 document. 253 2.2. DKIM-Specific References 255 Readers are encouraged to become familiar with [DKIM] and [ADSP] 256 which are core specification documents as well as [DKIM-OVERVIEW] and 257 [DKIM-DEPLOYMENT] which are DKIM's primary tutorial documents. 259 2.3. 'DKIM-Friendly' 261 The term "DKIM-Friendly" is used to describe an email intermediary 262 that, when handling a message, makes no changes to that message which 263 cause valid [DKIM] signatures present on the message on input to fail 264 to verify on output. 266 Various features of MTAs and MLMs seen as helpful to users often have 267 side effects that do render DKIM signatures unverifiable. These 268 would not qualify for this label. 270 2.4. Message Streams 272 This document makes reference to the concept of "message streams". 273 The idea is to identify groups of messages originating from within an 274 ADMD that are distinct in intent, origin and/or use, and partition 275 them somehow (i.e., via changing the value in the "d=" tag value in 276 the context of DKIM) so as to keep them associated to users yet 277 distinct in terms of their evaluation and handling by verifiers or 278 receivers. 280 A good example might be user mail generated by a company's employees, 281 versus operational or transactional mail that comes from automated 282 sources, versus marketing or sales campaigns. Each of these could 283 have different security policies imposed against them, or there might 284 be a desire to insulate one from the other (e.g., a marketing 285 campaign that gets reported by many spam filters could cause the 286 marketing stream's reputation to degrade without automatically 287 punishing the transactional or user streams). 289 3. Mailing Lists and DKIM 291 It is important to make some distinctions among different MLM-like 292 agents, their typical implementations, and the impacts they have in a 293 DKIM-aware environment. 295 3.1. Roles and Realities 297 In DKIM parlance, there are several key roles in the transit of a 298 message. Most of these are defined in [EMAIL-ARCH]. 300 author: The agent that provided the content of the message being 301 sent through the system, and performed the initial submission. 302 This can be a human using an MUA or a common system utility such 303 as "cron", etc. 305 originator: The agent that accepts a message from the author, 306 ensures it conforms to the relevant standards such as [MAIL], and 307 then relays it toward its destination(s). This is often referred 308 to as the Mail Submission Agent (MSA). 310 signer: The agent that affixes one or more DKIM signature(s) to a 311 message on its way toward its ultimate destination. It is 312 typically running at the MTA that sits between the author's ADMD 313 and the general Internet. The signer may also be the same agent 314 as the originator and/or author. 316 verifier: The agent that conducts DKIM signature analysis. It is 317 typically running at the MTA that sits between the general 318 Internet and the receiver's ADMD. Note that any agent that 319 handles a signed message could conduct verification; this document 320 only considers that action and its outcomes either at an MLM or at 321 the receiver. Filtering decisions could be made by this agent 322 based on verificaiton results. 324 receiver: The agent that is the final transit relay for the message 325 prior to being delivered to the recipient(s) of the message. 326 Filtering decisions based on results made by the verifier could be 327 applied by the receiver. The verifier and the receiver could be 328 the same agent. 330 In the case of simple user-to-user mail, these roles are fairly 331 straightforward. However, when one is sending mail to a list, which 332 then gets relayed to all of that list's subscribers, the roles are 333 often less clear to the general user as particular agents may hold 334 multiple important but separable roles. The above definitions are 335 intended to enable more precise discussion of the mechanisms 336 involved. 338 3.2. Types Of Mailing Lists 340 There are four common MLM implementation modes: 342 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 343 that makes no changes to a message as it redistributes; any 344 modifications are constrained to changes to the [SMTP] envelope 345 recipient list (RCPT commands) only. There are no changes to the 346 message body at all and only [MAIL] trace header fields are added. 347 The output of such an MLM is considered to be a continuation of 348 the author's original message. An example of such an MLM is an 349 address that expands directly in the MTA, such as a list of local 350 system administrators used for relaying operational or other 351 internal-only messages. See also Section 3.9.2 of [SMTP]. 353 resending: A resending MLM (see Sections 5.2 and 5.3 of 354 [EMAIL-ARCH]) is one that may make changes to a message. The 355 output of such an MLM is considered to be a new message; delivery 356 of the original has been completed prior to distribution of the 357 re-posted message. Such messages are often re-formatted, such as 358 with list-specific header fields or other properties, to 359 facilitate discussion among list subscribers. 361 authoring: An authoring MLM is one that creates the content being 362 sent as well as initiating its transport, rather than basing it on 363 one or more messages received earlier. This is a special case of 364 the MLM paradigm, one that generates its own content and does not 365 act as an intermediary. Typically replies are not generated, or 366 if they are, they go to a specific recipient and not back to the 367 list's full set of recipients. Examples include newsletters and 368 bulk marketing mail. 370 digesting: A special case of the resending MLM is one that sends a 371 single message comprising an aggregation of recent MLM submissons, 372 which might be a message of [MIME] type "multipart/digest" (see 373 [MIME-TYPES]). This is obviously a new message but it may contain 374 a sequence of original messages that may themselves have been 375 DKIM-signed. 377 In the remainder of this document we distinguish two relevant steps, 378 corresponding to the following SMTP transactions: 380 MLM Input: Originating user is author; originating ADMD is 381 originator and signer; MLM's ADMD is verifier; MLM's input 382 function is receiver. 384 MLM Output: MLM (sending its reconstructed copy of the originating 385 user's message) is author; MLM's ADMD is originator and signer; 386 the ADMD of each subscriber of the list is a verifier; each 387 subscriber is a receiver. 389 Much of this document focuses on the resending class of MLM as it has 390 the most direct conflict operationally with DKIM. 392 The dissection of the overall MLM operation into these two distinct 393 steps allows the DKIM-specific issues with respect to MLMs to be 394 isolated and handled in a logical way. The main issue is that the 395 repackaging and reposting of a message by an MLM is actually the 396 construction of a completely new message, and as such the MLM is 397 introducing new content into the email ecosystem, consuming the 398 author's copy of the message and creating its own. When considered 399 in this way, the dual role of the MLM and its ADMD becomes clear. 401 Some issues about these activities are discussed in Section 3.6.4 of 402 [MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. 404 3.3. Current MLM Effects On Signatures 406 As described above, an aliasing MLM does not affect any existing 407 signature, and an authoring MLM is always creating new content and 408 thus there is never an existing signature. However, the changes a 409 resending MLM can make typically affect the RFC5322.Subject header 410 field, addition of some list-specific header fields, and/or 411 modification of the message body. The impacts of each of these on 412 DKIM verification are discussed below. 414 Subject tags: A popular feature of MLMs is the "tagging" of an 415 RFC5322.Subject field by prefixing the field's contents with the 416 name of the list, such as "[example]" for a list called "example". 417 Altering the RFC5322.Subject field on new submissions by adding a 418 list-specific prefix or suffix will invalidate the signer's 419 signature if that header field was included when creating that 420 signature. [DKIM] lists RFC5322.Subject as one that should be 421 covered, so this is expected to be an issue for any list that 422 makes such changes. 424 List-specific header fields: Some lists will add header fields 425 specific to list administrative functions such as those defined in 426 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 427 [MAIL]. It is unlikely that a typical MUA would include such 428 fields in an original message, and DKIM is resilient to the 429 addition of header fields in general (see notes about the "h=" tag 430 in Section 3.5 of [DKIM]). Therefore this is seen as less of a 431 concern. 433 Other header fields: Some lists will add or replace header fields 434 such as "Reply-To" or "Sender" in order to establish that the 435 message is being sent in the context of the mailing list, so that 436 the list is identified ("Sender") and any user replies go to the 437 list ("Reply-To"). If these fields were included in the original 438 message, it is possible that one or more of them may have been 439 signed, and those signatures will thus be broken. 441 Minor body changes: Some lists prepend or append a few lines to each 442 message to remind subscribers of an administrative URL for 443 subscription issues, or of list policy, etc. Changes to the body 444 will alter the body hash computed at the DKIM verifier, so these 445 will render any exisitng signatures unverifiable. 447 Major body changes: There are some MLMs that make more substantial 448 changes to message bodies when preparing them for re-distribution, 449 such as adding, deleting, reordering, or reformatting [MIME] 450 parts, "flatten" HTML messages into plain text, or insert headers 451 or footers within HTML messages. Most or all of these changes 452 will invalidate a DKIM signature. 454 MIME part removal: Some MLMs that are MIME-aware will remove large 455 MIME parts from submissions and replace them with URLs to reduce 456 the size of the distributed form of the message and to prevent 457 inadvertent automated malware delivery. Except in cases where a 458 body length limit is applied in generation of the DKIM signature, 459 the signature will be broken. 461 There reportedly still exist a few scattered mailing lists in 462 operation that are actually run manually by a human list manager, 463 whose workings in preparing a message for distribution could include 464 the above or even some other changes. 466 In general, absent a general movement by MLM developers and operators 467 toward more DKIM-friendly practices, an MLM subscriber cannot expect 468 signatures applied before the message was processed by the MLM to be 469 valid. Such an evolution is not expected in the short term due to 470 general development and deployment inertia. Moreover, even if an MLM 471 currently passes messages unmodified such that author signatures 472 validate, it is possible that a configuration change or software 473 upgrade to that MLM will cause that no longer to be true. 475 4. Non-Participating MLMs 477 This section contains a discussion of issues regarding sending DKIM- 478 signed mail to or through an MLM that is not DKIM-aware. 479 Specifically, the header fields introduced by [DKIM] and 480 [AUTH-RESULTS] carry no special meaning to such an MLM. 482 4.1. Author-Related Signing 484 If an author knows that the MLM to which a message is being sent is a 485 non-participating resending MLM, the author is advised to be cautious 486 when deciding whether or not to send to the list when that mail would 487 be signed. The MLM could make a change that would invalidate the 488 author's signature but not remove it prior to re-distribution. 489 Hence, list recipients would receive a message purportedly from the 490 author but bearing a DKIM signature that would not verifiy. There 491 exist DKIM modules that incorrectly penalize messages with signatures 492 that do not validate, so this may have have detrimental effects 493 outside of the author's control. (Additional discussion of this is 494 below.) This problem could be compounded if there were receivers 495 that applied signing policies (e.g., [ADSP]) and the author published 496 any kind of strict policy. 498 For domains that do publish strict ADSP policies, the originating 499 site can consider using a separate message stream, such as a sub- 500 domain, for the "personal" mail -- a subdomain that is different from 501 domain(s) used for other mail streams. This allows each to develop 502 an independent reputation, and more stringent policies (including 503 ADSP) can be applied to the mail stream(s) that do not go through 504 mailing lists or perhaps do not get signed at all. 506 However, all of this presupposes a level of infrastructure 507 understanding that is not expected to be common. Thus, it will be 508 incumbent upon site administrators to consider how support of users 509 wishing to participate in mailing lists might be accomplished as DKIM 510 achieves wider adoption. 512 In general, the more strict practices and policies are likely to be 513 successful only for the mail streams subject to the most end-to-end 514 control by the originating organization. That typically excludes 515 mail going through MLMs. Therefore, authors whose ADSP is published 516 as "discardable" are advised not to send mail to MLMs, as it is 517 likely to be rejected by ADSP-aware recipients. (This is discussed 518 further in Section 5.6 below.) 520 4.2. Verification Outcomes at Receivers 522 There does not appear to be a reliable way to determine that a piece 523 of mail arrived via a non-participating MLM. Sites whose users 524 subscribe to non-participating MLMs should be prepared for legitimate 525 mail to arrive with no valid signature, just as it always has in the 526 absence of DKIM. 528 4.3. Handling Choices at Receivers 530 A receiver's ADMD would have to have some way to register such non- 531 participating lists to exempt them from the expectation of signed 532 mail as discussed in Section 4.1. This is, however, probably not a 533 scalable solution as it imposes a burden on the receiver that is 534 predicated on sender behaviour. 536 Note that the [DKIM] specification explicitly directs verifiers to 537 treat a verification failure as though the message was not signed in 538 the first place. In the absence of specific ADSP direction, any 539 treatment of a verification failure as having special meaning is 540 either outside the scope of DKIM or is in violation of it. 542 Use of restrictive domain policies such as [ADSP] "discardable" 543 presents an additional challenge. In that case, when a message is 544 unsigned or the signature can no longer be verified, the verifier is 545 requested to discard the message. There is no exception in the 546 policy for a message that may have been altered by an MLM, nor is 547 there a reliable way to identify such mail. Receivers are thus 548 advised to honor the policy and disallow the message. 550 4.4. Wrapping A Non-Participating MLM 552 One approach to adding DKIM support to an otherwise non-participating 553 MLM is to "wrap" it, or in essence place it between other DKIM-aware 554 components (such as MTAs) that provide some DKIM services. For 555 example, the ADMD operating a non-participating MLM could have a DKIM 556 verifier act on submissions, enforcing some of the features and 557 recommendations of Section 5 on behalf of the MLM, and the MTA or MSA 558 receiving the MLM Output could also add a DKIM signature for hte 559 MLM's domain. 561 5. Participating MLMs 563 This section contains a discussion of issues regarding sending DKIM- 564 signed mail to or through an MLM that is DKIM-aware, and may also be 565 ADSP-aware. 567 5.1. General 569 As DKIM becomes more widely deployed, it is highly desirable that MLM 570 software adopt more DKIM-friendly processing. 572 Changes that merely add new header fields, such as those specified by 573 [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to 574 a DKIM-participating email infrastructure, in that their addition by 575 an MLM will not affect any existing DKIM signatures unless those 576 fields were already present and covered by a signature's hash or a 577 signature was created specifically to disallow their addition (see 578 the note about "h=" in Section 3.5 of [DKIM]). 580 However, the practice of applying headers and footers to message 581 bodies is common and not expected to fade regardless of what 582 documents this or any standards body might produce. This sort of 583 change will invalidate the signature on a message where the body hash 584 covers the entire message. Thus, the following sections also 585 investigate and recommend other processing alternatives. 587 A possible mitigation to this incompatibility is use of the "l=" tag 588 to bound the portion of the body covered by the DKIM body hash, but 589 this is not workable for [MIME] messages; moreover, it has security 590 considerations (see Section 3.5 of [DKIM]). Its use is therefore 591 discouraged. 593 MLM operators often arrange to affix to outgoing messages expressions 594 of list-specific policy and related information (e.g., rules for 595 participation, small advertisements, etc.). There is currently no 596 header field proposed for relaying such general operational MLM 597 details apart from what [LIST-URLS] already supports. This sort of 598 information is what is commonly included in appended footer text or 599 prepended header text. The working group recommends periodic, 600 automatic mailings to the list to remind subscribers of list policy. 601 These will be repetitive, of course, but by being generally the same 602 each time they can be easily filtered if desired. 604 5.2. DKIM Author Domain Signing Practices 606 [ADSP] presents a particular challenge. An author domain posting a 607 policy of "discardable" imposes a very tight restriction on the use 608 of mailing lists, essentially constraining that domain's users to 609 lists operated by aliasing MLMs only; any MLM that alters a message 610 from such a domain or removes its signature subjects the message to 611 severe action by receivers. It is the consensus of the working group 612 that a resending MLM is advised to reject outright any mail from an 613 author whose domain posts such a policy as it is likely to be 614 rejected by any ADSP-aware recipients, and might also be well advised 615 to discourage such subscribers when they first sign up to the list. 616 Further discussion of this appears in Section 5.3. 618 Where the above practice is not observed and "discardable" mail 619 arrives via a list to a verifier that applies ADSP checks, the 620 receiver can either discard the message (i.e. accept the message at 621 the [SMTP] level but discard it without delivery) or conduct an SMTP 622 rejection by returning a 5xx error code. In the latter case, some 623 advice for how to conduct the rejection in a potentially meaningful 624 way can be found in Section 5.10. 626 See also Appendix B.5 of [ADSP] for further discussion. 628 5.3. Subscriptions 630 At subscription time, an ADSP-aware MLM could check for a published 631 ADSP record for the new subscriber's domain. If the policy specifies 632 "discardable", the MLM might disallow the subscription or present a 633 warning that the subscriber's submissions to the mailing list might 634 not be deliverable to some recipients because subscriber's ADMD's 635 published policy. 637 Of course, such a policy record could be applied after subscription, 638 so this is not a universal solution. An MLM implementation could do 639 periodic checks of its subscribers and issue warnings where such a 640 policy is detected, or simply check for each submission. 642 5.4. Author-Related Signing 644 An important consideration is that authors rarely have any direct 645 influence over the management of an MLM. As such, a signed message 646 from an author will in essence go to a set of unexpected places, 647 sometimes coupled with other messages from other sources. In the 648 future, as DKIM signature outputs (e.g. the SDID of [DKIM-UPDATE]) 649 are used as inputs to reputation modules, there may be a desire to 650 insulate one's reputation from influence by the unknown results of 651 sending mail through an MLM. In that case, authors may be well- 652 advised to create a mail stream specifically used for generating 653 signatures when sending traffic to MLMs. 655 This suggestion can be made more general. Mail that is of a 656 transactional or generally end-to-end nature, and not likely to be 657 forwarded around either by MLMs or users, should come from a 658 different mail stream than a stream that serves more varied uses. 660 5.5. Verification Outcomes at MLMs 662 MLMs typically attempt to authenticate messages posted through them. 663 They usually do this through the trivial (and insecure) means of 664 verifying the RFC5322.From field email address (or, less frequently, 665 the RFC5321.MailFrom parameter) against a list registry. DKIM 666 enables a stronger form of authentication, although this is not yet 667 formally documented: It can require that messages using a given 668 RFC5322.From address also have a DKIM signature with a corresponding 669 "d=" domain. This feature would be somewhat similar to using ADSP, 670 except that the requirement for it would be imposed by the MLM and 671 not the author's organization. 673 As described, the MLM might conduct DKIM verification of a signed 674 message to attempt to confirm the identity of the author. Although 675 it is a common and intuitive conclusion, not all signed mail will 676 include an author signature (see [ADSP]). MLM implementors are 677 advised to accomodate such in their configurations. For example, an 678 MLM might be designed to accomodate a list of possible signing 679 domains (the "d=" portion of a DKIM signature) for a given author, 680 and determine at verification time if any of those are present. 682 A message that cannot be thus authenticated could be held for 683 moderation or rejected outright. 685 This logic could apply to any list operation, not just list 686 submission. In particular, this improved authentication could apply 687 to subscription, unsubscription, and/or changes to subscriber options 688 that are sent via email rather than through an authenticated, 689 interactive channel such as the web. 691 In the case of verification of signatures on submissions, MLMs are 692 advised to add an [AUTH-RESULTS] header field to indicate the 693 signature(s) observed on the submission as it arrived at the MLM and 694 what the outcome of the evaluation was. Downstream agents may or may 695 not trust the content of that header field depending on their own a 696 priori knowledge of the operation of the ADMD generating (and, 697 preferably, signing) that header field. See [AUTH-RESULTS] for 698 further discussion. 700 5.6. Pros and Cons of Signature Removal 702 A message that arrives signed with DKIM means some domain prior to 703 MLM Input has made a claim of some responsibility for the message. 704 An obvious benefit to leaving the input-side signatures intact, then, 705 is to preserve that chain of responsibility of the message so that 706 the receivers of the final message have an opportunity to evaluate 707 the message with that information available to them. 709 However, if the MLM is configured to make changes to the message 710 prior to re-posting that would invalidate the original signature(s), 711 further action is recommended to prevent invalidated signatures from 712 arriving at final recipients, possibly triggering unwarranted filter 713 actions. (Note, however, that such filtering actions are plainly 714 wrong; [DKIM] stipulates that an invalid signature is to be treated 715 as no signature at all.) 717 A possible solution would be to: 719 1. Attempt verification of all DKIM signatures present on the input 720 message; 722 2. Apply local policy to authenticate the identity of the author; 724 3. Add an [AUTH-RESULTS] header field to the message to indicate the 725 results of the above; 727 4. Remove all previously-evaluated DKIM signatures; 729 5. Affix a new signature that covers the Authentication-Results 730 header field just added (see Section 5.7). 732 Removing the original signature(s) seems particularly appropriate 733 when the MLM knows it is likely to invalidate any or all of them due 734 to the nature of the reformatting it will do. This avoids false 735 negatives at the list's subscribers in their roles as receivers of 736 the message; although [DKIM] stipulates that an invalid signature is 737 the same as no signature, it is anticipated that there will be some 738 implementations that ignore this advice. 740 The MLM could re-evaluate exisiting signatures after making its 741 message changes to determine whether or not any of them have been 742 invalidated. The cost of this is reduced by the fact that, 743 presumably, the necessary public keys have already been downloaded 744 and one or both of the message hashes could be reused. 746 Per the discussion in [AUTH-RESULTS], there is no a priori reason for 747 the final receivers to put any faith in the veracity of that header 748 field when added by the MLM. Thus, the final recipients of the 749 message have no way to verify on their own the authenticity of the 750 author's identity on that message. However, should that field be the 751 only one on the message when the verifier gets it, and the verifier 752 explicitly trusts the signer (in this case, the MLM), the verifier is 753 in a position to believe that a valid author signature was present on 754 the message. 756 Since an aliasing MLM makes no substantive changes to a message, it 757 need not consider the issue of signature removal as the original 758 signatures should arrive at least to the next MTA unmodified. It is 759 possible that future domain-based reputations would prefer a more 760 rich data set on receipt of a message, and in that case signature 761 removal would be undesirable. 763 An authoring MLM is closed to outside submitters, thus much of this 764 discussion does not apply in that case. 766 5.7. MLM Signatures 768 DKIM-aware resending MLMs and authoring MLMs are encouraged to affix 769 their own signatures when distributing messages. The MLM is 770 responsible for the alterations it makes to the original messages it 771 is re-sending, and should express this via a signature. This is also 772 helpful for getting feedback from any FBLs that might be set up so 773 that undesired list mail can generate appropriate action. 775 MLM signatures will likely be used by recipient systems to recognize 776 list mail, and they give the MLM's ADMD an opportunity to develop a 777 good reputation for the list itself. 779 A signing MLM is, as any other MLM, free to omit redistribution of a 780 message if that message was not signed in accordance with its own 781 local configuration or policy. It could also redistribute but not 782 sign such mail. However, selective signing is discouraged; 783 essentially that would create two message streams from the MLM, one 784 signed and one not, which can confuse DKIM-aware verifiers and 785 receivers. 787 As is typical with DKIM signing, the MLM signature must be generated 788 immediately prior to sending, only after all other processing the MLM 789 wishes to apply has been completed. Failing to do so generates a 790 signature that can not be expected to validate. 792 A signing MLM could add a List-Post: header field (see [LIST-URLS]) 793 using a DNS domain matching what will be used in the "d=" tag of the 794 DKIM signature it will add to the new message. This could be used by 795 verifiers or receivers to identify the DKIM signature that was added 796 by the MLM. This is not required, however; it is believed the 797 reputation of the signer will be a more critical data point rather 798 than this suggested binding. Furthermore, this is not a binding 799 recognized by any current specification document. 801 Such MLMs are advised to ensure the signature's header hash will 802 cover: 804 o Any [AUTH-RESULTS] fields added by the MLM; 806 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 808 o Any [MAIL] fields, especially Sender and Reply-To, added or 809 replaced by the MLM. 811 A DKIM-aware resending MLM is encouraged to sign the entire message 812 after being prepared for distribution (i.e. the "MLM Output" from 813 Section 3.2), including any original signatures. 815 DKIM-aware authoring MLMs are advised to sign the mail they send 816 according to the regular signing guidelines given in [DKIM]. 818 One concern is that having an MLM apply its signature to unsigned 819 mail might cause some verifiers or receivers to interpret the 820 signature as conferring more authority or authenticity to the message 821 content than is defined by [DKIM]. This is an issue beyond MLMs and 822 primarily entails receive-side processing outside of the scope of 823 [DKIM]. It is nevertheless worth noting here. In the case of MLMs, 824 the presence of an MLM signature is best treated as similar to MLM 825 handling that affixes an RFC5322.Subject tag or similar information. 826 It therefore does not introduce any new concerns. 828 5.8. Verification Outcomes at Final Receiving Sites 830 In general, verifiers and receivers can treat a signed message from 831 an MLM like any other signed message; indeed, it would be difficult 832 to discern any difference since specifications such as [LIST-URLS] 833 and [LIST-ID] are not universally deployed and can be trivially 834 spoofed. 836 However, because the author domain will commonly be different from 837 the MLM's signing domain, there may be a conflict with [ADSP] as 838 discussed in Section 4.3 and Section 5.6, especially where an ADMD 839 has misused ADSP. 841 5.9. Use With FBLs 843 An FBL operator may wish to act on a complaint from a user about a 844 posting to a list. Some FBLs could choose to generate feedback 845 reports based on DKIM verifications in the subject message. Such 846 operators are advised to send a report to each domain with a valid 847 signature that has an FBL agreement established, as DKIM signatures 848 are claims of some responsibility for that message. Because authors 849 generally have limited control over the operation of a list, this 850 point makes MLM signing all the more important. 852 Where the FBL wishes to be more specific, it could act solely on a 853 DKIM signature where the signing domain matches the DNS domain found 854 in a List-Post: header field (or similar). 856 Use of FBLs in this way should be made explicit to list subscribers. 857 For example, if it is the policy of the MLM's ADMD to handle an FBL 858 item by unsubscribing the user that was the apparent sender of the 859 offending message, advising subscribers of this in advance would help 860 to avoid surprises later. 862 5.10. Handling Choices at Receivers 864 A recipient that explicitly trusts signatures from a particular MLM 865 may wish to extend that trust to an [AUTH-RESULTS] header field 866 signed by that MLM. The recipient may then do additional processing 867 of the message, using the results recorded in the Authentication- 868 Results header field instead of the original author's DKIM signature. 869 This includes possibly processing the message as per ADSP 870 requirements. 872 Receivers are advised to ignore or remove all unsigned externally- 873 applied Authentication-Results header fields, and those not signed by 874 an ADMD that can be trusted by the receiver. See Section 5 and 875 Section 7 of [AUTH-RESULTS] for further discussion. 877 Upon DKIM and ADSP evaluation during an SMTP session (a common 878 implementation), a receiver may decide to reject a message during an 879 SMTP session. If this is done, use of an [SMTP] failure code not 880 normally used for "user unknown" (550) is suggested; 554 seems an 881 appropriate candidate. If the rejecting SMTP server supports 882 [ENHANCED] status codes, is advised to make a distinction between 883 messages rejected deliberately due to policy decisions rather than 884 those rejected because of other deliverability issues. In 885 particular, a policy rejection is advised to be relayed using a 5.7.1 886 enhanced status code and some appropriate wording in the text part of 887 the reply, in contrast to a code of 5.1.1 indicating the user does 888 not exist. Those MLMs that automatically attempt to remove users 889 with prolonged delivery problems (such as account deletion) will thus 890 be able to tell the difference between policy rejection and other 891 delivery failures, and act accordingly. SMTP servers doing so are 892 also advised to use appropriate wording in the text portion of the 893 reply, perhaps explicitly using the string "ADSP" to facilitate 894 searching of relevant data in logs. 896 The preceding paragraph does not apply to an [ADSP] policy of 897 "discardable". In such cases where the submission fails that test, 898 the receiver is strongly advised to discard the message but return an 899 SMTP success code, i.e. accept the message but drop it without 900 delivery. An SMTP rejection of such mail instead of the requested 901 discard action causes more harm than good. 903 6. DKIM Reporting 905 The MARF working group is developing mechanisms for reporting 906 forensic details about DKIM verification failures. At the time of 907 this writing, this is still a work in progress. 909 MLMs are encouraged to apply these or other DKIM failure reporting 910 mechanisms as a method for providing feedback to signers about issues 911 with DKIM infrastructure. This is especially important for MLMs that 912 implement DKIM verification as a mechanism for authentication of list 913 configuration commands and submissions from subscribers. 915 7. IANA Considerations 917 This document includes no IANA actions. 919 8. Security Considerations 921 This document provides suggested or best current practices for use 922 with DKIM, and as such does not introduce any new technologies for 923 consideration. However, the following security issues should be 924 considered when implementing the above practices. 926 8.1. Authentication Results When Relaying 928 Section 5 advocates addition of an [AUTH-RESULTS] header field to 929 indicate authentication status of a message received as MLM Input. 930 Per Section 7.2 of [AUTH-RESULTS], receivers generally should not 931 trust such data without a good reason to do so, such as an a priori 932 agreement with the MLM's ADMD to do so. 934 Such agreements are strongly advised to include a requirement that 935 those header fields be covered by a [DKIM] signature added by the 936 MLM's ADMD. 938 9. References 940 9.1. Normative References 942 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 943 Sender Signing Practises", RFC 5617, August 2009. 945 [AUTH-RESULTS] 946 Kucherawy, M., "Message Header Field for Indicating 947 Message Authentication Status", RFC 5451, April 2009. 949 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 950 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 951 Signatures", RFC 4871, May 2007. 953 [EMAIL-ARCH] 954 Crocker, D., "Internet Mail Architecture", RFC 5598, 955 July 2009. 957 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 958 October 2008. 960 9.2. Informative References 962 [DKIM-DEPLOYMENT] 963 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 964 "DomainKeys Identified Mail (DKIM) Development, Deployment 965 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 966 January 2010. 968 [DKIM-OVERVIEW] 969 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 970 Identified Mail (DKIM) Service Overview", RFC 5585, 971 July 2009. 973 [DKIM-UPDATE] 974 Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 975 Signatures -- Update", RFC 5672, August 2009. 977 [ENHANCED] 978 Vaudreuil, G., "Enhanced Mail System Status Codes", 979 RFC 3463, January 2003. 981 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 982 Object Description Exchange Format", RFC 5070, 983 December 2007. 985 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 986 and Namespace for the Identification of Mailing Lists", 987 RFC 2919, March 2001. 989 [LIST-URLS] 990 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 991 for Core Mail List Commands and their Transport through 992 Message Header Fields", RFC 2369, July 1998. 994 [MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 995 Extensible Format for Email Feedback Reports", RFC 5965, 996 August 2010. 998 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 999 Extensions (MIME) Part One: Format of Internet Message 1000 Bodies", RFC 2045, November 1996. 1002 [MIME-TYPES] 1003 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1004 Extensions (MIME) Part Two: Media Types", RFC 2046, 1005 November 1996. 1007 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1008 October 2008. 1010 Appendix A. Acknowledgements 1012 The author wishes to acknowledge the following for their review and 1013 constructive criticism of this document: Serge Aumont, Daniel Black, 1014 Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John 1015 Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and 1016 Alessandro Vesely. 1018 Appendix B. Example Scenarios 1020 This section describes a few MLM-related DKIM scenarios that were 1021 part of the impetus for this work, and the recommended resolutions 1022 for each. 1024 B.1. MLMs and ADSP 1026 Problem: 1028 o author ADMD advertises an ADSP policy of "dkim=discardable" 1030 o author sends DKIM-signed mail to a non-participating MLM, which 1031 invalidates the signature 1033 o receiver MTA checks DKIM and ADSP at SMTP time, and is configured 1034 to reject ADSP failures, so rejects this message 1036 o process repeats a few times, after which the MLM unsubscribes the 1037 receiver 1039 Solution: MLMs should refuse mail from domains advertising ADSP 1040 policies of "discardable" unless the MLMs are certain they make no 1041 changes that invalidate DKIM signatures. 1043 B.2. MLMs and FBLs 1045 Problem: 1047 o subscriber sends signed mail to a non-participating MLM that does 1048 not invalidate the signature 1050 o a recipient reports the message as spam 1052 o FBL at recipient ADMD sends report to contributor rather than list 1053 manager 1055 Solution: MLMs should sign mail they send and might also strip 1056 existing signatures; FBLs should report to list operators instead of 1057 subscribers where such can be distinguished, otherwise to all parties 1058 with valid signatures. 1060 Author's Address 1062 Murray S. Kucherawy 1063 Cloudmark 1064 128 King St., 2nd Floor 1065 San Francisco, CA 94107 1066 US 1068 Phone: +1 415 946 3800 1069 Email: msk@cloudmark.com