[mail-vet-discuss] Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard
Murray S. Kucherawy
msk at sendmail.com
Mon Dec 1 23:33:34 PST 2008
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.
>> 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?
More information about the mail-vet-discuss