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 <[email protected]> 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 InternetWorkingbbiw.net > bluesky: @dcrocker.bsky.social > mast: @[email protected] > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
