ietf-dkim
[Top] [All Lists]

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

2006-08-03 07:40:36
On Wed, Aug 02, 2006 at 09:24:40PM -0700, Dave Crocker allegedly wrote:

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?

Er, unless the ISP is truly skanky and abuses access to your DNS, then
doesn't your email signed by your domain make the ISP irrelevant?

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

Why would your ISP be identified and, even if it is, why would its
signature, as a third-party, be more relevant than your signature, as
a first party?

Personally, if I see an inbound email with valid a first-party
signature, the relaying ISP is pretty much irrelevant. You could send
it via songbird, AT&T, Starbucks, hilton.com, who cares? Isn't that
the point of DKIM?

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.

Quite so. Your ISP is acting on your behalf but the ability of the
verifier to discern that, strike me as a) hard and b) un-necessary.

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.

I may not understand your concerns exactly. The failure case is that
your ISP uses your keys on behalf of another SUBMITTER.

However, if your ISP gets it right, that is they only use your
keys/selectors for your authenticated submission, then the failure
case is that your signature will be treated as a lesser third-party if
you choose to have a mis-matching 2822.From (or whatever SSP
anoints).

Point being that you have to get everything aligned for a first-party
signature. Any mis-alignment, apart for a buggy ISP, results in a
lesser, third-party signature.

To summarize, if your ISP can match up your authenticated submission
with a key that they usually manage, then that ISP need never add
third-party signatures and you get first-party signatures with no
work.


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