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.
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.
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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html