idnits 2.17.00 (12 Aug 2021) /tmp/idnits36169/draft-kucherawy-dkim-lists-00.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 (May 8, 2010) is 4395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 749, but not defined ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) -- No information found for draft-DRAFT-IETF-MARF-BASE - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 5070 (ref. 'IODEF') (Obsoleted by RFC 7970) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Informational May 8, 2010 5 Expires: November 9, 2010 7 Using DKIM With Mailing Lists 8 draft-kucherawy-dkim-lists-00 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 November 9, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4 55 1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5 56 1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 5 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 6 60 2.3. Feedback Loop References . . . . . . . . . . . . . . . . . 6 61 2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 6 62 3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 7 64 3.2. Types Of Mailing Lists Lists . . . . . . . . . . . . . . . 8 65 3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 9 66 3.4. Alternatives of Participation and Conformance . . . . . . 10 67 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11 68 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 11 69 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 12 70 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 12 71 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 13 73 5.2. Verification Outcomes at MLMs . . . . . . . . . . . . . . 13 74 5.3. Pros and Cons of Signature Removal . . . . . . . . . . . . 14 75 5.4. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 15 76 5.5. Verification Outcomes at Final Receiving Sites . . . . . . 15 77 5.6. Handling Choices at Receivers . . . . . . . . . . . . . . 15 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 7.1. Authentication Results When Relaying . . . . . . . . . . . 17 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 85 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 21 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 1. Introduction 90 [DKIM] allows an Administrative Mail Domain to take some 91 responsibility for a [MAIL] message. This can be an author's 92 organization, an operational relay (Mail Transfer Agent, or MTA) or 93 one of their agents. Assertion of responsibility is made through a 94 cryptographic signature. Message transit from author to recipient is 95 through relays that typically make no substantive change to the 96 message content and thus preserve the DKIM signature. 98 In contrast to relays, there are intermediaries, such as mailing list 99 managers (MLMs), that actively take delivery of messages, re-format 100 them, and re-post them, almost always invalidating DKIM signatures. 101 The goal for this document is to explore the use of DKIM for 102 scenarios that include intermediaries. Questions that will be 103 discussed include: 105 o When should an author, or its organization, use DKIM for mail sent 106 to mailing lists? 108 o What are the tradeoffs regarding having an MLM verify and use DKIM 109 identifiers? 111 o What are the tradeoffs regarding having a mailing list remove 112 exisitng DKIM signatures prior to re-posting the message? 114 o What are the tradeoffs regarding having a mailing list add its own 115 DKIM signature? 117 These and others are open questions for which there may be no 118 definitive answers. However, based on experience since the 119 publication of [DKIM] and its gradual deployment, there are some 120 useful views worth considering. 122 This document explores changes to common practice by the signers, the 123 verifiers and the mailing list managers (MLMs). 125 1.1. Background 127 DKIM signatures permit an agent of the email architecture (see 128 [EMAIL-ARCH]) to make a claim of responsibility for a message by 129 affixing a domain-level digital signature to the message as it passes 130 through a gateway. Although not the only possibility, this is most 131 commonly done as a message passes through a Mail Transport Agent 132 (MTA) as it departs an Administrative Mail Domain (ADMD) toward the 133 general Internet. 135 DKIM signatures will fail to verify if a portion of the message 136 covered by one of its hashes is altered. MLMs commonly alter 137 messages to provide information specific to the mailing list for 138 which it is providing service. Common modifications include: 140 o Prefix the Subject: header field with a short string for easy 141 sorting by receivers' Mail User Agents (MUAs) or other filtering 142 software; 144 o Prepend or append list management information to the message's 145 body, such as some text and/or a URL to which subscribers can go 146 to make administrative changes to their subscriptions; 148 o Add header fields such as Reply-To:, Sender:, Resent-Sender: 149 ([MAIL]), List-Id: ([LIST-ID]) or List-Unsubscribe: ([LIST-URLS]). 150 In some cases, such header fields are replaced if the original 151 message already contained them. 153 The DKIM specification documents deliberately refrain from the notion 154 of tying the signing domain (the "d=" tag in a DKIM signature) to any 155 identifier within a message; any ADMD could sign any message 156 regardless of its origin or author domain. As such, there is no 157 specification of any additional value if the content of the "d=" tag 158 in the DKIM signature and the value of (for example) the From header 159 field match, nor is there any obvious degraded value to a signature 160 where they do not match. Since any DKIM signature is merely an 161 assertion of "some" responsibility by an ADMD, a DKIM signature added 162 by an MLM has no more, or less, meaning as a signature with any other 163 "d=" value. 165 1.2. MLMs In Infrastructure 167 The previous section describes some of the things MLMs commonly do 168 that are not DKIM-friendly, producing broken signatures and thus 169 reducing the perceived value of DKIM. 171 Further, despite the advent of 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 MLM behaviors are well-established and standards compliant. Thus, 177 the best approach is to provide these best practices to all parties 178 involved, imposing the minimum requirements possible to MLMs 179 themselves. 181 An MLM is an autonomous agent that takes delivery of a message 182 delivered to it and can re-post it as a new message (or construct a 183 digest of it along with other messages) to the members of the list 184 (see [EMAIL-ARCH], Section 5.3). However, the fact that the From 185 field of such a message is typically the same as for the original 186 message and that recipients perceive the message as "from" the 187 original author rather than the MLM creates confusion about 188 responsibility and autonomy for the re-posted message. This has 189 important implications for use of DKIM. 191 A DKIM signature on a message is an expression of some responsibility 192 for the message taken by the signing domain. An open question, one 193 this document intends to address, is some idea of how such a 194 signature might be applied by an recipient's evaluation module after 195 the message has gone through a mailing list, and may or may not have 196 been invalidated, and if so, where the invalidation may have 197 happened. 199 1.3. Feedback Loops And Other Bi-Lateral Agreements 201 A Feedback Loop (FBL) is a bi-lateral agreement between two parties 202 to exchange reports of abuse. Typically, a bulk mail sender 203 registers with an email receiving site to receive abuse reports from 204 that site for mail coming from the sender. 206 An FBL reporting address is part of this bi-lateral registration. 207 Some FBLs require DKIM use by the registrant. Messages signed and 208 sent by a registrant through an MLM can therefore result in having 209 abuse reports sent to the original author when the actual problem 210 pertains to the operation of the MLM. However, the original author 211 has no involvement in operation of the MLM, meaning the FBL report is 212 not actionable and thus undesirable. 214 1.4. Document Scope and Goals 216 This document provides discussion on the above issues, to improve the 217 handling of possible interactions between DKIM and MLMs. An attempt 218 has been made to prefer imposing changes to behaviour at the signer 219 and verifier rather than at the MLM. 221 Wherever possible, MLMs will be conceptually decoupled from MTAs 222 despite the very tight integration that is sometimes observed in 223 implementation. This is done to emphasize the functional 224 independence of MLM services and responsibilities from those of an 225 MTA. 227 2. Definitions 229 2.1. Other Terms 231 See [EMAIL-ARCH] for a general description of the current messaging 232 architecture, and for definitions of various terms used in this 233 document. 235 2.2. DKIM-Specific References 237 Readers are encouraged to become familiar with [DKIM] and [ADSP] 238 which are standards-track protocol documents as well as 239 [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT] which are DKIM's primary 240 tutorial documents. 242 2.3. Feedback Loop References 244 FBLs tend to use the ARF ([I-D.DRAFT-IETF-MARF-BASE]) or the IODEF 245 ([IODEF]) format. 247 2.4. Message Streams 249 This document makes reference to the concept of "message streams". 250 The idea is to identify groups of messages originating from within an 251 ADMD that are distinct in intent, origin and/or use, and partition 252 them somehow (most commonly via DNS subdomains, and the "d=" tag 253 value in the context of DKIM) so as to keep them associated to users 254 yet operationally distinct. 256 A good example might be user mail, generated by a company's 257 employees, versus operational or transactional mail that comes from 258 automated sources, versus marketing or sales campaigns; each of these 259 could have different security policies imposed against them, or there 260 might be a desire to insulate one from the other (e.g., a marketing 261 campaign that gets reported by many spam filters could cause the 262 marketing stream's reputation to degrade without automatically 263 punishing the transactional or user streams). 265 3. Mailing Lists and DKIM 267 It is important to make some distinctions among different MLM-like 268 agents, their typical implementations, and the impacts they have in a 269 DKIM-aware environment. 271 3.1. Roles and Realities 273 In DKIM parlance, there are several key roles in the transit of a 274 message: 276 author: The agent that actually constructed the message being sent 277 through the system, and performed the initial submission. This 278 can be a human using an MUA or a common system utility such as 279 "cron", etc. 281 originator: The agent that accepts a message from the author, 282 ensures it conforms to the relevant standards such as [MAIL], and 283 then relays it toward its destination(s). This is often referred 284 to as the Mail Submission Agent (MSA). 286 signer: The agent that affixes one or more DKIM signature(s) to a 287 message on its way toward its ultimate destination. It is 288 typically running at the MTA that sits between the author's ADMD 289 and the general Internet. The signer and the sender may also be 290 the same agent. 292 verifier: The agent that conducts DKIM signature analysis. It is 293 typically running at the MTA that sits between the receiver's ADMD 294 and the general Internet. Note that any agent that handles a 295 signed message could conduct verification; this document only 296 considers that action and its outcomes either at an MLM or at the 297 receiver. 299 receiver: The agent that is the final transit relay for the message 300 prior to being delivered to the recipient(s) of the message. 302 In the case of simple user-to-user mail, these roles are fairly 303 straightforward. However, when one is sending mail to a list, which 304 then gets relayed to all of that list's subscribers, the roles are 305 often less clear to the general user, as particular agents may hold 306 multiple important but separable roles. The above definitions are 307 intended to enable more precise discussion of the mechanisms 308 involved. 310 3.2. Types Of Mailing Lists Lists 312 There are four common MLM implementation modes: 314 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 315 that makes no changes to a message as it redistributes; any 316 modifications are constrained to changes to the [SMTP] envelope 317 recipient list (RCPT commands) only. There are no changes to the 318 message body at all and only [MAIL] trace header fields are added. 319 The output of such an MLM is considered to be a continuation of 320 the author's original message. An example of such an MLM is a 321 address that expands directly in the MTA, such as a list of local 322 system administrators used for relaying operational or other 323 internal-only messages. 325 resending: A resending MLM (see Sections 5.2 and 5.3 of 326 [EMAIL-ARCH]) is one that may make changes to a message. The 327 output of such an MLM is considered to be a new message; delivery 328 of the original has been completed prior to distribution of the 329 re-posted message. Such messages are often re-formatted, such as 330 with list-specific header fields or other properties, to 331 facilitate discussion among list subscribers. 333 authoring: An authoring MLM is one that creates the content being 334 sent as well as initiating its transport, rather than basing it on 335 one or more messages received earlier. This is a special case of 336 the MLM paradigm, one which generates its own content and does not 337 act as an intermediary. Typically replies are not generated, or 338 if they are, they go to a specific recipient and not back to the 339 list's full set of recipients. Examples include newsletters and 340 bulk marketing mail. 342 digesting: A special case of the re-posting MLM is one that sends a 343 single message comprising an aggregation of recent MLM submissons, 344 which might be a message of [MIME] type "multipart/digest" (see 345 [MIME-TYPES]). This is obviously a new message but it may contain 346 a sequence of original messages that may themselves have been 347 DKIM-signed. 349 The remainder of this document operates on the presumption that a 350 message going through a re-posting MLM actually comprises two message 351 transactions: 353 1. Originating user to MLM: Originating user is author; originating 354 ADMD is signer; MLM's ADMD is verifier; MLM's input function is 355 receiver. 357 2. MLM to receivers: MLM (sending its reconstructed copy of the 358 originating user's message) is author; MLM's ADMD is signer; the 359 ADMD of each subscriber of the list is a verifier; each 360 subscriber is a receiver. 362 Much of this document focuses on the resending MLM as it has the most 363 direct conflict operationally with DKIM. 365 3.3. Current MLM Effects On Signatures 367 As described above, an aliasing MLM does not affect any existing 368 signature, and an authoring MLM is always new content and thus there 369 is never an existing signature. However, the changes a resending MLM 370 can make typically affect the Subject: header field, addition of some 371 list-specific header fields, or the addition of some list-specific 372 text to the top or bottom of the message body. The impacts of each 373 of these on DKIM verification are discussed below. 375 Subject tags: Altering the Subject: header field will invalidate the 376 signer's signature if that header field was covered by a hash of 377 that signature. [DKIM] lists Subject as one that should be 378 covered, so this is expected to be an issue for any list that 379 makes such changes. 381 List-specific header fields: Some lists will add header fields 382 specific to list administrative functions such as those defined in 383 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 384 [MAIL]. It is unlikely that a typical MUA would include such 385 fields in an original message, and DKIM is resilient to the 386 addition of header fields in general (though see notes about the 387 "h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as 388 less of a concern. 390 Other header fields: Some lists will add or replace header fields 391 such as "Reply-To" or "Sender" in order to establish that the 392 message is being sent in the context of the mailing list, so that 393 the list is identified ("Sender") and any user replies go to the 394 list ("Reply-To"). If these fields were included in the original 395 message, it is possible that one or more of them may have been 396 signed, and this could cause a concern for MLMs that add or 397 replace them. 399 Body changes: Some lists prepend or append a few lines to each 400 message to remind subscribers of an administrative URL for 401 subscription issues, or of list policy, etc. Changes to the body 402 will alter the body hash computed at the DKIM verifier, so these 403 pose an immediate problem. 405 3.4. Alternatives of Participation and Conformance 407 As DKIM becomes more entrenched, it is highly desirable that MLM 408 software adopt more DKIM-friendly processing. 410 Changes that merely add new header fields, such as those specified by 411 [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to 412 a DKIM-participating email infrastructure in that their addition by 413 an MLM will not affect any existing DKIM signatures unless those 414 fields were already present and covered by a signature's hash or a 415 signature was created specifically to disallow their addition (see 416 the note about "h=" in Section 3.5 of [DKIM]). The shortest path to 417 success for DKIM would be to mandate that all MLM software be re- 418 designed or re-configured with that goal in mind. 420 However, the practice of applying headers and footers to message 421 bodies is common and not expected to fade regardless of what 422 documents this or any standards body might produce. This sort of 423 change will invalidate the signature on a message where the body hash 424 covers the entire entire message. Thus, the following sections also 425 investigate and recommend other processing alternatives. 427 A possible mitigation to this incompatibility is use of the "l=" tag 428 to bound the portion of the body covered by the body hash, but this 429 has security considerations (see Section 3.5 of [DKIM]). 431 4. Non-Participating MLMs 433 This section contains a discussion of issues regarding sending DKIM- 434 signed mail to or through an MLM that is not DKIM-aware. 435 Specifically, the header fields introduced by [DKIM] and 436 [AUTH-RESULTS] carry no special meaning to such an MLM. 438 4.1. Author-Related Signing 440 If an author knows that the MLM to which a message is being sent is a 441 non-participating resending MLM, the author is advised to be cautious 442 when deciding whether or not to sign the message. The MLM could make 443 a change that would invalidate the author's signature but not remove 444 it prior to re-distribution. 446 Hence list recipients would receive a message message purportedly 447 from the author but bearing a DKIM signature that would not verifiy. 448 This problem would be compounded further if there were receivers that 449 applied signing policies ([ADSP]) and the author published any kind 450 of strict policy. 452 If this is cause for concern, the originating site can consider using 453 a sub-domain for the "personal" mail that is different from domain(s) 454 used for other mail streams, so that they develop independent 455 reputations, and more stringent policies (including ADSP) can be 456 applied to the mail stream(s) that do not go through mailing lists. 458 There is also a concern if the author's domain posts a restrictive 459 ADSP policy such as "discardable" and no author signature is applied 460 at all. Such a posting obviously violates the published policy and 461 the message is subject to rejection by any receiver that applies 462 ADSP. 464 However, all of this presupposes a level of infrastructure 465 understanding that is not expected to be common. Thus, it will be 466 incumbent upon site administrators to consider how support of users 467 wishing to participate in mailing lists might be accomplished as DKIM 468 achieves wider adoption. A common suggestion is to establish 469 subdomains in the DNS that are used for separating different streams 470 of mail from within an ADMD, such as user-created "direct" mail from 471 transactional or automated mail; some of these may be signed and some 472 not, some with published ADSP records, some not. In general, the 473 more strict practices and policies are likely to be successful only 474 for the mail streams subject to the most end-to-end control by the 475 originating organization. That typically excludes mail going through 476 MLMs. 478 4.2. Verification Outcomes at Receivers 480 Verifiers that receive mail bearing DKIM signatures that fail to 481 verify might benefit from attempting to detect that such mail passed 482 through a non-participating MLM and then decide not to apply [ADSP] 483 in order to avoid aggressive filtering of mail that should otherwise 484 have been delivered. 486 Unfortunately, there may not be a reliable way of making such 487 determinations, as there is no uniform MLM behaviour, and any tagging 488 mechanism meant to relay such information could easily be abused. 490 Note that the underlying problem is the operational choice to use 491 ADSP in a message stream that does not maintain the signature. 493 4.3. Handling Choices at Receivers 495 A receiver's ADMD would have to have some way to register such non- 496 participating lists to exempt them from the filtering described in 497 Section 4.1. This is, however, probably not a scalable solution as 498 it imposes a burden on the receiver that is predicated on sender 499 behaviour. 501 Note that the [DKIM] specification explicitly directs verifiers to 502 treat a verification failure as though the message were not signed in 503 the first place. In the absence of specific ADSP direction, any 504 treatment of a verification failure as having special meaning is 505 either outside the scope of DKIM or is in violation of it. 507 [ADSP] presents an additional challenge. Per that specification, 508 when a message is unsigned or the signature can no longer be 509 verified, the verifier must discard the message. There is no 510 exception in the policy for a message that may have been altered by 511 an MLM. Verifiers are thus advised to honor the policy and disallow 512 the message. Furthermore, authors whose ADSP is published as 513 "discardable" are advised not to send mail to MLMs as it is likely to 514 be rejected by ADSP-aware recipients. (This is discussed further in 515 Section 5.3 below.) 517 5. Participating MLMs 519 This section contains a discussion of issues regarding sending DKIM- 520 signed mail to or through an MLM that is DKIM-aware, and may also be 521 ADSP-aware. 523 5.1. Author-Related Signing 525 MLMs typically attempt to authenticate messages posted through them. 526 They usually do this through the trivial (and insecure) means of 527 verifying the From field email address against a list registry. DKIM 528 enables a stronger form of authentication, although this is not yet 529 formally documented: It can require that messages using a given From 530 address also have a DKIM signature with a corresponding "d=" domain. 531 (Note, however, that it is entirely reasonable for an MLM to permit 532 registration of some other "d=" domain as valid evidence of such 533 authentication.) This feature would be somewhat similar to using 534 ADSP, except that the requirement for it would be imposed by the MLM 535 and not the author's organization. 537 An important consideration is that authors rarely have any direct 538 influence over the management of an MLM. As such, a signed message 539 from an author will in essence go to a set of unexpected places. 540 Authors may be well-advised to create a DNS domain specifically used 541 for generating signatures when sending traffic to MLMs. This becomes 542 important as domain-based reputation systems begin to appear as 543 components of mail filtering modules. 545 5.2. Verification Outcomes at MLMs 547 As described above, the MLM may conduct DKIM verification of a signed 548 message to attempt to confirm the identity of the author. Although 549 it is a common and intuitive conclusion, however, not all signed mail 550 will include an author signature (see [ADSP]). MLM implementors are 551 advised to accomodate such in their configurations. For example, an 552 MLM might be designed to accomodate a list of possible signing 553 domains (the "d=" portion of a DKIM signature) for a given author, 554 and determine at verification time if any of those are present. 556 A message that cannot be thus authenticated could be held for 557 moderation or rejected outright. 559 This logic could apply to any list operation, not just list 560 submission. In particular, this improved authentication could apply 561 to subscription, unsubscription, and/or changes to subscriber options 562 that are sent via email rather than through an authenticated, 563 interactive channel such as the web. 565 In the case of verification of signatures on subscriptions, MLMs are 566 advised to add an [AUTH-RESULTS] header field to indicate the 567 signature(s) observed on the submission as it arrived at the MLM and 568 what the outcome of the evaluation was. 570 5.3. Pros and Cons of Signature Removal 572 If the MLM is configured to make changes to the message prior to re- 573 posting that would invalidate the original signature(s), further 574 action is recommended to prevent invalidated signatures from arriving 575 at final recipients, possibly triggering unwarranted filter actions. 576 A possible solution would be to: 578 1. Attempt verification of all DKIM signatures present on the 579 message; 581 2. Apply local policy to authenticate the identity of the author; 583 3. Add an [AUTH-RESULTS] header field to the message to indicate the 584 results of the above; 586 4. Remove all previously-evaluated DKIM signatures; 588 5. Affix a new signature that covers the Authentication-Results 589 header field just added. 591 Removing the original signature(s) seems particularly appropriate 592 when the MLM knows it is likely to invalidate any or all of them due 593 to the nature of the reformatting it will do. This avoids false 594 negatives at the list's subscribers in their roles as receivers of 595 the message. 597 However, per the discussion in [AUTH-RESULTS], there is no a priori 598 reason for the final receivers to put any faith in the veracity of 599 that header field when added by the MLM. Thus, the final recipients 600 of the message have no way to verify on their own the authenticity of 601 the author's identity on that message. 603 Since an aliasing MLM makes no substantive changes to a message, it 604 need not consider the issue of signature removal as the original 605 signatures should arrive at least to the next MTA unmodified. 607 An authoring MLM is closed to outside submitters, thus much of this 608 discussion does not apply in that case. 610 [ADSP] presents a particular challenge. An author domain posting a 611 policy of "discardable" imposes a very tight restriction on the use 612 of mailing lists, essentially constraining that domain's users to 613 lists operated by aliasing MLMs only; any MLM that alters a message 614 from such a domain or removes its signature subjects the message to 615 severe action by receivers. A resending MLM is advised to reject 616 outright any mail from an author whose domain posts such a policy as 617 it is likely to be rejected by any ADSP-aware recipients. 619 5.4. MLM Signatures 621 DKIM-aware resending MLMs and authoring MLMs are encouraged to affix 622 their own signatures when distributing messages. Such MLMs are 623 advised to ensure the signature's header hash will cover: 625 o Any [AUTH-RESULTS] fields added by the MLM; 627 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 629 o Any [MAIL] fields, especially Sender and Reply-To, added or 630 replaced by the MLM. 632 A DKIM-aware resending MLM is encouraged to sign the entire message 633 as it arrived, especially including the original signatures. 635 DKIM-aware authoring MLMs are advised to sign the mail they send 636 according to the regular signing guidelines given in [DKIM]. 638 5.5. Verification Outcomes at Final Receiving Sites 640 In general, verifiers and receivers can treat a signed message from 641 an MLM like any other signed message; indeed, it would be difficult 642 to discern any difference. 644 However, because the author domain will commonly be different from 645 the MLM's signing domain, there may be a conflict with [ADSP] as 646 discussed in Section 4.3 and Section 5.3. 648 5.6. Handling Choices at Receivers 650 A recipient that trusts signatures from an MLM may wish to extend 651 that trust to an [AUTH-RESULTS] header field signed by that MLM. The 652 recipient may then do additional processing of the message, using the 653 results recorded in the Authentication-Results header field instead 654 of the original author's DKIM signature. This includes possibly 655 processing the message as per ADSP requirements. 657 Receivers are advisedto ignore all unsigned Authentication-Results 658 header fields. 660 6. IANA Considerations 662 This document includes no IANA actions. 664 7. Security Considerations 666 This document provides suggested or best current practices for use 667 with DKIM, and as such does not introduce any new technologies for 668 consideration. However, the following security issues should be 669 considered when implementing the above practices. 671 7.1. Authentication Results When Relaying 673 some stuff about the fact that the MLM's auth-results can't be 674 trusted by default 676 8. References 678 8.1. Normative References 680 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 681 Sender Signing Practises", RFC 5617, August 2009. 683 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 684 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 685 Signatures", RFC 4871, May 2007. 687 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 688 October 2008. 690 8.2. Informative References 692 [AUTH-RESULTS] 693 Kucherawy, M., "Message Header Field for Indicating 694 Message Authentication Status", RFC 5451, April 2009. 696 [DKIM-DEPLOYMENT] 697 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 698 "DomainKeys Identified Mail (DKIM) Development, Deployment 699 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 700 January 2010. 702 [DKIM-OVERVIEW] 703 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 704 Identified Mail (DKIM) Service Overview", RFC 5585, 705 July 2009. 707 [EMAIL-ARCH] 708 Crocker, D., "Internet Mail Architecture", RFC 5598, 709 July 2009. 711 [I-D.DRAFT-IETF-MARF-BASE] 712 Shafranovich, Y., Levine, J., and M. Kucherawy, "An 713 Extensible Format for Email Feedback Reports", I-D DRAFT- 714 IETF-MARF-BASE, April 2010. 716 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 717 Object Description Exchange Format", RFC 5070, 718 December 2007. 720 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 721 and Namespace for the Identification of Mailing Lists", 722 RFC 2919, March 2001. 724 [LIST-URLS] 725 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 726 for Core Mail List Commands and their Transport through 727 Message Header Fields", RFC 2369, July 1998. 729 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 730 Extensions (MIME) Part One: Format of Internet Message 731 Bodies", RFC 2045, November 1996. 733 [MIME-TYPES] 734 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 735 Extensions (MIME) Part Two: Media Types", RFC 2046, 736 November 1996. 738 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 739 October 2008. 741 Appendix A. Acknowledgements 743 The author wishes to acknowledge the following for their review and 744 constructive criticism of this document: Dave Crocker, JD Falk, Tony 745 Hansen and S. Moonesamy. 747 Appendix B. Examples 749 [TBD] 751 Author's Address 753 Murray S. Kucherawy 754 Cloudmark 755 128 King St., 2nd Floor 756 San Francisco, CA 94107 757 US 759 Phone: +1 415 946 3800 760 Email: msk@cloudmark.com