Further to this, I like the existing language:
Signers SHOULD NOT sign an existing header field likely to be legitimately
modified or removed in transit. In particular, RFC 2821 explicitly permits
modification or removal of the "Return-Path" header field in transit.
... and don't think we should try and innumerate _all_ the specific headers
which SHOULD NOT be signed but a reference to excluding X- and
Authentication-Results might be welcome here. Anyway, I can see the need
for a BCP document on DKIM in the coming months with the results of all our
findings in this area.
--
Arvel
----- Original Message -----
From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
To: <ietf-mailsig(_at_)imc(_dot_)org>
Sent: Monday, July 18, 2005 7:02 PM
Subject: Re: DKIM - Header Fields
Its pretty useful to be able to sign Authentication-Results ...
That can't be done. This header is subject to stripping and if it gets
signed and later stripped it ruins the signature. So, this one must not
be signed. It would also be useful to sign the Return-Path header I guess
but this also can't be signed because it is subject to stripping as well.
Basically, any header in which it's own specification mandates or even
suggests with a "MAY" that a change or removal might occur - these must
not be included in a signature IMO. MDaemon doesn't sign any X-* header,
Return-Path, or Authentication-Results for this reason.
--
Arvel