Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DKIM will benefit to internet users if most emails are signed using DKIM. Many of the emails everyone received are comming from LS (List Server), that's why we propose DDX group to experiment DKIM on LS. Experimentation would start with the specification for a  reasonnable implementation.  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 into Sympa, but first, we must discuss the way LS should use DKIM and agree on a set of specifications for Sympa LS.

This document is intended to explain the issues and discuss them.

DKIM and MLM general issues

...

  • One of the initial goal is to be able to check the message origin against white list, black list or reputation services. This requires message origin verification, that's why a signing technology is needed. In the LS case, the LS reputation could be checked, not only the original sender reputation.
  • Most of existing LS modify some parts of the distributed messages and alter the original DKIM signature thereby. It is not the goal of the DKIM WG to specify what kind of message modification is unwanted or not. There is an agreement that we don't expect LS implementations to give away message customization ; they are related to features of interest for LS users.

Wiki MarkupThe 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 are a lot of discussion about LS, unfortunetly thre a poor number of conclusions.    One of the threads can introduce you to the question to solve. It's quite old (2006) but stll up to date. Stephen Farrell submitted an overview of the discussion that could be read first. A \[\[[an overview of the discussion|http://mipassoc. org/pipermail/ietf-dkim/2006q1/001839.html]. Unfortunately this summary covers only half of the discussion, there were lots of comments after it was sent :-( (sad)

Simple LS

Sometimes LS do not modify a message before it is distributed, so the initial DKIM signature is preserved. This depends on each LS software  but also on the initial message : if the initial signature included SMTP headers fields that were modified by the LS (Return-Path, List-id, etc). Even when it is feasible to preserve the initial DKIM message signature, some says it's better to remove it because spreading the signature may ease the replay attack.

...

Most LS modify messages in some way : summary of modification made by LS
The open issue is : what to do when a message is modified before it is distributed?
There It seems to be there is an agreement that the original DKIM signature should be removed.

Should the LS sign the message ? Not sure !

...

Broadcast messages to subscribers

3 possibilities :

  1. configure each robot to sign all list outgoing messages

...

  1. : Sympa could then be used with or without DKIM activation. This is the very minimum requirement.
  2. 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 messages is strict (for exemple newsletter) and not for lists that are open forums.

...

  1. 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
  2. Same as solution 2 but in addition, for each message, the "authorization scenario" could be use in ordre to decide if DKIM signature should be apply or not before broadcasting message. The goal would

...

  1. be to sign messages that have been validated by the list moderator or messages that have been authenticated

...

  1. and not to sign others. This may not be compatible with the SSP for the LS domain.

What ever solution is choseen, the

We will probably provide configuration parameters for each list, with a default that can be inherited by the virtual host setup or the global setup.

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.

Solution 3 seems pretty and should not be too deficult to introduce into Sympa code but is that choice the good one ? It may be a bit complicated for many listmasters. Choice 1 is really simple and provide a great advantage : only one policy for all outgoing message of a LS.