On Thu 20/Mar/2025 09:57:26 +0100 Bron Gondwana wrote:
On Wed, Mar 19, 2025, at 08:24, Wei Chuang wrote:
On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana
<brong=40fastmailteam....@dmarc.ietf.org> wrote:
I'll take this as a review comment that I need to be much more clear on how it
works! This text from section 2 tried to describe how to remove a header in
one of the examples:
Example for a message which has had Subject and From replaced, and
Reply-To added.
From: br...@fastmailteam.com.dmarc.fail
To: dk...@lists.ietf.org
Reply-To: dk...@lists.ietf.org
DKIM2-Delta-Header: i=3;
t=Subject:A replacement for DKIM;
b=From:YnJvbmdAZmFzdG1haWx0ZWFtLmNvbQo=;
t=Reply-To
Notice that "Reply-To" has no colon, and hence is an instruction to
remove any "Reply-To" headers. All headers are case insignificant
for removal, and SHOULD be inserted with the case given in the header
when being added back.
Thanks for pointing that out. Taking "Subject:" as an example of a header that is deleted at the forwarder i=3, when we apply the reversing transformation to restore the message to the representation at the output of i=2, where should the "Subject:A replacement for DKIM" be restored to? Another issue is that each DKIM2-Delta-Header requires scanning the entire set of headers to apply all possible restorative mutations. Further what if multiple DKIM2-Delta-Header headers can apply to a given header i.e. which one should win? So instead I propose that each DKIM2-Delta-Header be restricted to the mutation of one header to act as a placeholder for the location of the header for deletes, and adjacent to the added or modified header.
Hmm. I would probably put it at the top if there's no existing Subject header,
or at the same spot as the existing Subject header otherwise. But it shouldn't
matter, Subject isn't a trace header; and the DKIM2 signature will validate
regardless of where you put it - which is all that really matters when you're
recreating a past message. It doesn't have to have byte-identical headers,
just headers that will pass the DKIM validator.
There are either zero or one DKIM2-Delta-Headers with `i=3` , and if there is
one, then that's the one that you apply in order to convert from the output of
signer number 3 back to the the input of signer number 3 (AKA: the output of
signer 2).
I think I understand your proposal, which is to do something like:
DKIM2-Delta-Header: i=3; h=From; b="From:YnJvbmdAZmFzdG1haWx0ZWFtLmNvbQo="
From: d...@lists.ietf.org
DKIM2-Delta-Header: i=3; h=Reply-To
Reply-To: d...@lists.ietf.org
DKIM2-Delta-Header: i=3; h=Subject; t="A replacement for DKIM"
Subject: [DKIM2] A replacement for DKIM
And then it would mean that the "From" always gets put before the "Subject".
This would work fine. I'm OK with that. It does mean slightly more verbose syntax (zero or more
DKIM2-Delta-Header rather than zero or one DKIM2-Delta-Headers) - it also means there are multiple
headers with the same i= value.
If we stick with DKIM hashing, the fields are hashed in the order they appear
in h=, so the order they appear in the header is irrelevant. When h= is
implied, the order should be given in the spec.
IMHO, the original Bron's idea of a single DKIM2-Delta-Header: per signature is
more practical. Otherwise, it'd be nicer to have:
DKIM2-Original-From: i=3; YnJvbmdAZmFzdG1haWx0ZWFtLmNvbQo="
From: d...@lists.ietf.org
DKIM2-Original-Reply-To: i=3;
Reply-To: d...@lists.ietf.org
DKIM2-Original-Subject: i=3; A replacement for DKIM
Subject: [DKIM2] A replacement for DKIM
Empty fields are equivalent to non-existing.
BTW, I notice that the Subject: of this thread is probably not what was
originally signed by messagingengine and fastmailteam (which is what fails
heuristic reversal methods):
Subject:
=?utf-8?q?=5BIetf-dkim=5D_Re=3A_Review_of_draft-gondwana-dkim2-modification-?=
=?utf-8?q?alegbra-01?=
Is that kind of gibberish a candidate for using b= (base64) version? But it's
not actually needed. What's the reason for using b= instead of t=?
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
