[ietf-dkim] Mailing lists as 2822-Sender

[Hector Santos]

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