----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Please don't overreact. I would have spoken up sooner if I had
understood the disconnect and if I thought that your interpretation
was
as broken as you seem to think it is. I think only minor adjustments
are necessary.
In this chart produced over 6 months ago, you, Eric and among others all
indicated a "I like this chart" statement:
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verification against SSP.
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER | NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | | |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | accept | accept | REJECT | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn | warn | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL 3PS | reject | warn | warn | REJECT | reject | warn |
+------------------------------------------------------------------+
It clearly shows in the EXCLU/REQ column, that there was a REJECT
condition for both the PASS 3PS (valid 3rd party signature) and the FAIL
3PS (invalid 3rd party signature). This was due to "my" intepretation
of this O=! policy.
But we now know it would be incorrect according to the correct intent of
this SSP draft O=! policy.
Instead, the PASS 3PS is not reject but a ACCEPT. The FAIL 3PS is not
reject, but mostly a warning now or accept depending ignore the 3PS.
Hence, you can see how EXCLUSIVE could fold into a STRONG policy.
So in essence, I misread the policy, and everyone else must of
misunderstood this chart because it was too obvious to point the
discrepency. I am no longer sure if you understood the purpose of the
chart. But I will say, many columns now do fold simply because of the
relaxed definition of the O=! policy.
In fact, now that it is cleared, when applying Michael's statement and
pseudo-code DKIM verifier logic:
"SSP is not for signed mail, it is for unsigned mail."
the chart is now reduced to one verify NONE condition:
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER | NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | | |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
When you compare the two tables for loopholes conditions, the loopholes
would be in not checking for unauthorized 3rd party signing.
So for the logic to be correct, it would more closely follow:
"SSP is for unsigned mail and 3rd party signed mail."
But then again, this all depends on the intepretation of ALLOW or NOT
ALLOW 3rd party signing policies. I understand now it is more
declarative, and not imperative.
To me that is a mistake. It increases risk and uncertainty and it will
be surely be exploited, making the payoff of DKIM processing much less.
So yes, it is a big thing. The 3PS issues needs to get resolved pretty
quickly because it defines much of what the threats will be.
The bottom line is that there is no longer any absolute "exclusive"
protection for a domain who wishes to use such a policy.
Finally, I think you are underestimating how many domains will be
interested in a "TRUE" exclusive policy. But then again, that only
applies if SSP is followed.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org