ietf-dkim
[Top] [All Lists]

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

2006-08-02 21:33:07


Mark Delany wrote:
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?


If I used a skanky ISP, rather than the stellar songbird.com, how could my own
wonderful reputation overcome the awfulness of the reputation of my ISP?

In other words, I think that fate-sharing is inherent here, where two different
domain names can be identified.


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.

John L pointed this out, privately, too.  What I think it highlights is that all
our focus on "third-party" signatures might be missing the boat (except maybe
for signatures from mailing lists, but let's hold that in abeyance for the
moment.)

A "delegated" signature is one that is done by an outsourced service, but it
uses the same (parent) domain as the rfc2822.From.  Hence, delegation is not at
all like "third-party" where the domain of the signature is different than the 
From.


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.

Hmmm.  Sounds reasonable, although I find myself a little concerned about the
possibility -- or likelihood -- of independent operation of the ISP's MTA from
the 2822.From's domain entries. Certainly this is a coordination issue.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html