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!)
--
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
