I raised the idea of having status codes so results can
be more granular, allowing for better decision making
processes downstream.
Sounds good.
What has not be discussed is what about multiple
signatures. Are there multiple result fields?
Multiple AR's are not needed to document multiple signature validation
attempts. I concatenate each signature authentication result into a single
AR like this:
Authentication-Results: r2d2.altn.com
[EMAIL PROTECTED]; domainkeys=pass (good); dkim=pass (1:0:good;
2:-1:SIGNATURE_BAD_BUT_TESTING; 3:-2:DNS_FAILURE)
There is more defining we need to do here, yes. Currently, we all document
the result in an AR header but each implementation so far provides a varying
and non-standard degree of information on each result. In other words, we
all get the 'dkim=pass/fail' part right but the bit in ( and ) chars is
optional and varies wildly. DKIM could recommend a standardized format for
that bit.
I agree this will need work if it gets included in the charter. I think it
should be included because:
(a) We need to document DKIM results if there is to be any filtering later
on by other processing modules (be they an MUA someday 100 years from now or
a heuristic filtering agent).
(b) This I-D has no other home and it needs our help (not a compelling
reason on it's face but we seem to need it also).
What about attempts to spoof the result fields? If a DKIM
verifier sees a results field, should it remove it to avoid
spoof attempts?
It can't be spoofed if you follow the spec closely. There's good security
for this header there IMO and I've been using it for a long time now in my
commercial MTA.
A verifier may want to sign the results field, allowing for
downstream verifiers to verify the integrity of the validation.
The possibility of this header being stripped is a necessary component of
it's anti-spoofing provision. So, since it has the potential to be
stripped, I personally don't sign it ever.
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org