ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Mailing lists as 2822-Sender

2007-12-04 17:01:20
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