On 16.04.2025 13:01, Steffen Nurpmeso wrote:
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.
In general I'd agree, but there's plenty of software that could be
considered "good", yet their signing configuration is really rather
conservative. Very likely partially because it's difficult to determine
right now what should (or should not) be signed. I really think that
"let everyone figure it out themselves" has proven to cause trivial
mistakes and poor signing practices.
Any new standard should IMHO attempt to provide a minimal list of
headers that MUST be signed and a list of headers that MAY be signed.
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.
It heavily depends on DKIMv2 semantics though. If any additions are to
be recorded in sequential signatures, there should be little need. Such
additions should cause a signature verification failure, if one of the
goals is to provide reliable authentication.
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.
+1
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.
Any future standard should not allow anything resembling the length tag
in the first place. Mixing unsigned and signed content is (empirically)
a recipe for disaster.
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
