I like the idea of making signatures recoverable wherever possible.
For mailing lists, I wonder if this approach is sufficient to solve the whole problem. If the MLM transformation is for security rather than informational purposes, I expect that the transformations will be (even should be) non-reversible. For some spam filters, it might be important. Lots of spam filters add DKIM-invalidating content upon entry to the protected domain. Many of those changes should be reversible. URL rewrite is the most difficult to reverse using this approach. However, when the incoming and outgoing email gateways are from the same vendor, as I suspect is often the case, the reversal should already be feasible using proprietary methods. Is any known spam filter vendor doing this type of reversal? DF From: dmarc [mailto:[email protected]] On Behalf Of Murray S. Kucherawy Sent: Sunday, July 05, 2020 5:56 PM To: IETF DMARC WG Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt I decided to breathe life into this idea since it's relevant and got some discussion recently. Comments welcome. I'm talking to the Mailman people about the idea now; this is based on some things they mentioned. I haven't managed to get the attention of Sympa or L-Soft yet. -MSK ---------- Forwarded message --------- From: <[email protected]> Date: Sun, Jul 5, 2020 at 2:46 PM Subject: New Version Notification for draft-kucherawy-dkim-transform-01.txt To: Murray S. Kucherawy <[email protected]> A new version of I-D, draft-kucherawy-dkim-transform-01.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dkim-transform Revision: 01 Title: Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures Document date: 2020-07-05 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-kucherawy-dkim-transform-01.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Htmlized: https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform Diff: https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-transform-01 Abstract: DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent one of a handful of well-defined transformations prior to being re-signed by a mediator, so that a verifier might rewind such a modification and thereby confirm that the original signature still verifies against the original content. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
