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