[ietf-dkim] Re: Step 9
mike at mtcc.com
Sun Sep 30 12:14:23 PDT 2007
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
The requirements make no mention of "all" being tied to them, and I --
don't see what the value is for the _originator_ to make any statement
"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
More information about the ietf-dkim