On Dec 6, 2007, at 11:40 AM, Michael Thomas wrote:
Steve Atkins wrote:
On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:
Steve Atkins wrote:
On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote:
And as far as I can tell, you alone seem to be carrying this
torch
here. Changing what we agreed on with rfc5016 should require
a very
high barrier. I see little if any support, let alone broad
consensus
that we got it wrong.
You still didn't respond: did you read 5016 before it was
issued?
In fact I know that you did because you gave a lot of very
detailed
feedback. And this was not one of the thing you commented on
at the
time, so charges of "paradigm change" ring rather hollow.
So, you missed the postings by Levine and Atkins? (Perhaps
some others were on "my" side of this topic, but these two
were at least quite explicit.
I didn't read them as supporting your reading. Let them speak
for
themselves. There are a lot of things being discussed, after
all.
I broadly agree with most of Dave's concerns...
Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. The specific issue is whether *any* DKIM
signature
from *any* domain should be sufficient to qualify for "strict" or
"all".
Do you agree with that or not?
In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.
(Michael removes the relevant comment here, let me re-add it).
But that's not the protocol we have.
I agree, in principle, with Dave's view that a valid DKIM
signature should not provoke additional DNS queries
for self-published policies.
However I do not believe that SSP does not require
that, from my reading of the current drafts.
This is rather astonishing, and then you go on to say:
I think RFC 5016 shows a lack of understanding of DKIM (or is
choosing
not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.
Gee thanks, I am new on this block I guess.
In any case, the problem that I'm having with a lot of the nay-
sayers
is that it is purely destructive rather than constructive feedback.
The feedback is always of the nature of this is wrong, not what will
correct the problem. When I raise issues, I suggest a change to make
the spec better. If you don't suggest concrete changes to the draft,
it's really sort of hard to take you or anybody else seriously.
Frankly if you think this is just a piece of junk, I really don't
understand why you or Dave or John waste your time.
RFC 5016 isn't based on a clear articulation of what threat
SSP is supposed to defend against. It's also based on the
misconception that if a sender DKIM signs a mail then it
will still be signed on receipt (I understand that you know
that that isn't the case, but a lot of the document appears to
be based on simply ignoring that fact). It's a good solid
description of what a protocol should look like, and many
of the points it does bring up are good ones - but it's
based on false assumptions.
Given that, any suggested changes aren't going to be
wordsmithing, they're going to be wholesale rewrites
which will both be rejected by the document owner and
cause yet more aggravation, noise and personal attacks
here (the level of discourse is so coarse that everyone,
myself included, is letting their frustration leak through
into the discussion). What's the point? My goal is not
to annoy people, it's to improve the quality of the global
email infrastructure.
If you want to work on an analysis of SSP, based on an
honest evaluation of the weaknesses of DKIM on which
it's based, a clear articulation of the threat it intends to
thwart and a real analysis of the actual threat model and
the ways in which SSP can alleviate it, and the harmful
side effects that doing so may have on email in general
then that would be a useful document for the group to
put together and a good use of time.
Minor wordsmithing of an existing document based on
invalid lemmas may improve that documents clarity, but
doesn't seem like the most useful use of time.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html