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