Honestly, with the capacity to undo header changes from dkim2-modification-algebra I would be more inclined to have the spec list headers which MUST NOT be signed (probably just trace headers), and to list additional headers to not sign, rather than additional headers to sign.
I would also mention here than one thing we (or at least I) want to change between DKIM and this new spec, is that every instance of any signed header is signed, there's no "oversigning" where you have to list "Subject" twice in the list to avoid somebody adding a second Subject header which displays in some systems despite the first one being the one that's checked by the signature verifier. Sure it's wrong, and in a perfect world with perfectly compliant software that didn't have bugs, that email would be rejected for being non-spec-correct with its two instances of a single-instance header. But we don't live in that world, and my design philosophy is to make it hard to screw up - and if you do, to have the failure be obvious. So I'm very interested in a discussion of *"should we have an exclude-list rather than an include-list of signed headers?"*. I think that's maybe even the first discussion, followed by* "should said list have implicit members defined in the spec?"* once we've made a decision on that first question; and only then if we've decided that question, the final question of *"what header names should be included in that list?"*. Cheers, Bron. On Mon, Apr 14, 2025, at 15:30, Emil Gustafsson wrote: > Yes, the reason why each header should be signed should be documented. I > agree with you there. > > I don't understand the purpose of the memory aid comment. > I think it is a good thing if a standard prevents users of the standard > defined from shooting themselves in the foot. Similar to newer versions of > TLS remove insecure ciphers. > If such foot-gun prevention unnecessarily restrict the standard I agree it > should be avoided, but in this case I don't think an implicit header list is > a restriction. If there is such a restriction here that I'm missing, please > elaborate. > /E > > On Mon, Apr 14, 2025 at 9:32 AM Dave Crocker <d...@dcrocker.net> wrote: >> __ >> On 4/14/2025 5:10 PM, Emil Gustafsson wrote: >>> rom what I think is the main purpose with a set of defined headers that >>> have to be signed: Making sure senders don't forget to sign them. >> >> >> Forget? As if a normative requirement in a standard is a memory aid? >> >> It might help to see some clear, explicit justification for each of the >> choices, since it is clear that the goal is quite different from what DKIM >> originally intended the header field linkages for. >> >> Absent such justification, the list is arbitrary and even whimsical. >> >> d/ >> >> -- >> Dave Crocker >> >> Brandenburg InternetWorking >> bbiw.net >> bluesky: @dcrocker.bsky.social >> mast: @dcrocker@mastodon.social >> _______________________________________________ >> Ietf-dkim mailing list -- ietf-dkim@ietf.org >> To unsubscribe send an email to ietf-dkim-le...@ietf.org > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org > -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
