Paul Hoffman wrote:
At 5:27 PM +0100 4/4/06, Stephen Farrell wrote:
Currently "h=foo" is usable to say "I didn't sign foo cause it
wasn't there" (or some better wording), effectively meaning
that if someone adds a foo header field then the sig breaks.
Ought your proposal make reference to this, even if only
to include a reminder that making use of this feature/trick
is liable to be problematic if such a field is likely to be
added by a later MTA/signer?
No, because it doesn't seem related to signing the DKIM-Signature
header. There is no sensible way to use DKIM-Signature in h= to indicate
"there will be no future DKIM-Signature headers".
Maybe I'm misunderstanding your question.
I think so.
Take some list related header field and two signers - the 1st signer
being the 1st outbound MTA and the 2nd signer being the list s/w (or
some other adjacent signer, whatever).
For some reason the originator doesn't want that list header field to
be signed, so he puts "h=<<list-field>>" even though there's on such
header on the message he signed.
Later the list adds a list-field header field and then adds its
signature (over whatever header fields, doesn't matter).
Now, as I understand it, its guaranteed that the 1st signature will
not verify. The second will, or won't, depending on the usual stuff.
My question was whether or not a reminder about this behaviour
would be useful.
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html