...
DKIM will benefit to internet users if most emails are signed using DKIM. Many of the emails everyone received are comming coming from LS (List Server), that's why we propose DDX group to experiment DKIM on LS. Naturally, Sympa LS software which is used by internet2 should be the LS used for this. Sympa author's team (CRU) will introduce DKIM technologie technologies into Sympa, but first, we must discuss the way LS should use DKIM and agree on a set of specifications for Sympa LS.
...
The goal is to specify a clear way for a LS to implement DKIM and tell in which situations a List Server MAY/MUST/SHOULD remove an existing DKIM signature and add its own signature. ietf-dkim mailing list archive can help. Thre There are a lot of discussion about LS, unfortunetly thre unfortunately there is a poor number of conclusions. One of the threads can introduce you to the question to solve. It's quite old (2006) but stll still up to date. Stephen Farrell submitted an overview of the discussion that could be read first. Unfortunately this summary covers only half of the discussion, there were lots of comments after it was sent 
...
- From: is part of signed headers
- the optionnal optional "'i=" tag ((identity of the user or agent on behalf of which this message is signed)) from '"DKIM-Signature:" header is present
- "i='"tag value match the "From:" including the local part of the adressaddress.
the description of "i=" tag in RFC 4871 (page 21) includes an informative discussion section that recommends to strictly limit this usage. In addition, we doubt that the optional "i=" tag is used many users overall with a local part.
...
In a virtual host based configuration, Sympa should be able to sign each automatic answer, notification and alarm that are issued by Sympa himself. In such case the configuation configuration should allow to specify :
...
- configure each robot to sign all list outgoing messages : Sympa could then be used with or without DKIM activation. This is the very minimum requirement.
- configure each list to sign all outgoing messages or not : this could be used in order to apply signature for lists where the control of broadcasted broad casted messages is strict (for exemple example newsletter) and not for lists that are open forums. The signature parameters including private key and selector could be defined list by list. In that solution the configuration parameters will be defined for each list, with a default that can be inherited by the virtual host setup or the global setup
- Same as solution 2 but in addition, for each message, the "authorization scenario" could be use in ordre order to decide if DKIM signature should be apply or not before broadcasting message. The goal would be to sign messages that have been validated by the list moderator or messages that have been authenticated and not to sign others. This may not be compatible with the SSP for the LS domain.
What ever solution is choseenchosen, the configuration will allow the same level of parameters as for service messages. The recommendation should be to use "i=listname-request@robot.domain" when broadcasting message to subscribers.
...