Mark Martinec 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.
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 ...
and RFC 2822 only allows one instance of a Sender header field.
Note that it is a SHOULD not a MUST.
Hmmmm, I seem to recall a discussion and consensus that signatures
should not include headers likely to change.
Yes, see 5.4. Determine the Header Fields to Sign
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
sign is non-obvious. One strategy is to sign all existing, non-
repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver.
It is indicated as one possible strategy and it is prudent this logic
must be part of new DKIM systems signing configuration options.
The long time reality is such it is long established Mail List Servers
(MLS) may strip/replace a Sender header. It just is. Therefore new
systems need to fit with the process. Originating DKIM signature signing
systems MUST be aware of where its signed mail is going, especially if
it is expected to be re-distributed.
> It would be nice to have a clear guideline on what a mailing list
> should do with a Sender, and/or a guideline that DKIM should not sign
> the Sender field if message is intended for posting.
I would be willing to volunteer to write a I-D of BCP on this or at
least put the initial considerations together. I provided many
considerations for interfacing a MLS with DKIM/SSP. In my (now expired)
DSAP I-D, I had this written:
3.3. Mailing List Servers
Mailing List Servers (MLS) applications who are compliant
with DKIM and DSAP operations, SHOULD adhere to the following
guidelines:
Subscription Controls
MLS subscription processes should perform a DSAP check to
determine if a subscribing email domain DSAP policy is
restrictive in regards to mail integrity changes or
3rd party signatures. The MLS SHOULD only allow original
domain policies who allow 3rd party signatures.
Message Content Integrity Change
List Servers which will alter the message content SHOULD
only do so for original domains with optional DKIM
signing practices and it should remove the original
signature if present. If the List Server is not going
to alter the message, it SHOULD NOT remove the signature,
if present.
So, MLS systems can adapt, but the original systems also need to take
into account where they are sending mail too. Signing headers that are
very likely to change is just not a smart idea for DKIM signers.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html