[ietf-dkim] Authentication-Results: Header

[Arvel Hathcock]

> 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.from=foo at bar.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