idnits 2.17.1 draft-vesely-dmarc-mlm-transform-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 27 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2021) is 1163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MLM-tag' is mentioned on line 151, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-dmarc-dmarcbis-00 -- Obsolete informational reference (is this intentional?): RFC 7601 (Obsoleted by RFC 8601) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Vesely 3 Internet-Draft February 2021 4 Intended status: Informational 5 Expires: 5 August 2021 7 Mailing List Manager (MLM) Transformations 8 draft-vesely-dmarc-mlm-transform-01 10 Abstract 12 The widespread adoption of Domain-based Message Authentication, 13 Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to 14 rewrite the From: header field as a workaround. 16 This document describes cases where it is possible to revert MLM 17 transformations and hence verify DomainKeys Identified Mail (DKIM) 18 signatures that were applied at submission time. For reliable 19 results, some compliance is required of all agents involved, author 20 domain signers, MLMs, forwarders, and final recipients. 22 MLM transformation reversion reduces the DMARC's effects on indirect 23 mail flows. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 5 August 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terms Definitions . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Revertible Transformations . . . . . . . . . . . . . . . . . 3 58 3.1. Header Transformations . . . . . . . . . . . . . . . . . 3 59 3.2. Body Transformations . . . . . . . . . . . . . . . . . . 4 60 4. Outline of a Reverting Verifier . . . . . . . . . . . . . . . 5 61 5. Actors Roles and Compliance . . . . . . . . . . . . . . . . . 6 62 5.1. Original Signer . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. MLM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.3. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7.1. Permanent Message Header Field Names . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 72 A.1. Single-part plain text . . . . . . . . . . . . . . . . . 12 73 A.2. Multipart added . . . . . . . . . . . . . . . . . . . . . 13 74 A.3. Multipart wrapped . . . . . . . . . . . . . . . . . . . . 15 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 Mailing List Managers (MLMs) can be configured to add a footer and a 80 subject tag to the messages that they redistribute. Although that 81 behavior slightly exceeds the very limited set of modifications and 82 actions described by Section 3.9.2 of [RFC5321], it is a welcome, 83 time-honored tradition. According to their configuration, the 84 modifications they carry out on messages may result in a set of 85 stylized transformations that are programmatically revertible. 86 Reversion allows to verify DomainKeys Identified Mail (DKIM) 87 signatures ([RFC6376]) that were applied before the transformation. 89 Domain-based Message Authentication, Reporting, and Conformance 90 (DMARC) ([I-D.ietf-dmarc-dmarcbis]) hinges on the alignment of the 91 domain in the From: header field with a verified DKIM signature. For 92 that reason, MLMs that transform messages have to rewrite From:. A 93 deed which can be mitigated in some cases. 95 Mailbox providers can configure their mail submission agents (MSAs) 96 in order to ease MLM transformation reversion. Or they can make it 97 impossible. It is their policy and their will. MLM operators make a 98 similar decision. When they both agree on revertibility, a well 99 equipped receiver can verify the original signatures. The outcome is 100 twofold: 102 1. Author domains receive positive feedback about DKIM verification 103 of mailing list traffic. That might eventually lead them to 104 harden their DMARC policy. 106 2. Final recipient's mail delivery agents (MDAs), which know by the 107 Authentication-Results: field whether a rewritten From: header 108 was verified, can safely undo From: munging (after any external 109 forwarding). 111 2. Terms Definitions 113 *Signers* and *verifiers* are defined in [RFC6376]. The use of the 114 term *Mailing List Manager*, almost always abbreviated *MLM* follows 115 [RFC6377]. A MLM is a kind of *Mediator* in [RFC5598] parlance. 117 *Message* is defined in [RFC5322]. It consists of a *header* made up 118 of one or more *fields* and a *body*, possibly composed of various 119 MIME *entities*, the latter being defined in [RFC2045] and 120 companions. 122 The term *original* is used here to refer to the Author or parts of 123 the Author's message as it was sent out by the Author's domain, where 124 *Author* is defined in [RFC5598]. 126 3. Revertible Transformations 128 Message modifications can affect the header and/or the body of a 129 message. This document only considers the very limited set of 130 transformation described in the following subsections. They turn out 131 to be revertible. 133 3.1. Header Transformations 135 MLM often modify the Subject: field by inserting a tag at the 136 beginning of its value. A tag consists of a short text delimited by 137 square brackets. For example: 139 Subject: [added tag] Original value of subject 141 This transformation is easily reverted by removing the tag. For 142 security reasons, subject tags must not exceed 20 characters. 144 Note that some MLM carry out further changes to this field. For 145 example: 147 Subject: AW: [MLM-tag] German reply subject 149 can be transformed to: 151 Subject: Re: [MLM-tag] German reply subject 153 Therefore, if the field is signed, it is clever to save a copy of it 154 as Original-Subject:. 156 A more recent modification carried out by MLMs is From: rewriting. 157 It alters the value of From: in order to pass DMARC filters. MLMs 158 save the original value of From: in a variety of places, including 159 Reply-To:, Cc:, X-Original-From:. When the original value is known, 160 the transformation is revertible. 162 3.2. Body Transformations 164 Footer addition is often performed in one of three ways, according to 165 the format of the original message. 167 Single-part plain text 168 When the original message is not structured, a footer can be 169 appended at the end of the original text. See example in 170 Appendix A.1 172 Multipart added 173 The footer stands in its own MIME entity, which is appended as the 174 last part of an original multipart/mixed structure. See example 175 in Appendix A.2 177 Multipart wrapped 178 The footer stands in the second entity of a new multipart/mixed 179 MIME structure whose first entity consists of the original body. 180 See example in Appendix A.3 182 The footer begins with a line consisting exclusively of underscore 183 ("_", ASCII 95) characters, at least four of them. Alternatively, a 184 footer can consist of the three characters "-- " (dash, dash, space), 185 the Usenet signature convention (see for example Section 4.3 of 186 [RFC3676]). For security reasons, the footer must belong to an 187 entity of Content-Type: text/plain in all cases. In addition, 188 footers cannot exceed 10 lines of text, each shorter than 80 189 characters. 191 4. Outline of a Reverting Verifier 193 The algorithm described here is implemented in a mail filter. It 194 usually reads the input message twice -first pass, verify; last pass, 195 write Authentication-Results and the rest of the message to follow. 196 When enabling MLM transformation reversion, there can be a retry pass 197 in between those two. The result is yielded during the SMTP dialogue 198 with no noticeable delay. Implementing reversion changed the 199 software from 22730 lines of C code to 26762. The bulk of such ~18% 200 increase is due to the addition of encoding conversion functions. 201 Changes involve both verifying and signing functions (see Section 5.1 202 for the latter). 204 While reading the header in the first pass, the verifier looks for 205 specific fields: 207 * From: 209 * Original-From: 211 * X-Original-From: 213 * Reply-To: 215 * Cc: 217 These are candidates to the original mailbox. 219 The verifier also collects the Subject: and any field named 220 Original-* that the original signer might have set to ease the 221 reversion. At the end of the header, candidate original mailboxes 222 are sorted according to the display name, which MLMs try and keep 223 unaltered. The best candidate is then added to the collected set of 224 Original-* fields. If the Subject: begins with a tag, its version 225 without tag is added to that set as well, unless one is there 226 already. 228 Next, before reading the body, the verifier looks for prospect 229 signatures; that is, signatures whose "d=" domain is not aligned with 230 SPF credentials ([RFC7208]), List-Post: ([RFC4201]), Sender:, or the 231 rewritten From: (if deemed to have been rewritten). If any such 232 signature exist, along with MLM or other signatures, then the 233 verifier enables parsing the body to look for a footer. 235 Body parsing is done in parallel with body canonicalization during 236 the first pass. For multipart, track top level entities. Set 237 transformation type to "wrapped" if there are exactly two entities, 238 "added" otherwise. For single-part, body parsing must avail of 239 encoding conversions as needed. Assume identity encoding, 7bit or 240 8bit, unless otherwise directed by an Original-Content-Transfer- 241 Encoding: field. 243 At the end of the first pass, the verifier knows how prospect 244 signatures did. Let's recall that DKIM signature verification 245 results from two independent operations, steps 3 and 4 in 246 Section 6.1.3 of [RFC6376]. The signature in the "b=" tag depends on 247 the header, while the body hash in the "bh=" tag depends on the body: 249 * If the signature "b=" did not verify and the set of Original-* 250 fields is not empty, then it is worth to try and re-canonicalize 251 the header using the values in the set of Original-* fields. 253 * If the body hash "bh=" did not match and a footer was found, then 254 it is worth to try and re-canonicalize the body excluding the 255 footer. 257 None, one, or both of the above operations are performed in the retry 258 pass. 260 On writing Authentication-Results, if a prospect signature verifies 261 after replacing the From: field, the verifier writes a prominent, 262 well documented "reason" in the relevant resinfo stanza (Section 2.2 263 of [RFC7601]). That way, reversion elements can be easily recognized 264 and parsed by downstream agents. 266 5. Actors Roles and Compliance 268 5.1. Original Signer 270 Signers who wish their users to be able to participate to mailing 271 lists can adopt rules apt to ease MLM transformations reversion. 272 Doing so can slightly weaken DKIM'S stiffness, and expose to the risk 273 of malicious MLMs. A sender that doesn't know which of its mail 274 recipients are likely to be MLMs might abide by the following rules 275 for all outgoing mail, in the expectation that few of its users 276 correspondents are likely to be malicious. A sender that had some 277 idea which recipients are MLMs could apply the rules only to mail to 278 those recipients. Or a sender might apply the rules to all mail 279 except that sent to recipients with poor reputations. 281 A special rule is the addition of an Original-From: header field with 282 a value identical to the one signed in From:. Original-From: is 283 defined by [RFC5703] in the context of Sieve Email Filtering. As 284 Sieve operates at time of final delivery, DKIM verifiers which act at 285 the time of message transit can reliably use it. 287 Original-From: is special because verifiers may infer that the field 288 was added by the original signer rather than by MLMs. In that case, 289 they can send DMARC feedback reports to the original signer even if 290 From: was rewritten. 292 Note that [RFC7960] suggests that ReSenders can add an Original-From: 293 too, although it is not being used consistently. If this is a 294 conflict, the field name has to be changed before publishing this 295 document. 297 Other generic rules to ease reversion are as follows: 299 * DKIM signatures must deploy the "relaxed" canonicalization, at 300 least for the header, since MLMs may reflow header fields. 302 * The quoted-printable encoding must not be used for the body of 303 single-part text/plain messages, as it is impossible to guess 304 original soft line breaks after re-encoding. Base64 is much more 305 robust. 307 * Single-part text/plain messages encoded as base64 must follow a 308 constant column width of 76 characters. The encoding must be 309 advertised by adding a new header field as follows: 311 Original-Content-Transfer-Encoding: base64 313 * If the original Subject: begins with a tag, its value must be 314 copied to an Original-Subject: header field. The latter field is 315 also defined by [RFC5703], and the same usage considerations hold. 317 * Content-Type: and Content-Transfer-Encoding: are fields related to 318 the data form. Mailers often rewrite them, so they should not be 319 signed. If signed, their Original- counterpart should be set too. 321 * When signing Cc: or Reply-To:, add their Original- counterparts to 322 the header, as MLMs are likely to change them. 324 * Original-*: fields with an empty value stand for non-existing 325 counterparts. 327 * Original-* fields need not be signed. If original signatures can 328 be recovered, that suffices; otherwise, the unverified signature 329 is irrelevant. 331 5.2. MLM 333 Participating MLMs must not operate transformations other than those 334 listed in Section 3. Since DKIM is MIME-agnostic, attention must be 335 paid to preserve the exact preamble and epilogue of the original MIME 336 structure. 338 MLMs must apply their own DKIM signature. The presence of signatures 339 by multiple domains can be used by verifiers to infer that a message 340 underwent MLM transformations. 342 MLMs must not set the Original-From: field, which is reserved to 343 original signers. It is recommended that MLMs add a mailbox entry to 344 Reply-To: or Cc: in order to ease off-list replies as well as to 345 allow transformation reversion, but only in case the Original-From: 346 is missing. 348 MLMs may set Original-* fields other than Original-From:, but only if 349 the original message contains no Original-* field at all. That is, 350 when the author's domain is not aware of the possibility to ease MLM 351 transformation reversion. 353 MLMs which collect posts from other MLMs must avoid to add their own 354 footer and subject tag. Transformation reversion cannot be stacked. 355 A second-level MLM can modify or replace the content of previous 356 transformations. Attention must be paid to not exceed tag and footer 357 length limits. 359 5.3. Verifier 361 Attempts to verify original signatures can be done as outlined in 362 Section 4. The reversion must not replace the messages signed and 363 distributed by MLMs, with one exception detailed in the next 364 paragraph. Only the result of the verification is written out. 366 If an original signature with rewritten From: is recovered, the 367 verifier must make sure that an Original-From: field with the 368 verified mailbox is written out. An MDA downstream may combine the 369 Authentication-Results: and Original-From: fields to restore the 370 original value of From:. This is the only recommended modification 371 to the distributed message. It must be done after any dot-forward 372 processing, so that external verifiers receive the message as 373 distributed by the MLM, and can revert transformations by themselves. 375 If the Original-From: is set, the corresponding DMARC record may be 376 looked up and its "rua=" and "ruf=" tags considered for feedback 377 reports. If DMARC policies are considered, it is the the From: field 378 which rules, not the Original-From: nor any other mailbox value, 379 unless verified. 381 6. Security Considerations 383 Rewriting the From: header field is an unwelcome modification to 384 messages. It fosters the belief that the display name of a mailbox 385 is more trustworthy than the angle address. A belief further 386 consented by the tendency to not even display the latter. Bad actors 387 take advantage of this belief by displaying the names of trusted 388 institution paired with trash email addresses hidden between angle 389 brackets. That trick defeats DMARC's purpose. 391 It is out of this document's scope to suggest how mail user agents 392 (MUAs) could counter phishing by highlighting security indicators 393 (for the extent that indicators can actually help preventing phishing 394 attacks). Let's just note that MUAs have to cope with MLM and 395 phishing alike, which makes it hard to devise a pattern to tell apart 396 one from the other without getting involved with the reputation of 397 the specific domains. 399 By safely restoring munged From: to the original value, that contrast 400 is eliminated. Then, perhaps, deceptive mailboxes might become 401 amenable to some kind of efficient indication. 403 Of course, MLM role can be played by miscreants as well. However, 404 replaying a signed message, even with revertible transformations, has 405 more limits than forging scam messages anew. Therefore, the risk 406 introduced by easing transformation reversion is considerably lower 407 than that of not signing, or of keeping DMARC policy at "none". 409 Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the 410 fact that footers are written in plain text removes the main security 411 objection about footer additions. Namely, footers cannot completely 412 replace the original content in the end recipient's eyes by 413 exploiting lax HTML parsing in the MUA. 415 Still, a footer can contain dangerous URLs and deceiving text. That 416 possibility has to be countered by usual mail filtering and savvy 417 behavior. 419 7. IANA Considerations 421 IANA maintains the "Message Header" registry with several 422 subregistries. IANA is asked to make the assignments set out in the 423 following section. 425 7.1. Permanent Message Header Field Names 427 IANA is asked to create new entries in the "Permanent Message Header 428 Field Names" registry as follows. 430 +===================+==========+==========+==========+===========+ 431 | Header Field Name | Template | Protocol | Status | Reference | 432 +===================+==========+==========+==========+===========+ 433 | Original-Content- | | mail | standard | this I-D | 434 | Transfer-Encoding | | | | | 435 +-------------------+----------+----------+----------+-----------+ 436 | Original-Reply-To | | mail | standard | this I-D | 437 +-------------------+----------+----------+----------+-----------+ 438 | Original-Cc | | mail | standard | this I-D | 439 +-------------------+----------+----------+----------+-----------+ 441 Table 1 443 8. References 445 8.1. Normative References 447 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 448 Extensions (MIME) Part One: Format of Internet Message 449 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 450 . 452 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 453 DOI 10.17487/RFC5321, October 2008, 454 . 456 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 457 DOI 10.17487/RFC5322, October 2008, 458 . 460 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 461 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 462 RFC 6376, DOI 10.17487/RFC6376, September 2011, 463 . 465 [I-D.ietf-dmarc-dmarcbis] 466 Gustafsson, E., Herr, T., and J. Levine, "Domain-based 467 Message Authentication, Reporting, and Conformance 468 (DMARC)", Work in Progress, Internet-Draft, draft-ietf- 469 dmarc-dmarcbis-00, 11 November 2020, 470 . 473 8.2. Informative References 475 [RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters", 476 RFC 3676, DOI 10.17487/RFC3676, February 2004, 477 . 479 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 480 in MPLS Traffic Engineering (TE)", RFC 4201, 481 DOI 10.17487/RFC4201, October 2005, 482 . 484 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 485 Tests, Iteration, Extraction, Replacement, and Enclosure", 486 RFC 5703, DOI 10.17487/RFC5703, October 2009, 487 . 489 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 490 DOI 10.17487/RFC5598, July 2009, 491 . 493 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 494 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 495 September 2011, . 497 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 498 Authorizing Use of Domains in Email, Version 1", RFC 7208, 499 DOI 10.17487/RFC7208, April 2014, 500 . 502 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 503 Message Authentication Status", RFC 7601, 504 DOI 10.17487/RFC7601, August 2015, 505 . 507 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 508 E., Ed., and K. Andersen, Ed., "Interoperability Issues 509 between Domain-based Message Authentication, Reporting, 510 and Conformance (DMARC) and Indirect Email Flows", 511 RFC 7960, DOI 10.17487/RFC7960, September 2016, 512 . 514 Appendix A. Examples 516 In the examples that follow, the first character of each wrapped line 517 of DKIM-Signature: fields should be a TAB. For editorial reasons, it 518 is rendered as four spaces. While visually there is little 519 difference, those signatures won't verify unless replacing them with 520 a TAB. 522 To verify the examples, public keys can be set as follows: 524 s._domainkey.example.com IN TXT ( "v=DKIM1; g=*; k=rsa; " 525 "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqlye7m5zLLXoIpBp2OO05LNMqK" 526 "u0zKowoHOpyRpviOVqOaNCk5uZ+wY00JwrKbt5u1G1ghuXsFkFkl0h00LBurz7ivyZH" 527 "3LohSWOZ8okgR+8kuGu9GHtQ+MqgRd16tlCF8PlWS2kGaBQKua1zk+ZCDwFy82Uo5G2" 528 "1nu/+Nn2sUwIDAQAB" ) 530 s._domainkey.lists.example IN TXT ( "v=DKIM1; k=rsa; " 531 "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgnLb2TZ6KECBMBo9ZLqDFt4ZBz" 532 "NHFrgBj/LVJVFU8IQP8uH4G8Pj0mEHRo1qpf0vuFI2HVpe/3NhzkT4Ay/1ZIIsxY754" 533 "f2thlhBvKh4AAgZFmzRvA3aZs6Tb/ERmD+a51liEMFaTOmY4mWeLi9wOM51usQ9Q65i" 534 "8IP/vjHM3rQIDAQAB" ) 536 A.1. Single-part plain text 538 Base64 encoding has to be decoded in order to locate the footer. The 539 original encoding was text/plain, this can be inferred by the 540 verifier from the absence of an Original-Content-Transfer-Encoding: 541 field. The original body hash will match after decoding and removing 542 the footer. Note that an "l=" tag couldn't have done the trick in 543 this case. 545 Received: from lists.example by subscriber.example.org with ESMTP 546 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s; 547 t=1603901305; bh=MjC5ikx26j8beyDJiz7Rk/4W+ppdGOmqh6koz0gLa8o=; 548 h=Date:From:To:Subject; 549 b=PNIYHGd7aytHEvew44WRpSfl4Py3c/9mKjovvQ1ps/xdpkl1/z+gWeu8e8ZmR7gdE 550 iT2TsJ7ni3Lfp5oUpGCko5MvCoqcKX7Zmq3CmXTxRTwwvVZrAp/ir8UTvG+rJFnyEZ 551 Yi3dSTX4rKe2LotyLkqcs+/uXaWEADbqcBp/9iHo= 552 Received: from mail.example.com by lists.example with ESMTP 553 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s; 554 t=1603889142; bh=hrDXocZNPy1+eUFYIk1PVRKa6mUMb8+ql9CFNABacww=; 555 h=Date:From:To:Subject; 556 b=YFLwvvW5bGbE5HpJwBM1JoL1F9b8AxdVFlwE/vOkL0p/pPpr7g9KnPXqwoEXZgFI0 557 /kkTHK/Afy4gaWZQfwDZ77LuxYSMFjwpNorSc0YEGzHYzLCN7rL1e+xE7B7kOCThiq 558 ebaMdcaHeZF6QUmWcUkEj8LVkxrvWi+bTzd3RnaA= 559 Original-From: Author 560 Received: from mua.example.com by mail.example.com with ESMTPA 561 Message-ID: <123456@author.example> 562 Date: Mon, 28 Oct 2020 13:12:55 +0100 563 From: Author 564 MIME-Version: 1.0 565 To: MLM@lists.example 566 Subject: [example] Check simple MLM message 567 Content-Type: text/plain; charset=us-ascii 568 Content-Transfer-Encoding: base64 570 VGhpcyBpcyBhIHBsYWluIHRleHQgbWVzc2FnZSBzdWJtaXR0ZWQgdG8gYSBtYWlsaW5nIGxpc3Qu 571 ClRoZSBtYWlsaW5nIGxpc3QgaXMgZXhwZWN0ZWQgdG8gYWRkIGEgZm9vdGVyIGFuZCBhIHN1Ympl 572 Y3QgdGFnLgoKQmVzdApBdXRob3IKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f 573 X19fX18KdGhpcyBtZXNzYWdlIHdhcyBtb2RpZmllZCBieSBNTE0gZXhhbXBsZQphZGRpbmcgdGhp 574 cyBmb290ZXIgYW5kIHRoZSBzdWJqZWN0IHRhZwoobm90ZSB0aGF0IGw9IGlzIG5vdCBzZXQpCg== 576 A.2. Multipart added 578 When the original message has a MIME structure, MLMs can append an 579 entity. 581 Received: from lists.example by subscriber.example.org with ESMTP 582 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s; 583 t=1603974193; bh=sEPYSlJlh90leqy5+63oPn1iU+9P684R92cZHXa9ENw=; 584 h=Date:From:To:Subject; 585 b=fTSAMcaEatofQCuAeUhlTXmVl5j9bPbwWgc84NWtoSt5zT+SSNp37DTzhYIGHozEk 586 bpldArGQ+GygJE1b2witi6NctBd1O/xsUwDcJQxDXkF63QlCcalbKWypHZOhRqncUQ 587 zgUzdcuYgqTYMJ0NoTP8fqu0HdgmjD2LJXjV3pVI= 588 Old-Authentication-Results: lists.example; 589 dkim=pass header.d=example.com 590 Received: from mail.example.com by lists.example with ESMTP 591 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s; 592 t=1603973996; bh=eWqyE53pjRVCFGyHY1zGQTkCEvucN1vNN4cTcWk90WU=; 593 h=Date:From:To:Subject; 594 b=LGP1M3IX6XORfLs8HRLCFOcymzsPn+8+ljgQlmeNlCC/2Cl1+aBDCIEnzWI0pceCb 595 zg32vFfEeryvRDHB1L1K4rrKCEznvO0J3p1xkUPEWpSpzxUGw+PK9KA9ePZ5qdz7cI 596 /hXf7zjebznNdDQJnxajf7QHnx1tXmxijsJ1jiGQ= 597 Old-Authentication-Results: example.com; auth=pass (details omitted) 598 Original-From: Author 599 Received: from mua.example.com by mail.example.com with ESMTPA 600 Message-ID: <123456@author.example> 601 Date: Mon, 28 Oct 2020 13:12:55 +0100 602 From: Author via MLM 603 MIME-Version: 1.0 604 To: MLM@lists.example 605 Subject: [example] Check simple MLM message 606 Content-Type: multipart/mixed; boundary=original-boundary 608 Original preamble must be preserved! 610 --original-boundary 611 Content-Type: text/plain; charset=us-ascii 612 Content-Transfer-Encoding: 7bit 614 This is a plain text message submitted to a mailing list. 615 The mailing list is expected to add a footer and a subject tag. 617 Best 618 Author 620 --original-boundary 621 Content-Type: image/png 622 Content-Transfer-Encoding: base64 624 iVBORw0KGgoAAAANSUhEUgAAAAYAAAAGCAYAAADgzO9IAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz 625 AAAHKgAAByoB49HU1wAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAB+SURB 626 VAiZNcGxDYUgAEXRhxTMYWLFVlDTOAUjOIEzWDqEC1igCQ0LSLi/+ueotUZKieu6uO+bdV2ptaLz 627 PDHGsG0b+74jieM40Pd91Fr5K6UAMC3LImutxhgaY8g5p3meNcUYFULQ+756nkchBMUYpd47OWe8 628 93jvyTnTe+cHXqRZbKSV4EoAAAAASUVORK5CYII= 630 --original-boundary 631 Content-Tyep: text/plain 633 ________________________________________ 634 this message was modified by MLM example 635 adding this footer and the subject tag 636 (note that l= cannot work in this case) 638 --original-boundary-- 640 A.3. Multipart wrapped 642 When the original body is multipart/alternative, MLMs have to wrap 643 the whole body into the first entity of a multipart/mixed structure. 644 Indeed, appending an entity to a multipart/alternative would result 645 in it either hiding or being hidden by the existing ones. 647 Received: from lists.example by subscriber.example.org with ESMTP 648 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s; 649 t=1603962061; bh=n4/RahgnfVg7htgJtCr7TwEW4eKA1O5oiNaQFA5HU+A=; 650 h=Date:From:To:Subject; 651 b=RJlq/Fu40AC1hdJfljd+KPU69Vq2M7capbGQyEMhDWvaN7xDPJdXotwnTwiz91iZY 652 5W3ITY7YXKHsWweLxu1Rph3ST3bbYQ1cifztpmtu4VPifBkm9MAe7OMDLHhk5ua9YL 653 VzJOsXieiIw5a8JhOsr6F/05/K05kNiEXvuLgKd8= 654 Old-Authentication-Results: lists.example; 655 dkim=pass header.d=example.com 656 Received: from mail.example.com by lists.example with ESMTP 657 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s; 658 t=1603961679; bh=XiCPbOV1vcu2Q2TyEUOuT4SMun2AjYj/Va6KRPa1lv0=; 659 h=Date:From:To:Subject; 660 b=gvM5grV2dbtinFMLcExv+gMATILzY+c8RY7QPVBJSFohH5HMgOLwrgSH8uwOcZxq0 661 FoXtBcHnukonqo97l8nY0faHi0Dp0LAmqn9e4ijwXw9IWwhFuUiCwICRaLEzrNUVBN 662 TWtzkQKnHpEXnPGBD7Q9f924mBe+eZsDyRc41ZvQ= 663 Old-Authentication-Results: example.com; auth=pass (details omitted) 664 Original-From: Author 665 Received: from mua.example.com by mail.example.com with ESMTPA 666 Message-ID: <123456@author.example> 667 Date: Mon, 28 Oct 2020 13:12:55 +0100 668 From: Author via MLM 669 MIME-Version: 1.0 670 To: MLM@lists.example 671 Subject: [example] Check simple MLM message 672 Content-Type: multipart/mixed; boundary=MLM-boundary 674 This is the MLM preamble, not signed by Author. 676 --MLM-boundary 677 Content-Type: multipart/alternative; boundary=original-boundary 679 Original preamble must be preserved! 681 --original-boundary 682 Content-Type: text/plain; 684 This is a plain text message submitted to a mailing list. 685 The mailing list is expected to add a footer and a subject tag. 687 Best 688 Author 690 --original-boundary 691 Content-Type: text/html; 693

This is a plain text message submitted to a mailing list. 694 The mailing list is expected to add a footer and a subject tag. 696

Best
697 Author
699 --original-boundary-- 701 Original epilogue 703 --MLM-boundary 704 Content-Type: text/plain 706 ________________________________________ 707 this message was modified by MLM example 708 adding this footer and the subject tag 709 (note that l= is not set) 711 --MLM-boundary-- 713 MLM epilogue 715 Author's Address 717 Alessandro Vesely 718 v. L. Anelli 13 719 20122 Milano MI 720 Italy 722 Email: vesely@tana.it