[ietf-dkim] Attempted text for x=
Michael Thomas
mike at mtcc.com
Wed Apr 19 13:40:39 PDT 2006
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
More information about the ietf-dkim
mailing list