Dave CROCKER wrote:
Jim Fenton wrote:DKIM results I'm a little concerned about "too much information" coming from the A-R header field...we want to encourage everyone to treat messages with broken signatures as if those signatures didn't exist, neither more or less favorably than without a signature. Returning different "fail" and "neutral" results might tend to encourage people to do the opposite. I'm a little sensitive about this because I have just been working with two different domains that were rejecting messages with broken DKIM signatures, and am trying to counsel them to do otherwise.Well, yes, it's important to be careful about this. However I don't take the DKIM proscription as reaching to the point of destroying output information. This field reports output from a validation engine. That's different from its directing differential handling based on that output.
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.
Iprev It seems a little strange to me to introduce a new authentication method in the auth-results draft. If we need this, I think it should be in a separate draft/RFC. Auth-results is about representing the results of authentication, not how to authenticate.Yes, this specifies something that is an adjunct to the focus of the spec. And it's always good to question the inclusion of such material. One vote in favor can be that it facilitates adoption. In any event, this one does not seem all that risky and it hasn't bothered anybody, so I suggest leaving it alone.
Indeed, RFC2045 (MIME) also defines several things that arguably could've gone in their own specs (text/plain, base64, quoted-printable) but were included there presumably as a jump-start of sorts. I'm inclined to go with what was said elsewhere in this thread and just leave it in unless there's strong objection, especially from the IESG.
Header field removal I suggested additional text cautioning about (sec 5 paragraph 2) removing all auth-results header fields. I can picture that some users might want to trust Authentication-Results from specific domains (I might trust ietf.org, for example) especially if it was signed as described in section 8.1 #1.A MAY does not prohibit such trust. Rather, it establishes the normative point of view that retaining the file, as it crosses a trust boundary, carries danger and it really is ok to remove the sucker. Adding some text to say that it might be ok to retain it is fine, too.
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 (John Levine's example of trusting those added at his ISP comes to mind). Is the suggestion here to leave the current text in section 5, but amend it with additional language explaining that there may be legitimate reasons to leave those with foreign authserv-ids in the message as it transits inward? Or perhaps those with specific external authserv-ids? What do others think? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html