idnits 2.17.00 (12 Aug 2021) /tmp/idnits33498/draft-ietf-dkim-mailinglists-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 (July 26, 2010) is 4316 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 DKIM Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Informational July 26, 2010 5 Expires: January 27, 2011 7 DKIM And Mailing Lists 8 draft-ietf-dkim-mailinglists-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 January 27, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4 55 1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5 56 1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 5 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7 60 2.3. 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 16 75 5.4. Pros and Cons of Signature Removal . . . . . . . . . . . . 16 76 5.5. DKIM Author Domain Signing Practices . . . . . . . . . . . 17 77 5.6. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18 78 5.7. Verification Outcomes at Final Receiving Sites . . . . . . 19 79 5.8. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 19 80 5.9. Handling Choices at Receivers . . . . . . . . . . . . . . 20 81 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 21 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 8.1. Authentication Results When Relaying . . . . . . . . . . . 23 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 89 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 27 90 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 27 91 B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 27 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 94 1. Introduction 96 [DKIM] allows an Administrative Mail Domain to take some 97 responsibility for a [MAIL] message. This can be an author's 98 organization, an operational relay (Mail Transfer Agent, or MTA) or 99 one of their agents. Assertion of responsibility is made through a 100 cryptographic signature. Message transit from author to recipient is 101 through relays that typically make no substantive change to the 102 message content and thus preserve the DKIM signature. 104 In contrast to relays, there are intermediaries, such as mailing list 105 managers (MLMs), that actively take delivery of messages, re-format 106 them, and re-post them, almost always invalidating DKIM signatures. 107 The goal for this document is to explore the use of DKIM for 108 scenarios that include intermediaries. Questions that will be 109 discussed include: 111 o When should an author, or its organization, use DKIM for mail sent 112 to mailing lists? 114 o What are the tradeoffs regarding having an MLM verify and use DKIM 115 identifiers? 117 o What are the tradeoffs regarding having an MLM remove exisitng 118 DKIM signatures prior to re-posting the message? 120 o What are the tradeoffs regarding having an MLM add its own DKIM 121 signature? 123 These and others are open questions for which there may be no 124 definitive answers. However, based on experience since the 125 publication of [DKIM] and its gradual deployment, there are some 126 useful views worth considering. 128 This document explores changes to common practice by the signers, the 129 verifiers and the MLMs. 131 1.1. Background 133 DKIM signatures permit an agent of the email architecture (see 134 [EMAIL-ARCH]) to make a claim of responsibility for a message by 135 affixing a domain-level digital signature to the message as it passes 136 through a gateway. Although not the only possibility, this is most 137 commonly done as a message passes through a Mail Transport Agent 138 (MTA) as it departs an Administrative Mail Domain (ADMD) toward the 139 general Internet. 141 DKIM signatures will fail to verify if a portion of the message 142 covered by one of its hashes is altered. MLMs commonly alter 143 messages to provide information specific to the mailing list for 144 which it is providing service. Common modifications include: 146 o Prefix the RFC5322.Subject field with a short string for easy 147 sorting by receivers' Mail User Agents (MUAs) or other filtering 148 software; 150 o Prepend or append list management information to the message's 151 body, such as some text and/or a URL to which subscribers can go 152 to make administrative changes to their subscriptions; 154 o Add header fields such as Reply-To:, Sender:, Resent-Sender: 155 ([MAIL]), List-Id: ([LIST-ID]), List-Post: or List-Unsubscribe: 156 ([LIST-URLS]). In some cases, such header fields are replaced if 157 the original message already contained them. 159 The above list is not exhaustive, but instead only lists common 160 modifications. It also does not consider changes the MTA might make 161 independent of what changes the MLM chooses to apply. 163 The DKIM specification documents deliberately refrain from the notion 164 of tying the signing domain (the "d=" tag in a DKIM signature) to any 165 identifier within a message; any ADMD could sign any message 166 regardless of its origin or author domain. As such, there is no 167 specification of any additional value if the content of the "d=" tag 168 in the DKIM signature and the value of (for example) the RFC5322.From 169 field match, nor is there any obvious degraded value to a signature 170 where they do not match. Since any DKIM signature is merely an 171 assertion of "some" responsibility by an ADMD, a DKIM signature added 172 by an MLM has no more, or less, meaning as a signature with any other 173 "d=" value. 175 1.2. MLMs In Infrastructure 177 The previous section describes some of the things MLMs commonly do 178 that are not DKIM-friendly, producing broken signatures and thus 179 reducing the perceived value of DKIM. 181 Further, despite the advent of standards that are specific to MLM 182 behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption 183 has been spotty at best. Hence, efforts to specify the use of DKIM 184 in the context of MLMs needs to be incremental and value-based. 186 MLM behaviors are well-established and standards compliant. Thus, 187 the best approach is to provide these best practices to all parties 188 involved, imposing the minimum requirements possible to MLMs 189 themselves. 191 An MLM is an autonomous agent that takes delivery of a message 192 delivered to it and can re-post it as a new message (or construct a 193 digest of it along with other messages) to the members of the list 194 (see [EMAIL-ARCH], Section 5.3). However, the fact that the 195 RFC5322.From field of such a message is typically the same as for the 196 original message and that recipients perceive the message as "from" 197 the original author rather than the MLM creates confusion about 198 responsibility and autonomy for the re-posted message. This has 199 important implications for use of DKIM. 201 A DKIM signature on a message is an expression of some responsibility 202 for the message taken by the signing domain. An open question, one 203 this document intends to address, is some idea of how such a 204 signature might be applied by an recipient's evaluation module after 205 the message has gone through a mailing list, and may or may not have 206 been invalidated, and if so, where the invalidation may have 207 happened. 209 Note that where in this document there is discussion of an MLM 210 conducting validation of DKIM signatures or ADSP policies, the actual 211 implementation could be one where the validation is done by the MTA 212 or an agent attached to it, and the results of that work are relayed 213 by a trusted channel not specified here. See [AUTH-RESULTS] for a 214 discussion of this. This document does not favour any particular 215 arrangement of these agents over another, but merely talks about the 216 MLM itself doing the work as a matter of simplicity. 218 1.3. Feedback Loops And Other Bi-Lateral Agreements 220 A Feedback Loop (FBL) is a bi-lateral agreement between two parties 221 to exchange reports of abuse. Typically, a bulk mail sender 222 registers with an email receiving site to receive abuse reports from 223 that site for mail coming from the sender. 225 An FBL reporting address is part of this bi-lateral registration. 226 Some FBLs require DKIM use by the registrant. Messages signed and 227 sent by a registrant through an MLM can therefore result in having 228 abuse reports sent to the original author when the actual problem 229 pertains to the operation of the MLM. However, the original author 230 has no involvement in operation of the MLM, meaning the FBL report is 231 not actionable and thus undesirable. 233 1.4. Document Scope and Goals 235 This document provides discussion on the above issues, to improve the 236 handling of possible interactions between DKIM and MLMs. An attempt 237 has been made to prefer imposing changes to behaviour at the signer 238 and verifier rather than at the MLM. 240 Wherever possible, MLMs will be conceptually decoupled from MTAs 241 despite the very tight integration that is sometimes observed in 242 implementation. This is done to emphasize the functional 243 independence of MLM services and responsibilities from those of an 244 MTA. 246 2. Definitions 248 2.1. Other Terms 250 See [EMAIL-ARCH] for a general description of the current messaging 251 architecture, and for definitions of various terms used in this 252 document. 254 2.2. DKIM-Specific References 256 Readers are encouraged to become familiar with [DKIM] and [ADSP] 257 which are standards-track protocol documents as well as 258 [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT] which are DKIM's primary 259 tutorial documents. 261 2.3. Feedback Loop References 263 FBLs tend to use the ARF ([I-D.DRAFT-IETF-MARF-BASE]) or the IODEF 264 ([IODEF]) format. 266 2.4. Message Streams 268 This document makes reference to the concept of "message streams". 269 The idea is to identify groups of messages originating from within an 270 ADMD that are distinct in intent, origin and/or use, and partition 271 them somehow (most commonly via DNS subdomains, and/or the "d=" tag 272 value in the context of DKIM) so as to keep them associated to users 273 yet operationally distinct. 275 A good example might be user mail, generated by a company's 276 employees, versus operational or transactional mail that comes from 277 automated sources, versus marketing or sales campaigns; each of these 278 could have different security policies imposed against them, or there 279 might be a desire to insulate one from the other (e.g., a marketing 280 campaign that gets reported by many spam filters could cause the 281 marketing stream's reputation to degrade without automatically 282 punishing the transactional or user streams). 284 3. Mailing Lists and DKIM 286 It is important to make some distinctions among different MLM-like 287 agents, their typical implementations, and the impacts they have in a 288 DKIM-aware environment. 290 3.1. Roles and Realities 292 In DKIM parlance, there are several key roles in the transit of a 293 message. Most of these are defined in [EMAIL-ARCH]. 295 author: The agent that actually constructed the message being sent 296 through the system, and performed the initial submission. This 297 can be a human using an MUA or a common system utility such as 298 "cron", etc. 300 originator: The agent that accepts a message from the author, 301 ensures it conforms to the relevant standards such as [MAIL], and 302 then relays it toward its destination(s). This is often referred 303 to as the Mail Submission Agent (MSA). 305 signer: The agent that affixes one or more DKIM signature(s) to a 306 message on its way toward its ultimate destination. It is 307 typically running at the MTA that sits between the author's ADMD 308 and the general Internet. The signer and the originator may also 309 be the same agent. 311 verifier: The agent that conducts DKIM signature analysis. It is 312 typically running at the MTA that sits between the receiver's ADMD 313 and the general Internet. Note that any agent that handles a 314 signed message could conduct verification; this document only 315 considers that action and its outcomes either at an MLM or at the 316 receiver. 318 receiver: The agent that is the final transit relay for the message 319 prior to being delivered to the recipient(s) of the message. 321 In the case of simple user-to-user mail, these roles are fairly 322 straightforward. However, when one is sending mail to a list, which 323 then gets relayed to all of that list's subscribers, the roles are 324 often less clear to the general user, as particular agents may hold 325 multiple important but separable roles. The above definitions are 326 intended to enable more precise discussion of the mechanisms 327 involved. 329 3.2. Types Of Mailing Lists 331 There are four common MLM implementation modes: 333 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 334 that makes no changes to a message as it redistributes; any 335 modifications are constrained to changes to the [SMTP] envelope 336 recipient list (RCPT commands) only. There are no changes to the 337 message body at all and only [MAIL] trace header fields are added. 338 The output of such an MLM is considered to be a continuation of 339 the author's original message. An example of such an MLM is a 340 address that expands directly in the MTA, such as a list of local 341 system administrators used for relaying operational or other 342 internal-only messages. See also Section 3.9.2 of [SMTP]. 344 resending: A resending MLM (see Sections 5.2 and 5.3 of 345 [EMAIL-ARCH]) is one that may make changes to a message. The 346 output of such an MLM is considered to be a new message; delivery 347 of the original has been completed prior to distribution of the 348 re-posted message. Such messages are often re-formatted, such as 349 with list-specific header fields or other properties, to 350 facilitate discussion among list subscribers. 352 authoring: An authoring MLM is one that creates the content being 353 sent as well as initiating its transport, rather than basing it on 354 one or more messages received earlier. This is a special case of 355 the MLM paradigm, one which generates its own content and does not 356 act as an intermediary. Typically replies are not generated, or 357 if they are, they go to a specific recipient and not back to the 358 list's full set of recipients. Examples include newsletters and 359 bulk marketing mail. 361 digesting: A special case of the re-posting MLM is one that sends a 362 single message comprising an aggregation of recent MLM submissons, 363 which might be a message of [MIME] type "multipart/digest" (see 364 [MIME-TYPES]). This is obviously a new message but it may contain 365 a sequence of original messages that may themselves have been 366 DKIM-signed. 368 In the remainder of this document we distinguish Two relevant steps, 369 corresponding to the following SMTP transactions: 371 MLM Input: Originating user is author; originating ADMD is signer; 372 MLM's ADMD is verifier; MLM's input function is receiver. 374 MLM Output: MLM (sending its reconstructed copy of the originating 375 user's message) is author; MLM's ADMD is signer; the ADMD of each 376 subscriber of the list is a verifier; each subscriber is a 377 receiver. 379 Much of this document focuses on the resending MLM as it has the most 380 direct conflict operationally with DKIM. 382 The dissection of the overall MLM operation into these two distinct 383 steps allows the DKIM-specific issues with respect to MLMs to be 384 isolated and handled in a logical way. The main issue is that the 385 repackaging and reposting of a message by an MLM is actually the 386 construction of a completely new message, and as such the MLM is 387 introducing new content into the email ecosystem, consuming the 388 author's copy of the message and creating its own. When considered 389 in this way, the dual role of the MLM and its ADMD becomes clear. 391 Some issues about these activities are discussed in Section 3.6.4 of 392 [MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. 394 3.3. Current MLM Effects On Signatures 396 As described above, an aliasing MLM does not affect any existing 397 signature, and an authoring MLM is always new content and thus there 398 is never an existing signature. However, the changes a resending MLM 399 can make typically affect the RFC5322.Subject header field, addition 400 of some list-specific header fields, and/or the addition of some 401 list-specific text to the top or bottom of the message body. The 402 impacts of each of these on DKIM verification are discussed below. 404 Subject tags: Altering the RFC5322.Subject field by adding a list- 405 specific prefix will invalidate the signer's signature if that 406 header field was covered by a hash of that signature. [DKIM] 407 lists RFC5322.Subject as one that should be covered, so this is 408 expected to be an issue for any list that makes such changes. 410 List-specific header fields: Some lists will add header fields 411 specific to list administrative functions such as those defined in 412 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 413 [MAIL]. It is unlikely that a typical MUA would include such 414 fields in an original message, and DKIM is resilient to the 415 addition of header fields in general (though see notes about the 416 "h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as 417 less of a concern. 419 Other header fields: Some lists will add or replace header fields 420 such as "Reply-To" or "Sender" in order to establish that the 421 message is being sent in the context of the mailing list, so that 422 the list is identified ("Sender") and any user replies go to the 423 list ("Reply-To"). If these fields were included in the original 424 message, it is possible that one or more of them may have been 425 signed, and this could cause a concern for MLMs that add or 426 replace them. 428 Minor body changes: Some lists prepend or append a few lines to each 429 message to remind subscribers of an administrative URL for 430 subscription issues, or of list policy, etc. Changes to the body 431 will alter the body hash computed at the DKIM verifier, so these 432 pose an immediate problem. 434 Major body changes: There are some MLMs that make more substantial 435 changes to message bodies when preparing them for re-distribution, 436 such as deleting, reordering, or reformatting [MIME] parts, 437 "flatten" HTML messages into plain text, or insert headers or 438 footers within HTML messages. Most or all of these changes will 439 invalidate a DKIM signature with little or no hope of compensation 440 by either the signer or the verifier. 442 MIME part removal: Some MLMs that are MIME-aware will remove large 443 MIME parts from submissions and replace them with URLs to reduce 444 the size of the distributed form of the message and to prevent 445 inadvertent automated malware delivery. 447 There reportedly still exist a few scattered mailing lists in 448 operation that are actually run manually by a human list manager. 450 In general, an MLM subscriber cannot be expected to be able to 451 reconstruct the original message as it appeared at time of signing 452 and thus whether or not an author signature is actually valid after 453 MLM rewriting. Moreover, even if an MLM currently passes messages 454 unmodified such that author signatures validate, it is possible that 455 a configuration change or software upgrade to that MLM will cause 456 that no longer to be true. 458 3.4. Alternatives of Participation and Conformance 460 As DKIM becomes more entrenched, it is highly desirable that MLM 461 software adopt more DKIM-friendly processing. 463 Changes that merely add new header fields, such as those specified by 464 [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to 465 a DKIM-participating email infrastructure in that their addition by 466 an MLM will not affect any existing DKIM signatures unless those 467 fields were already present and covered by a signature's hash or a 468 signature was created specifically to disallow their addition (see 469 the note about "h=" in Section 3.5 of [DKIM]). The shortest path to 470 success for DKIM would be to mandate that all MLM software be re- 471 designed or re-configured with that goal in mind. 473 However, the practice of applying headers and footers to message 474 bodies is common and not expected to fade regardless of what 475 documents this or any standards body might produce. This sort of 476 change will invalidate the signature on a message where the body hash 477 covers the entire entire message. Thus, the following sections also 478 investigate and recommend other processing alternatives. 480 A possible mitigation to this incompatibility is use of the "l=" tag 481 to bound the portion of the body covered by the body hash, but this 482 not workable for [MIME] messages and moreover has security 483 considerations (see Section 3.5 of [DKIM]). Its use is therefore 484 discouraged. 486 There is currently no header field proposed for relaying general list 487 policy details, apart from what [LIST-URLS] already supports. This 488 sort of information is what is commonly included in appended footer 489 text or prepended header text. Rather than anticipating or proposing 490 a new field here for that purpose, the working group recommends 491 periodic, automatic mailings to the list to remind subscribers of 492 list policy. These will be repetitive, of course, but by being 493 generally the same each time they can be easily filtered if needed. 495 4. Non-Participating MLMs 497 This section contains a discussion of issues regarding sending DKIM- 498 signed mail to or through an MLM that is not DKIM-aware. 499 Specifically, the header fields introduced by [DKIM] and 500 [AUTH-RESULTS] carry no special meaning to such an MLM. 502 4.1. Author-Related Signing 504 If an author knows that the MLM to which a message is being sent is a 505 non-participating resending MLM, the author is advised to be cautious 506 when deciding whether or not to sign the message. The MLM could make 507 a change that would invalidate the author's signature but not remove 508 it prior to re-distribution. Hence, list recipients would receive a 509 message purportedly from the author but bearing a DKIM signature that 510 would not verifiy. This problem would be compounded further if there 511 were receivers that applied signing policies ([ADSP]) and the author 512 published any kind of strict policy. 514 If this is cause for concern, the originating site can consider using 515 a separate message stream, such as a sub-domain, for the "personal" 516 mail that is different from domain(s) used for other mail streams, so 517 that they develop independent reputations, and more stringent 518 policies (including ADSP) can be applied to the mail stream(s) that 519 do not go through mailing lists. 521 However, all of this presupposes a level of infrastructure 522 understanding that is not expected to be common. Thus, it will be 523 incumbent upon site administrators to consider how support of users 524 wishing to participate in mailing lists might be accomplished as DKIM 525 achieves wider adoption. A common suggestion is to establish 526 subdomains in the DNS that are used for separating different streams 527 of mail from within an ADMD, such as user-created "direct" mail from 528 transactional or automated mail; some of these may be signed and some 529 not, some with published ADSP records, some not. In general, the 530 more strict practices and policies are likely to be successful only 531 for the mail streams subject to the most end-to-end control by the 532 originating organization. That typically excludes mail going through 533 MLMs. 535 4.2. Verification Outcomes at Receivers 537 There does not appear to be a reliable way to determine that a piece 538 of mail arrived via a non-participating MLM. Thus, it is not 539 reasonably possible to suggest any particular processing heuristics 540 specific to this case with respect to DKIM and ADSP. 542 4.3. Handling Choices at Receivers 544 A receiver's ADMD would have to have some way to register such non- 545 participating lists to exempt them from the filtering described in 546 Section 4.1. This is, however, probably not a scalable solution as 547 it imposes a burden on the receiver that is predicated on sender 548 behaviour. 550 Note that the [DKIM] specification explicitly directs verifiers to 551 treat a verification failure as though the message were not signed in 552 the first place. In the absence of specific ADSP direction, any 553 treatment of a verification failure as having special meaning is 554 either outside the scope of DKIM or is in violation of it. 556 [ADSP] presents an additional challenge. Per that specification, 557 when a message is unsigned or the signature can no longer be 558 verified, the verifier must discard the message. There is no 559 exception in the policy for a message that may have been altered by 560 an MLM. Verifiers are thus advised to honor the policy and disallow 561 the message. Furthermore, authors whose ADSP is published as 562 "discardable" are advised not to send mail to MLMs as it is likely to 563 be rejected by ADSP-aware recipients. (This is discussed further in 564 Section 5.4 below.) 566 5. Participating MLMs 568 This section contains a discussion of issues regarding sending DKIM- 569 signed mail to or through an MLM that is DKIM-aware, and may also be 570 ADSP-aware. 572 5.1. Subscriptions 574 At subscription time, an ADSP-aware MLM could check for a published 575 ADSP record for the new subscriber, and present a warning for one 576 whose ADMD's published policy is "discardable" indicating that 577 submissions from that ADMD may not be deliverable because of 578 modifications that are likely to be made to the message. 580 Of course, such a policy could be applied after subscription, so this 581 is not a universal solution. An MLM implementation could do periodic 582 checks of its subscribers and issue warnings where such a policy is 583 detected. 585 5.2. Author-Related Signing 587 MLMs typically attempt to authenticate messages posted through them. 588 They usually do this through the trivial (and insecure) means of 589 verifying the RFC5322.From field email address (or, less frequently, 590 the RFC5321.MailFrom parameter) against a list registry. DKIM 591 enables a stronger form of authentication, although this is not yet 592 formally documented: It can require that messages using a given 593 RFC5322.From address also have a DKIM signature with a corresponding 594 "d=" domain. (Note, however, that it is entirely reasonable for an 595 MLM to permit registration of some other "d=" domain as valid 596 evidence of such authentication.) This feature would be somewhat 597 similar to using ADSP, except that the requirement for it would be 598 imposed by the MLM and not the author's organization. 600 An important consideration is that authors rarely have any direct 601 influence over the management of an MLM. As such, a signed message 602 from an author will in essence go to a set of unexpected places. 603 Authors may be well-advised to create a mail stream specifically used 604 for generating signatures when sending traffic to MLMs. This becomes 605 important as domain-based reputation systems begin to appear as 606 components of mail filtering modules. 608 This suggestion can be made more general. Mail that is of a 609 transactional or generally end-to-end nature, and not likely to be 610 forwarded around either by MLMs or users, should come from a 611 different mail stream than a stream that serves a broader purpose. 613 5.3. Verification Outcomes at MLMs 615 As described above, the MLM might conduct DKIM verification of a 616 signed message to attempt to confirm the identity of the author. 617 Although it is a common and intuitive conclusion, however, not all 618 signed mail will include an author signature (see [ADSP]). MLM 619 implementors are advised to accomodate such in their configurations. 620 For example, an MLM might be designed to accomodate a list of 621 possible signing domains (the "d=" portion of a DKIM signature) for a 622 given author, and determine at verification time if any of those are 623 present. 625 A message that cannot be thus authenticated could be held for 626 moderation or rejected outright. 628 This logic could apply to any list operation, not just list 629 submission. In particular, this improved authentication could apply 630 to subscription, unsubscription, and/or changes to subscriber options 631 that are sent via email rather than through an authenticated, 632 interactive channel such as the web. 634 In the case of verification of signatures on subscriptions, MLMs are 635 advised to add an [AUTH-RESULTS] header field to indicate the 636 signature(s) observed on the submission as it arrived at the MLM and 637 what the outcome of the evaluation was. Downstream agents may or may 638 not trust the content of that header field depending on their own a 639 priori knowledge of the operation of the ADMD generating (and, 640 preferably, signing) that header field. See [AUTH-RESULTS] for 641 further discussion. 643 5.4. Pros and Cons of Signature Removal 645 If the MLM is configured to make changes to the message prior to re- 646 posting that would invalidate the original signature(s), further 647 action is recommended to prevent invalidated signatures from arriving 648 at final recipients, possibly triggering unwarranted filter actions. 649 A possible solution would be to: 651 1. Attempt verification of all DKIM signatures present on the input 652 message; 654 2. Apply local policy to authenticate the identity of the author; 656 3. Add an [AUTH-RESULTS] header field to the message to indicate the 657 results of the above; 659 4. Remove all previously-evaluated DKIM signatures; 660 5. Affix a new signature that covers the Authentication-Results 661 header field just added. 663 Removing the original signature(s) seems particularly appropriate 664 when the MLM knows it is likely to invalidate any or all of them due 665 to the nature of the reformatting it will do. This avoids false 666 negatives at the list's subscribers in their roles as receivers of 667 the message; although [DKIM] stipulates that an invalid signature is 668 the same as no signature, it is anticipated that there will be some 669 implementations to the contrary. 671 The MLM could re-evaluate exisiting signatures after making its 672 message changes to determine whether or not any of them have been 673 invalidated. The cost of this is reduced by the fact that, 674 presumably, the necessary public keys have already been downloaded 675 and one or both of the message hashes could be reused. 677 Per the discussion in [AUTH-RESULTS], there is no a priori reason for 678 the final receivers to put any faith in the veracity of that header 679 field when added by the MLM. Thus, the final recipients of the 680 message have no way to verify on their own the authenticity of the 681 author's identity on that message. However, should that field be the 682 only one on the message when the verifier gets it, and the verifier 683 explicitly trusts the signer (in this case, the MLM), the verifier is 684 in a position to believe that a valid author signature was present on 685 the message. 687 Since an aliasing MLM makes no substantive changes to a message, it 688 need not consider the issue of signature removal as the original 689 signatures should arrive at least to the next MTA unmodified. It is 690 possible that future domain-based reputations would prefer a more 691 rich data set on receipt of a message, and in that case signature 692 removal would be undesirable. 694 An authoring MLM is closed to outside submitters, thus much of this 695 discussion does not apply in that case. 697 5.5. DKIM Author Domain Signing Practices 699 [ADSP] presents a particular challenge. An author domain posting a 700 policy of "discardable" imposes a very tight restriction on the use 701 of mailing lists, essentially constraining that domain's users to 702 lists operated by aliasing MLMs only; any MLM that alters a message 703 from such a domain or removes its signature subjects the message to 704 severe action by receivers. It is the consensus of the working group 705 that a resending MLM is advised to reject outright any mail from an 706 author whose domain posts such a policy as it is likely to be 707 rejected by any ADSP-aware recipients, and might also be well advised 708 to present a warning to such subscribers when first signing up to the 709 list. 711 Where the above practice is not observed and "discardable" mail 712 arrives via a list to a verifier that applies ADSP checks, the 713 verifier can either discard the message (i.e. accept the message at 714 the [SMTP] level but discard it without delivery) or conduct an SMTP 715 rejection by returning a 5xx error code. In the latter case, some 716 advice for how to conduct the rejection in a potentially meaningful 717 way can be found in Section 5.9. 719 5.6. MLM Signatures 721 DKIM-aware resending MLMs and authoring MLMs are encouraged to affix 722 their own signatures when distributing messages. The MLM is 723 responsible for the alterations it makes to the original messages it 724 is re-sending, and should express this via a signature. This is also 725 helpful for getting feedback from any FBLs that might be set up so 726 that undesired list mail can generate appropriate action. 728 A signing MLM is, as any other MLM, free to omit redistribution of a 729 message from an author if that message was not signed in accordance 730 with its own local configuration or policy. However, selective 731 signing is discouraged; essentially that would create two message 732 streams from the MLM, one signed and one not, which can confuse DKIM- 733 aware verifiers and receivers. 735 As is typical with DKIM signing, the MLM signature must be generated 736 only after all modifications the MLM wishes to apply have been 737 completed. Failing to do so generates a signature that can not be 738 expected to validate. 740 A signing MLM is advised to add a List-Post: header field (see 741 [LIST-URLS]) using a DNS domain matching what will be used in the 742 "d=" tag of the DKIM signature it will add to the new message. This 743 could be used by verifiers or receivers to identify the DKIM 744 signature that was added by the MLM. This is not required, however; 745 it is believed the reputation of the signer will be a more critical 746 data point rather than this suggested binding. 748 Such MLMs are advised to ensure the signature's header hash will 749 cover: 751 o Any [AUTH-RESULTS] fields added by the MLM; 753 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 754 o Any [MAIL] fields, especially Sender and Reply-To, added or 755 replaced by the MLM. 757 A DKIM-aware resending MLM is encouraged to sign the entire message 758 as it arrived (i.e. the "MLM Input" from Section 3.2), especially 759 including the original signatures. 761 DKIM-aware authoring MLMs are advised to sign the mail they send 762 according to the regular signing guidelines given in [DKIM]. 764 Operators of non-DKIM-aware MLMs could arrange to submit MLM mail 765 through an MSA that is DKIM-aware so that its mail will be signed. 767 Some concern has been expressed about an MLM applying its signature 768 to unsigned mail, which some verifiers or receivers might interpret 769 as conferring more authority to the message content. The working 770 group feels this is no different than present-day lists relaying 771 traffic and affixing RFC5322.Subject tags or similar, and thus it 772 doesn't introduce any new concerns. 774 5.7. Verification Outcomes at Final Receiving Sites 776 In general, verifiers and receivers can treat a signed message from 777 an MLM like any other signed message; indeed, it would be difficult 778 to discern any difference. 780 However, because the author domain will commonly be different from 781 the MLM's signing domain, there may be a conflict with [ADSP] as 782 discussed in Section 4.3 and Section 5.4. 784 5.8. Use With FBLs 786 An FBL operator wishing act on a complaint by making use of DKIM 787 verifications is advised to send a report to any domain with a valid 788 signature that has an FBL agreement established, as DKIM signatures 789 are claims of some responsibility for that message. Because authors 790 generally have limited control over the operation of a list, this 791 point makes MLM signing all the more important. 793 Where the FBL wishes to be more specific, it could act solely on a 794 DKIM signature where the signing domain matches the DNS domain found 795 in a List-Post: header field (or similar). 797 Use of FBLs in this way should be made explicit to list subscribers. 798 For example, if it is the policy of the MLM's ADMD to handle an FBL 799 item by unsubscribing the user that was the apparent sender of the 800 offending message, advising subscribers of this in advance would help 801 to avoid surprises later. 803 5.9. Handling Choices at Receivers 805 A recipient that trusts signatures from an MLM may wish to extend 806 that trust to an [AUTH-RESULTS] header field signed by that MLM. The 807 recipient may then do additional processing of the message, using the 808 results recorded in the Authentication-Results header field instead 809 of the original author's DKIM signature. This includes possibly 810 processing the message as per ADSP requirements. 812 Receivers are advised to ignore all unsigned Authentication-Results 813 header fields. 815 Upon DKIM and ADSP evaluation, a receiver may decide to reject a 816 message during an SMTP session. If this is done, use of an [SMTP] 817 failure code not normally used for "user unknown" (550) is suggested; 818 554 seems an appropriate candidate. If the rejecting SMTP server 819 supports [ENHANCED] status codes, is advised to make a distinction 820 between messages rejected deliberately due to policy decisions rather 821 than those rejected because of other deliverability issues. In 822 particular, a policy rejection is advised to be relayed using a 5.7.2 823 enhanced status code and some appropriate wording in the text part of 824 the reply, in contrast to a code of 5.1.1 indicating the user does 825 not exist. Those MLMs that attempt to automatically remove users 826 with prolonged delivery problems (such as account deletion) will thus 827 be able to tell the difference between policy rejection and delivery 828 failures, and act accordingly. SMTP servers doing so are also 829 advised to use appropriate wording in the text portion of the reply. 831 6. DKIM Reporting 833 The MARF working group is developing mechanisms for reporting 834 forensic details about DKIM verification failures. At the time of 835 writing, this is still a work in progress. 837 MLMs are encouraged to apply these or other DKIM failure reporting 838 mechanisms as a method for providing feedback about issues with DKIM 839 infrastructure back to signers. This is especially important for 840 MLMs that implement DKIM verification as a mechanism for 841 authentication of list configuration commands and submissions from 842 subscribers. 844 7. IANA Considerations 846 This document includes no IANA actions. 848 8. Security Considerations 850 This document provides suggested or best current practices for use 851 with DKIM, and as such does not introduce any new technologies for 852 consideration. However, the following security issues should be 853 considered when implementing the above practices. 855 8.1. Authentication Results When Relaying 857 some stuff about the fact that the MLM's auth-results can't be 858 trusted by default 860 9. References 862 9.1. Normative References 864 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 865 Sender Signing Practises", RFC 5617, August 2009. 867 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 868 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 869 Signatures", RFC 4871, May 2007. 871 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 872 October 2008. 874 9.2. Informative References 876 [AUTH-RESULTS] 877 Kucherawy, M., "Message Header Field for Indicating 878 Message Authentication Status", RFC 5451, April 2009. 880 [DKIM-DEPLOYMENT] 881 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 882 "DomainKeys Identified Mail (DKIM) Development, Deployment 883 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 884 January 2010. 886 [DKIM-OVERVIEW] 887 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 888 Identified Mail (DKIM) Service Overview", RFC 5585, 889 July 2009. 891 [EMAIL-ARCH] 892 Crocker, D., "Internet Mail Architecture", RFC 5598, 893 July 2009. 895 [ENHANCED] 896 Vaudreuil, G., "Enhanced Mail System Status Codes", 897 RFC 3463, January 2003. 899 [I-D.DRAFT-IETF-MARF-BASE] 900 Shafranovich, Y., Levine, J., and M. Kucherawy, "An 901 Extensible Format for Email Feedback Reports", I-D DRAFT- 902 IETF-MARF-BASE, April 2010. 904 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 905 Object Description Exchange Format", RFC 5070, 906 December 2007. 908 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 909 and Namespace for the Identification of Mailing Lists", 910 RFC 2919, March 2001. 912 [LIST-URLS] 913 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 914 for Core Mail List Commands and their Transport through 915 Message Header Fields", RFC 2369, July 1998. 917 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 918 Extensions (MIME) Part One: Format of Internet Message 919 Bodies", RFC 2045, November 1996. 921 [MIME-TYPES] 922 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 923 Extensions (MIME) Part Two: Media Types", RFC 2046, 924 November 1996. 926 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 927 October 2008. 929 Appendix A. Acknowledgements 931 The author wishes to acknowledge the following for their review and 932 constructive criticism of this document: Serge Aumont, Daniel Black, 933 Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, John Levine, S. 934 Moonesamy and Alessandro Vesely. 936 Appendix B. Example Scenarios 938 This section describes a few MLM-related DKIM scenarios that were 939 part of the impetus for this work, and the recommended resolutions 940 for each. 942 B.1. MLMs and ADSP 944 Problem: 946 o author ADMD advertise an ADSP policy of "dkim=discardable" 948 o author sends DKIM-signed mail to a non-participating MLM, which 949 invalidates the signature 951 o receiver MTA checks DKIM and ADSP at SMTP time, and is configured 952 to reject ADSP failures, so rejects this message 954 o process repeats a few times, after which the MLM unsubscribes the 955 receiver 957 Solution: MLMs should refuse mail from domains advertising ADSP 958 policies of "discardable" unless they are certain they make no 959 changes that invalidate DKIM signatures. 961 B.2. MLMs and FBLs 963 Problem: 965 o subscriber sends sign mail to a non-participating MLM that does 966 not invalidate the signature 968 o a recipient reports the message as spam 970 o FBL at recipient ADMD sends report to contributor rather than list 971 manager 973 Solution: MLMs should sign mail they send and might also strip 974 existing signatures; FBLs should report to list operators instead of 975 to subscribers where such can be distinguished. 977 Author's Address 979 Murray S. Kucherawy 980 Cloudmark 981 128 King St., 2nd Floor 982 San Francisco, CA 94107 983 US 985 Phone: +1 415 946 3800 986 Email: msk@cloudmark.com