Michael Thomas wrote in <4af22ea9-b533-497b-bd14-d37b46a61...@mtcc.com>: |On 1/30/25 5:00 PM, Murray S. Kucherawy wrote: |> On Thu, Jan 30, 2025 at 1:34 PM Michael Thomas <m...@mtcc.com> wrote: |>> But I'm content to leave that discussion to the WG rather than |>> the charter. |>> |> I do think it's a valid discussion point to understand why this |> has bubbled up to the top. I know there's been talk about this off |> and on for quite a while, but it's never seemed very serious. That |> makes me curious why it is now. |> |> Basically, assuming it works, it gives a more reliable answer to "Did |> the author domain actually send this?" than any of the DKIM policy |> add-ons can. |> |Depending on the scope of what the mutations reversal is, a fair amount |of it has been available 20 years. New work might be more comprehensive,
No. What DKIM as standardized provides was never enough to deal with the actual mutations that a message sees on the fly. This is especially true with MIME, as mailing-lists then change the MIME structure. It was like that already twenty years ago (even thirty), so sorry, with respect to how you speak here it must be said ... |but the concept is hardly new. The proposed new work also suffers from |the sender depending on something that's out of its control: that a |mailing list, for example, participates and a receiver cares, which is |far from a given. That is true. That is true for anything, may it be DMARC, ARC, or anything else. However, *if* the WG adopts a DKIM v1 "iteration approach, instead of inventing "something new", then it can/could be expected that the installed software base is "upgraded" as new versions of their used software appear, and then time will it bring. However, it seems to me it (DKIMACDC) *could* (i have yet to see any possible technical reasoning against it, actually) adapt to "holes in the chain", if only certain domains along the way are upgraded. This, of course, should be those which perform modifications, like mailing-lists o/ So i bet the IETF lists, given their configuration state, will be a problem for a long time. |So it's just curious to me why people think this is a problem worth |solving now after decades of disparaging the general idea. I had a |specific use case in mind: spear-phishing. This doesn't seem about that. What has this to do with DKIM?? Ie if i trust the Kaspersky definition of that phishing attack that is. That new DKIM(ACDC) improves the situation: for the first time reputation can be build upon cryptographic grounds etc etc etc. I am not a politician to reiterate that shit over and over again. |So I'm a little puzzled. I do think we should have a clear rationale for |why we are doing what we are going. That seems to be lacking in the \ |charter. Me too. What *i* do not understand, by the way, is *WHY* the IETF works the way it does. Mr. Kucherawy, for example, who deserves a big and fat acknowledgement, already stated in RFC 7372, and that was in 2014, eleven (11!) years ago, "(This violates the advice of Section 6.1 of RFC 6376.)", *several times*. And there was more, thinking about his draft with the SMTP receivers cast in stone (forgotten about its name; i think it was from 2017!). So the problems and solutions are very well known. What is happening here *THUS*??? So *IF* *I* see *THAT* picture, you know, the IETF *SUCKS*. (I am out for cycling now, in the dark, under the stars.) Greetings and Ciao! from Germany, --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) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
