John R. Levine wrote:
The "worthless signature" may not have been so worthless if one of
the header fields in question wasn't present at the time of signing,
... Are you suggesting that whether that header field is signed or
not is irrelevant to the assessor?
That's an interesting question, with a multipart answer. One part is
that in retrospect, Jon's suggestion is not a great design, and if
Doug or anyone wants to add extra stuff to a DKIM signature that is
intended to be passed to the assessor, it'd be a lot better to invent
an extra field or two, add it to the existing signature, and
specifically say that field is passed along with the d= to the
assessor. This both avoids the question of was it there originally,
and also avoids having to match up multiple signatures with possible
multiple extra info headers.
I agree that it is better to include this information in the signature
itself, which is why draft-fenton-dkim-reputation-hint does it that
way. But the constraints on the output of the verifier being proposed
would mean that the assessor can't depend on that additional tag/value
being available to it. How does one "say that field is passed...to the
assessor"? The signer certainly can't, and it shouldn't be necessary to
modify the verifier to do that.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html