On Thu, Oct 23, 2025, at 20:36, Richard Clayton wrote: > In message <[email protected] > .PROD.OUTLOOK.COM>, Tobias Herkula <[email protected] > .org> writes > > >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. > > Tobias is correct ... that's what everyone does. > > That said -- I hear from many people at ESPs who have to hold their > customers' hands whilst they cut and paste private keys or set up the > CNAMEs that this is far from the simple process that people here might > expect it to be. > > That's why there is interest in developing automation so that the ESP > can push data to the registrar and end-users just push "OK" buttons... > > pp= is, I think, a little simpler to understand than adding CNAMEs or > understanding 255 byte limits ... but a key aim of DKIM2 is to have as > little impact on domain owners as possible and pp= violates that ! > > I will remove pp= from my draft (albeit the 2-week freeze means I will > need to post it somewhere other than on the IETF site!)
I'll be leaving pp= in the headers draft until the meeting. I figure we can talk about it, nd=, and the "cname a selector in the DNS" workflows as one of the points. SPEAKING OF WHICH! Chairs, do we have an agenda yet? Some things might come out of the hackathon, but I expect we know a few of the major discussion areas already! * nd/pp/etc - ways in which to define / derive the legitimate signers of the next hop * rt= list vs single item (I'm happy with the list here but I have heard dissent so we may need chairs to assess consensus on this topic) * sign all headers or not? * the mechanism of algorithmic dexterity * what to include in MailVersion (and bikeshedding on the concept generally) - also, is the "separate counters for versions and DKIM2 signatures" a good design? 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]
