Thanks for the thoughtful and detailed response. I agree that functional clarity is essential, but I believe the distinction being drawn here is overstated, and that you may be overestimating how rigid naming conventions need to be in protocol evolution.
The distinction between “same function” and “different name” feels too binary. In practice, standards often evolve in scope and purpose while keeping a name that signals continuity. That’s not marketing spin, it’s a pragmatic way to guide understanding and adoption across a diverse ecosystem. Take the Wi-Fi 4 through 7 as an example. Those names were introduced after the technical specs were finalized. They didn’t change the underlying functionality, but they helped operators, vendors, and users track the evolution and adopt the changes with minimal friction. Naming didn’t dilute the standard, it amplified its reach. Similarly, DKIM2 acknowledges its heritage while signaling meaningful evolution. DKIM’s goal was to let a domain “claim some responsibility for a message.” DKIM2 strengthens that model by making responsibility more structured and durable across complex delivery paths. Each intermediary shall now assert and sign its role, making trust and accountability traceable end-to-end. In addition, DKIM2 borrows alignment from DMARC, a mechanism that has proven highly effective against phishing and abuse. This isn't scope creep, it's a natural extension to improve the reliability and security of domain-based trust assertions in today’s threat landscape. Calling this “DKIM2” reflects both continuity and progress. It helps maintain alignment across tooling, operational understanding, and adoption workflows. Naming matters, not just for technical clarity, but for enabling the ecosystem to move with us. / Tobias Herkula Von: Dave Crocker <[email protected]> Datum: Dienstag, 3. Juni 2025 um 15:45 An: [email protected] <[email protected]> Betreff: [Ietf-dkim] New product; not just an evolution Folks, The Porsche 911 example nicely confuses differences in components with differences in function and market segment. In fact, it's role, nature, and product segment have remained constant, throughout the changes. "The Porsche 911 model series (pronounced Nine Eleven or in German<https://en.wikipedia.org/wiki/German_language>: Neunelf) is a family of German two-door, high performance rear-engine<https://en.wikipedia.org/wiki/Rear-engine_design> sports cars<https://en.wikipedia.org/wiki/Sports_car>, ... Though the 911 core concept has remained largely unchanged..." https://en.wikipedia.org/wiki/Porsche_911 The Wi-Fi example suffers the same confusion. Technology enhancements, but the same functional goal. Faster, farther, larger access scale. But the same function. Now, compare these two explanations -- provided by their defining documents -- and tell me how the second functionality sounds like the first. Again, it is a completely new (and different) product: DKIM: DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. DKIM2: "There are a number of things beyond authenticating email that would be useful for mail system operators, particularly when it travels through multiple hops. ...having every hop in a forwarding chain responsible for: 1. verifying the path that messages have taken to get to it, including by being able to reverse modifications or by asserting that it trusts the previous hop unconditionally. 2. declaring (under protection of its own signature) where the message is being sent to next. 3. promising that it will pass control messages (including bounces, abuse reports and delivery notifications) back to the previous hop for a reasonable time." And note these substantial changes to email, by DKIM2, where DKIM made none. Taken from Section 2 'Properties" of the Motivation document: * A single recipient per signature While it is noted as already being common practice, this institutionalizes a change to the operation of SMTP itself. It certainly is not DKIM. * A chain of aligned DKIM2 signatures over SMTP from/to pairs Nothing to do with DKIM. Sounds more like ARC. Maybe call it ARC2? * A signed bounce format, sent in reverse along the same path Nothing to do with DKIM. Maybe more like DMARC? So call it DMARC2? * A way to describe changes Unprecedented in email. Certainly nothing to do with DKIM. * Simplification of signed header list Minor tweak to DKIM practices, at best. And of debatable utility. * Security gateways Doesn't actually say what one of these is. And it isn't clear what DKIM2 functionality this is meant to reference. So, arguably, nothing to do with DKIM. Section 3, Goals of Motivation: * DKIM-replay Certainly has to do with DKIM. But does the means of dealing with it involve changes to DKIM or the creation of new (and different) functionality? (With DKOR demonstrating at least some of the answer.) * Backscatter Nothing to do with DKIM d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net bluesky: @dcrocker.bsky.social mast: @[email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
