Jim Fenton wrote:
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.
Hmm, that seems like it could work. Seems pretty complicated though in
real life; I guess I'm just a little skeptical about mail providers
managing
other people's DNS in general.
Truth in advertising: I'm very much on the fence about all of this and I'm
only trying to figure out whether there's a big enough constiuency for a
general enough problem that seems like it _could_ be solved such that
it's worthwhile putting into the requirements.
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.
Yep.
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.
That's a good point.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html