| Internet-Draft | MLM Transformations | May 2021 |
| Vesely | Expires 11 November 2021 | [Page] |
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to rewrite the From: header field as a workaround.¶
This document describes cases where it is possible to revert MLM transformations and hence verify DomainKeys Identified Mail (DKIM) signatures that were applied at submission time. For reliable results, some compliance is required of all agents involved, author domain signers, MLMs, forwarders, and final recipients.¶
MLM transformation reversion reduces the DMARC's effects on indirect mail flows.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 November 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Mailing List Managers (MLMs) can be configured to add a footer and a subject tag to the messages that they redistribute. Although that behavior slightly exceeds the very limited set of modifications and actions described by Section 3.9.2 of [RFC5321], it is a welcome, time-honored tradition. According to their configuration, the modifications they carry out on messages may result in a set of stylized transformations that are programmatically revertible. Reversion allows to verify DomainKeys Identified Mail (DKIM) signatures ([RFC6376]) that were applied before the transformation.¶
Domain-based Message Authentication, Reporting, and Conformance (DMARC) ([I-D.ietf-dmarc-dmarcbis]) hinges on the alignment of the domain in the From: header field with a verified DKIM signature. For that reason, MLMs that transform messages have to rewrite From:. A deed which can be mitigated in some cases.¶
Mailbox providers can configure their mail submission agents (MSAs) in order to ease MLM transformation reversion. Or they can make it impossible. It is their policy and their will. MLM operators make a similar decision. When they both agree on revertibility, a well equipped receiver can verify the original signatures. The outcome is twofold:¶
Signers and verifiers are defined in [RFC6376]. The use of the term Mailing List Manager, almost always abbreviated MLM follows [RFC6377]. A MLM is a kind of Mediator in [RFC5598] parlance.¶
Message is defined in [RFC5322]. It consists of a header made up of one or more fields and a body, possibly composed of various MIME entities, the latter being defined in [RFC2045] and companions.¶
The term original is used here to refer to the Author or parts of the Author's message as it was sent out by the Author's domain, where Author is defined in [RFC5598].¶
Message modifications can affect the header and/or the body of a message. This document only considers the very limited set of transformation described in the following subsections. They turn out to be revertible.¶
MLM often modify the Subject: field by inserting a tag at the beginning of its value. A tag consists of a short text delimited by square brackets. For example:¶
Subject: [added tag] Original value of subject¶
This transformation is easily reverted by removing the tag. For security reasons, subject tags must not exceed 20 characters.¶
Note that some MLM carry out further changes to this field. For example:¶
Subject: AW: [MLM-tag] German reply subject¶
can be transformed to:¶
Subject: Re: [MLM-tag] German reply subject¶
Therefore, if the field is signed, it is clever to save a copy of it as Original-Subject:.¶
A more recent modification carried out by MLMs is From: rewriting. It alters the value of From: in order to pass DMARC filters. MLMs save the original value of From: in a variety of places, including Reply-To:, Cc:, X-Original-From:. When the original value is known, the transformation is revertible.¶
Footer addition is often performed in one of three ways, according to the format of the original message.¶
The footer begins with a line consisting exclusively of underscore ("_", ASCII 95) characters, at least four of them. Alternatively, a footer can consist of the three characters "-- " (dash, dash, space), the Usenet signature convention (see for example Section 4.3 of [RFC3676]). For security reasons, the footer must belong to an entity of Content-Type: text/plain in all cases. In addition, footers cannot exceed 10 lines of text, each shorter than 80 characters.¶
The algorithm described here is implemented in a mail filter. It usually reads the input message twice -first pass, verify; last pass, write Authentication-Results and the rest of the message to follow. When enabling MLM transformation reversion, there can be a retry pass in between those two. The result is yielded during the SMTP dialogue with no noticeable delay. Implementing reversion changed the software from 22730 lines of C code to 26762. The bulk of such ~18% increase is due to the addition of encoding conversion functions. Changes involve both verifying and signing functions (see Section 5.1 for the latter).¶
While reading the header in the first pass, the verifier looks for specific fields:¶
These are candidates to the original mailbox.¶
The verifier also collects the Subject: and any field named Original-* that the original signer might have set to ease the reversion. At the end of the header, candidate original mailboxes are sorted according to the display name, which MLMs try and keep unaltered. The best candidate is then added to the collected set of Original-* fields. If the Subject: begins with a tag, its version without tag is added to that set as well, unless one is there already.¶
Next, before reading the body, the verifier looks for prospect signatures; that is, signatures whose "d=" domain is not aligned with SPF credentials ([RFC7208]), List-Post: ([RFC4201]), Sender:, or the rewritten From: (if deemed to have been rewritten). If any such signature exist, along with MLM or other signatures, then the verifier enables parsing the body to look for a footer.¶
Reversing verifiers also have to watch out for idiosyncrasies used to mask DKIM signatures. For example, a MLM introduced a header field named X-Mailman-Original-DKIM-Signature, because some receivers took the habit to downgrade messages with failed signatures, despite [RFC6376] recommendation to consider an unauthenticated message regardless of whether or not it looks like it was signed. For authentication purposes, the first 19 characters of that field can be discarded.¶
Body parsing is done in parallel with body canonicalization during the first pass. For multipart, track top level entities. Set transformation type to "wrapped" if there are exactly two entities, "added" otherwise. For single-part, body parsing must avail of encoding conversions as needed. Assume identity encoding, 7bit or 8bit, unless otherwise directed by an Original-Content-Transfer-Encoding: field.¶
At the end of the first pass, the verifier knows how prospect signatures did. Let's recall that DKIM signature verification results from two independent operations, steps 3 and 4 in Section 6.1.3 of [RFC6376]. The signature in the "b=" tag depends on the header, while the body hash in the "bh=" tag depends on the body:¶
None, one, or both of the above operations are performed in the retry pass.¶
On writing Authentication-Results, if a prospect signature verifies after replacing the From: field, the verifier writes a prominent, well documented "reason" in the relevant resinfo stanza (Section 2.2 of [RFC7601]). That way, reversion elements can be easily recognized and parsed by downstream agents.¶
Signers who wish their users to be able to participate to mailing lists can adopt rules apt to ease MLM transformations reversion. Doing so can slightly weaken DKIM'S stiffness, and expose to the risk of malicious MLMs. A sender that doesn't know which of its mail recipients are likely to be MLMs might abide by the following rules for all outgoing mail, in the expectation that few of its users correspondents are likely to be malicious. A sender that had some idea which recipients are MLMs could apply the rules only to mail to those recipients. Or a sender might apply the rules to all mail except that sent to recipients with poor reputations.¶
A special rule is the addition of an Original-From: header field with a value identical to the one signed in From:. Original-From: is defined by [RFC5703] in the context of Sieve Email Filtering. As Sieve operates at time of final delivery, DKIM verifiers which act at the time of message transit can reliably use it.¶
Original-From: is special because verifiers may infer that the field was added by the original signer rather than by MLMs. In that case, they can send DMARC feedback reports to the original signer even if From: was rewritten.¶
Note that [RFC7960] suggests that ReSenders can add an Original-From: too, although it is not being used consistently. If this is a conflict, the field name has to be changed before publishing this document.¶
Other generic rules to ease reversion are as follows:¶
Original-Content-Transfer-Encoding: base64¶
Participating MLMs must not operate transformations other than those listed in Section 3. Since DKIM is MIME-agnostic, attention must be paid to preserve the exact preamble and epilogue of the original MIME structure.¶
MLMs must apply their own DKIM signature. The presence of signatures by multiple domains can be used by verifiers to infer that a message underwent MLM transformations.¶
MLMs must not set the Original-From: field, which is reserved to original signers. It is recommended that MLMs add a mailbox entry to Reply-To: or Cc: in order to ease off-list replies as well as to allow transformation reversion, but only in case the Original-From: is missing.¶
MLMs may set Original-* fields other than Original-From:, but only if the original message contains no Original-* field at all. That is, when the author's domain is not aware of the possibility to ease MLM transformation reversion.¶
MLMs which collect posts from other MLMs must avoid to add their own footer and subject tag. Transformation reversion cannot be stacked. A second-level MLM can modify or replace the content of previous transformations. Attention must be paid to not exceed tag and footer length limits.¶
Attempts to verify original signatures can be done as outlined in Section 4. The reversion must not replace the messages signed and distributed by MLMs, with one exception detailed in the next paragraph. Only the result of the verification is written out.¶
If an original signature with rewritten From: is recovered, the verifier must make sure that an Original-From: field with the verified mailbox is written out. An MDA downstream may combine the Authentication-Results: and Original-From: fields to restore the original value of From:. This is the only recommended modification to the distributed message. It must be done after any dot-forward processing, so that external verifiers receive the message as distributed by the MLM, and can revert transformations by themselves.¶
If the Original-From: is set, the corresponding DMARC record may be looked up and its "rua=" and "ruf=" tags considered for feedback reports. If DMARC policies are considered, it is the the From: field which rules, not the Original-From: nor any other mailbox value, unless verified.¶
Rewriting the From: header field is an unwelcome modification to messages. It fosters the belief that the display name of a mailbox is more trustworthy than the angle address. A belief further consented by the tendency to not even display the latter. Bad actors take advantage of this belief by displaying the names of trusted institution paired with trash email addresses hidden between angle brackets. That trick defeats DMARC's purpose.¶
It is out of this document's scope to suggest how mail user agents (MUAs) could counter phishing by highlighting security indicators (for the extent that indicators can actually help preventing phishing attacks). Let's just note that MUAs have to cope with MLM and phishing alike, which makes it hard to devise a pattern to tell apart one from the other without getting involved with the reputation of the specific domains.¶
By safely restoring munged From: to the original value, that contrast is eliminated. Then, perhaps, deceptive mailboxes might become amenable to some kind of efficient indication.¶
Of course, MLM role can be played by miscreants as well. However, replaying a signed message, even with revertible transformations, has more limits than forging scam messages anew. Therefore, the risk introduced by easing transformation reversion is considerably lower than that of not signing, or of keeping DMARC policy at "none".¶
Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the fact that footers are written in plain text removes the main security objection about footer additions. Namely, footers cannot completely replace the original content in the end recipient's eyes by exploiting lax HTML parsing in the MUA.¶
Still, a footer can contain dangerous URLs and deceiving text. That possibility has to be countered by usual mail filtering and savvy behavior.¶
IANA maintains the "Message Header" registry with several subregistries. IANA is asked to make the assignments set out in the following section.¶
IANA is asked to create new entries in the "Permanent Message Header Field Names" registry as follows.¶
| Header Field Name | Template | Protocol | Status | Reference |
|---|---|---|---|---|
| Original-Content-Transfer-Encoding | standard | this I-D | ||
| Original-Reply-To | standard | this I-D | ||
| Original-Cc | standard | this I-D |
In the examples that follow, the first character of each wrapped line of DKIM-Signature: fields should be a TAB. For editorial reasons, it is rendered as four spaces. While visually there is little difference, those signatures won't verify unless replacing them with a TAB.¶
To verify the examples, public keys can be set as follows:¶
s._domainkey.example.com IN TXT ( "v=DKIM1; g=*; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqlye7m5zLLXoIpBp2OO05LNMqK" "u0zKowoHOpyRpviOVqOaNCk5uZ+wY00JwrKbt5u1G1ghuXsFkFkl0h00LBurz7ivyZH" "3LohSWOZ8okgR+8kuGu9GHtQ+MqgRd16tlCF8PlWS2kGaBQKua1zk+ZCDwFy82Uo5G2" "1nu/+Nn2sUwIDAQAB" ) s._domainkey.lists.example IN TXT ( "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgnLb2TZ6KECBMBo9ZLqDFt4ZBz" "NHFrgBj/LVJVFU8IQP8uH4G8Pj0mEHRo1qpf0vuFI2HVpe/3NhzkT4Ay/1ZIIsxY754" "f2thlhBvKh4AAgZFmzRvA3aZs6Tb/ERmD+a51liEMFaTOmY4mWeLi9wOM51usQ9Q65i" "8IP/vjHM3rQIDAQAB" )¶
Base64 encoding has to be decoded in order to locate the footer. The original encoding was text/plain, this can be inferred by the verifier from the absence of an Original-Content-Transfer-Encoding: field. The original body hash will match after decoding and removing the footer. Note that an "l=" tag couldn't have done the trick in this case.¶
Received: from lists.example by subscriber.example.org with ESMTP
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s;
t=1603901305; bh=MjC5ikx26j8beyDJiz7Rk/4W+ppdGOmqh6koz0gLa8o=;
h=Date:From:To:Subject;
b=PNIYHGd7aytHEvew44WRpSfl4Py3c/9mKjovvQ1ps/xdpkl1/z+gWeu8e8ZmR7gdE
iT2TsJ7ni3Lfp5oUpGCko5MvCoqcKX7Zmq3CmXTxRTwwvVZrAp/ir8UTvG+rJFnyEZ
Yi3dSTX4rKe2LotyLkqcs+/uXaWEADbqcBp/9iHo=
Received: from mail.example.com by lists.example with ESMTP
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s;
t=1603889142; bh=hrDXocZNPy1+eUFYIk1PVRKa6mUMb8+ql9CFNABacww=;
h=Date:From:To:Subject;
b=YFLwvvW5bGbE5HpJwBM1JoL1F9b8AxdVFlwE/vOkL0p/pPpr7g9KnPXqwoEXZgFI0
/kkTHK/Afy4gaWZQfwDZ77LuxYSMFjwpNorSc0YEGzHYzLCN7rL1e+xE7B7kOCThiq
ebaMdcaHeZF6QUmWcUkEj8LVkxrvWi+bTzd3RnaA=
Original-From: Author <user@example.com>
Received: from mua.example.com by mail.example.com with ESMTPA
Message-ID: <123456@author.example>
Date: Mon, 28 Oct 2020 13:12:55 +0100
From: Author <user@example.com>
MIME-Version: 1.0
To: MLM@lists.example
Subject: [example] Check simple MLM message
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: base64
VGhpcyBpcyBhIHBsYWluIHRleHQgbWVzc2FnZSBzdWJtaXR0ZWQgdG8gYSBtYWlsaW5nIGxpc3Qu
ClRoZSBtYWlsaW5nIGxpc3QgaXMgZXhwZWN0ZWQgdG8gYWRkIGEgZm9vdGVyIGFuZCBhIHN1Ympl
Y3QgdGFnLgoKQmVzdApBdXRob3IKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KdGhpcyBtZXNzYWdlIHdhcyBtb2RpZmllZCBieSBNTE0gZXhhbXBsZQphZGRpbmcgdGhp
cyBmb290ZXIgYW5kIHRoZSBzdWJqZWN0IHRhZwoobm90ZSB0aGF0IGw9IGlzIG5vdCBzZXQpCg==
¶
When the original message has a MIME structure, MLMs can append an entity.¶
Received: from lists.example by subscriber.example.org with ESMTP
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s;
t=1603974193; bh=sEPYSlJlh90leqy5+63oPn1iU+9P684R92cZHXa9ENw=;
h=Date:From:To:Subject;
b=fTSAMcaEatofQCuAeUhlTXmVl5j9bPbwWgc84NWtoSt5zT+SSNp37DTzhYIGHozEk
bpldArGQ+GygJE1b2witi6NctBd1O/xsUwDcJQxDXkF63QlCcalbKWypHZOhRqncUQ
zgUzdcuYgqTYMJ0NoTP8fqu0HdgmjD2LJXjV3pVI=
Old-Authentication-Results: lists.example;
dkim=pass header.d=example.com
Received: from mail.example.com by lists.example with ESMTP
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s;
t=1603973996; bh=eWqyE53pjRVCFGyHY1zGQTkCEvucN1vNN4cTcWk90WU=;
h=Date:From:To:Subject;
b=LGP1M3IX6XORfLs8HRLCFOcymzsPn+8+ljgQlmeNlCC/2Cl1+aBDCIEnzWI0pceCb
zg32vFfEeryvRDHB1L1K4rrKCEznvO0J3p1xkUPEWpSpzxUGw+PK9KA9ePZ5qdz7cI
/hXf7zjebznNdDQJnxajf7QHnx1tXmxijsJ1jiGQ=
Old-Authentication-Results: example.com; auth=pass (details omitted)
Original-From: Author <user@example.com>
Received: from mua.example.com by mail.example.com with ESMTPA
Message-ID: <123456@author.example>
Date: Mon, 28 Oct 2020 13:12:55 +0100
From: Author via MLM <MLM@lists.example>
MIME-Version: 1.0
To: MLM@lists.example
Subject: [example] Check simple MLM message
Content-Type: multipart/mixed; boundary=original-boundary
Original preamble must be preserved!
--original-boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is a plain text message submitted to a mailing list.
The mailing list is expected to add a footer and a subject tag.
Best
Author
--original-boundary
Content-Type: image/png
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAAAYAAAAGCAYAAADgzO9IAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz
AAAHKgAAByoB49HU1wAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAB+SURB
VAiZNcGxDYUgAEXRhxTMYWLFVlDTOAUjOIEzWDqEC1igCQ0LSLi/+ueotUZKieu6uO+bdV2ptaLz
PDHGsG0b+74jieM40Pd91Fr5K6UAMC3LImutxhgaY8g5p3meNcUYFULQ+756nkchBMUYpd47OWe8
93jvyTnTe+cHXqRZbKSV4EoAAAAASUVORK5CYII=
--original-boundary
Content-Tyep: text/plain
________________________________________
this message was modified by MLM example
adding this footer and the subject tag
(note that l= cannot work in this case)
--original-boundary--
¶
When the original body is multipart/alternative, MLMs have to wrap the whole body into the first entity of a multipart/mixed structure. Indeed, appending an entity to a multipart/alternative would result in it either hiding or being hidden by the existing ones.¶
Received: from lists.example by subscriber.example.org with ESMTP
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s;
t=1603962061; bh=n4/RahgnfVg7htgJtCr7TwEW4eKA1O5oiNaQFA5HU+A=;
h=Date:From:To:Subject;
b=RJlq/Fu40AC1hdJfljd+KPU69Vq2M7capbGQyEMhDWvaN7xDPJdXotwnTwiz91iZY
5W3ITY7YXKHsWweLxu1Rph3ST3bbYQ1cifztpmtu4VPifBkm9MAe7OMDLHhk5ua9YL
VzJOsXieiIw5a8JhOsr6F/05/K05kNiEXvuLgKd8=
Old-Authentication-Results: lists.example;
dkim=pass header.d=example.com
Received: from mail.example.com by lists.example with ESMTP
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s;
t=1603961679; bh=XiCPbOV1vcu2Q2TyEUOuT4SMun2AjYj/Va6KRPa1lv0=;
h=Date:From:To:Subject;
b=gvM5grV2dbtinFMLcExv+gMATILzY+c8RY7QPVBJSFohH5HMgOLwrgSH8uwOcZxq0
FoXtBcHnukonqo97l8nY0faHi0Dp0LAmqn9e4ijwXw9IWwhFuUiCwICRaLEzrNUVBN
TWtzkQKnHpEXnPGBD7Q9f924mBe+eZsDyRc41ZvQ=
Old-Authentication-Results: example.com; auth=pass (details omitted)
Original-From: Author <user@example.com>
Received: from mua.example.com by mail.example.com with ESMTPA
Message-ID: <123456@author.example>
Date: Mon, 28 Oct 2020 13:12:55 +0100
From: Author via MLM <MLM@lists.example>
MIME-Version: 1.0
To: MLM@lists.example
Subject: [example] Check simple MLM message
Content-Type: multipart/mixed; boundary=MLM-boundary
This is the MLM preamble, not signed by Author.
--MLM-boundary
Content-Type: multipart/alternative; boundary=original-boundary
Original preamble must be preserved!
--original-boundary
Content-Type: text/plain;
This is a plain text message submitted to a mailing list.
The mailing list is expected to add a footer and a subject tag.
Best
Author
--original-boundary
Content-Type: text/html;
<p>This is a plain text message submitted to a mailing list.
The mailing list is expected to add a footer and a subject tag.
<p>Best<br>
Author<br>
--original-boundary--
Original epilogue
--MLM-boundary
Content-Type: text/plain
________________________________________
this message was modified by MLM example
adding this footer and the subject tag
(note that l= is not set)
--MLM-boundary--
MLM epilogue
¶