[ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
hsantos at santronics.com
Sat Feb 9 11:25:27 PST 2008
Eric Allman wrote:
> 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
> 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
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
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 -
Hector Santos, CTO
More information about the ietf-dkim