Mark Delany wrote:
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?
That certainly sounds reasonable, doesn't it? However I find myself wondering
whether receive-side filtering really will ignore who I use as my operator.
So far, filtering efforts seem to try pretty hard to use as much information as
they can find, not as little.
In other words, I think that what we are talking about here is a paradigm change
for receive-side filtering. But perhaps my assessment is not correct.
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?
Some will do their own signature "just to be safe". Certainly their IP address
will be obtained as it is now.
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?
Folks have been pretty cavalier about the idea that a message will have multiple
signatures, for whatever reason strikes the fancy of an (additional) signer.
I think this discussion suggests that extra signatures invites extra problems.
(Cliche: If you have one watch, you know what time it is; if you have two, you
are never quite sure.)
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.
Upon being stated, this seems pretty obvious. However it has not been a clear
implication, to me, and I find myself suspecting that it has been missed by
others, too. It strikes me as a rather important implication, in terms of what
we want to add to DKIM; or at least important for discussing DKIM usage.
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.
...
Point being that you have to get everything aligned for a first-party
signature.
Definitely true. However my point was not a concern about ISP misbehavior, but
having the administrator of the ISP be different from the administrator of the
DNS entry that contains your DKIM information. This falls under your statement
about alignment, but I think it is an operational scenario that needs to be
cited explicitly because it invites misalignment.
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.
Right.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html