Eric Allman wrote:
Jim Fenton wrote:
The key words here are Verifier Acceptable. The verifier gets to
specify which signatures are Verifier Acceptable, which gives it
precisely the liberty you describe.
We're not communicating. What might a receiver do differently with
a third party signature with and without the "all"? I can't think
of anything.
You're forgetting the "strict" case.
Without step 9, the algorithm would fall through to step 10 ("The
message is Suspicious and the algorithm terminates"). Step 9
explicitly allows the third party signature in the "all" case, but not
in the "strict" case. Note that the valid first party signature case
was handled in step 1, and the "dkim=unknown" case was handled in step
8, so by step 9 we're down to either no valid signature or a valid
third party signature, and a dkim tag of "all", "strict", or something
else due to a malformed SSP record.
It might be easier to understand (and nearly semantically equivalent)
if steps 9 and 10 read:
9. If the SSP "dkim" tag is "strict", or if no Verifier Acceptable
Third-Party Signatures are present on the message and the SSP "dkim"
tag is "all", the message is Suspicious and the algorithm terminates.
10. The message is not Suspicious and the algorithm terminates.
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.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html