On Tue, 04 Dec 2007 19:32:26 -0000, Mark Martinec
<Mark(_dot_)Martinec+dkim(_at_)ijs(_dot_)si> wrote:
I'm observing regular cases of originator signature breakage
by mailing lists which DO NOT modify mail body or header in
intrusive ways. This happens every time the poster included
a Sender header field in its original posting, and then sign it.
A mailing list which replaces the original Sender by its own
causes a signature breakage, quite unnecessarily.
But if RFC 2822 is followed, then Sender SHOULD NOT be present unles there
are explicit reasons for doing so. The usual examples given are:
1. The secretary is sending on behalf of her boss
2. There are multiple entries in the From (in which case the Sender MUST
be included).
Neither of those commonly arises in mailing lists.
In the few cases where an already signed Sender arrives at a mailing list,
then the mailing list should do the same as if it makes any other change
which invalidates the signature. My preference for that situation is for
the mailing list to:
1. Check the existing signature (and maybe reject outright if it is
'suspicious').
2. Record his (hopefully correct) check result in an
Authentication-Results header.
3. Re-sign the message, including that new Authentication-Results header.
Unfortunately the RFC 4871 wants a Sender signed:
The following header fields SHOULD be included in the signature,
if they are present in the message being signed:
o From (REQUIRED in all signatures)
o Sender, Reply-To ...
Yes, but I would be inclined to modify that by only signing it where it
was NOT identical to the From (i.e. in the secretary and multiple Froms
cases above).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html