Murray S. Kucherawy wrote:
I have the following text in my not-yet-published version to address this:
Current wisdom among [DKIM] verifier implementations is to avoid taking final
filtering actions such as rejecting messages based on a "fail" result, as
there are plenty of legitimate reasons a signed message might fail to verify.
Instead, such messages should generally be treated as though they were not
signed at all. Thus, a verifier MAY elect to report "neutral" in place of
"fail" to discourage needlessly harsh reactions from downstream agents.
A specification should not cite temporal reality. It's a spec. It won't make
sense for a reference to "current wisdom" when someone is reading it 10 or 20
years from now. (trust me on this...)
In addition, the particular statement you are making isn't really correct, since
the DKIM spec contains a normative directive in the matter. That's not to say
that your spec should ignore or prevent taking contingent action on a fail, but
merely that it can be navigated with different language, such as:
The DKIM specification advises against taking final filtering, actions such as
rejecting messages, based on a "fail" result, since there are legitimate reasons
a signed message might fail to verify. Per the DKIM specification such messages
SHOULD be treated as though they were not signed at all. Thus, a verifier MAY
elect to report "neutral" in place of "fail" to discourage needlessly harsh
reactions from downstream agents.
Header field removal
...
My first inclination was simply to remove the normative text and provide
discussion about both possibilities. I find myself, however, wanting to err
on the side of mistrust of the unknown, thus saying implementors at the
border SHOULD remove all of them but might have good reason to let certain
specific ones slip in
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html