I will state <LOUDLY> that without the ability to handle 3rd party signing
statements, SSP is useless to me.</LOUDLY>
thanks,
Bill
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Jim Fenton
Sent: Fri 1/25/2008 7:03 PM
To: IETF DKIM WG
Subject: [ietf-dkim] A proposal for restructuring SSP
Eric Allman and I have been discussing a larger change to the SSP
specification that we believe addresses a number of the issues that have
been raised.
The biggest change is the separation of the SSP function into a
"checker", that retrieves the SSP record/records relevant to a given
message, and provides this information to an "adjudicator" that makes
the ultimate decision on how the message should be processed at a given
site. The Adjudicator combines the DKIM signature information, SSP
Checker results, and any other information it cares to consult (possibly
including, but not limited to, reputation, accreditation, content
filtering, SPF, and Sender ID). The definition of the Adjudicator is
out of scope of the SSP specification.
This version addresses concerns expressed in several issues:
o Reworded introduction for clarity.
o Added definition of Signing Identity and other definition
clarifications.
o Made examples of "strict" practice use non-normative (partially
addresses issue 1538).
o Clarified possible confusion over handling of syntax errors.
o Removed normative language from Introduction (issue 1538).
o Changed "Originator" to "Author" throughout (issue 1529).
o Removed all references to Third-Party Signatures (issues 1512,
1521).
o Removed all mention of "Suspicious" (issues 1528, 1530).
o Removed "t=y" (testing) flag (issue 1540).
o Broke up the "Sender Signing Practices Check Procedure" into two
algorithms: fetching the SSP record and interpretation thereof
(issues 1531, 1535; partially addresses issue 1520).
o Document restructuring for better flow and remove redundancies
(some may address issue 1523, but I'm not sure I understand that
issue completely; also issues 1532, 1537).
o Removed all mention of how this interacts with users, even though
it makes parts of the document harder to understand (issue 1526).
o Introduced the concepts of "SSP Checker" and "Adjudicator".
This draft isn't ready for submission yet, but I wanted to provide an
indication of the direction of the editors' thinking, and get a general
reaction if this is going in the right direction. I'm hoping NOT to
launch another multi-zillion-message thread with this message, so please
keep your comments at a high level for now until (assuming there is
general consensus to go in this direction) this is submitted.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html