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