idnits 2.17.00 (12 Aug 2021) /tmp/idnits30962/draft-ietf-dkim-mailinglists-05.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 (March 28, 2011) is 4071 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 March 28, 2011 5 Expires: September 29, 2011 7 DKIM And Mailing Lists 8 draft-ietf-dkim-mailinglists-05 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 September 29, 2011. 35 Copyright Notice 37 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 20 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 Section 3.3 describes some of the things MLMs commonly do that 169 produce broken signatures, thus reducing the perceived value of DKIM. 171 Further, while there are published standards that are specific to MLM 172 behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption 173 has been spotty at best. Hence, efforts to specify the use of DKIM 174 in the context of MLMs needs to be incremental and value-based. 176 Other MLM behaviours are well-established. Although it can be argued 177 that they frustrate widespread DKIM adoption, it cannot be said that 178 such behaviours are not standards compliant. Thus, the best approach 179 is to provide these best practices to all parties involved, imposing 180 the minimum requirements possible to MLMs themselves. 182 An MLM is an autonomous agent that takes delivery of a message and 183 can re-post it as a new message, or construct a digest of it along 184 with other messages to the members of the list (see [EMAIL-ARCH], 185 Section 5.3). However, the fact that the RFC5322.From field of such 186 a message (in the non-digest case) is typically the same as that of 187 the original message, and that recipients perceive the message as 188 "from" the original author rather than the MLM, creates confusion 189 about responsibility and autonomy for the re-posted message. This 190 has important implications for use of DKIM. 192 A DKIM signature on a message is an expression of some responsibility 193 for the message taken by the signing domain. An open issue, and one 194 this document intends to address, is some idea of how such a 195 signature might be used by a recipient's evaluation module after the 196 message has gone through a mailing list and may or may not have been 197 invalidated, and if it has, where and how the invalidation may have 198 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. 220 A DKIM-signed message sent to an MLM, and then distributed to all of 221 a list's recipients, could result in a complaint from one of the 222 recipients for some reason. This could be an actual complaint from 223 some subscriber that finds the message abusive or otherwise 224 undesirable, or it could be an automated complaint such as receiver 225 detection of an invalidated DKIM signature or some other condition. 226 It could also be a complaint that results from antagonistic 227 behaviour, such as is common when a subscriber to a list is having 228 trouble unsubscribing, and then begins issuing complaints about all 229 submissions to the list. This would result in a complaint being 230 generated in the context of an FBL report back to the message author. 231 However, the original author has no involvement in operation of the 232 MLM itself, meaning the FBL report is not actionable and thus 233 undesirable. 235 See Section 6 for additional discussion. 237 FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) format. 239 1.4. Document Scope and Goals 241 This document provides discussion on the above issues, to improve the 242 handling of possible interactions between DKIM and MLMs. In general, 243 consensus shows a preference toward imposing changes to behaviour at 244 the signer and verifier rather than at the MLM. 246 Wherever possible, MLMs will be conceptually decoupled from MTAs 247 despite the very tight integration that is sometimes observed in 248 implementation. This is done to emphasize the functional 249 independence of MLM services and responsibilities from those of an 250 MTA. 252 Parts of this document explore possible changes to common practice by 253 signers, verifiers and MLMs. The suggested enhancements are largely 254 theoretical in nature, taking into account the current email 255 infrastructure, the facilities DKIM can provide as it gains wider 256 deployment, and working group consensus. There is no substantial 257 implementation history upon which these suggestions are based, and 258 the efficacy, performance and security characteristics of them have 259 not yet been fully explored. 261 2. Definitions 263 2.1. Other Terms 265 See [EMAIL-ARCH] for a general description of the current messaging 266 architecture, and for definitions of various terms used in this 267 document. 269 2.2. DKIM-Specific References 271 Readers are encouraged to become familiar with [DKIM] and [ADSP], 272 which are core specification documents, as well as [DKIM-OVERVIEW] 273 and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents. 275 2.3. 'DKIM-Friendly' 277 The term "DKIM-Friendly" is used to describe an email intermediary 278 that, when handling a message, makes no changes to that message which 279 cause valid [DKIM] signatures present on the message on input to fail 280 to verify on output. 282 Various features of MTAs and MLMs seen as helpful to users often have 283 side effects that do render DKIM signatures unverifiable. These 284 would not qualify for this label. 286 2.4. Message Streams 288 This document makes reference to the concept of "message streams". 289 The idea is to identify groups of messages originating from within an 290 ADMD that are distinct in intent, origin and/or use, and partition 291 them somehow (i.e., via changing the value in the "d=" tag value in 292 the context of DKIM) so as to keep them associated to users yet 293 distinct in terms of their evaluation and handling by verifiers or 294 receivers. 296 A good example might be user mail generated by a company's employees, 297 versus operational or transactional mail that comes from automated 298 sources, versus marketing or sales campaigns. Each of these could 299 have different security policies imposed against them, or there might 300 be a desire to insulate one from the other (e.g., a marketing 301 campaign that gets reported by many spam filters could cause the 302 marketing stream's reputation to degrade without automatically 303 punishing the transactional or user streams). 305 3. Mailing Lists and DKIM 307 It is important to make some distinctions among different MLM-like 308 agents, their typical implementations, and the impacts they have in a 309 DKIM-aware environment. 311 3.1. Roles and Realities 313 In DKIM parlance, there are several key roles in the transit of a 314 message. Most of these are defined in [EMAIL-ARCH]. 316 author: The agent that provided the content of the message being 317 sent through the system, and performed the initial submission. 318 This can be a human using an MUA or a common system utility such 319 as "cron", etc. 321 originator: The agent that accepts a message from the author, 322 ensures it conforms to the relevant standards such as [MAIL], and 323 then relays it toward its destination(s). This is often referred 324 to as the Mail Submission Agent (MSA). 326 signer: Any agent that affixes one or more DKIM signature(s) to a 327 message on its way toward its ultimate destination. There is 328 typically a signer running at the MTA that sits between the 329 author's ADMD and the general Internet. The originator and/or 330 author might also be a signer. 332 verifier: Any agent that conducts DKIM signature analysis. One is 333 typically running at the MTA that sits between the general 334 Internet and the receiver's ADMD. Note that any agent that 335 handles a signed message could conduct verification; this document 336 only considers that action and its outcomes either at an MLM or at 337 the receiver. Filtering decisions could be made by this agent 338 based on verification results. 340 receiver: The agent that is the final transit relay for the message 341 prior to being delivered to the recipient(s) of the message. 342 Filtering decisions based on results made by the verifier could be 343 applied by the receiver. The verifier and the receiver could be 344 the same agent. 346 In the case of simple user-to-user mail, these roles are fairly 347 straightforward. However, when one is sending mail to a list, which 348 then gets relayed to all of that list's subscribers, the roles are 349 often less clear to the general user as particular agents may hold 350 multiple important but separable roles. The above definitions are 351 intended to enable more precise discussion of the mechanisms 352 involved. 354 3.2. Types Of Mailing Lists 356 There are four common MLM implementation modes: 358 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 359 that makes no changes to a message as it redistributes; any 360 modifications are constrained to changes to the [SMTP] envelope 361 recipient list (RCPT commands) only. There are no changes to the 362 message body at all and only [MAIL] trace header fields are added. 363 The output of such an MLM is considered to be a continuation of 364 the author's original message. An example of such an MLM is an 365 address that expands directly in the MTA, such as a list of local 366 system administrators used for relaying operational or other 367 internal-only messages. See also Section 3.9.2 of [SMTP]. 369 resending: A resending MLM (see Sections 5.2 and 5.3 of 370 [EMAIL-ARCH]) is one that may make changes to a message. The 371 output of such an MLM is considered to be a new message; delivery 372 of the original has been completed prior to distribution of the 373 re-posted message. Such messages are often re-formatted, such as 374 with list-specific header fields or other properties, to 375 facilitate discussion among list subscribers. 377 authoring: An authoring MLM is one that creates the content being 378 sent as well as initiating its transport, rather than basing it on 379 one or more messages received earlier. This is a special case of 380 the MLM paradigm, one that generates its own content and does not 381 act as an intermediary. Typically replies are not generated, or 382 if they are, they go to a specific recipient and not back to the 383 list's full set of recipients. Examples include newsletters and 384 bulk marketing mail. 386 digesting: A special case of the resending MLM is one that sends a 387 single message comprising an aggregation of recent MLM 388 submissions, which might be a message of [MIME] type "multipart/ 389 digest" (see [MIME-TYPES]). This is obviously a new message but 390 it may contain a sequence of original messages that may themselves 391 have been DKIM-signed. 393 In the remainder of this document we distinguish two relevant steps, 394 corresponding to the following SMTP transactions: 396 MLM Input: Originating user is author; originating ADMD is 397 originator and signer; MLM's ADMD is verifier; MLM's input 398 function is receiver. 400 MLM Output: MLM (sending its reconstructed copy of the originating 401 user's message) is author; MLM's ADMD is originator and signer; 402 the ADMD of each subscriber of the list is a verifier; each 403 subscriber is a receiver. 405 Much of this document focuses on the resending class of MLM as it has 406 the most direct conflict operationally with DKIM. 408 The dissection of the overall MLM operation into these two distinct 409 steps allows the DKIM-specific issues with respect to MLMs to be 410 isolated and handled in a logical way. The main issue is that the 411 repackaging and reposting of a message by an MLM is actually the 412 construction of a completely new message, and as such the MLM is 413 introducing new content into the email ecosystem, consuming the 414 author's copy of the message and creating its own. When considered 415 in this way, the dual role of the MLM and its ADMD becomes clear. 417 Some issues about these activities are discussed in Section 3.6.4 of 418 [MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. 420 3.3. Current MLM Effects On Signatures 422 As described above, an aliasing MLM does not affect any existing 423 signature, and an authoring MLM is always creating new content and 424 thus there is never an existing signature. However, the changes a 425 resending MLM can make typically affect the RFC5322.Subject header 426 field, addition of some list-specific header fields, and/or 427 modification of the message body. The impacts of each of these on 428 DKIM verification are discussed below. 430 Subject tags: A popular feature of MLMs is the "tagging" of an 431 RFC5322.Subject field by prefixing the field's contents with the 432 name of the list, such as "[example]" for a list called "example". 433 Altering the RFC5322.Subject field on new submissions by adding a 434 list-specific prefix or suffix will invalidate the signer's 435 signature if that header field was included when creating that 436 signature. [DKIM] lists RFC5322.Subject as one that should be 437 covered, so this is expected to be an issue for any list that 438 makes such changes. 440 List-specific header fields: Some lists will add header fields 441 specific to list administrative functions such as those defined in 442 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 443 [MAIL]. It is unlikely that a typical MUA would include such 444 fields in an original message, and DKIM is resilient to the 445 addition of header fields in general (see notes about the "h=" tag 446 in Section 3.5 of [DKIM]). Therefore this is seen as less of a 447 concern. 449 Other header fields: Some lists will add or replace header fields 450 such as "Reply-To" or "Sender" in order to establish that the 451 message is being sent in the context of the mailing list, so that 452 the list is identified ("Sender") and any user replies go to the 453 list ("Reply-To"). If these fields were included in the original 454 message, it is possible that one or more of them may have been 455 signed, and those signatures will thus be broken. 457 Minor body changes: Some lists prepend or append a few lines to each 458 message to remind subscribers of an administrative URL for 459 subscription issues, or of list policy, etc. Changes to the body 460 will alter the body hash computed at the DKIM verifier, so these 461 will render any existing signatures that cover those portions of 462 the message body unverifiable. 464 Major body changes: There are some MLMs that make more substantial 465 changes to message bodies when preparing them for re-distribution, 466 such as adding, deleting, reordering, or reformatting [MIME] 467 parts, "flattening" HTML messages into plain text, or insert 468 headers or footers within HTML messages. Most or all of these 469 changes will invalidate a DKIM signature. 471 MIME part removal: Some MLMs that are MIME-aware will remove large 472 MIME parts from submissions and replace them with URLs to reduce 473 the size of the distributed form of the message and to prevent 474 inadvertent automated malware delivery. Except in cases where a 475 body length limit is applied in generation of the DKIM signature, 476 the signature will be broken. 478 There reportedly still exist a few scattered mailing lists in 479 operation that are actually run manually by a human list manager, 480 whose workings in preparing a message for distribution could include 481 the above or even some other changes. 483 In general, absent a general movement by MLM developers and operators 484 toward more DKIM-friendly practices, an MLM subscriber cannot expect 485 signatures applied before the message was processed by the MLM to be 486 valid on delivery to a receiver. Such an evolution is not expected 487 in the short term due to general development and deployment inertia. 488 Moreover, even if an MLM currently passes messages unmodified such 489 that author signatures validate, it is possible that a configuration 490 change or software upgrade to that MLM will cause that no longer to 491 be true. 493 4. Non-Participating MLMs 495 This section contains a discussion of issues regarding sending DKIM- 496 signed mail to or through an MLM that is not DKIM-aware. 497 Specifically, the header fields introduced by [DKIM] and 498 [AUTH-RESULTS] carry no special meaning to such an MLM. 500 4.1. Author-Related Signing 502 If an author knows that the MLM to which a message is being sent is a 503 non-participating resending MLM, the author is advised to be cautious 504 when deciding whether or not to send to the list when that mail would 505 be signed. The MLM could make a change that would invalidate the 506 author's signature but not remove it prior to re-distribution. 507 Hence, list recipients would receive a message purportedly from the 508 author but bearing a DKIM signature that would not verify. There 509 exist DKIM modules that incorrectly penalize messages with signatures 510 that do not validate, so this may have detrimental effects outside of 511 the author's control. (Additional discussion of this is below.) 512 This problem could be compounded if there were receivers that applied 513 signing policies (e.g., [ADSP]) and the author published any kind of 514 strict policy. 516 For domains that do publish strict ADSP policies, the originating 517 site can consider using a separate message stream (see Section 2.4), 518 such as a sub-domain, for the "personal" mail -- a subdomain that is 519 different from domain(s) used for other mail streams. This allows 520 each to develop an independent reputation, and more stringent 521 policies (including ADSP) can be applied to the mail stream(s) that 522 do not go through mailing lists or perhaps do not get signed at all. 524 However, all of this presupposes a level of infrastructure 525 understanding that is not expected to be common. Thus, it will be 526 incumbent upon site administrators to consider how support of users 527 wishing to participate in mailing lists might be accomplished as DKIM 528 achieves wider adoption. 530 In general, the more strict practices and policies are likely to be 531 successful only for the mail streams subject to the most end-to-end 532 control by the originating organization. That typically excludes 533 mail going through MLMs. Therefore, authors whose ADSP is published 534 as "discardable" are advised not to send mail to MLMs, as it is 535 likely to be rejected by ADSP-aware verifiers or recipients. (This 536 is discussed further in Section 5.6 below.) 538 4.2. Verification Outcomes at Receivers 540 There does not appear to be a reliable way to determine that a piece 541 of mail arrived via a non-participating MLM. Sites whose users 542 subscribe to non-participating MLMs should be prepared for legitimate 543 mail to arrive with no valid signature, just as it always has in the 544 absence of DKIM. 546 4.3. Handling Choices at Receivers 548 A receiver's ADMD would have to have some way to register such non- 549 participating lists to exempt them from the expectation of signed 550 mail as discussed in Section 4.1. This is, however, probably not a 551 scalable solution as it imposes a burden on the receiver that is 552 predicated on sender behaviour. 554 Note that the [DKIM] specification explicitly directs verifiers and 555 receivers to treat a verification failure as though the message was 556 not signed in the first place. In the absence of specific ADSP 557 direction, any treatment of a verification failure as having special 558 meaning is either outside the scope of DKIM or is in violation of it. 560 Use of restrictive domain policies such as [ADSP] "discardable" 561 presents an additional challenge. In that case, when a message is 562 unsigned or the signature can no longer be verified, discarding of 563 the message is requested. There is no exception in the policy for a 564 message that may have been altered by an MLM, nor is there a reliable 565 way to identify such mail. Participants are thus advised to honor 566 the policy and disallow the message. 568 4.4. Wrapping A Non-Participating MLM 570 One approach to adding DKIM support to an otherwise non-participating 571 MLM is to "wrap" it, or in essence place it between other DKIM-aware 572 components (such as MTAs) that provide some DKIM services. For 573 example, the ADMD operating a non-participating MLM could have a DKIM 574 verifier act on submissions, enforcing some of the features and 575 recommendations of Section 5 on behalf of the MLM, and the MTA or MSA 576 receiving the MLM Output could also add a DKIM signature for the 577 MLM's domain. 579 5. Participating MLMs 581 This section contains a discussion of issues regarding sending DKIM- 582 signed mail to or through an MLM that is DKIM-aware, and may also be 583 ADSP-aware. 585 5.1. General 587 As DKIM becomes more widely deployed, it is highly desirable that MLM 588 software adopt more DKIM-friendly processing. 590 Changes that merely add new header fields, such as those specified by 591 [LIST-ID], [LIST-URLS] and [MAIL], are generally the most friendly to 592 a DKIM-participating email infrastructure in that their addition by 593 an MLM will not affect any existing DKIM signatures unless those 594 fields were already present and covered by a signature's hash or a 595 signature was created specifically to disallow their addition (see 596 the note about "h=" in Section 3.5 of [DKIM]). 598 However, the practice of applying headers and footers to message 599 bodies is common and not expected to fade regardless of what 600 documents this or any standards body might produce. This sort of 601 change will invalidate the signature on a message where the body hash 602 covers the entire message. Thus, the following sections also discuss 603 and suggest other processing alternatives. 605 A possible mitigation to this incompatibility is use of the "l=" tag 606 to bound the portion of the body covered by the DKIM body hash, but 607 this is not workable for [MIME] messages; moreover, it has security 608 considerations (see Section 3.5 of [DKIM]). Its use is therefore 609 discouraged. 611 MLM operators often arrange to affix to outgoing messages expressions 612 of list-specific policy and related information (e.g., rules for 613 participation, small advertisements, etc.). There is currently no 614 header field proposed for relaying such general operational MLM 615 details apart from what [LIST-URLS] already supports. This sort of 616 information is what is commonly included in appended footer text or 617 prepended header text. The working group recommends periodic, 618 automatic mailings to the list to remind subscribers of list policy. 619 These will be repetitive, of course, but by being generally the same 620 each time they can be easily filtered if desired. 622 5.2. DKIM Author Domain Signing Practices 624 [ADSP] presents a particular challenge. An author domain posting a 625 policy of "discardable" imposes a very tight restriction on the use 626 of mailing lists, essentially constraining that domain's users to 627 lists operated by aliasing MLMs only; any MLM that alters a message 628 from such a domain or removes its signature subjects the message to 629 severe action by verifiers or receivers. It is the consensus of the 630 working group that a resending MLM is advised to reject outright any 631 mail from an author whose domain posts such a policy as it is likely 632 to be rejected by any ADSP-aware recipients, and might also be well 633 advised to discourage such subscribers when they first sign up to the 634 list. Further discussion of this appears in Section 5.3. 636 Where the above practice is not observed and "discardable" mail 637 arrives via a list to a verifier that applies ADSP checks which fail, 638 the message can either be discarded (i.e. accept the message at the 639 [SMTP] level but discard it without delivery) or the message can be 640 rejected by returning a 5xx error code. In the latter case, some 641 advice for how to conduct the rejection in a potentially meaningful 642 way can be found in Section 5.10. 644 See also Appendix B.5 of [ADSP] for further discussion. 646 5.3. Subscriptions 648 At subscription time, an ADSP-aware MLM could check for a published 649 ADSP record for the new subscriber's domain. If the policy specifies 650 "discardable", the MLM might disallow the subscription or present a 651 warning that the subscriber's submissions to the mailing list might 652 not be deliverable to some recipients because of the subscriber's 653 ADMD's published policy. 655 Of course, such a policy record could be applied after subscription, 656 so this is not a universal solution. An MLM implementation could do 657 periodic checks of its subscribers and issue warnings where such a 658 policy is detected, or simply check upon each submission. 660 5.4. Author-Related Signing 662 An important consideration is that authors rarely have any direct 663 influence over the management of an MLM. As such, a signed message 664 from an author will in essence go to a set of unexpected places, 665 sometimes coupled with other messages from other sources. In the 666 future, as DKIM signature outputs (e.g. the AUID or SDID of 667 [DKIM-UPDATE]) are used as inputs to reputation modules, there may be 668 a desire to insulate one's reputation from influence by the unknown 669 results of sending mail through an MLM. In that case, authors may be 670 well-advised to create a mail stream specifically used for generating 671 signatures when sending traffic to MLMs. 673 This suggestion can be made more general. Mail that is of a 674 transactional or generally end-to-end nature, and not likely to be 675 forwarded around either by MLMs or users, should come from a 676 different mail stream than a stream that serves more varied uses. 678 5.5. Verification Outcomes at MLMs 680 MLMs typically attempt to authenticate messages posted through them. 681 They usually do this through the trivial (and insecure) means of 682 verifying the RFC5322.From field email address (or, less frequently, 683 the RFC5321.MailFrom parameter) against a list registry. DKIM 684 enables a stronger form of authentication, although this is not yet 685 formally documented: It can require that messages using a given 686 RFC5322.From address also have a DKIM signature with a corresponding 687 "d=" domain. This feature would be somewhat similar to using ADSP, 688 except that the requirement for it would be imposed by the MLM and 689 not the author's organization. 691 As described, the MLM might conduct DKIM verification of a signed 692 message to attempt to confirm the identity of the author. Although 693 it is a common and intuitive conclusion, not all signed mail will 694 include an author signature (see [ADSP]). MLM implementers are 695 advised to accommodate such in their configurations. For example, an 696 MLM might be designed to accommodate a list of possible signing 697 domains (the "d=" portion of a DKIM signature) for a given author, 698 and determine at verification time if any of those are present. 700 A message that cannot be thus authenticated could be held for 701 moderation or rejected outright. 703 This logic could apply to any list operation, not just list 704 submission. In particular, this improved authentication could apply 705 to subscription, unsubscription, and/or changes to subscriber options 706 that are sent via email rather than through an authenticated, 707 interactive channel such as the web. 709 In the case of verification of signatures on submissions, MLMs are 710 advised to add an [AUTH-RESULTS] header field to indicate the 711 signature(s) observed on the submission as it arrived at the MLM and 712 what the outcome of the evaluation was. Downstream agents may or may 713 not trust the content of that header field depending on their own a 714 priori knowledge of the operation of the ADMD generating (and, 715 preferably, signing) that header field. See [AUTH-RESULTS] for 716 further discussion. 718 5.6. Signature Removal Issues 720 A message that arrives signed with DKIM means some domain prior to 721 MLM Input has made a claim of some responsibility for the message. 722 An obvious benefit to leaving the input-side signatures intact, then, 723 is to preserve that chain of responsibility of the message so that 724 the receivers of the final message have an opportunity to evaluate 725 the message with that information available to them. 727 However, if the MLM is configured to make changes to the message 728 prior to re-posting that would invalidate the original signature(s), 729 further action is recommended to prevent invalidated signatures from 730 arriving at final recipients, possibly triggering unwarranted filter 731 actions. (Note, however, that such filtering actions are plainly 732 wrong; [DKIM] stipulates that an invalid signature is to be treated 733 as no signature at all.) 735 A possible solution would be to: 737 1. Attempt verification of all DKIM signatures present on the input 738 message; 740 2. Apply local policy to authenticate the identity of the author; 742 3. Remove all existing [AUTH-RESULTS] fields (optional); 744 4. Add an [AUTH-RESULTS] header field to the message to indicate the 745 results of the above; 747 5. Remove all previously-evaluated DKIM signatures; 749 6. Affix a new signature that covers the entire message on the 750 output side, including the Authentication-Results header field 751 just added (see Section 5.7). 753 Removing the original signature(s) seems particularly appropriate 754 when the MLM knows it is likely to invalidate any or all of them due 755 to the nature of the reformatting it will do. This avoids false 756 negatives at the list's subscribers in their roles as receivers of 757 the message; although [DKIM] stipulates that an invalid signature is 758 the same as no signature, it is anticipated that there will be some 759 implementations that ignore this advice. 761 The MLM could re-evaluate existing signatures after making its 762 message changes to determine whether or not any of them have been 763 invalidated. The cost of this is reduced by the fact that, 764 presumably, the necessary public keys have already been downloaded 765 and one or both of the message hashes could be reused. 767 Per the discussion in [AUTH-RESULTS], there is no a priori reason for 768 the final receivers to put any faith in the veracity of that header 769 field when added by the MLM. Thus, the final recipients of the 770 message have no way to verify on their own the authenticity of the 771 author's identity on that message. However, should that field be the 772 only one on the message when the verifier gets it, and the verifier 773 explicitly trusts the signer (in this case, the MLM), the verifier is 774 in a position to believe that a valid author signature was present on 775 the message. 777 This can be generalized as follows: A receiver is advised to consider 778 only [AUTH-RESULTS] fields bearing an authserv-id that appears in a 779 list of sites the receiver trusts that is also included in the header 780 hash of a [DKIM] signature added by a domain in the same trusted 781 list. 783 Since an aliasing MLM makes no substantive changes to a message, it 784 need not consider the issue of signature removal as the original 785 signatures should arrive at least to the next MTA unmodified. It is 786 possible that future domain-based reputations would prefer a more 787 rich data set on receipt of a message, and in that case signature 788 removal would be undesirable. 790 An authoring MLM is closed to outside submitters, thus much of this 791 discussion does not apply in that case. 793 5.7. MLM Signatures 795 DKIM-aware resending MLMs and authoring MLMs are encouraged to affix 796 their own signatures when distributing messages. The MLM is 797 responsible for the alterations it makes to the original messages it 798 is re-sending, and should express this via a signature. This is also 799 helpful for getting feedback from any FBLs that might be set up so 800 that undesired list mail can generate appropriate action. 802 MLM signatures will likely be used by recipient systems to recognize 803 list mail, and they give the MLM's ADMD an opportunity to develop a 804 good reputation for the list itself. 806 A signing MLM is, as any other MLM, free to omit redistribution of a 807 message if that message was not signed in accordance with its own 808 local configuration or policy. It could also redistribute but not 809 sign such mail. However, selective signing is discouraged; 810 essentially that would create two message streams from the MLM, one 811 signed and one not, which can confuse DKIM-aware verifiers and 812 receivers. 814 A signing MLM could add a List-Post: header field (see [LIST-URLS]) 815 using a DNS domain matching what will be used in the "d=" tag of the 816 DKIM signature it will add to the new message. This could be used by 817 verifiers or receivers to identify the DKIM signature that was added 818 by the MLM. This is not required, however; it is believed the 819 reputation of the signer will be a more critical data point rather 820 than this suggested binding. Furthermore, this is not a binding 821 recognized by any current specification document. 823 Such MLMs are advised to ensure the signature's header hash will 824 cover: 826 o Any [AUTH-RESULTS] fields added by the MLM; 828 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 830 o Any [MAIL] fields, especially Sender and Reply-To, added or 831 replaced by the MLM. 833 A DKIM-aware resending MLM is encouraged to sign the entire message 834 after being prepared for distribution (i.e. the "MLM Output" from 835 Section 3.2). Any other configuration might generate signatures that 836 cannot be expected to validate. The signature would deally include 837 any original signatures and any header fields that were covered by 838 those signatures, but not any that were not already signed. 840 DKIM-aware authoring MLMs are advised to sign the mail they send 841 according to the regular signing guidelines given in [DKIM]. 843 One concern is that having an MLM apply its signature to unsigned 844 mail might cause some verifiers or receivers to interpret the 845 signature as conferring more authority or authenticity to the message 846 content than is defined by [DKIM]. This is an issue beyond MLMs and 847 primarily entails receive-side processing outside of the scope of 848 [DKIM]. It is nevertheless worth noting here. In the case of MLMs, 849 the presence of an MLM signature is best treated as similar to MLM 850 handling that affixes an RFC5322.Subject tag or similar information. 851 It therefore does not introduce any new concerns. 853 5.8. Verification Outcomes at Final Receiving Sites 855 In general, verifiers and receivers can treat a signed message from 856 an MLM like any other signed message; indeed, it would be difficult 857 to discern any difference since specifications such as [LIST-URLS] 858 and [LIST-ID] are not universally deployed and can be trivially 859 spoofed. 861 However, because the author domain will commonly be different from 862 the MLM's signing domain, there may be a conflict with [ADSP] as 863 discussed in Section 4.3 and Section 5.6, especially where an ADMD 864 has misused ADSP. 866 5.9. Use With FBLs 868 An FBL operator may wish to act on a complaint from a user about a 869 posting to a list. Some FBLs could choose to generate feedback 870 reports based on DKIM verifications in the subject message. Such 871 operators are advised to send a report to each domain with a valid 872 signature that has an FBL agreement established, as DKIM signatures 873 are claims of some responsibility for that message. Because authors 874 generally have limited control over the operation of a list, this 875 point makes MLM signing all the more important. 877 Where the FBL wishes to be more specific, it could act solely on a 878 DKIM signature where the signing domain matches the DNS domain found 879 in a List-Post: header field (or similar). 881 Use of FBLs in this way should be made explicit to list subscribers. 882 For example, if it is the policy of the MLM's ADMD to handle an FBL 883 item by unsubscribing the user that was the apparent sender of the 884 offending message, advising subscribers of this in advance would help 885 to avoid surprises later. 887 5.10. Handling Choices at Receivers 889 A recipient that explicitly trusts signatures from a particular MLM 890 may wish to extend that trust to an [AUTH-RESULTS] header field 891 signed by that MLM. The recipient may then do additional processing 892 of the message, using the results recorded in the Authentication- 893 Results header field instead of the original author's DKIM signature. 894 This includes possibly processing the message as per ADSP 895 requirements. 897 Receivers are advised to ignore or remove all unsigned externally- 898 applied Authentication-Results header fields, and those not signed by 899 an ADMD that can be trusted by the receiver. See Section 5 and 900 Section 7 of [AUTH-RESULTS] for further discussion. 902 Upon DKIM and ADSP evaluation during an SMTP session (a common 903 implementation), an agent might decide to reject a message during an 904 SMTP session. If this is done, use of an [SMTP] failure code not 905 normally used for "user unknown" (550) is suggested; 554 seems an 906 appropriate candidate. If the rejecting SMTP server supports 907 [ENHANCED] status codes, is advised to make a distinction between 908 messages rejected deliberately due to policy decisions rather than 909 those rejected because of other deliverability issues. In 910 particular, a policy rejection is advised to be relayed using a 5.7.1 911 enhanced status code and some appropriate wording in the text part of 912 the reply, in contrast to a code of 5.1.1 indicating the user does 913 not exist. Those MLMs that automatically attempt to remove users 914 with prolonged delivery problems (such as account deletion) will thus 915 be able to tell the difference between policy rejection and other 916 delivery failures, and act accordingly. SMTP servers doing so are 917 also advised to use appropriate wording in the text portion of the 918 reply, perhaps explicitly using the string "ADSP" to facilitate 919 searching of relevant data in logs. 921 The preceding paragraph does not apply to an [ADSP] policy of 922 "discardable". In such cases where the submission fails that test, 923 the receiver or verifier is strongly advised to discard the message 924 but return an SMTP success code, i.e. accept the message but drop it 925 without delivery. An SMTP rejection of such mail instead of the 926 requested discard action causes more harm than good. 928 6. DKIM Reporting 930 The MARF working group is developing mechanisms for reporting 931 forensic details about DKIM verification failures. At the time of 932 this writing, this is still a work in progress. 934 MLMs are encouraged to apply these or other DKIM failure reporting 935 mechanisms as a method for providing feedback to signers about issues 936 with DKIM infrastructure. This is especially important for MLMs that 937 implement DKIM verification as a mechanism for authentication of list 938 configuration commands and submissions from subscribers. 940 7. IANA Considerations 942 This document includes no IANA actions. 944 8. Security Considerations 946 This document provides suggested or best current practices for use 947 with DKIM, and as such does not introduce any new technologies for 948 consideration. However, the following security issues should be 949 considered when implementing the above practices. 951 8.1. Authentication Results When Relaying 953 Section 5 advocates addition of an [AUTH-RESULTS] header field to 954 indicate authentication status of a message received as MLM Input. 955 Per Section 7.2 of [AUTH-RESULTS], receivers generally should not 956 trust such data without a good reason to do so, such as an a priori 957 agreement with the MLM's ADMD. 959 Such agreements are strongly advised to include a requirement that 960 those header fields be covered by a [DKIM] signature added by the 961 MLM's ADMD. 963 9. References 965 9.1. Normative References 967 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 968 Sender Signing Practises", RFC 5617, August 2009. 970 [AUTH-RESULTS] 971 Kucherawy, M., "Message Header Field for Indicating 972 Message Authentication Status", RFC 5451, April 2009. 974 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 975 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 976 Signatures", RFC 4871, May 2007. 978 [EMAIL-ARCH] 979 Crocker, D., "Internet Mail Architecture", RFC 5598, 980 July 2009. 982 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 983 October 2008. 985 9.2. Informative References 987 [DKIM-DEPLOYMENT] 988 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 989 "DomainKeys Identified Mail (DKIM) Development, Deployment 990 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 991 January 2010. 993 [DKIM-OVERVIEW] 994 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 995 Identified Mail (DKIM) Service Overview", RFC 5585, 996 July 2009. 998 [DKIM-UPDATE] 999 Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1000 Signatures -- Update", RFC 5672, August 2009. 1002 [ENHANCED] 1003 Vaudreuil, G., "Enhanced Mail System Status Codes", 1004 RFC 3463, January 2003. 1006 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1007 Object Description Exchange Format", RFC 5070, 1008 December 2007. 1010 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1011 and Namespace for the Identification of Mailing Lists", 1012 RFC 2919, March 2001. 1014 [LIST-URLS] 1015 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1016 for Core Mail List Commands and their Transport through 1017 Message Header Fields", RFC 2369, July 1998. 1019 [MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 1020 Extensible Format for Email Feedback Reports", RFC 5965, 1021 August 2010. 1023 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1024 Extensions (MIME) Part One: Format of Internet Message 1025 Bodies", RFC 2045, November 1996. 1027 [MIME-TYPES] 1028 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1029 Extensions (MIME) Part Two: Media Types", RFC 2046, 1030 November 1996. 1032 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1033 October 2008. 1035 Appendix A. Acknowledgements 1037 The author wishes to acknowledge the following for their review and 1038 constructive criticism of this document: Serge Aumont, Daniel Black, 1039 Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John 1040 Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and 1041 Alessandro Vesely. 1043 Appendix B. Example Scenarios 1045 This section describes a few MLM-related DKIM scenarios that were 1046 part of the impetus for this work, and the recommended resolutions 1047 for each. 1049 B.1. MLMs and ADSP 1051 Problem: 1053 o author ADMD advertises an ADSP policy of "dkim=discardable" 1055 o author sends DKIM-signed mail to a non-participating MLM, which 1056 invalidates the signature 1058 o receiver MTA checks DKIM and ADSP at SMTP time, and is configured 1059 to reject ADSP failures, so rejects this message 1061 o process repeats a few times, after which the MLM unsubscribes the 1062 receiver 1064 Solution: MLMs should refuse mail from domains advertising ADSP 1065 policies of "discardable" unless the MLMs are certain they make no 1066 changes that invalidate DKIM signatures. 1068 B.2. MLMs and FBLs 1070 Problem: 1072 o subscriber sends signed mail to a non-participating MLM that does 1073 not invalidate the signature 1075 o a recipient reports the message as spam 1077 o FBL at recipient ADMD sends report to contributor rather than list 1078 manager 1080 Solution: MLMs should sign mail they send and might also strip 1081 existing signatures; FBLs should report to list operators instead of 1082 subscribers where such can be distinguished, otherwise to all parties 1083 with valid signatures. 1085 Author's Address 1087 Murray S. Kucherawy 1088 Cloudmark 1089 128 King St., 2nd Floor 1090 San Francisco, CA 94107 1091 US 1093 Phone: +1 415 946 3800 1094 Email: msk@cloudmark.com