On Mon, 18 Jul 2005, Arvel Hathcock wrote:
Its pretty useful to be able to sign Authentication-Results ...
That can't be done. This header is subject to stripping
I predict "fun time" running this "stripping" by ietf-smtp and ietf-822 folks
(especialy as Authentication-Results is defined similar to trace fields)...
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.
ReturnPath is supposed to be MDA-added header field and there supposed
to be only one MDA that delivered email. That means that for email that
is subject to normal delivery on the internet, there should be no ReturnPath
header field and its only ok for LMTP or for POP3/IMAP email retrieval.
This is not the same for Authentication-Results as for debugging I would
find it useful to have Authentication-Results header field present which
was added by another server in email path (I would not trust it, but that
is another matter).
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.
How do you deal with Sender? How about From, Reply-To, To?
No suggest that they should change, but no suggestion oterwise either and
you probably can guess what will happen if your email had Sender in it...