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.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html