Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
2008-02-09 12:31:14
Eric Allman wrote:
Hector,
Thanks for your example on SMTP vs SUBMIT --- that gives me a good
handle on what you mean by "relaxed protocol". But I'm not
understanding "protocol consistency fraud". I think they are connected,
but I don't understand how, and how SSP-02 makes it easier vs. SSP-01.
I'm not sure which part is not understood. The phrase? the usage of
consistency? combine with fraud?
Consistency in this technical sense deals with protocol logic, it means
that everything you measure (or get, receive) is "consistent" with what
expected to be true.
Some definitions in the field:
- "propositions are consistent if they can all be true. A system of
propositions can be shown to be inconsistent if it contains a
contradiction (a proposition and its negation). Consistency and
completeness are two key concerns of modern logic."
- "a harmonious uniformity or agreement among things or parts"
SSP-02, as I read it, does not allow a receiver or lets say removes the
incentive to perform a consistency check because the specification
allows for the inconsistent state to exist.
So far as I am aware, the SSP-02 /protocol/ is no weaker than in
SSP-01. What is weaker normative requirements on how the receiver
interprets that protocol, which is inevitable if you buy into the idea
that SSP has no right to impose any requirements on the receivers. If
you're disagreeing with that premise then I fully understand; this is
just a case where you have to choose one and go with it, because you
can't have it both ways.
Well, I don't think SSP is impose any requirements on the receiver. It
is allowing the receiver to make the final decision with known facts
about what is inconsistent transactions.
Most Receivers don't want any more junk than it has to take on. If it is
told "Hey, this is junk. I don't care if you get rid of it." then what
is the final outcome is really up to the receiver.
But just consider that you just said. Aren't you inherently imposing
rules on the receiver by indicating SSP should not telling what the
receiver can or can not do?
As I said before, my position is that as
desirable as it may seem to put requirements on the receiver in order to
guarantee consistent results, the reality is that the receivers will do
whatever they want to in order to give the best results for themselves
and their customers.
Exactly, but I believe SSP-02 has removing vital information from the
decision table, and therefore, in virtue of that decision to do this in
SSP-02, you are negatively imposing your own rules and policies on how
receivers should behave.
> Hence, saying "no normative requirements for
receivers" is in my mind just bowing to an inevitable reality.
Don't you don't you will have a SPF SOFTFAIL like consequent with SSP-02
DKIM=ALL?
This is at the root of eliminating the concept of 3rd Party Signatures.
Sorry, I still don't follow the logic. The decision is still not based
on technical merits but subjective policy making on the receiver.
They were only relevant in terms of how the receiver interprets the DKIM
results, and hence inappropriate for discussion.
Do you think everyone is going to implement DKIM as a stand-alone
appliance "proxy" box engine where it can be fed millions of messages
and its sole job to process these messages?
If so, then I pity the general case receivers if you believe they are
going to tolerate such high volume overhead and abuse with little payoff
in return.
Remember, DKIM eliminates the problem we had with SPF SOFTFAILS. I
believe you have stated so yourself in DKIM Media Interviews. But if you
want results to be treated in the same way via SSP-02, people are going
to find that, unlike SPF, just REJECTING these "softfails" is a pretty
reliable bet
As you said, you have no control of the receivers, but you are not
leaving them any choice either and as far as I am concern, DKIM is sure
to come out of the gate with a thorn on its side and a black eye with
this SSP-02 model
You say some things about the Evaluator that lead me to believe that
you've got a different idea of what it should be than I do. You say:
So to me the idea of an Evaluator would be first a fundamental
protocol consistency Evaluator that would be part of the DKIM/SSP
framework across all supportive/compliant systems. It would be
100% independent from any subjective or heuristics or reputation
analysis or any one group detecting their questionable inherent
policies or implementations methods.
This is the inverse of the model in my head, where the Evaluator is
completely /dependent/ on "subjective or heuristics or reputation
analysis" --- it is, in short, how the receiver decides how to process
the message. Indeed, the point of introducing the concept is an attempt
to make explicit what is out of scope for normative definition in the
SSP spec.
If I'm misunderstanding what you are trying to say (very possible) then
I apologize and request further explanation.
The standard track SSP protocol should have a protocol consistency check
before you subject the system with unknown out of scope evaluators.
We had that before, now we don't and there is really no solid
engineering logic behind the removal.
But its your bag and ball and I guess thats it. ASP wins! SSP is dead
and DKIM will be isolated to a limited market but not the general case,
where it will begin to be taken advantage of because of all the include
DKIM forge the SSP-02/ASP people don't want receivers to worry about -
right!
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, (continued)
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Hector Santos
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Douglas Otis
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Eric Allman
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Hector Santos
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Eric Allman
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8,
Hector Santos <=
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Charles Lindsey
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8, Stephen Farrell
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, Douglas Otis
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, Eric Allman
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, Steve Atkins
- RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, MH Michael Hammer (5304)
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, Steve Atkins
- RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, MH Michael Hammer (5304)
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, Steve Atkins
- Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive, Michael Thomas
|
|
|