idnits 2.17.1 draft-kucherawy-dkim-lists-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 1, 2010) is 5076 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) -- 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Informational June 1, 2010 5 Expires: December 3, 2010 7 DKIM And Mailing Lists 8 draft-kucherawy-dkim-lists-01 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 December 3, 2010. 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. Feedback Loop References . . . . . . . . . . . . . . . . . 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 Lists . . . . . . . . . . . . . . . 9 65 3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10 66 3.4. Alternatives of Participation and Conformance . . . . . . 11 67 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 13 68 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 13 69 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13 70 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 14 71 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 15 72 5.1. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15 73 5.2. Author-Related Signing . . . . . . . . . . . . . . . . . . 15 74 5.3. Verification Outcomes at MLMs . . . . . . . . . . . . . . 15 75 5.4. Pros and Cons of Signature Removal . . . . . . . . . . . . 16 76 5.5. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 17 77 5.6. Verification Outcomes at Final Receiving Sites . . . . . . 18 78 5.7. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 18 79 5.8. Handling Choices at Receivers . . . . . . . . . . . . . . 19 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 7.1. Authentication Results When Relaying . . . . . . . . . . . 21 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 87 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 25 88 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 25 89 B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 25 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 [DKIM] allows an Administrative Mail Domain to take some 95 responsibility for a [MAIL] message. This can be an author's 96 organization, an operational relay (Mail Transfer Agent, or MTA) or 97 one of their agents. Assertion of responsibility is made through a 98 cryptographic signature. Message transit from author to recipient is 99 through relays that typically make no substantive change to the 100 message content and thus preserve the DKIM signature. 102 In contrast to relays, there are intermediaries, such as mailing list 103 managers (MLMs), that actively take delivery of messages, re-format 104 them, and re-post them, almost always invalidating DKIM signatures. 105 The goal for this document is to explore the use of DKIM for 106 scenarios that include intermediaries. Questions that will be 107 discussed include: 109 o When should an author, or its organization, use DKIM for mail sent 110 to mailing lists? 112 o What are the tradeoffs regarding having an MLM verify and use DKIM 113 identifiers? 115 o What are the tradeoffs regarding having an MLM remove exisitng 116 DKIM signatures prior to re-posting the message? 118 o What are the tradeoffs regarding having an MLM add its own DKIM 119 signature? 121 These and others are open questions for which there may be no 122 definitive answers. However, based on experience since the 123 publication of [DKIM] and its gradual deployment, there are some 124 useful views worth considering. 126 This document explores changes to common practice by the signers, the 127 verifiers and the MLMs. 129 1.1. Background 131 DKIM signatures permit an agent of the email architecture (see 132 [EMAIL-ARCH]) to make a claim of responsibility for a message by 133 affixing a domain-level digital signature to the message as it passes 134 through a gateway. Although not the only possibility, this is most 135 commonly done as a message passes through a Mail Transport Agent 136 (MTA) as it departs an Administrative Mail Domain (ADMD) toward the 137 general Internet. 139 DKIM signatures will fail to verify if a portion of the message 140 covered by one of its hashes is altered. MLMs commonly alter 141 messages to provide information specific to the mailing list for 142 which it is providing service. Common modifications include: 144 o Prefix the Subject: header field with a short string for easy 145 sorting by receivers' Mail User Agents (MUAs) or other filtering 146 software; 148 o Prepend or append list management information to the message's 149 body, such as some text and/or a URL to which subscribers can go 150 to make administrative changes to their subscriptions; 152 o Add header fields such as Reply-To:, Sender:, Resent-Sender: 153 ([MAIL]), List-Id: ([LIST-ID]), List-Post: or List-Unsubscribe: 154 ([LIST-URLS]). In some cases, such header fields are replaced if 155 the original message already contained them. 157 The DKIM specification documents deliberately refrain 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 could sign any message 160 regardless of its origin or author domain. As such, there is no 161 specification of any additional value if the content of the "d=" tag 162 in the DKIM signature and the value of (for example) the From header 163 field match, nor is there any obvious degraded value to a signature 164 where they do not match. Since any DKIM signature is merely an 165 assertion of "some" responsibility by an ADMD, a DKIM signature added 166 by an MLM has no more, or less, meaning as a signature with any other 167 "d=" value. 169 1.2. MLMs In Infrastructure 171 The previous section describes some of the things MLMs commonly do 172 that are not DKIM-friendly, producing broken signatures and thus 173 reducing the perceived value of DKIM. 175 Further, despite 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 and standards compliant. Thus, 181 the best approach is to provide these best practices to all parties 182 involved, imposing the minimum requirements possible to MLMs 183 themselves. 185 An MLM is an autonomous agent that takes delivery of a message 186 delivered to it and can re-post it as a new message (or construct a 187 digest of it along with other messages) to the members of the list 188 (see [EMAIL-ARCH], Section 5.3). However, the fact that the From 189 field of such a message is typically the same as for the original 190 message and that recipients perceive the message as "from" the 191 original author rather than the MLM creates confusion about 192 responsibility and autonomy for the re-posted message. This has 193 important implications for use of DKIM. 195 A DKIM signature on a message is an expression of some responsibility 196 for the message taken by the signing domain. An open question, one 197 this document intends to address, is some idea of how such a 198 signature might be applied by an recipient's evaluation module after 199 the message has gone through a mailing list, and may or may not have 200 been invalidated, and if so, where the invalidation may have 201 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 bulk mail sender 216 registers with an email receiving site to receive abuse reports from 217 that site for mail coming from the sender. 219 An FBL reporting address is part of this bi-lateral registration. 220 Some FBLs require DKIM use by the registrant. Messages signed and 221 sent by a registrant through an MLM can therefore result in having 222 abuse reports sent to the original author when the actual problem 223 pertains to the operation of the MLM. However, the original author 224 has no involvement in operation of the MLM, meaning the FBL report is 225 not actionable and thus undesirable. 227 1.4. Document Scope and Goals 229 This document provides discussion on the above issues, to improve the 230 handling of possible interactions between DKIM and MLMs. An attempt 231 has been made to prefer imposing changes to behaviour at the signer 232 and verifier rather than at the MLM. 234 Wherever possible, MLMs will be conceptually decoupled from MTAs 235 despite the very tight integration that is sometimes observed in 236 implementation. This is done to emphasize the functional 237 independence of MLM services and responsibilities from those of an 238 MTA. 240 2. Definitions 242 2.1. Other Terms 244 See [EMAIL-ARCH] for a general description of the current messaging 245 architecture, and for definitions of various terms used in this 246 document. 248 2.2. DKIM-Specific References 250 Readers are encouraged to become familiar with [DKIM] and [ADSP] 251 which are standards-track protocol documents as well as 252 [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT] which are DKIM's primary 253 tutorial documents. 255 2.3. Feedback Loop References 257 FBLs tend to use the ARF ([I-D.DRAFT-IETF-MARF-BASE]) or the IODEF 258 ([IODEF]) format. 260 2.4. Message Streams 262 This document makes reference to the concept of "message streams". 263 The idea is to identify groups of messages originating from within an 264 ADMD that are distinct in intent, origin and/or use, and partition 265 them somehow (most commonly via DNS subdomains, and/or the "d=" tag 266 value in the context of DKIM) so as to keep them associated to users 267 yet operationally distinct. 269 A good example might be user mail, generated by a company's 270 employees, versus operational or transactional mail that comes from 271 automated sources, versus marketing or sales campaigns; each of these 272 could have different security policies imposed against them, or there 273 might be a desire to insulate one from the other (e.g., a marketing 274 campaign that gets reported by many spam filters could cause the 275 marketing stream's reputation to degrade without automatically 276 punishing the transactional or user streams). 278 3. Mailing Lists and DKIM 280 It is important to make some distinctions among different MLM-like 281 agents, their typical implementations, and the impacts they have in a 282 DKIM-aware environment. 284 3.1. Roles and Realities 286 In DKIM parlance, there are several key roles in the transit of a 287 message. Most of these are defined in [EMAIL-ARCH]. 289 author: The agent that actually constructed the message being sent 290 through the system, and performed the initial submission. This 291 can be a human using an MUA or a common system utility such as 292 "cron", etc. 294 originator: The agent that accepts a message from the author, 295 ensures it conforms to the relevant standards such as [MAIL], and 296 then relays it toward its destination(s). This is often referred 297 to as the Mail Submission Agent (MSA). 299 signer: The agent that affixes one or more DKIM signature(s) to a 300 message on its way toward its ultimate destination. It is 301 typically running at the MTA that sits between the author's ADMD 302 and the general Internet. The signer and the originator may also 303 be the same agent. 305 verifier: The agent that conducts DKIM signature analysis. It is 306 typically running at the MTA that sits between the receiver's ADMD 307 and the general Internet. Note that any agent that handles a 308 signed message could conduct verification; this document only 309 considers that action and its outcomes either at an MLM or at the 310 receiver. 312 receiver: The agent that is the final transit relay for the message 313 prior to being delivered to the recipient(s) of the message. 315 In the case of simple user-to-user mail, these roles are fairly 316 straightforward. However, when one is sending mail to a list, which 317 then gets relayed to all of that list's subscribers, the roles are 318 often less clear to the general user, as particular agents may hold 319 multiple important but separable roles. The above definitions are 320 intended to enable more precise discussion of the mechanisms 321 involved. 323 3.2. Types Of Mailing Lists Lists 325 There are four common MLM implementation modes: 327 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 328 that makes no changes to a message as it redistributes; any 329 modifications are constrained to changes to the [SMTP] envelope 330 recipient list (RCPT commands) only. There are no changes to the 331 message body at all and only [MAIL] trace header fields are added. 332 The output of such an MLM is considered to be a continuation of 333 the author's original message. An example of such an MLM is a 334 address that expands directly in the MTA, such as a list of local 335 system administrators used for relaying operational or other 336 internal-only messages. 338 resending: A resending MLM (see Sections 5.2 and 5.3 of 339 [EMAIL-ARCH]) is one that may make changes to a message. The 340 output of such an MLM is considered to be a new message; delivery 341 of the original has been completed prior to distribution of the 342 re-posted message. Such messages are often re-formatted, such as 343 with list-specific header fields or other properties, to 344 facilitate discussion among list subscribers. 346 authoring: An authoring MLM is one that creates the content being 347 sent as well as initiating its transport, rather than basing it on 348 one or more messages received earlier. This is a special case of 349 the MLM paradigm, one which generates its own content and does not 350 act as an intermediary. Typically replies are not generated, or 351 if they are, they go to a specific recipient and not back to the 352 list's full set of recipients. Examples include newsletters and 353 bulk marketing mail. 355 digesting: A special case of the re-posting MLM is one that sends a 356 single message comprising an aggregation of recent MLM submissons, 357 which might be a message of [MIME] type "multipart/digest" (see 358 [MIME-TYPES]). This is obviously a new message but it may contain 359 a sequence of original messages that may themselves have been 360 DKIM-signed. 362 The remainder of this document operates on the presumption that a 363 message going through a resending MLM actually comprises two message 364 transactions: 366 1. Originating user to MLM: Originating user is author; originating 367 ADMD is signer; MLM's ADMD is verifier; MLM's input function is 368 receiver. 370 2. MLM to receivers: MLM (sending its reconstructed copy of the 371 originating user's message) is author; MLM's ADMD is signer; the 372 ADMD of each subscriber of the list is a verifier; each 373 subscriber is a receiver. 375 Much of this document focuses on the resending MLM as it has the most 376 direct conflict operationally with DKIM. 378 The dissection of the overall MLM operation into these two distinct 379 steps allows the DKIM-specific issues with respect to MLMs to be 380 isolated and handled in a logical way. The main issue is that the 381 repackaging and reposting of a message by an MLM is actually the 382 construction of a completely new message, and as such the MLM is 383 introducing new content into the email ecosystem, consuming the 384 author's copy of the message and creating its own. When considered 385 in this way, the dual role of the MLM and its ADMD becomes clear. 387 3.3. Current MLM Effects On Signatures 389 As described above, an aliasing MLM does not affect any existing 390 signature, and an authoring MLM is always new content and thus there 391 is never an existing signature. However, the changes a resending MLM 392 can make typically affect the Subject: header field, addition of some 393 list-specific header fields, and/or the addition of some list- 394 specific text to the top or bottom of the message body. The impacts 395 of each of these on DKIM verification are discussed below. 397 Subject tags: Altering the Subject: header field will invalidate the 398 signer's signature if that header field was covered by a hash of 399 that signature. [DKIM] lists Subject as one that should be 400 covered, so this is expected to be an issue for any list that 401 makes such changes. 403 List-specific header fields: Some lists will add header fields 404 specific to list administrative functions such as those defined in 405 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 406 [MAIL]. It is unlikely that a typical MUA would include such 407 fields in an original message, and DKIM is resilient to the 408 addition of header fields in general (though see notes about the 409 "h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as 410 less of a concern. 412 Other header fields: Some lists will add or replace header fields 413 such as "Reply-To" or "Sender" in order to establish that the 414 message is being sent in the context of the mailing list, so that 415 the list is identified ("Sender") and any user replies go to the 416 list ("Reply-To"). If these fields were included in the original 417 message, it is possible that one or more of them may have been 418 signed, and this could cause a concern for MLMs that add or 419 replace them. 421 Minor body changes: Some lists prepend or append a few lines to each 422 message to remind subscribers of an administrative URL for 423 subscription issues, or of list policy, etc. Changes to the body 424 will alter the body hash computed at the DKIM verifier, so these 425 pose an immediate problem. 427 Major body changes: There are some MLMs that make more substantial 428 changes to message bodies when preparing them for re-distribution, 429 such as deleting, reordering, or reformatting [MIME] parts, 430 "flatten" HTML messages into plain text, or insert headers or 431 footers within HTML messages. Most or all of these changes will 432 invalidate a DKIM signature with little or no hope of compensation 433 by either the signer or the verifier. 435 There reportedly still exist a few scattered mailing lists in 436 operation that are actually run manually by a human list manager. 438 In general, an MLM subscriber cannot be expected to be able to 439 reconstruct the original message as it appeared at time of signing 440 and thus whether or not an author signature is actually valid after 441 MLM rewriting. Moreover, even if an MLM currently passes messages 442 unmodified such that author signatures validate, it is possible that 443 a configuration change or software upgrade to that MLM will cause 444 that no longer to be true. 446 3.4. Alternatives of Participation and Conformance 448 As DKIM becomes more entrenched, it is highly desirable that MLM 449 software adopt more DKIM-friendly processing. 451 Changes that merely add new header fields, such as those specified by 452 [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to 453 a DKIM-participating email infrastructure in that their addition by 454 an MLM will not affect any existing DKIM signatures unless those 455 fields were already present and covered by a signature's hash or a 456 signature was created specifically to disallow their addition (see 457 the note about "h=" in Section 3.5 of [DKIM]). The shortest path to 458 success for DKIM would be to mandate that all MLM software be re- 459 designed or re-configured with that goal in mind. 461 However, the practice of applying headers and footers to message 462 bodies is common and not expected to fade regardless of what 463 documents this or any standards body might produce. This sort of 464 change will invalidate the signature on a message where the body hash 465 covers the entire entire message. Thus, the following sections also 466 investigate and recommend other processing alternatives. 468 A possible mitigation to this incompatibility is use of the "l=" tag 469 to bound the portion of the body covered by the body hash, but this 470 not workable for [MIME] messages and moreover has security 471 considerations (see Section 3.5 of [DKIM]). Its use is therefore 472 discouraged. 474 4. Non-Participating MLMs 476 This section contains a discussion of issues regarding sending DKIM- 477 signed mail to or through an MLM that is not DKIM-aware. 478 Specifically, the header fields introduced by [DKIM] and 479 [AUTH-RESULTS] carry no special meaning to such an MLM. 481 4.1. Author-Related Signing 483 If an author knows that the MLM to which a message is being sent is a 484 non-participating resending MLM, the author is advised to be cautious 485 when deciding whether or not to sign the message. The MLM could make 486 a change that would invalidate the author's signature but not remove 487 it prior to re-distribution. Hence, list recipients would receive a 488 message purportedly from the author but bearing a DKIM signature that 489 would not verifiy. This problem would be compounded further if there 490 were receivers that applied signing policies ([ADSP]) and the author 491 published any kind of strict policy. 493 If this is cause for concern, the originating site can consider using 494 a separate message stream, such as a sub-domain, for the "personal" 495 mail that is different from domain(s) used for other mail streams, so 496 that they develop independent reputations, and more stringent 497 policies (including ADSP) can be applied to the mail stream(s) that 498 do not go through mailing lists. 500 However, all of this presupposes a level of infrastructure 501 understanding that is not expected to be common. Thus, it will be 502 incumbent upon site administrators to consider how support of users 503 wishing to participate in mailing lists might be accomplished as DKIM 504 achieves wider adoption. A common suggestion is to establish 505 subdomains in the DNS that are used for separating different streams 506 of mail from within an ADMD, such as user-created "direct" mail from 507 transactional or automated mail; some of these may be signed and some 508 not, some with published ADSP records, some not. In general, the 509 more strict practices and policies are likely to be successful only 510 for the mail streams subject to the most end-to-end control by the 511 originating organization. That typically excludes mail going through 512 MLMs. 514 4.2. Verification Outcomes at Receivers 516 Verifiers that receive mail bearing DKIM signatures that fail to 517 verify might benefit from attempting to detect that such mail passed 518 through a non-participating MLM and then decide not to apply [ADSP] 519 in order to avoid aggressive filtering of mail that should otherwise 520 have been delivered. 522 Unfortunately, there may not be a reliable way of making such 523 determinations, as there is no uniform MLM behaviour, and any tagging 524 mechanism meant to relay such information could easily be abused. 526 Note that the underlying problem is the operational choice to use 527 ADSP in a message stream that does not maintain the signature. 529 4.3. Handling Choices at Receivers 531 A receiver's ADMD would have to have some way to register such non- 532 participating lists to exempt them from the filtering described in 533 Section 4.1. This is, however, probably not a scalable solution as 534 it imposes a burden on the receiver that is predicated on sender 535 behaviour. 537 Note that the [DKIM] specification explicitly directs verifiers to 538 treat a verification failure as though the message were not signed in 539 the first place. In the absence of specific ADSP direction, any 540 treatment of a verification failure as having special meaning is 541 either outside the scope of DKIM or is in violation of it. 543 [ADSP] presents an additional challenge. Per that specification, 544 when a message is unsigned or the signature can no longer be 545 verified, the verifier must discard the message. There is no 546 exception in the policy for a message that may have been altered by 547 an MLM. Verifiers are thus advised to honor the policy and disallow 548 the message. Furthermore, authors whose ADSP is published as 549 "discardable" are advised not to send mail to MLMs as it is likely to 550 be rejected by ADSP-aware recipients. (This is discussed further in 551 Section 5.4 below.) 553 5. Participating MLMs 555 This section contains a discussion of issues regarding sending DKIM- 556 signed mail to or through an MLM that is DKIM-aware, and may also be 557 ADSP-aware. 559 5.1. Subscriptions 561 At subscription time, an ADSP-aware MLM could check for a published 562 ADSP record for the new subscriber, and present a warning for one 563 whose ADMD's published policy is "discardable" indicating that 564 submissions from that ADMD may not be deliverable because of 565 modifications that are likely to be made to the message. 567 5.2. Author-Related Signing 569 MLMs typically attempt to authenticate messages posted through them. 570 They usually do this through the trivial (and insecure) means of 571 verifying the From field email address against a list registry. DKIM 572 enables a stronger form of authentication, although this is not yet 573 formally documented: It can require that messages using a given From 574 address also have a DKIM signature with a corresponding "d=" domain. 575 (Note, however, that it is entirely reasonable for an MLM to permit 576 registration of some other "d=" domain as valid evidence of such 577 authentication.) This feature would be somewhat similar to using 578 ADSP, except that the requirement for it would be imposed by the MLM 579 and not the author's organization. 581 An important consideration is that authors rarely have any direct 582 influence over the management of an MLM. As such, a signed message 583 from an author will in essence go to a set of unexpected places. 584 Authors may be well-advised to create a mail stream specifically used 585 for generating signatures when sending traffic to MLMs. This becomes 586 important as domain-based reputation systems begin to appear as 587 components of mail filtering modules. 589 This suggestion can be made more general. Mail that is of a 590 transactional or generally end-to-end nature, and not likely to be 591 forwarded around either by MLMs or users, should come from a 592 different mail stream than a stream that serves a broader purpose. 594 5.3. Verification Outcomes at MLMs 596 As described above, the MLM might conduct DKIM verification of a 597 signed message to attempt to confirm the identity of the author. 598 Although it is a common and intuitive conclusion, however, not all 599 signed mail will include an author signature (see [ADSP]). MLM 600 implementors are advised to accomodate such in their configurations. 602 For example, an MLM might be designed to accomodate a list of 603 possible signing domains (the "d=" portion of a DKIM signature) for a 604 given author, and determine at verification time if any of those are 605 present. 607 A message that cannot be thus authenticated could be held for 608 moderation or rejected outright. 610 This logic could apply to any list operation, not just list 611 submission. In particular, this improved authentication could apply 612 to subscription, unsubscription, and/or changes to subscriber options 613 that are sent via email rather than through an authenticated, 614 interactive channel such as the web. 616 In the case of verification of signatures on subscriptions, MLMs are 617 advised to add an [AUTH-RESULTS] header field to indicate the 618 signature(s) observed on the submission as it arrived at the MLM and 619 what the outcome of the evaluation was. Downstream agents may or may 620 not trust the content of that header field depending on their own a 621 priori knowledge of the operation of the ADMD generating (and, 622 preferably, signing) that header field. See [AUTH-RESULTS] for 623 further discussion. 625 5.4. Pros and Cons of Signature Removal 627 If the MLM is configured to make changes to the message prior to re- 628 posting that would invalidate the original signature(s), further 629 action is recommended to prevent invalidated signatures from arriving 630 at final recipients, possibly triggering unwarranted filter actions. 631 A possible solution would be to: 633 1. Attempt verification of all DKIM signatures present on the 634 message; 636 2. Apply local policy to authenticate the identity of the author; 638 3. Add an [AUTH-RESULTS] header field to the message to indicate the 639 results of the above; 641 4. Remove all previously-evaluated DKIM signatures; 643 5. Affix a new signature that covers the Authentication-Results 644 header field just added. 646 Removing the original signature(s) seems particularly appropriate 647 when the MLM knows it is likely to invalidate any or all of them due 648 to the nature of the reformatting it will do. This avoids false 649 negatives at the list's subscribers in their roles as receivers of 650 the message. 652 However, per the discussion in [AUTH-RESULTS], there is no a priori 653 reason for the final receivers to put any faith in the veracity of 654 that header field when added by the MLM. Thus, the final recipients 655 of the message have no way to verify on their own the authenticity of 656 the author's identity on that message. 658 Since an aliasing MLM makes no substantive changes to a message, it 659 need not consider the issue of signature removal as the original 660 signatures should arrive at least to the next MTA unmodified. It is 661 possible that future domain-based reputations would prefer a more 662 rich data set on receipt of a message, and in that case signature 663 removal would be undesirable. 665 An authoring MLM is closed to outside submitters, thus much of this 666 discussion does not apply in that case. 668 [ADSP] presents a particular challenge. An author domain posting a 669 policy of "discardable" imposes a very tight restriction on the use 670 of mailing lists, essentially constraining that domain's users to 671 lists operated by aliasing MLMs only; any MLM that alters a message 672 from such a domain or removes its signature subjects the message to 673 severe action by receivers. It is the consensus of the working group 674 that a resending MLM is advised to reject outright any mail from an 675 author whose domain posts such a policy as it is likely to be 676 rejected by any ADSP-aware recipients, and might also be well advised 677 to present a warning to such subscribers when first signing up to the 678 list. 680 5.5. MLM Signatures 682 DKIM-aware resending MLMs and authoring MLMs are encouraged to affix 683 their own signatures when distributing messages. The MLM is 684 responsible for the alterations it makes to the original messages it 685 is re-sending, and should express this via a signature. This is also 686 helpful for getting feedback from any FBLs that might be set up so 687 that undesired list mail can generate appropriate action. 689 A signing MLM is, as any other MLM, free to omit redistribution of a 690 message from an author if that message was not signed in accordance 691 with its own local configuration or policy. However, selective 692 signing is discouraged; essentially that would create two message 693 streams from the MLM, which can confuse verifiers and receivers. 695 A signing MLM is advised to add a List-Post: header field (see 696 [LIST-URLS]) using a DNS domain matching what will be used in the 697 "d=" tag of the DKIM signature it will add to the new message. This 698 could be used by verifiers or receivers to identify the DKIM 699 signature that was added by the MLM. 701 Such MLMs are advised to ensure the signature's header hash will 702 cover: 704 o Any [AUTH-RESULTS] fields added by the MLM; 706 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 708 o Any [MAIL] fields, especially Sender and Reply-To, added or 709 replaced by the MLM. 711 A DKIM-aware resending MLM is encouraged to sign the entire message 712 as it arrived, especially including the original signatures. 714 DKIM-aware authoring MLMs are advised to sign the mail they send 715 according to the regular signing guidelines given in [DKIM]. 717 Operators of non-DKIM-aware MLMs could arrange to submit MLM mail 718 through an MSA that is DKIM-aware so that its mail will be signed. 720 5.6. Verification Outcomes at Final Receiving Sites 722 In general, verifiers and receivers can treat a signed message from 723 an MLM like any other signed message; indeed, it would be difficult 724 to discern any difference. 726 However, because the author domain will commonly be different from 727 the MLM's signing domain, there may be a conflict with [ADSP] as 728 discussed in Section 4.3 and Section 5.4. 730 5.7. Use With FBLs 732 An FBL operator wishing act on a complaint by making use of DKIM 733 verifications is advised to send a report to any domain with a valid 734 signature that has an FBL agreement established, as DKIM signatures 735 are claims of some responsibility for that message. Because authors 736 generally have limited control over the operation of a list, this 737 point makes MLM signing all the more important. 739 Where the FBL wishes to be more specific, it could act solely on a 740 DKIM signature where the signing domain matches the DNS domain found 741 in a List-Post: header field (or similar). 743 5.8. Handling Choices at Receivers 745 A recipient that trusts signatures from an MLM may wish to extend 746 that trust to an [AUTH-RESULTS] header field signed by that MLM. The 747 recipient may then do additional processing of the message, using the 748 results recorded in the Authentication-Results header field instead 749 of the original author's DKIM signature. This includes possibly 750 processing the message as per ADSP requirements. 752 Receivers are advised to ignore all unsigned Authentication-Results 753 header fields. 755 Upon DKIM and ADSP evaluation, a receiver may decide to reject a 756 message during an SMTP session. If this is done, use of [ENHANCED] 757 is advised to make a distinction between messages rejected 758 deliberately due to policy decisions rather than those rejected 759 because of other deliverability issues. In particular, a policy 760 rejection is advised to be relayed using a 5.7.1 enhanced status 761 code, in contrast to a code of 5.1.1 indicating the user does not 762 exist. Those MLMs that attempt to automatically remove users with 763 prolonged delivery problems (such as account deletion) will thus be 764 able to tell the difference between policy rejection and delivery 765 failures, and act accordingly. Where the receiver's MTA does not 766 support enhanced status codes, [SMTP] reply codes could also be 767 carefully selected (554 and 550, respectively, for example). 769 6. IANA Considerations 771 This document includes no IANA actions. 773 7. Security Considerations 775 This document provides suggested or best current practices for use 776 with DKIM, and as such does not introduce any new technologies for 777 consideration. However, the following security issues should be 778 considered when implementing the above practices. 780 7.1. Authentication Results When Relaying 782 some stuff about the fact that the MLM's auth-results can't be 783 trusted by default 785 8. References 787 8.1. Normative References 789 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 790 Sender Signing Practises", RFC 5617, August 2009. 792 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 793 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 794 Signatures", RFC 4871, May 2007. 796 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 797 October 2008. 799 8.2. Informative References 801 [AUTH-RESULTS] 802 Kucherawy, M., "Message Header Field for Indicating 803 Message Authentication Status", RFC 5451, April 2009. 805 [DKIM-DEPLOYMENT] 806 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 807 "DomainKeys Identified Mail (DKIM) Development, Deployment 808 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 809 January 2010. 811 [DKIM-OVERVIEW] 812 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 813 Identified Mail (DKIM) Service Overview", RFC 5585, 814 July 2009. 816 [EMAIL-ARCH] 817 Crocker, D., "Internet Mail Architecture", RFC 5598, 818 July 2009. 820 [ENHANCED] 821 Vaudreuil, G., "Enhanced Mail System Status Codes", 822 RFC 3463, January 2003. 824 [I-D.DRAFT-IETF-MARF-BASE] 825 Shafranovich, Y., Levine, J., and M. Kucherawy, "An 826 Extensible Format for Email Feedback Reports", I-D DRAFT- 827 IETF-MARF-BASE, April 2010. 829 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 830 Object Description Exchange Format", RFC 5070, 831 December 2007. 833 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 834 and Namespace for the Identification of Mailing Lists", 835 RFC 2919, March 2001. 837 [LIST-URLS] 838 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 839 for Core Mail List Commands and their Transport through 840 Message Header Fields", RFC 2369, July 1998. 842 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 843 Extensions (MIME) Part One: Format of Internet Message 844 Bodies", RFC 2045, November 1996. 846 [MIME-TYPES] 847 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 848 Extensions (MIME) Part Two: Media Types", RFC 2046, 849 November 1996. 851 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 852 October 2008. 854 Appendix A. Acknowledgements 856 The author wishes to acknowledge the following for their review and 857 constructive criticism of this document: Dave Crocker, JD Falk, Tony 858 Hansen, Eliot Lear, John Levine and S. Moonesamy. 860 Appendix B. Example Scenarios 862 This section describes a few MLM-related DKIM scenarios that were 863 part of the impetus for this work, and the recommended resolutions 864 for each. 866 B.1. MLMs and ADSP 868 Problem: 870 o author ADMD advertise an ADSP policy of "dkim=discardable" 872 o author sends DKIM-signed mail to a non-participating MLM, which 873 invalidates the signature 875 o receiver MTA checks DKIM and ADSP at SMTP time, and is configured 876 to reject ADSP failures, so rejects this message 878 o process repeats a few times, after which the MLM unsubscribes the 879 receiver 881 Solution: MLMs should refuse mail from domains advertising ADSP 882 policies of "discardable" unless they are certain they make no 883 changes that invalidate DKIM signatures. 885 B.2. MLMs and FBLs 887 Problem: 889 o subscriber sends sign mail to a non-participating MLM that does 890 not invalidate the signature 892 o a recipient reports the message as spam 894 o FBL at recipient ADMD sends report to contributor rather than list 895 manager 897 Solution: MLMs should sign mail they send and should probably strip 898 signatures; FBLs should report to list operators instead of to 899 subscribers where such can be distinguished. 901 Author's Address 903 Murray S. Kucherawy 904 Cloudmark 905 128 King St., 2nd Floor 906 San Francisco, CA 94107 907 US 909 Phone: +1 415 946 3800 910 Email: msk@cloudmark.com