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 InternetWorkingbbiw.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
