Regardless of the specific words we may use to describe it, I've seen some very large email platforms omit some important headers in their DKIM signatures - headers explicitly recommended by the DKIM RFC - and I've seen that absence enable real-world abuse. Based on samples from multiple senders on one platform, it appears this may have been their standard signing practice since at least 2017.
Generating a failure on absence of a key header is a way to give a sender immediate feedback that they need to make a change. Compare that to the current header approach in DKIM, which doesn't create enough of an incentive for certain platforms to change their practices to reduce abuse, since DKIM passes without a problem. At first glance, this initial list of headers looks pretty reasonable, but I wouldn't be opposed to a closer review. On Mon, Apr 14, 2025 at 12:30 PM Emil Gustafsson <emgu= 40google....@dmarc.ietf.org> 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 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 >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
