Steffen Nurpmeso wrote in <20250415202743.1cAkTnbb@steffen%sdaoden.eu>: |Bron Gondwana wrote in | <5df9212c-5014-4323-8d70-fbc7d044b...@app.fastmail.com>: ||Honestly, with the capacity to undo header changes from dkim2-modificati\ ||on-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. | |For DKIMACDC we simply go with DKIM.
Having said that i repeat that for *me* the idea to check the accumulated IETF standards / header registry entries since RFC 6376 happened has a lot of merits. In fact it seems a lack of inter-IETF/IANA automatization that new header fields are not automatically announced to standards which need to cover them cryptographically, .. DKIM! Isn't it? The list as posted by Richard Clayton was surely meant to sparkle discussion, .. i hope. But there is nothing to discuss. So i also repeat that it seems to be a non-issue. In practice good software -- i recall for example Scott Kitterman's post on his dkimpy on this very list i think -- comes with a comprehensive (all-inclusive) list of RFC 6376+ headers to be signed. (Should have been around May 2024 since i then added headers to the default lists of my own DKIM signer that normally do not occur in main header fields, but only in MIME part ones, like content-description.) Ie, it is a quality-of-implementation issue, and standards cannot cover everything. Ie dkimpy's default set, or my one with one-letter shortcuts to very easily have a comprehensive default set at hand (that then can be added to or subtracted from). If the only freedom that remains is the one to consciously generate wrong configurations for free-time projects (like IETF DKIM config), it is a pity, but should not be taken away. Regarding oversigning/sealing. For my one i thought about making it the default, but did not. The manual clearly points it out everwhere, and the examples use it, however. I .. would refrain from making it a default. Regarding block (black) lists as opposed to allow (white) lists. Better not, there is such an unbelievable amount of garbage in the main headers, in the wild, *i* would not do this. Having said that, it is true that only like this very important header fields like Mail-Followup-To: etc, which were rejected by IETF in its very usual fail mode, and never sprang into existence even decades later when DMARC mitigations etc actually increased their necessity, add the OpenPGP: header field, and there are surely more, but please do not add autocrypt, HA-HA, here we see where this ends up. But Iron-Port, MGA, and whatever else magic huge headers exist, i would definetely vote for not including those. So, DKIMACDC: update of RFC 6376, "5.4.1. Recommended Signature Content", yes please. (I do not expect lots of new entries, however, as in practice i at least do not see such, and MIME language, jesus, if it has to be.) Other than that no, it is a quality of implementation issue, but i expect most people too intelligent to come via 6376 If the "l=" signature tag is in use (see Section 3.5), the Content- Type field is also a candidate for being included as it could be replaced in a way that causes completely different content to be rendered to the receiving user. to the conclusion that their default set should include MIME fields, otherwise the noxxi thing from 2017/8 could not have happened. Good software gives a hand. That a standard likely will never be able to provide all by itself. Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
