idnits 2.17.1 draft-fosterd-dmarc-compliant-mailing-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2021) is 924 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC7489' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC7960' is defined on line 428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC D.E. Foster, Ed. 3 Internet-Draft Self 4 Intended status: Informational October 2021 5 Expires: 6 April 2022 7 DMARC Compliant Mailing Lists 8 draft-fosterd-dmarc-compliant-mailing-lists-00 10 Abstract 12 Mailing Lists often make changes to a message before it is 13 retransmitted. This invalidates DKIM signatures, causing a DMARC 14 test on the RFC5322.From addres to fail. A DMARC-compliant mailing 15 list is one which uses member alias addresses to identify the 16 document as sent by a specific author via the mechanism of the list. 17 An appropriate aliasing mechanism will not only prevent DMARC FAIL, 18 but will also allow messages between members, will look natural to 19 senders and recipients, and will allow list organization domains to 20 advance to p=reject. This document describes an aliasing approach 21 which meets these goals. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 4 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Solution Outline . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Solution Infrastructure . . . . . . . . . . . . . . . . . . . 4 61 6. Benefits of full deployment of Group Identifiers . . . . . . 6 62 6.1. Avoids DMARC FAIL . . . . . . . . . . . . . . . . . . . . 6 63 6.2. Enables DMARC enforcement for List-related Messages . . . 7 64 6.3. Avoids Inconsistent Delivery based on RFC5322.From domain 65 filtering . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.4. Avoids Inconsistent Delivery based on bounce-back 67 Filters . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.5. Avoids Incorrect Suspension of Member Addresses . . . . . 8 69 6.6. Available Duplicate Elimination . . . . . . . . . . . . . 8 70 6.7. Available Friendly Name Controls . . . . . . . . . . . . 8 71 6.8. Improves List Isolation . . . . . . . . . . . . . . . . . 8 72 6.9. Permits portability . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 76 10. Informative References . . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Mailing Lists often make changes to a message before it is 82 retransmitted. This invalidates DKIM signatures, causing a DMARC 83 test on the RFC5322.From addres to FAIL. This problem has created a 84 standoff between mailing lists and domain owners. Many domains which 85 participate in mailing lists feel unable to publish a DMARC policy 86 other than NONE, even if their messages are fully DMARC-compliant at 87 origination. 89 Some domain owners publish p=reject anyway, creating difficulties for 90 mailing lists if their users subscribe. In some cases, mailing lists 91 allow participation by users from DMARC-enforcing domains by 92 rewriting those RFC5322.From addresses, often by changing 93 author@authordomain to author=authordomain@listdomain. This 94 rewriting mechanism aliases the author into the list domain, which 95 avoids the DMARC FAIL result, but produces other problems. 97 Previous proposals to adddress these problems have required new 98 software logic and new trust configurations for every organization 99 that participates with mailing lists. Under these proposals, success 100 will depend on the list activating the new authentication signals, 101 the evaluator implementing logic to check those signals, the 102 evalautor trusting the list's reputation when the valid signals are 103 present, and the list operator knowing that the evaluator will use 104 the signals to trust list messages. Such an outcome is difficult to 105 achieve on a large scale, so it becomes necessary to seek a solution 106 which is wholely in control of the mailing list operator. 108 A DMARC-compliant mailing list is one which uses a permanent alias 109 addresses for each member. The alias provides subscribers with a 110 stable identifier within a domain controled by the list organization. 111 This identifier is implemented to allow replies to the author 112 address, to look natural to senders and recipients, and to allow 113 participating domains to advance to p=reject. This document 114 describes an aliasing approach which meets these goals. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. Problem Statement 124 Many closed-group communication systems use member identifiers which 125 allow communication between members, without enabling communication 126 outside of the group environment. Examples include social networking 127 products, online games, and web forums. These environments typically 128 have controls which validate member identity, controls which 129 determine whether members can communicate with each other, controls 130 which limit unacceptable content, and administrative monitoring to 131 maintain good order. The closed communication environment serves to 132 minimize any risk assocoated with interacting with strangers. 134 Email mailing lists are a hybrid environment, providing some of the 135 benefits and controls of other group communication systems, but 136 lacking other elements. The benefits include an enrollment which 137 establishes initial identity, sender authentication mechanisms which 138 verify identity at time of submission, content filters which limit 139 inappropriate messages, and list operator involvement to manage 140 problems. 142 On the negative side, mediators that make changes to an author's 143 message arouse suspicion, since any specific change may be helpful, 144 innocuous, cause misrepresentation, or cause harm. Consequently, the 145 existence of an in-transit change means that the reputation of the 146 change agent is more important than the reputation of the originator. 147 This is even more applicable for mediators that can be trusted to 148 have checked source identity, source reputation, and content risk 149 before determining that the message can be forwarded. 151 For the reputation of the mediator to be the focus of attention by 152 mediators which use existing evaluation strategies, the RFC5322.From 153 address must point to the mediator organization and should be signed 154 by the mediator organization. In short, the message must produce 155 DMARC PASS. The purpose of From-rewrite is not to fix a defect in 156 the design of DKIM or DMARC, but rather to point the evaluator to the 157 organization most responsible for the final state of the document. 159 4. Solution Outline 161 List members are given a permanent alias email address, within the 162 list organization. When list messages are transmitted from the 163 Mailing List Management software (MLM), or between list members, the 164 author's actual email address is rewritten with the author's member 165 alias. When messages are destined to a member alias address, the 166 RFC5321.RcptTo address is rewritten with the member's actual email 167 address. Because the alias email address is registered and 168 permanent, and supported by necessary infrastructure, it can be used 169 for member-to-member communication. 171 For technical reasons, the alias addresses should use a dedicated 172 subdomain within the list organization. A single subdomain could be 173 used for multiple mailing lists, or each list could have its own 174 subdomain, based on organizational preference and technical 175 considerations. For domain example.com, a shared alias domain could 176 be "authoralias@lists.example.com" while a list-specific alias domain 177 could be "authoralias@techtopics.example.com" 179 After a member is unsubscribed, his alias should not be reused, 180 except to reinstate that member, so that there is no identity 181 confusion between past and present subscribers. 183 These features require interoperability between the list enrollment 184 process, where list member aliases are configured, and the mail 185 processing gateways where address replacement occurs. 187 5. Solution Infrastructure 189 Several infrastructure additions are needed to support the alias 190 implementation. 192 * List enrollment processes are needed to select an alias for each 193 subscriber and verify that the alias is unique and not previously 194 used. Additioinally, the translation table of actual address to 195 alias address must be published for use by the rewriting gateways. 197 * A new server or function module is necessary to rewrite the From 198 address on messages posted to the list, and then apply a DKIM 199 signature. 201 * A new message flow path is necessary for member-to-member 202 communication using the list alias domain. 204 The first diagram illustrates a possible mailing list configuration 205 without aliasing. Messages flow in through the incoming gateway, and 206 are forwarded to the list domain mail store. Mailing List 207 Managerment (MLM) software processes messages for the list address, 208 and replicates accepted messages to all recipients. Both internal 209 and external recipients can be delivered to the mail store for 210 delivery or forwarding. Optionally, list messages may be archived. 212 +----------------+ +-------------+ +--------------+ 213 | List Domain MX |->| List Domain |->| List Domain | 214 | Inbound Gwy | | Mail Store | | Outbound Gwy | 215 +----------------+ +-------------+ +--------------+ 216 In | | Out 217 +----------------+ +--------------+ 218 | Journal/Audit |<-| Mailing List | 219 | /Archive (opt) | | Manager | 220 +----------------+ +--------------+| 222 Figure 1 224 The second diagram illustrates a possible mailing list configuration 225 after aliasing is enabled. Messages flow in through the incoming 226 gateway, and are forwarded to the list domain mail store. Mailing 227 List Managerment (MLM) software processes messages for the list 228 address, and replicates accepted messages to all recipients. 229 Outbound messages are forwarded to a smarthost server which performs 230 rewriting of the From address, based on an actual-to-alias address 231 translation table published from the MLM. Additionally, a DKIM 232 signature is applied once all rewriting has been completed. Finally, 233 messages are relayed to an appropriate server or gateway for 234 delivery. 236 +---------------------+ +----------------+ +----------+ 237 | List Alias MX |-->| From Address |->| Outbound | 238 | Inbound Gwy | | Rewrite Server | | Gateway | 239 | MailFrom-RcptTo chk | +----------------+ +----------+ 240 | Receiver rewrite | |In 241 | Content Filters | +----------------+ 242 +---------------------+ | Journal/Audit | 243 | /Archive (opt) | 244 +----------------+ 246 Figure 2 248 The third diagram illustrates a possible mailing configuration of the 249 alias domain used for member-to-member messages. The incoming 250 gateway has the most complexity. It validates the sender identity, 251 verifies that the sender actual address and receiver alias addrss are 252 subscribers to a common list, translates the recipient address to an 253 actual address, and performs content filtering. Accepted messages 254 are forwarded to a smarthost server for rewriting of the From address 255 and application of a DKIM signature. This may be the same smarthost 256 server used for outbound messages from the MLM. Based on list owner 257 policy, messages or message characteristics may be captured for audit 258 or archive purposes. Finally messages are relayed to an appropriate 259 server or gateway for delivery. 261 +---------------------+ +----------------+ +----------+ 262 | List Alias MX |-->| From Address |->| Outbound | 263 | Inbound Gwy | | Rewrite Server | | Gateway | 264 | MailFrom-RcptTo chk | +----------------+ +----------+ 265 | Receiver rewrite | |In 266 | Content Filters | +----------------+ 267 +---------------------+ | Journal/Audit | 268 | /Archive (opt) | 269 +----------------+ 271 Figure 3 273 6. Benefits of full deployment of Group Identifiers 275 While any aliasing scheme could be rolled out on a limited basis to 276 only some subscribers, the benefits of aliasing are maximized when 277 all members are configured with aliases. 279 6.1. Avoids DMARC FAIL 281 As has been well documented, a list without aliasing can encounter 282 problems when the author domain enforces DMARC. 284 6.2. Enables DMARC enforcement for List-related Messages 286 Without aliasing, a list message can be easily spoofed by an 287 attacker. The attacker need only know a list to which the victim 288 subscribes, the visual characteristics of the list message, and an 289 RFC5322.From domain which does not enforce DMARC. Incoming email 290 filters will see an SPF PASS based on the attacker domain, and a From 291 domain without DMARC policy. Unless the message is blocked based on 292 attacker domain reputation or content filtering, the spoofed message 293 will be released to the victim. Similarly, the victim recipient will 294 have no visual clues to raise suspicion. 296 Once a list migrates to aliases for all subscribers, list messages 297 will be from the list organization, list messages will earn DMARC 298 PASS, and list-related domains can be protected with DMARC p=reject 299 to ensure that spoofing attempts are hindered. Recipients will have 300 the visual clue that list-related messages always come from a 301 specific domain within the list organization. 303 6.3. Avoids Inconsistent Delivery based on RFC5322.From domain 304 filtering 306 Some evaluators will filter messages based on the RFC5322.From 307 address. Most commonly, this is used to block addresses from 308 unexpected or untrusted geographies and domains. A mailing list may 309 have a more diverse participation than these filters expect. Without 310 aliasing, some list messages may be blocked by these filters. The 311 subscriber is likely to perceive these missing mesage events as 312 strangely random. Even when the cause is identified, an acceptable 313 resolution may not exist, since the evaluator cannot know the set of 314 all necessary exceptions for all present and future list subscribers. 316 When aliasing is enabled, any filtering performed by the recipient 317 system on the RFC5322.From address will see a list organization 318 domain, rather than an author domain. This helps to ensure that list 319 messages are delivered consistently. If list messages are 320 inappropriately blocked by content filtering, the recipient system 321 manager can safely implement a whitelist rule based on the DMARC- 322 verifiable From domain. 324 6.4. Avoids Inconsistent Delivery based on bounce-back Filters 326 Some evaluators will block external messages that claim to be from an 327 internal domain, when the evaluator does not check DMARC or the 328 sender domain does not enforce DMARC. List posts will always 329 generate these bounce-back messages, because the post is relayed back 330 to the author and may also be sent to other subscribers in the same 331 domaion as the author. With aliasing, messages are never be blocked 332 by such filters, because list-related messages will always be from 333 the list organization, not the author's organization. 335 6.5. Avoids Incorrect Suspension of Member Addresses 337 If a message is inappropriately blocked for any of the above reasons, 338 the mailing list management software may detect the block as a reason 339 to disable the recipient account from future deliveries. By avoiding 340 false blocks, the list also avoids false account suspensions. 342 6.6. Available Duplicate Elimination 344 When a user chooses "Reply All" to a list msessage, the author 345 receives one copy to his own address and one copy from the list 346 expansion. With aliasing, the incoming gateway will see both names, 347 and can optionally be configured to suppress the duplication. 349 6.7. Available Friendly Name Controls 351 When an alias name is registered, the subscription process could also 352 collect a Friendly Name to use along with the alias name. When an 353 RFC5322.From address is replaced with an alias, the registered 354 Friendly Name could be inserted as well. This standardization may 355 help avoid subscriber reconfiguration of the Friendly Name to insert 356 content that is objectionable, or misleading. 358 6.8. Improves List Isolation 360 Mailing lists are intended to be a closed group. By using aliases, 361 membership in the group is verified by the alias domain address. 362 When a user leaves a group, he loses the ability to send messages to 363 list members using their member alias, and list members lose the 364 ability to contact him using his member alias address. In most 365 cases, the alias will be the only address that other members know. 366 Actual addresses may be leaked in message headers, but they are not 367 published explicitly in the From address. 369 6.9. Permits portability 371 Upon evidence satisfactory to the list owner, a subscriber can 372 migrate to a new primary mailing account while preserving his member 373 alias, and thereby retain his identity within the mailing list. 375 7. IANA Considerations 377 This memo includes no request to IANA. 379 8. Security Considerations 381 * Any form of aliasing introduces the possibility of identify 382 misrepresentation or identity obfuscation. Misrepresentation 383 neecds to be controlled by the list operator during the enrollment 384 process. Obfuscation may or may not be acceptable, based on the 385 policies and purposes of the mailing list. A thorough discussion 386 of the issues related to digital identity and enrollment can be 387 found in NIST SP-800-63 [NIST800-63] 389 * The proposed design causes list messages to appear as if they are 390 direct messages from the list domain, rather than forwarded 391 messages that passed through the list domain. As a result, the 392 list domain will bear the reputation consequences, if any 393 inappropriate messages are forwarded to the list. The best 394 defense against this risk is for the list domain to perform 395 effective spam filtering. 397 * Subscribers within the list domain should be fully notified of the 398 limitations of the aliasing strategy, and that their identity 399 cannot be fully protected from other subscribers within the list 400 domain. 402 9. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 410 DOI 10.17487/RFC2629, June 1999, 411 . 413 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 414 Text on Security Considerations", BCP 72, RFC 3552, 415 DOI 10.17487/RFC3552, July 2003, 416 . 418 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 419 Authorizing Use of Domains in Email, Version 1", RFC 7208, 420 DOI 10.17487/RFC7208, April 2014, 421 . 423 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 424 Message Authentication, Reporting, and Conformance 425 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 426 . 428 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky, 429 E., Ed., and K. Andersen, Ed., "Interoperability Issues 430 between Domain-based Message Authentication, Reporting, 431 and Conformance (DMARC) and Indirect Email Flows", 432 RFC 7960, DOI 10.17487/RFC7960, September 2016, 433 . 435 10. Informative References 437 [NIST800-63] 438 U.S. National Institute of Standards and Technology, "The 439 four-volume SP 800-63 Digital Identity Guidelines document 440 suite", 2017, . 442 Author's Address 444 Douglas Foster (editor) 445 Self 446 Virginia Beach, VA 23464 447 United States of America 449 Email: dougfoster.emailstandards@gmail.com