In <42D7D089(_dot_)7020702(_at_)att(_dot_)com> Tony Hansen
<tony(_at_)att(_dot_)com> writes:
Yes, the interaction between DKIM's results and the
Authentication-Results: header need to be better defined.
Earl mentions status codes. Don't you think the "pass" / "fail" /
"softfail" / "neutral" / "temperror" / "permerror" set defined in
draft-kucherawy-sender-auth-header are sufficient? If not, how and where
would you expand on those statuses?
I'm not sure if those result codes are sufficient or not. That
depends on what the DKIM spec ends up defining, I think.
From what I can tell, draft-kucherawy-sender-auth-header attempts to
define a generic header for various email authentication systems. If
so, I somewhat question the wisdom of doing so. The definitions for
such terms as "pass" in the sender-auth-header I-D do not match those
definitions in the SPF-classic spec, and if I understand the folks in
the CSV camp correctly, an SPF "Pass" is not the same as a CSV
"Pass". Ditto for PGP results, or MTAMark results.
So, I think it would be a bad idea to use a Authentication-Result:
header for SPF, CSV, PGP or MTAMark. It could be used for DKIM if we
wanted to match up the semantics with those in sender-auth-header or
vice versa. I guess if DKIM wanted to match the semantics defined by
SPF and the sender-auth-header I-D was updated, that would be ok, but
I suspect that the natural semantics of a DKIM result will not fit
perfectly with the semantics of SPF.
Another approach would be for the sender-auth-header I-D to make the
terms like "softfail" specific to the authorization/authentication
system, but then you would lose most of the advantages of having a
generic header. Likewise, sender-auth-header could define the terms
so broadly that the cover many all possible systems, but I don't think
that would be very useful either.
Personally, I suspect that DKIM would be best off defining a new
header that is designed for DKIM.
-wayne