I think that the actual problem here is when we try to attach any sort of
receive side semantics to the presense or lack of a signature. As I've said
many times, DKIM produces many more states than just "verified"
and "unverified" since there are many, many different states in verified.
The new "bodyhash" is yet another outcome where a signature might be
partially valid (eg, good header, broken body).
The real solution here, IMO, is to resist being perscriptive about what
the receiever should do with this information. What we really need to
do is list the possible states as outcomes of the verification process and
leave it at that. Ie, no recommendation at all; just input to a receiver's
evaluation logic. That way we postpone *all* of these semantic
discussions for which we are at this point ill prepared to pass judgement.
These would make *excellent* topics for a BCP when we have some
CP.
Mike
Paul Hoffman wrote:
This looks pretty good! One major stumbling block, though.
At 4:44 PM +0100 4/19/06, Stephen Farrell wrote:
Proposed:
. . .
Verifiers SHOULD support checking of x= values.
From RFC 2119, which DKIM normative references:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
. . .
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
What is the interoperability or harm-limiting purpose of verifiers
checking x= values? If there is none, the sentence above needs to be a
MAY.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html