On 2/4/25 5:24 PM, Wei Chuang wrote:
That data is possible to be found in the here and now. Again. With what is standardized with DKIM, STD 76. Actually it would be a very good experiment to run again to see if something more complicated is actually warranted. My sense from my experiments is that l= and z= capture the vast majority of the typical mailing list changes: changing the subject line and adding a footer. The real question is how worth it is to go after the long tail of intermediaries making other modifications that it doesn't capture. Which goes to the heart of the question: what problem are we trying to solve here? I had a very specific problem in mind. I'm not as sure about those proposing this why this is necessary (and the proposal requiring mailing lists to upgrade doesn't adequately solve my problem, so it's not that).On Tue, Feb 4, 2025 at 4:28 PM Dave Crocker <dcroc...@bbiw.net> wrote: Hence my use of "Procrustean" since what you've described is an environment that will penalize places doing otherwise legitimate changes but not conforming to the fairly simple changes the filtering engines expects (ie, demands.)I commented <https://mailarchive.ietf.org/arch/msg/ietf-dkim/hohNna8Kh-igfUAHo2IjpSA3ooI/> not long ago that the WG ought to consider complex and simple changes. Bron's algebra draft <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/> supports fairly general changes at the expense of diff overhead. I happen to agree with John that most changes are fairly simple and there's a lot of advantages in supporting the common case. But this is something that should be evaluated with operational data and better yet on the ground experience with an implementation as I would agree with what many have said that mutations can often be complex.
Mike
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
