Taavi Eomäe wrote in <[email protected]>: |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.
Sure. For giving a list that is. RFC 6376 is likely expecting too much from today's readers given that, well, yes, there *is* such software, even actively maintained such. Maybe it was even a fault of mine to offer a basic and a (much safer) extended set for my own little thing. (But i think the actual safe list as such is pretty much identical in between software i "consider good" myself. None of those cover any of these additional IETF standards, like RFC 3798->8098 "Message Disposition Notification", however.) |> 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. I have some problems parsing this. I, ... Ok, if i recall correctly my problem with oversigning was merely an implementation issue. For example, one question is, does "oversigning/sealing" mean to close the door for only existing headers, or for all headers mentioned in the list of headers to be oversigned/sealed? Ok, now with "DKIM-forte", how i always called it, one *can* tell about who and where (or the signature breaks, as you say), so a real "oversigning" of only existing headers becomes something more natural. Caveat: in an all-"dkim-forte" environment, where all hops use the new approach. Otherwise not. Until then it remains an issue. (My ACDC approach embeds within DKIM v1 per se..) And then, you know, it is still true that the mechanical possibility to tell about changes does not at all help the end user aka the consumer of the email message. It requires a user interface that shows content transformations. Otherwise any spammer in the middle can perform changes with verifying signatures. |> 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. I agree. (Less lots of noise in the header fields that live on islands .. which possibly sign it because for them it is more.) Yes. --End of <[email protected]> --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 -- [email protected] To unsubscribe send an email to [email protected]
