ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Authentication-Results: Header

2005-08-17 15:42:51
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
header(_dot_)from=foo(_at_)bar(_dot_)com; 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

<Prev in Thread] Current Thread [Next in Thread>