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. 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.
There are various questions about what a LS (list server) should do with DKIM signed messages. A simple answer "keep original message unchanged" may not be a sufficient answer for various reasons :
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 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 discussionthat could be read first. Unfortunately this summary covers only half of the discussion, there were lots of comments after it was sent
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?
It seems there is an agreement that the original DKIM signature should be removed.
Should the LS sign the message ? Not sure !
This is a short description of the development planned in Sympa project for DKIM support. Many question are still open and every point may be discussed with the DDX group.
I love the following sentence that John Levine published in a post post about mailing lists and DKIM in his blog :
"One thing I can definitely promise is that people will have religious beliefs as deep and irrational as the ones they have about Reply-To: headers, so no matter what you do, you can be sure that someone will tell you that you are an idiot for not doing it his way." |
---|
We will focus on :
Sympa apply 3 different authentication levels for incoming messages.
Sympa could apply *basic authentication* if the incoming message includes a valid DKIM signature and :
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.
Sympa DKIM signature verification module could add a new variable to its Message object so as to tell if the DKIM signature is present or not, verified success fully or not and says if the signer entity :
Sympa could use those message properties within its authorization scenario mecanism.
Could Sympa use DKIM signature in order to reject or drop unwanted messages? This depends on the SSP (Sender Signing Policy) information about the domain. As long as SSP is a draft it is difficult to decide what to do with it. Anyhow, if the SSP requires a valid signature for the domain of the sender, Sympa could drop or reject incoming message that do not satisfy it .
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 should allow to specify :
3 possibilities :
What ever solution is choseen, 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.