Michael Thomas wrote: > This could possibly be dealt with in a couple of ways: > > 1) make all of the customer's zones change (bletch). > 2) customer delegates the _domainkey subdomain to the provider so they > can manage it on the customer's behalf (probably only scales to one > provider > though) Actually, the multiple-provider case is one of the situations supported by the "dotted selector" mechanism: the customer can delegate the zone foo._domainkey.example.com to provider A, and bar._domainkey.example.com to provider B. Provider A could sign messages with a selector such as aardvark.foo, and B could sign with a selector such as zebra.bar. > 3) have the ability for the policy statement say that a provider(s) > legitimately > signs for that domain. > > (2) puts the responsibility for management of the zone on the email > service provider > which may not be very natural. (3) has scaling issues transport if > there were to be > more than one entity allowed to sign for a domain, which seems like a > likely use > case too. The potential scaling problem with multiple providers in (3) is one of my main concerns with this approach. I have heard of enterprises with upward of 100 authorized mailers, so this has real potential to be an excessively long list.
I have a somewhat less tangible concern, too. If example.com publishes an SSP record saying that some mail provider is an authorized sender, and there is an abuse problem, will example.com feel the same responsibility for the use of their address as if the message had been signed directly "by" their domain? They may not, and I view any spreading of the responsibility to be undesirable. We have put in lots of mechanisms for domains to delegate signing authority: they can delegate individual keys, the entire _domainkey zone, or a subdomain of that. Mailing providers are free to use the same keypair to sign for all of their customers, if they want to assume that risk, and they only need to apply the right domain name and selector when they sign. Is that really a big burden? -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
