Murray S. Kucherawy wrote:
For my A-R reporting if there an explicit DKIM=UNKNOWN record, I took
this declaration to mean the domain only allows it to sign sometimes
and no one else.
That's not what RFC5617 says.
Meaning: No valid Author Domain Signature was found on the message
and the published ADSP was "unknown".
Can't that be read as meaning a non-Author Domain Signature was not
expected.
Authentication-Results: dkim.winserver.com;
dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org
(unauthorized signer);
The "(unauthorized signer)" was added because it was an explicit
DKIM=UKKNOWN DNS record declaration.
Reporting a "fail" against "dkim=unknown" is technically impossible.
I don't quite read it that way Murry. But it says No Author Domain
Signature, it would be a failed. See below why I used "adsp=" instead.
You should use "unknown". See Section 5.4.
Also, it should be "dkim-adsp", not "adsp". See Section 5.3.
If there was no ADSP record, the adsp= info would look like this:
adsp=none author.d=tana.it signer.d=mipassoc.org;
"none" doesn't appear in the registry.
I am also reporting ADSP/ATPS/ASL reporting and wanted to fold it into
one line. The "adsp=" tag is for handler PASS|FAIL|NONE status for our
internal MAIL API consumption only. I needed a different simpler
namespace to not step over the two line dkim-adsp, dkim-atps.
adsp=<HANDLER status> [policy=<explicit-dkim=value>] ....
Anyway. My Reading is:
No DNS record - no consideration for ADSP whatsoever. No (NONE)
assumptions can be made, so you can't default
to an "UNKNOWN" because it was known to the
author and verifier - it wasn't defined (NONE)
DKIM=UNKNOWN - it describes it as an optional expectation
and its defines it as Author Domain, not
just any signature.
To me, there is diagnostic value between a real no signature (NONE)
and an invalid one (FAIL). I don't wish to combine those as UNKNOWN.
In short the combinations of inputs and outputs allows for all states
to exist.
Note, these are all part of the semantics ambiguities discussed in the
past regarding ADSP. I hope we can fix it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html