This is an interesting sketch, but it doesn't include the hard parts, so it's hard to know if it can provide what is needed. For example, will the rolling hash allow for exact boundaries of changes to be determined? Subjects are pretty short, how does a rolling hash handle that? I'm not familiar with rolling hashes, so perhaps my questions are naive.
The mime body canonicalization is odd, what percentage of mail isn't multipart at this point? It also requires that mime canonicalization requires impl of this other spec, which seems more v2ish, though maybe not in formatting. I'd say the mime header canonicalization doesn't go far enough. For example, most mailing lists that are i18n aware are going to decode rfc2047 subjects before adding a subject prefix, and then reencode, which may not be in the same charset, especially if the prefix and subject are in different languages. Another issue we see is in optional things, such as quoting in address and parameter headers. Defining a canonical form for those headers might be necessary to accomplish what you want. There's also smtputf8 downgrades, which would imply taking a utf8 nonencoded subject and encoding it. It's also useful if your system uses a non rfc822 format internally and only gateways to the internet. I think a proper mime canonicalization would be useful on it's own, we've talked about it before internally here at Google. I believe that we discussed something similar to this early on this list, but the challenge is in the details. Brandon On Sep 25, 2017 3:02 AM, "Rick van Rein" <r...@openfortress.nl> wrote: > Hello DKIM/DMARC list, > > I would like to propose a method for "fixing" the real-world problems > that currently break DKIM. I am aware of the work on ARC, but in > comparison this appriach: > > 1. is much simpler, with a simple cryptographic foundation > 2. works without explicit support from message-modifying intermediates > 3. locates message parts that have changed [within practical bounds] > 4. allows training on acceptable changes for given senders/intermediates > 5. pins down rogue senders/intermediates more accurately > > The idea isn't completely worked out yet, but the approach should be > crystal clear from the current text. I believe that this leads to > better email user experiences than possible with ARC. > > I am looking forward to your responses. Please keep me in Cc: if possible? > > > Best wishes, > > Rick van Rein > ARPA2.net / InternetWide.org > > *From:* internet-dra...@ietf.org > > *Date:* 25 September 2017 at 11:49 > > *To:* "Rick van Rein" <r...@openfortress.nl> > > *Subject:* New Version Notification for draft-vanrein-dkim-lenient-00. > txt > > A new version of I-D, draft-vanrein-dkim-lenient-00.txt > > has been successfully submitted by Rick van Rein and posted to the > > IETF repository. > > > > Name: draft-vanrein-dkim-lenient > > Revision: 00 > > Title: Lenient DKIM > > Document date: 2017-09-25 > > Group: Individual Submission > > Pages: 7 > > URL: https://www.ietf.org/internet-drafts/draft-vanrein-dkim- > lenient-00.txt > > Status: https://datatracker.ietf.org/doc/draft-vanrein-dkim- > lenient/ > > Htmlized: https://tools.ietf.org/html/ > draft-vanrein-dkim-lenient-00 > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-vanrein-dkim-lenient-00 > > > > > > Abstract: > > DKIM is a framework for signed messages, especially for email. While > > in transit, changes are sometimes made, and these break the DKIM- > > Signature. This specification makes DKIM more lenient, without > > changes to its core. It adds leniency towards MIME body rewrites, > > removal of alternatives and annotation with bits of text. The > > intention is to allow these changes such that they can be clearly > > shown to the user, while indicating that the remainder of the > > signedmessage is still in tact. > > > > > > > > > > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
