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. 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. This also wouldn't support large mutations like re-encoding transport encodings of mimeparts or deletions in general. As you've noted in your example, base64 poses additional difficulties. Here to avoid mutating the mime part, it might be more expedient to make the footer addition as a footer mime part as a child of a multipart/mixed. It would not support the rewrite of a URL as mailing lists tend not to do this. URL rewriting is more often performed by security gateways, and those are already meant to be a special case as noted in 2.6 of draft-gondwana-dkim2-motivation <https://www.ietf.org/archive/id/draft-gondwana-dkim2-motivation-02.html>. Some of these concerns are further expanded in draft-chuang-mailing-list-modifications <https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-04> but that draft is out of date. -Wei
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
