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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]
