It sounds like you are arguing that "all" should be "strict" and
"strict" should be eliminated; as a corollary, no Third Party
Signatures should be accepted under any circumstances. That's a
valid argument, but it has nothing to do with whether the -ssp draft
is accurate.
I note however that -ssp-requirements doesn't seem to cover the Third
Party Signature case at all. Section 2 defines "Third Party
Signature" but then never uses the term. In fact, although the one
line description of Problem Scenario 1 reads "Is All Mail Signed with
DKIM?", and section 4.1 seems to cover the case of a Third Party
Signature (at least, it doesn't mandate a First Party Signature),
sections 2 and 5.3 point 3 define "DKIM Signing Complete" as
requiring a First Party Signature. In short, it appears that -req
doesn't permit third party signatures under any circumstances. I'm
not sure this was the intent of the working group.
Reading the documents in this light, it's pretty clear that -ssp and
-req are in conflict. The WG needs to decide on which way it wants
to go.
eric
--On September 30, 2007 12:14:23 PM -0700 Michael Thomas
<mike(_at_)mtcc(_dot_)com> wrote:
The main problem I'm having is tying "all" to third party
signatures whatsoever. The requirements make no mention of "all"
being tied to them, and I -- again -- don't see what the value is
for the _originator_ to make any statement about them. "All" is a
function of the originator's practices alone. Whether a useful (to
the receiver) third party signature is tacked on in transit is
completely out of its hands.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html