[taking off emailcore] Nathaniel Borenstein wrote in <CAP-k+n=nA-QtcXFnC7WN=pTW64XMXOmX+J02z=4vkbmefqy...@mail.gmail.com>: |The LLM makes no mention of the fact that Content-Type was actually first |defined in RFC 1049. That may be the desired behavior, as per section 6.3, |but I thought I should mention it in case it reflects an oversight in its |summarization.
Yeah, and i wanted to say at first that the "brute-force sign-everything except X", where X is for example trace headers, which Bron Gondwana surely referred to when posting this to DKIM also, is a black hole of grief for many. You just cannot do it like this *imho*. You do not know what people are doing. You should not sign things which are *meant* as "trace-alike" headers, for example. And falling back to exclude ^X- headers is just what i already said on dkim@, for all the unknown number of people who designed *whatever* with RFC 6648 in mind. Btw i was not allowed to post, but did post to internet-history the all-true Steffen Nurpmeso wrote in <20260722225956.YiFNSrni@steffen%sdaoden.eu>: |[only to the list as i think i get redirected to /dev/null] | |Dave Crocker via Internet-history wrote in | <[email protected]>: ||On 7/18/2026 12:51 PM, Jack Haverty via Internet-history wrote: ||> From a historical perspective, there has been lots of work in the past ||> to create technologies that address such problems. In the email ||> world, that includes things like digital signatures, S/MIME, DMARC, ||> and many others. | ... ||DKIM2 has been underway for several years. At base, it takes the lesson ||of strict, hop by hop compliance and extends it considerably. That is, | |It is hot-air that does not address any of the mess that the email |part of the IETF has introduced. |And you did not mention SPF. | ||it is an infrastructure play, far beyond anything attempted for email so ||far. It will require adoption by everything in the handling sequence, ||from original posting to final delivery. | |It does not change anything really, it actually addresses problems |already pointed out in RFC 6376, the DKIM that is now known. |(Backscatter bounces, and message replay. Good that this is |addressed, yes.) | |In order to do that it dramatically changes SMTP. |That effectively becomes single-recipient. |How can a simple (though cryptographic) helper dare to mutilate |its base protocol like this? |What a massive transaction overhead! Unbelievable!! | |In order to do that it tramples upon decade-old best common |practices, of the RFC 6648 that you are a co-author of, and |furthermore brute-force signs (almost) all header fields of |a message. How senseless is that? Brute force selection? | |After that brain damage ARC that cryptographically signed fishy, |unverifiable data, now they brute force sign data masses in header |fields that are of no value, let alone for an iterated DKIM. | |Yes, it ships differential changes that allow restoration of |former message content, so that elder signatures can be |cryptographically verified. That is good. |(I have an opinion on how they do that. Though.) | |However, it does nothing to change the situation with From:, |neither today, and not even in an all-DKIM2-everywhere future. |It does nothing to make an email that crosses a mailing-list, or |just any "final delivery for the [original] message", as RFC 3461 |puts it, that changes the message, more valid to the user as it is |today. | |For example, if this list would pepper up your message with porn, |or political phrases, or what, DKIM2 would still allow your very |own name and address in From:. DKIM2 does not deal at all. | |So for *you* to be protected from the most dramatic psychological |failure of the email part of the IETF, to push users to trust |in that "X via Y" notation of the From: line that reality |brought in response to failures of the IETF, you do not only |need differential changes to restore former content to check for |former signatures. |But you need to mitigate on the protocol level to apply such |notations everywhere. | |Then any change of content results in a mitigation of From: (the |original Author: would still be alive and visible if RFC 9057 |would become used more often), and users can deduce with one |glance that a change there was. | |Then mail user agents can offer interfaces to show users former |message versions, after cryptographically verifying them. |I once, on this list, i think, talked about "traffic light |semantics that on click unfold to traffic light semantic of elder |message versions". | |Unfortunately the email part of the IETF only has balls to create |barriers and distress for administrators and email users, but not |for creating a slim, efficient and practicable solution to fix the |mess they themselves have created. |(In fact: many do not even recognize the fact as such.) --End of <20260722225956.YiFNSrni@steffen%sdaoden.eu> --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]
