-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
However, draft-kucherawy-sender-auth-header requires that an extension
field be registered with IANA for use by any given authentication
system. The DKIM spec should register and use a "dkim" extension field.
This could be discussed in section 3.6.
The IANA considerations section needs to be updated to discuss
registering the dkim extension field in the Authentication-Results registry.
The example in section B.3 needs to be updated to use
Authentication-Results: instead of Authentication-Status:, along with
more than just XXX. An example matching the rest of the example might
look like this:
Authentication-Results: shopping.example.net
header(_dot_)dkim-signature=joe(_at_)football(_dot_)example(_dot_)com;
dkim=pass (good signature)
Tony Hansen
tony(_at_)att(_dot_)com
Earl Hood wrote:
Section 6.6 mentions that Authentication-Results: should be used to
specify the reason for authentication failure.
My question: Should there be a formal set of status codes (like SMTP
status codes or HTTP response codes) classifying verification results.
Such codes can make it easier to diagnose failures and to apply
auto-weighted filtering of mail since some failures are more
severe than others.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC19CIxsSylYhzrRYRAtLeAJ9/IAhR3rIX7doNBSGh2GcckMTQ5QCgvb8Q
l5RC20WgD/gtd4SnuHPhQls=
=kbbD
-----END PGP SIGNATURE-----