On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana <brong= 40fastmailteam....@dmarc.ietf.org> wrote:
> On Sun, Mar 16, 2025, at 22:33, Wei Chuang wrote: > > Review of draft-gondwana-dkim2-modification-alegbra-01 > <https://www.ietf.org/archive/id/draft-gondwana-dkim2-modification-alegbra-01.html> > > Overall: I'm very supportive of the direction of this draft, which is to > describe mutations in messages as it traverses forwarders, with the intent > to be able to reverse them. The benefit of this reverse operation is to > enable successful DKIM signature verification on earlier versions of the > message at the receiver. In addition this procedure can help determine > which party added or removed content to a message. The following are some > comments. > > Section 2. Delta format - headers > > The DKIM2-Delta-Header can help reverse singleton header replacement and > addition style mutations, however it appears support for header deletion is > missing. Further this header representation likely has difficulties when > there can be multiples e.g. DKIM-Signature. Potentially this can be fixed > by adding deletion bit and position metadata to DKIM2-Delta-Header. An > implementation simplification that tries to remove some ambiguity might be > to have the DKIM2-Delta-Header apply to a single header adjacent to it. > > > 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. > Every DKIM2-Delta-Header item describes a header name, and it always > removes all instances of headers with that name, and replaces them with > zero or more new headers with the name. > > 3. Delta format - body > > The DKIM2-Delta-Body is a powerful construct to support arbitrary > mutations. However from an implementation perspective, it requires keeping > the old and new version of the message which will be cumbersome. It also > is also unbounded in header size. For example, imagine encoding the change > when the MTA re-encodes the transport format of a large message. For that > reason, I propose that the diff mechanism focuses on additive changes that > mailing lists tend to do like appending a footer. These can be encoded > simply. > > > They can be encoded very simply with this format too. In DKIM1 if the > additive change had been implemented from l=10423 then it would be encoded > as: > > DKIM2-Delta-Body: i=2; c=0-10423 > > > which is pretty short! > Indeed I think this approach is the right way to go. I would suggest that we limit the representation to additive transformations for now, and leave deletions out for now until there is more evidence that it is needed. You might argue that it's needed for appending to the base64, but what about adding a new parent multipart/mixed and appending a footer mime-part? That seems less damaging. Agreed that restoring patching the diff operation is straight forward. However it does burden the forwarder as noted about keeping the original and updated message. That bookkeeping will be particularly expensive for large messages. I suspect a much easier process is for mailing list forwarders to keep track of the mutation and publish those simple mutations. This might be an area where we try some experimentation to see what can be done at scale. -Wei
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
