ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] What third-party ISP problem?

2006-08-03 08:10:01
Mark Delany wrote:

But then I don't understand the great difficulty with "delegated
signing" in the first place.
What I've got out of this current discussion is the real problem is
with selector management.  If I want isp.com to run my mail with
their zillions of mta's, I as the customer am clearly not going to keep
my DNS in synch by hand -- some automation is some kind is clearly
needed.

Read on:

Wheeling out my - admittedly dusty - ISP hat, I wonder why we need
third-party ISP signatures when an ISP can relatively easily generate
first-party signatures on behalf of their customer.

Thinking out aloud here, what if:

a) bbiw.net delegates _domainkey.bbiw.net to their ISP - typically
  that'll be a no-brainer as your ISP already runs your DNS content
  server. If not, add a couple of NS entries or a CNAME and you're
  done.

NS delegation works for exactly one provider. This is probably just
fine for a pretty reasonable swath of small business, but it really
doesn't addresss the whole spectrum. For example, if I outsource my
mail to isp.com, I'm also pretty likely to outsource my email campaigns
to advertisomatic.com too. If I delegate the entire _domainkey subdomain
to isp.com, will they also set up the infrastructure to allow advertisomatic.com
also sign my mail? How would that work?

And I don't see how CNAME's would work: as far as I know, you can
only CNAME at a leaf which would be at the individual selector level.
That would make it rather problematic for a provider to retire/revoke a
selector, not to mention adding new selectors.

So *if* it could be done (which I am not convinced about), there seems
like there would be some advantage to do the indirection at the protocol
layer (eg, SSP) rather than at the DNS layer (eg NS).

      Mike

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html