ietf-dkim
[Top] [All Lists]

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

2006-08-02 20:59:02
On Wed, Aug 02, 2006 at 08:02:54PM -0700, Dave Crocker allegedly wrote:

[Starting a new thread to focus on a one aspect]

Outsourcing for mail sending is already common, so it seems likely that
delegating signing would be, too.

But my question is why it is better to have a "delegation of my domain" scheme
rather than simply having the outsourced sending do its own signature and then
use its domain name for evaluating its own reputation.  If it is a Good Actor,
then it shouldn't need to rely on the domain name of the content author.  If 
it
is a Bad Actor, then relying on the domain name of the content author would
merely wind up hurting the content author.

The point seems to be that there is a potential mis-match. Reputation
of content author != reputation of outsourced-sender, aka ISP.

One imagines that most small businesses fall into this category where
they have an impeccable record, yet their ISP is, by necessity, the
lowest-common-denominator of all their customers.

For example, is bbiw.net equal to, worse than or better than the ISP
it uses? Would you want the reputation of bbiw.net tied to your ISP or
would you rather stand on your own? And would your answer be the same
if your ISP was larger, say, Earthlink or AT&T or BT Internet?


But then I don't understand the great difficulty with "delegated
signing" in the first place.

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.

b) bbiw.net makes authenticated SUBMITs to their ISP

c) Based on the authenticated SUBMIT, the ISP picks a selector for the
   bbiw.net domain and signs on their behalf and generates a
   d=bbiw.net, etc.

The interesting thing is, depending on where SSP ends up, an ISP need
not even care about the various identities in the submitted email, ie,
2822.From, all it has to do is generate the d= based on the SUBMIT
authentication and let verifiers apply SSP to the content.


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