Internet DRAFT - draft-chuang-mailing-list-modifications
draft-chuang-mailing-list-modifications
Independent Stream W. Chuang
Internet-Draft Google, Inc.
Intended status: Experimental 20 February 2024
Expires: 23 August 2024
Tolerating Mailing-List Modifications
draft-chuang-mailing-list-modifications-04
Abstract
Mailing-lists distribute email to multiple recipients by forwarding
and potentially modifying messages to document the distribution to
the recipients. Unfortunately forwarding breaks SPF (RFC7208)
authentication and message modification breaks DKIM (RFC6376)
authentication. This document is based on ARC (RFC8617) to provide a
framework to describe forwarding with extensions to tolerate common
mailing-list message modifications. This specification characterizes
the mailing-list transforms such that a receiver can reverse them to
enable digital signatures verification and attribution of the message
content. These message modifications are: 1) adding a description
string to the Subject header, 2) rewriting the From header, 3)
removing the original DKIM-Signature and 4) appending a footer to the
message body. This also specifies those modifications for the
purpose of making them reversible.
Status of This Memo
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 23 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chuang Expires 23 August 2024 [Page 1]
Internet-Draft Mailing-List Modifications February 2024
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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. *Terminology and Definitions* . . . . . . . . . . . . . . 4
1.2. *Algorithm* . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Forwarder Characterization . . . . . . . . . . . . . 4
1.2.2. Header Rewriting Characterization . . . . . . . . . . 5
1.2.3. Message Footer Characterization . . . . . . . . . . . 6
1.2.4. Validation . . . . . . . . . . . . . . . . . . . . . 8
1.3. Mailing-List Modifications . . . . . . . . . . . . . . . 9
1.3.1. Subject Header Modification . . . . . . . . . . . . . 9
1.3.2. Body Modification . . . . . . . . . . . . . . . . . . 10
1.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1. Originator ⇒ First Mailing-List ⇒ Second Mailing-List
⇒Receiver . . . . . . . . . . . . . . . . . . . . . . 14
1.5. Security Considerations . . . . . . . . . . . . . . . . . 17
1.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 17
2. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Mailing-lists have long complicated email authentication. They break
SPF [RFC7208] authentication due to forwarding and break DKIM
[RFC6376] authentication due to message modification that used to
identify the mailing-list. This specification provides methods to
restore authentication even in the presence of forwarding and message
modification. Being able to restore authentication is particularly
important as senders may specify a sender-defined receiver email
handling policy that may prevent delivery of the message as defined
in DMARC [RFC7489]. Moreover malicious content is currently
attributed to all parties in the mail flow. This specification
permits a receiver to attribute the email content to its author be it
the sender or the mailing-list.
The approach in this document is to be highly opinionated about only
supporting common case mutations to lessen the implementation burden
upon mailing-lists and receivers. This also seeks to eliminate any
burden for messages that don't go through mailing-lists. At
Chuang Expires 23 August 2024 [Page 2]
Internet-Draft Mailing-List Modifications February 2024
origination, it is sufficient to sign a message with a DKIM signature
as typically done already. It does ask those mailing-lists that wish
to use this specification to characterize the modifications it
performs at each forwarding step. The goal is to permit receivers to
reverse the modification so that the message hash can be recovered
and the prior signature verified at each forwarding step, be it from
DKIM or ARC. This allows the receiver to determine which forwarder
or the originating sender contributed which content, in the received
message. This specification uses the ARC [RFC8617] framework to
describe each forwarder, and then record the mutation performed at
each forwarding step. Consequently this attribution enables more
precise reputation systems and UI features. The supported
modifications are: 1) adding a description string to the Subject
header, 2) rewriting the "From" header, 3) rewriting the original
DKIM-Signature and 4) appending a footer to the message body. This
document specifies the characterization of the modifications and how
to apply the modifications.
The validation results in this specification are orthogonal to the
results in
draft-chuang-replay-resistant-arc (https://datatracker.ietf.org/doc/
draft-chuang-replay-resistant-arc/). In addition to better
supporting DMARC in the presence of mailing-list modifications, this
specification enables attribution of malicious content back to the
author. However this specification is vulnerable to replay much like
DKIM and ARC. draft-chuang-replay-resistant-arc
(https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/)
validation is tolerant of header and message body modifications but
unable to provide attribution. It also detects and prevents replay.
A receiver may want to combine the results of these two validations
to create a strong authentication result that provides greater
certainty that a message was sent by some originating sender through
a mailing-list.
This specification assumes that originators and forwarders are named
by the methods specified in the internet-draft draft-chuang-
identifying-email-forwarding (https://datatracker.ietf.org/doc/draft-
chuang-identifying-email-forwarding/). That specification calls for
a naming method of participants in the mail flow using a mail flow
tag. That also names the ADMDs by the signer domain as defined in
the DKIM-Signature "d=" SDID domains, and the ARC-Seal and ARC-
Message-Signature "d=" SDID domains.
Chuang Expires 23 August 2024 [Page 3]
Internet-Draft Mailing-List Modifications February 2024
1.1. *Terminology and Definitions*
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. *Algorithm*
The specification in this document is divided into procedures
computed at the mailing-list forwarders and at the receiver and is
based on the procedures in ARC [RFC8617]. The steps at the forwarder
are further divided at the forwarder into the inbound validation
procedures and outbound forwarding procedures. The receiver only
performs the inbound validation procedures. The inbound validation
procedures are variable length corresponding to the depth of the ARC
sets. At each ARC set corresponding to some earlier forwarder, the
receiver computes any reversing procedure described later for any
described mailing-list mutations to obtain the message hash of the
message as seen at the inbound of the mailing-list. This hash comes
from an ARC-Message-Signature if the sender is a forwarder and a
DKIM-Signature (or possibly ARC-message-signature) if the sender is
the originator. That signature MUST verify correctly, otherwise this
is considered a signature verification failure by this specification.
Interpretation of that failure is described later.
1.2.1. Forwarder Characterization
Conformant forwarders characterize message mutations to enable
receivers to interpret mutations and potentially verification
failures. A description is added as a tag-value to the ARC-Message-
Signature mail flow description tag "m" as defined in the internet-
draft draft-chuang-identifying-email-forwarding
(https://datatracker.ietf.org/doc/draft-chuang-identifying-email-
forwarding/). The following mail flow values are considered
mutators:
mailing_list: Describes a forwarder that distributes messages to
multiple recipients and any modification conforms to the
specification in this document.
ofs: Outbound-Filtering-Service is a mutating forwarder that works
on behalf of the originating sender. The sender is presumed to
have delegated responsibility to sign on behalf of the originating
sender.
ifs: Inbound-Filtering-Service mutating forwarder that works on
Chuang Expires 23 August 2024 [Page 4]
Internet-Draft Mailing-List Modifications February 2024
behalf of the final receiver. The receiver is presumed to have an
established trust model with the gateway outside of this document
and, and validation failure result is interpreted by the receiver.
Receivers MAY use the ARC-Message-Signature d= SDID domain to
identify trusted forwarders. Receivers SHOULD NOT use the mail flow
tag-value description to detect the existence of such trust
relationships, as those descriptions exist for human operators to
interpret gateway's actions.
1.2.2. Header Rewriting Characterization
A mailing-list forwarder that rewrites a Subject, From or DKIM-
Signature headers can store the prior values by substituting with a
modified header name i.e. prefixing "X-Prior-" to the original name.
Moreover the header name retains the original capitalization, its
place with respect to other headers, and is not ambiguous if there
are multiple headers of the same name. First the bottoms-up line
count of all headers is computed starting from the 0th position.
Then all headers to be rewritten are collected, ordered by position
to be prepended to the headers list and given a bottoms-up line count
position. This is an offset from "X-Prior-" header to it's rewritten
counterpart. It is assumed that the prior header has the following
format:
<header name>:<value including any whitespaces>
The conserved header name is prefixed with a "X-Prior-". Then an ARC
instance number tag "i" i.e. "=<#>," and line count tag "l" i.e.
"l=<bottoms-up line count offset>" are prepended to the header value
and separated by a semicolon and one whitespace. The position of
this "i" and "l" is important because they may otherwise be ambiguous
with the original header's tag-values e.g DKIM-Signature. Thus the
conserved header is:
X-Prior-<header name>: i=<#>; l=<bottoms-up line count offset>;
<value including any whitespaces>
For example:
X-Prior-Dkim-Signature: i=1; l=4; d=example.com; b=...
X-Prior-Subject: i=1; l=3; Meeting on the 5th
This stores the prior header in a format that SHOULD be ignored by
subsequent forwarders, and if not then will cause a verification
failure. The forwarder then rewrites or deletes the header as before
by prepending the rewritten header to the message or skipping
prepending for deletion. To protect the integrity of these headers,
Chuang Expires 23 August 2024 [Page 5]
Internet-Draft Mailing-List Modifications February 2024
these headers are hashed separately from ARC-Message-Signature "h"
header list. The forwarder generates the header hash by hashing the
"X-Prior-" headers (and any "Content-Footer" header described below)
found in bottoms up order as found in the headers. This
specification calls for the header hash to be explicitly added to the
ARC-Message-Signature with a tag "fh" as defined in the internet-
draft draft-chuang-replay-resistant-arc
(https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-
arc/). Conformant forwarders even without mailing-lists mutations
MUST report header hash explicitly to better differentiate and
tolerate body modifications when verifying headers.
To reverse the rewriting or deletion of headers, all "X-Prior-"
headers are collected at the given ARC instance number. The prior
header name is extracted from the "X-Prior-" header, and the original
value extracted and restored. The rewritten header is found by
taking the "X-Prior-" header line count position and adding the
offset in the "l" tag's value. Rewritten headers are deleted in top
down order.
1.2.3. Message Footer Characterization
Mailing-lists may choose to add a message footer to the body of the
message to notify the recipient of the mailing-list distribution
action and conformant mailing-list will describe this mutation to the
receiver. One method is to append the footer text to all content-
type text in the top level of MIME [RFC2045] part "multipart/
alternative". Another method is to append a new successor MIME part
for a "multipart/mixed" part, and that MIME part contains the footer
as a content-type text. If the message is not mime formatted, the
entire body is treated as text and the mailing-list may append a text
footer at the bottom of the message.
Chuang Expires 23 August 2024 [Page 6]
Internet-Draft Mailing-List Modifications February 2024
Conformant mailing-list forwarders characterize these changes with a
new "Content-Footer" header. It contains a list of semicolon and
whitespace separated tag-values using the formatting specifications
in DKIM. The first of these is an ARC set instance number describing
which forwarder added the header. When the mailing-list appends a
text part, the receiver characterizes it with the beginning and
ending byte offset of the MIME part or message-body if MIME
unformatted. If the mailing-list adds a text MIME part as footer, it
describes the mime part with its purpose tag-value. The Content-
Footer header is added to the MIME part for MIME formatted messages,
and to the message headers for unformatted messages. To protect the
integrity of the header, in the latter case, the Content-Footer is
hashed along with "X-Prior-" headers in the same bottoms up order.
In the former case, Content-Footer headers added to the message-body
are protected by the message body hash. The following are the
Content-Footer header tag-values:
i Instance tag. Must be the first tag-value. The value contains
the instance number
b Footer beginning octet offset from the start of the text MIME part
or the message-body if no MIME unformatted. MUST always appear
with a footer ending offset.
e Footer ending octet offset from the start of the text MIME part or
the message-body if no mime unformatted. MUST always appear with
a footer beginning offset.
m Mime-part purpose description. If the added MIME part contains
the text footer, then the value is "footer". If the added MIME
part is "multipart/mixed" and meant to support adding the text
footer, then the value is "mixed". If the text footer is
appended, then this tag-value is not added.
For example:
Content-Footer: i=1; b=100; e=200
Content-Footer: i=2; m=footer
Chuang Expires 23 August 2024 [Page 7]
Internet-Draft Mailing-List Modifications February 2024
To reverse the footer addition, the receiver looks at the headers to
see if the message is MIME formatted. If not, the receiver looks for
a "Content-Footer" in the headers. If so, the receiver looks for
"Content-Footer" in the MIME tree content headers. For each
"Content-Footer" found header at the current ARC set instance, it
reverses the footer mutation. For offset values designated by
beginning and ending offset tags, it removes the text from that MIME
part or the message-body designated. For a MIME part text footer, it
deletes it along with any supporting "multipart/mixed" MIME part.
Then the receiver deletes the Content-Footer header from the updated
message if not done so already.
1.2.4. Validation
The receiver verifies prior ARC sets per the procedure described in
ARC [RFC8617]. In addition, the receiver validates the ARC sets
starting from the largest instance number found to the smallest.
First the receiver verifies the given instance ARC-Message-Signature
or DKIM-Signature as appropriate. Then the receiver computes the
rewritten header hash taking the header hash computed by ARC-Message-
Signature at the given instance number or DKIM-Signature. Then the
hash is taken for "X-Prior-" headers and "Content-Footer" header if
found in the headers at the current ARC set instance number and all
prior ones. This is verified against the header hash value
associated with the tag "fh", reporting signature failure if it
mismatches.
Next the receiver determines whether it needs to reverse any header
or footer mutations at that ARC set instance by looking for the ARC-
Message-Signature mutation tag "m=". For values of "mailinglist", it
attempts to reverse mutations keeping the resulting message so that
further validations are possible. The receiver attempts to provide
header reversing procedures given in "Header Rewriting" section and
body reversing procedures given in "Message Footer" section. For
values "gateway" the receiver MAY apply local policy to interpret
subsequent validation failures. For all other mutation tag "m"
values, it assumes no mutations are present or outside the scope of
mailing-list modifications.
In addition, the originating sender's DKIM-signature or ARC-Message-
Signature MUST successfully verify. If so and all prior signatures
verify, then the result is a "pass". Verification failures are
subject to interpretation in "Footer Characterization" section, and
potentially indicate a "fail". The result of this procedure is
written in Authentication-Result [RFC8601] and ARC-Authentication-
Result with a method named "reverse" as the REVERSE result.
Chuang Expires 23 August 2024 [Page 8]
Internet-Draft Mailing-List Modifications February 2024
Informationally, if the receiver implements draft-chuang-replay-
resistant-arc (https://datatracker.ietf.org/doc/draft-chuang-replay-
resistant-arc/), this specification suggests modifying draft-chuang-
replay-resistant-arc (https://datatracker.ietf.org/doc/draft-chuang-
replay-resistant-arc/) PATH results to take into account the REVERSE
result. At each ARC set instance where PATH recursively combines the
local DARA results, if REVERSE reports "fail" then the PATH result
reports "fail". Because _REVERSE _combined with_ _DARA_ _represents
a higher bar of verification than DARA alone, the receiver applies
local policy when interpreting the PATH result.
1.3. Mailing-List Modifications
When a message body or Subject header is modified by a forwarder, the
sender's DKIM signature will no longer validate. To mitigate this
forwarders MAY elect to replace the DKIM signature with their own
with a new message hash that takes into account the modifications.
Because the signature is not DMARC aligned, senders also MAY rewrite
the From header to take ownership of the message. The following
creates a specification making the message body or Subject header
modification, replacing the DKIM signature and applying
characterization headers.
1.3.1. Subject Header Modification
The mailing-list may want to communicate to the recipient that a
message went through a mailing-list by modifying the Subject header
to append the name of the mailing-list. Typically the name is put
between brackets e.g. "[name]" and prepended to the Subject header
content. This specification supports arbitrary text changes by
saving the earlier inbound version of the Subject header's content in
the "X-Prior-Subject" header. The change in Subject text will break
the DKIM-Signature so mailing-lists MAY rewrite DKIM-Signature to
update the message header hash and resign the signature. Similarly
they MAY update the From header to DMARC align the DKIM-Signature
"d=" domain with the From header domain. Typically the From address
is the set to the mailing-list address to further identify the
mailing-list. This specification supports saving the earlier inbound
version of the DKIM-Signature and From headers in the "X-Prior-DKIM-
Signature" and "X-Prior-From" headers respectively.
For example the original message looks like:
Dkim-Signature: d=example.com; b=...
From: john.doe@example.com
Subject: Meeting on the 5th
Chuang Expires 23 August 2024 [Page 9]
Internet-Draft Mailing-List Modifications February 2024
A mailing-list rewrite Subject, From and DKIM-Signature headers and
saves the original content in the "X-Prior-" headers
Dkim-Signature: d=mailinglist.example.com; b=...
From: mailinglist@mailinglist.example.com
Subject: [mailing-list] Meeting on the 5th
X-Prior-Dkim-Signature: i=1; l=3; d=example.com; b=...
X-Prior-From: i=1; l=3; john.doe@example.com
X-Prior-Subject: i=1; l=3; Meeting on the 5th
1.3.2. Body Modification
The mailing-list may want to communicate to the recipient that a
message went through a mailing-list by adding a text footer
describing the mailing-list. Typically this is done by appending
that text description at the bottom of message body text. This
specification supports three different footer organizations,
depending on the MIME structure, content type and content transport
encoding of the MIME parts of the message. In particular the
organization depends if its MIME parts can be concatenated, meaning
whether a text footer can be appended and removed without having to
re-encode the original content to preserve the original content. For
example appending new content to "base64", and "binary" will likely
introduce artifacts between the original message and the
interpretation footer. MIME parts that can be concatenated are
defined as having one of the following type and subtype of Content-
type:
* text/plain
* text/html
and one of the following mechanisms for Content-transfer-encoding:
* 7bit
* 8bit
* quoted-printable
Similarly, non-text MIME parts, and complex multipart MIME parts
don't lend themselves to appending text. One exception to this is
"multipart/alternative" as will be described shortly. To handle
these scenarios, this specification calls for adding a new text MIME
part footer that can handle any encoding or any mime structure but
requires altering the MIME tree.
Chuang Expires 23 August 2024 [Page 10]
Internet-Draft Mailing-List Modifications February 2024
The following procedure describes how the mailing-lists MAY choose
from one of those formats to add a footer. Here a mailing-list
should evaluate in the same order as these three sections, following
the steps in each section. If any footer addition is successful,
then the footer algorithm stops.
1.3.2.1. Unstructured or Text Message Body
The simplest structure applies when the message lacks [RFC2045] MIME
structure or the top level MIME part can be concatenated. Here the
forwarder appends a text footer with the same content type and
content transfer encoding as the message-body. When a message lacks
MIME struct, the default message content-type is "text/plain"
(section 5.2) and default content transfer encoding is "7bit"
(section 6.1). Next a "Content-Footer" header is prepended
describing the start and ending message body octet offsets.
Reversing this transform is a straightforward deletion of the footer
at the offsets given.
For example given an original message of:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: john.doe@example.com
This is the message body.
A text footer can be appended as follows:
Content-Footer: i=1; b=25; e=67
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: john.doe@example.com
This is the message body.
============
This is a mailing-list footer.
1.3.2.2. Multipart/Alternative
When the top level MIME part is Content-type "multipart/alternative",
the forwarder checks if any of the immediate children MIME parts can
be concatenated. If so, it attempts to append a text footer with the
same content type and content transfer encoding as the children MIME
part. Next it prepends a Content-Footer header in the child MIME
part header description with the start and end octet offsets from the
beginning of the part. If a footer can be added to a child MIME
Chuang Expires 23 August 2024 [Page 11]
Internet-Draft Mailing-List Modifications February 2024
part, then this is considered success and the algorithm can halt.
The reversing algorithm is to look for the top level MIME part with
Content-type "multipart/alternative". If so then look in the
immediate child MIME parts and delete the text at the offsets given
by the Content-Footer.
For example given an original message of:
Content-Type: multipart/alternative; boundary="abcd"
From: john.doe@example.com
--abcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This is the message body.
--abcd--
A text footer can be appended as follows:
Content-Type: multipart/alternative; boundary="abcd"
From: john.doe@example.com
--abcd
Content-Footer: i=1; b=25; e=67
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This is the message body.
============
This is a mailing-list footer.
--abcd--
1.3.2.3. MIME Part Footer
The following procedure adds a MIME "multipart/mixed" at the top
level and has as its children the original top level MIME part as the
first child and the footer MIME text part as the second child. This
procedure will always succeed no matter the MIME structure or MIME
content transfer encoding, however this modifies the MIME tree. The
top level MIME "multipart/mixed" is denoted by adding a "Content-
Footer" header purpose description with "mixed" value and the footer
MIME part denoted by adding a "Content-Footer" header purpose of
"footer" value. To reverse the mutation, the original top-level mime
part is moved back to the actual top-level and delete the "multipart/
Chuang Expires 23 August 2024 [Page 12]
Internet-Draft Mailing-List Modifications February 2024
mixed" and the footer MIME parts.
For example given an original message of:
Content-Type: multipart/mixed; boundary="abcd"
From: john.doe@example.com
--abcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
VGhpcyBpcyB0aGUgbWVzc2FnZSBib2R5Lg==
--abcd--
A "multipart/mixed" and text footer MIME parts can be appended as
follows:
Content-Footer: m=mixed
Content-Type: multipart/mixed; boundary="efgh"
From: john.doe@example.com
--efgh
Content-Type: multipart/mixed; boundary="abcd"
--abcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
VGhpcyBpcyB0aGUgbWVzc2FnZSBib2R5Lg==
--abcd--
--efgh
Content-Footer: m=footer
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
============
This is a mailing-list footer.
--efgh--
1.4. Examples
These examples are informational.
Chuang Expires 23 August 2024 [Page 13]
Internet-Draft Mailing-List Modifications February 2024
1.4.1. Originator ⇒ First Mailing-List ⇒ Second Mailing-List ⇒Receiver
This message is sent through two mailing-lists to some receiver. The
originating sender creates and signs a message as follows:
DKIM-Signature: d=example.com
From: john.doe@example.com
Subject: A really big announcement
It's Jane Doe's birthday tomorrow!
The first mailing-list adds a Subject header prefix and message-body
footer, and denotes this using the procedures and headers specified
in this document. It denotes that it performed mailing-list
mutations in the ARC-Message-Signature.
ARC-Message-Signature: i=1; m=mailinglist...
Content-Footer: i=1; b=34; e=78
DKIM-Signature: d=mailinglist.example.com...
From: school@mailinglist.example.com
Subject: [school list] A really big announcement
X-Prior-DKIM-Signature: i=1; l=3; d=example.com...
X-Prior-From: i=1; l=5=3; john.doe@example.com
X-Prior-Subject: i=1; l=3; A really big announcement
It's Jane Doe's birthday tomorrow!
============
This is the school mailing-list.
The second mailing-list adds a Subject header prefix and message-body
footer, and denotes this using the procedures and headers specified
in this document. It denotes that it performed mailing-list
mutations in the ARC-Message-Signature.
Chuang Expires 23 August 2024 [Page 14]
Internet-Draft Mailing-List Modifications February 2024
ARC-Message-Signature: i=2; m=mailinglist...
Content-Footer: i=2; b=79; e=124
DKIM-Signature: d=mailinglist.example.com...
From: district@mailinglist.example.com
Subject: [district list] [school list] A really big announcement
ARC-Message-Signature: i=1; m=mailinglist...
Content-Footer: i=1; b=34; e=78
X-Prior-DKIM-Signature: i=2; l=5; d=mailinglist.example.com
X-Prior-From: i=2; l=5; school@mailinglist.example.com
X-Prior-Subject: i=2; l=5; [school list] A really big announcement
X-Prior-DKIM-Signature: i=1; l=3; d=example.com
X-Prior-From: i=1; l=3; john.doe@example.com
X-Prior-Subject: i=1; l=3; A really big announcement
It's Jane Doe's birthday tomorrow!
============
This is the school mailing-list.
============
This is the district mailing-list.
The receiver sees the above message on inbound delivery, and attempts
to verify the ARC message signature at the i=2. Upon success, the
receiver notices that there were mailing-list mutations at ARC set
i=2. It applies the REVERSE validation algorithm to reverse the
mutations from the second mailing-list. After applying the reverse
procedure, the reversed message looks like:
ARC-Message-Signature: i=2; m=mailinglist...
ARC-Message-Signature: i=1; m=mailinglist...
Content-Footer: i=1; b=34; e=79
DKIM-Signature: d=mailinglist.example.com
From: school@mailinglist.example.com
Subject: [school list] A really big announcement
X-Prior-DKIM-Signature: i=1,l=3, d=example.com
X-Prior-From: i=1; l=3; john.doe@example.com
X-Prior-Subject: i=1; l=3; A really big announcement
It's Jane Doe's birthday tomorrow!
============
This is the school mailing-list.
Chuang Expires 23 August 2024 [Page 15]
Internet-Draft Mailing-List Modifications February 2024
Again the receiver attempts to verify the ARC message signature now
at the i=1. Upon success, the receiver notices that there were
mailing-list mutations at ARC set i=1. It applies the REVERSE
validation algorithm to reverse the mutations from the first mailing-
list, obtaining the original message. The reversed message looks
like:
ARC-Message-Signature: i=2; m=mailinglist...
ARC-Message-Signature: i=1; m=mailinglist...
From: john.doe@example.com
DKIM-Signature: d=example.com...
Subject: A really big announcement
It's Jane Doe's birthday tomorrow!
The resulting reversed headers and message body DKIM-Signature
verifies, and the REVERSE passing result is published in the ARC-
Authentication-Result:
ARC-Authentication-Result: i=3; mx.example.com; reverse=pass...
ARC-Message-Signature: i=2; m=mailinglist...
Content-Footer: i=2; b=79; e=124
DKIM-Signature: d=mailinglist.example.com...
From: district@mailinglist.example.com
Subject: [district list] [school list] A really big announcement
ARC-Message-Signature: i=1; m=mailinglist...
Content-Footer: i=1; b=34; e=78
X-Prior-DKIM-Signature: i=2; l=5; d=mailinglist.example.com...
X-Prior-From: i=2; l=5; school@mailinglist.example.com
X-Prior-Subject: i=2; l=5; [school list] A really big announcement
X-Prior-DKIM-Signature: i=1; l=3; d=example.com...
X-Prior-From: i=1; l=3; john.doe@example.com
X-Prior-Subject: i=1; l=3; A really big announcement
It's Jane Doe's birthday tomorrow!
============
This is the school mailing-list.
============
This is the district mailing-list.
Chuang Expires 23 August 2024 [Page 16]
Internet-Draft Mailing-List Modifications February 2024
1.5. Security Considerations
Care must be used if the reversed transformed message is used for
authentication. The reversed transformed message is vulnerable to
replay attacks and "hides" the potentially spammy contribution from
the mailing-lists.
1.6. IANA Considerations
There are no requests at this time.
2. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/rfc/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/rfc/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/rfc/rfc7489>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601,
DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/rfc/rfc8601>.
[RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Kucherawy, Ed., "The Authenticated Received Chain (ARC)
Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/rfc/rfc8617>.
Chuang Expires 23 August 2024 [Page 17]
Internet-Draft Mailing-List Modifications February 2024
Author's Address
Weihaw Chuang
Google, Inc.
Email: weihaw@google.com
Chuang Expires 23 August 2024 [Page 18]
