On Thu, Sep 4, 2025, at 04:59, Dave Crocker wrote: > On 8/31/2025 2:22 AM, Bron Gondwana wrote: >> On Sat, Aug 30, 2025, at 03:20, Dave Crocker wrote: >>> On 8/29/2025 10:03 AM, Murray S. Kucherawy wrote: >>>> * Adopt Bron’s document, and prefer a more omnibus approach, breaking out >>>> things when it makes sense to do so. >>> Apologies. In spite of the added clause, I do not know what 'omnibus' >>> means in this context, given the definition of the word. >>> >> >> My recollection was "design an integrated specification/protocol which >> addresses multiple issues rather than taking a piecemeal approach of trying >> to solve each problem individually without a wholistic overview". That >> sounds like buzzword bingo even to me as I re-read it, but I think it's >> accurate. >> >> Does that help? Others - does that match your recollection? > I think it underscores the misunderstanding. The view that being 'modular' > precludes also having an overview is simply nothing like what I have ever > espoused. Nor anything I have written, said or impled, or meant. > > Note, for example, that your own team's line of effort has started breaking > components out into separate documents (modules.) > > So, fully-integrated or 'omnibus' does not describe what your team's efforts > are actually producing. So, to invoke a cliche punchline, we are merely > haggling about price. >
OK, we're definitely in terminology confusion here. Integrated means "you have to implement all these things or you are not in compliance". You are arguing for the opposite, which I characterise as "we should design something which you could implement part of and still get benefit". My meaning of "omnibus" (and Murrary, please chime in and confirm whether that's what you meant) is "you have to implement all the bits to say you support DKIM2". > At the base of my own effort are the views that: > > • Much of what is desired has little or nothing to do with the existing DKIM > and therefore has no business being in a document that purports to be about > DKIM, and > • What does pertain to DKIM does not require changing the base DKIM spec but > can, instead, be done as one or more value-added specifications. > The reaction to the spec I offered was that, somehow, it was meant as being > instead of the entire range of your teams spec. It wasn't and was never cast > in those terms. > > Rather, it was offered as an example of carving out some of what your team is > attempting, but in a way that is compatible with existing DKIM and therefore > can avoid the (very long) parallel 'transition'. > > Your team's effort has dismissed the utility of preserving the installed > base. In spite of extensive Internet experience with the challenges that > produces and the significant track record of failures. And in spite of > noting that those failed efforts had advocates very bit as confident as your > team is... > "Your team" - we're all individuals here with different opinions. Even when some people chat directly with each other, that doesn't mean we're a united "team". I've had disagreements with my co-authors in public on this list, despite talking with them directly. But personally I have dismissed the utility of your _design goal_ here. I don't believe that an incremental approach that uses existing DKIM is valuable here for the reasons that I have documented before in emails to this list and am happy to repeat until I'm blue in the face: • existing DKIM parsers will reject messages because the first DKIM header will fail validation if any changes are made. • if a partial implementation appears in the middle of a complex mail flow, it's likely to break validation for later hops without realising it, so it's harder to get to "you can reject things with broken DKIM2 or missing recipients" A major point of DKIM2 is to allow you to reject things which you currently can't reject. > > > Also note that your team is producing something that is not 'interoperable' > with existing DKIM. Reusing components is not 'interoperability'. > Interoperability means that one instance can directly interact with the > other. That ain't what you folks are doing. It is, however, what I believe > /can/ be done. > Agree that the drafts produced with dkim2 in their name add up to something which is not 'interoperable' at the technical software design level. It IS interoperable at the operator level. You can keep the same DNS entries, replace the software, start doing both DKIM and DKIM2 without changing your DNS entries. That's not nothing. For the vast bulk of domain owners, this is the thing that makes their life easier. So operationally, it's interoperable. And... I still believe that at the technical level it can not be done to be backwards compatbile at the "reuse same-named header / be cross-interoperable". >> (rough definition: DKIM2-complete; there is a sequence of DKIM2 header >> fields with no gaps per the "destination domain of `rt=` on hop `n=i` >> matches signing domain of hop `n=i+1`" rule and the `n=MAX` header field has >> an `rt=` on the receiving system) > So, that is a re-do of ARC, not DKIM. > It's more ARC than DKIM in some ways, yes. At a purely technical level. The use of DKIM for branding purposes is based on "people have heard of DKIM and they can put keys in the DNS for DKIM now and get the benefits of DKIM2 when their MTA software is updated with no other effort". I think that's an achievable goal. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
