We did discuss a diff based approach in the past, but ran into issues. Thread here: https://mailarchive.ietf.org/arch/msg/dmarc/_soxy-2IPCbXuV5aET9z4RFnG4o
The problem happens when we try to enumerate all the ways in which messages can be modified during forwarding. I agree, that if all we cared about was the 99% mailing list case, then we're talking subject markers and footers, which would be pretty easy to handle. If we start getting into the final 1%, we're looking at things like stripping attachments, and including the attachment in a diff basically defeats the purpose of removing them. Or, some mailing list providers like Yahoo Groups allow the moderator to edit the message, including the diff there also defeats that (whether such features are a good idea or the result should actually authenticate as the original author is it's own debate, of course) If you go beyond mailing lists, you also run into more things like URL rewriting or S/MIME de-encapsulation which could also result in large diffs. There is an argument to be made that handling the 99% mailing list case simply and effectively would be a better choice, and maybe there are N solutions for the top M DMARC breaking issues, and even the complete set of M is a better choice. Brandon On Wed, Aug 23, 2017 at 12:27 AM, Rick van Rein <[email protected]> wrote: > Hi, > > Enhancing my own remark with example text: > > > 11. > > As a design alternative, catering to those much-cheaper forwarding > > structures, has it been considered that a "diff" style header could be > > inserted much more easily? This would inform the recipient with > > information that could be presented in colour, for instance, seeing that > > the intention [of DMARC] is to protect that what is shown to the user. > > Since we're mostly talking of inserted "[listname] " in the Subject: > > header I wonder if ARC isn't a bit going over the top -- as well as > > limiting the ability to judge where things went wrong. At the same > > time, I do believe that the improved privacy of being able to drop > > information from the headers can be valuable (as long as someone takes > > responsibility over it). > > I worked out a ROUGH SKETCH of how a diff-based approach would look. It > could save a lot of work, both in the simplistic forwarders / lists and in > the validation nodes. I could work to get this more accurate if you think > it is a valuable approach. IMHO, it is simpler and that can be better for > some use cases. IMHO, it should not replace current ARC headers but could > be useful to augment it. > > Cheers, > -Rick > > > 5.4. ARC-Patch > > The ARC-Patch header indiciates changes that have been made to the > message while in transit. Headers are inserted at the top in the > order of occurrence, and can thus be unwound by going over the > headers in their order of appearance in the header list. > > An example application is the insertion of a list name in the Subject > header, with: > > ARC-Patch: Subject /^/[Katy] / > > This would transform a Subject header value "Something Like A Song" > to "[Katy] Something Like A Song", which is considered helpful by > list members, but which also breaks DKIM signatures. Changes to the > body are written as : for the entire email body, or :1 for the first > element in a multiple-entry MIME form, :1:2 for the second of the > first, and so on. > > Upon presenting content to email users, these differences are helpful > in colouring the text presented. At the same time, they can be used > to reverse the changes and return the text to values that can be > validated based on their original signature, whether made with DKIM > or ARC. > > I-D NOTE: Regular expressions can be kept as simple as possible to > make their reversal really simple. Examples of this include > mentioning the line number instead of just ranging over a body; > mentioning /KateBush/Katy/ instead of /(K[a-z]*)eBush/\1y/ and so on. > It is however possible to reverse even such a patch to a form by > swapping (...) and \N to derive /(K[a-z]*)y/\1eBush/ as a reversal of > the form. The trick of specifying this well will be to balance > simplicity in the most simplistic mail handling nodes against > efficient handling in the mail validation nodes. > > In general, multiple patterns may occur in each line, in the order in > which they are applied; upon reconstruction of the original text, the > order should be reversed. Furthermore, the reversal involves > matching the pattern of the outcome, which may lead to more matches > than desired; to accommodate for this, the matches in the output that > should be mapped may be specified in a list of numbers in [N,M,O] > form. Each pattern may be preceded with a line number to which it > applies. Patterns should not span multiple lines; they should then > be represented as multiple patterns, each modifying one line. > Provisions are made for inserting and removing lines. > > The ARC-Patch header may be released together with (TODO: before, > after, between?) a triple of cryptographic ARC headers, but it may > also be released independently. In general, a server passing a > message with modest modifications can use this mechanism to avoid the > overhead of cryptographic message handling. > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
