While I understand the desire to keep DKIM2 simpler, pp= permits delegation to an email hosting provider as already pointed out above. One consideration I didn't think of till now is this pp= delegation can help with the DKIM2 adoption especially when we consider the algorithmic agility requirement. DKIM2 at some near point wants to mandate publishing and signing both with RSA and ED25519. My guess is that many senders and forwarders will have trouble deploying ED25519, and one avenue to smooth adoption is allowing them to delegate publishing and signing to their platform. That said, I noticed that pp= has been removed in draft-clayton-dkim2-spec-03, so perhaps this discussion is perhaps moot.
Regarding the mv= tag, can more clarity be provided how that is different from the i= instance number? Is the idea that a more recent (higher i= number) DKIM2 signature can reference an older (low mv=) MailVersion header? thanks, -Wei On Wed, Oct 22, 2025 at 2:59 PM Tobias Herkula <tobias.herkula= [email protected]> wrote: > I don't think we need additional complexity here of the nd= or now pp= > fields, as we already have a best practice on how to delegate sending > privileges to third parties, that are well understood. In the Bulk Senders > and Hosted Mailbox industry it's already very common that the 3rd party > that needs to be able to sign on the 1st party behalf will provide a > public key to the 1st party to be included in the corresponding DNS zone, > for ease of use, most of the time not the public key is provided but a set > of CNAME-RRs, with these the 3rd party can easily sign on behalf of its > user/customer and keep the chain intact. This is also much more explicit as > both parties need to agree on these kind of functionality anyways and would > help to stabilize forwarding and security gateway scenarios. > > This could result in a need for additional intermediary signatures. But I > see that as a benefit, bot a problem. > > IF this will suddenly become common we perhaps should add a note about > considering better names for selectors to not create collisions for complex > forwarding scenarios, especially in corporate environments I often see at > least 4 different providers involved that all need to sign in the name of > the customer and all of them would request a small set of selectors. > > -- > > /Tobias Herkula > 1&1 Mail & Media GmbH > > ------------------------------ > *From:* Bron Gondwana <[email protected]> > *Sent:* Monday, October 20, 2025 19:42 > *To:* [email protected] <[email protected]> > *Subject:* [Ietf-dkim] Re: New drafts posted > > Quick note because I'm about to run out, but updated the draft to get in > ahead of the deadline! > > Richard got back to me and doesn't like nd=, so in version 4 I used his > proposal of pp= instead, putting responsibility on the receiving system to > provide information about the domain it's signing on behalf of, and > defining that the relationship can be inferred from the MX records or > leaving space to define a DNS key for it as well. This will allow bounce > records to be created from the MX domain for example. > > Anyway, we can discuss the various approaches in Montreal! It's good to > have both documented. > > Bron. > > On Fri, Oct 17, 2025, at 22:43, Bron Gondwana wrote: > > Hi All, > > I've posted a couple of updated drafts. Particularly the one where I have > co-authors, I haven't run this text past them, so we could for sure pull my > changes out again, they're just a proposal! But I wanted to get aligned > versions in the datatracker before the draft submission deadline, and I'm > traveling all of next week. > > I renamed the Delta stuff "MailVersion"; and I've proposed putting in mime > part binary hashes. The format is very much not locked in, but it was an > example of what versioning could look like, with the sender adding one of > these headers with hashes and signing that using something other than DKIM2 > potentially, allowing you to know that attachments hadn't been tampered > with (for example) or that an attachment had been removed but the text > hadn't been tampered with. > > And I added the nd= that I discussed in my previous email. > > Enjoy, and please provide feedback! > > Thanks, > > 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] > > > -- > 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
