Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dkim_and_mailing_lists [2009/03/09 15:45]
serge.aumont@cru.fr
dkim_and_mailing_lists [2009/03/13 10:35] (current)
serge.aumont@cru.fr
Line 1: Line 1:
- +This page is now part of [[https://spaces.internet2.edu/display/ddx/Mailing+lists+and+DKIM|internet 2 DDX wiki]]
- +
- +
- +
-====== DKIM and MLM general issues ====== +
- +
- +
-On this topic John Levine produce [[http://​weblog.johnlevine.com/​Email/​dkimlists.html|a nice billet about DKIM and mailing list]]. We love this sentence : +
- +
-<note idea> +
-"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." extracted from John Levine blog (([[http://​weblog.johnlevine.com/​Email/​dkimlists.html|a nice billet about DKIM and mailing list]])) +
-</​note>​ +
-  +
-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 : +
-  * 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. 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.  +
- +
-The goal is to specify a clear way for a LS to implement DKIM. In which case it MAY/​MUST/​SHOULD remove the existing DKIM signature and add its own signature. +
- +
-[[http://mipassoc.org/​pipermail/​ietf-dkim/​2006q1/​001839.html|good overview of the LS thread]] was submitted by Stephen Farrell. **Please read this message first. ** Unfortunately this summary cover only half of the discussion, there was a lot of comment after it was sent. +
- +
-===== Simple LS  ===== +
- +
-In some cases LS do not modify the message before distributing it, so the initial DKIM signature is preserved. This depends on each LS but also on the initial message : if the initial signature may include some headers that must be modified by the LS (Return-Path,​ List-id, etc). **Even, when it is possible to preserve the initial signature some says it's better to remove it because disseminating the signature may ease the replay attack** +
- +
-===== LS modifying messages ===== +
- +
-Most LS modify messages in some way : [[http://mipassoc.org/pipermail/​ietf-dkim/​2006q1/​001853.html|summary of modification made by LS]].  +
- +
-The open issue is what to do when a message is modified before it is distributed ? +
- +
-There seems to be an agreement that the original ​DKIM signature should be removed. Should the LS sign the message ? Not sure ! +
-  * it may depend on the DKIM SSP of the sender : the Sender Signing Policy should be checked before applying a signature at the LS level. The SSP may desallow third party signature. ​ In such case the message could be rejected (not because the original signature is altered but because the message can't be distributed according to the SSP). HAve a look to [[http://​mipassoc.org/​pipermail/​ietf-dkim/​2006q1/​001774.html|Hector Santos position]].   +
-  * but remember the initial goal : be able to //check LS origin agains reputation services// . +
-  * There is still an open issue about the semantic of a signature added by a LS. Wietse Venema says //"I am concerned that the FROM: address is becoming a conceptual bottle neck, and would like to see a solution that allows mailing lists and other forwarders to sign mail ("as I forwarded this") without implied claims about the authenticity of the FROM:  address. That is, the possibility of a mailing list etc. DKIM signature that just authenticates the list or forwarder."//​ Some others guys agree with him proposing various solution that do not sign the message itself but just sign a part of it with the semantic that prove which service did forward the message. This seems a good solution for any forwarder but I could not identify a conclusion. +
- +
-====== Sympa and DKIM ====== +
- +
-This is a short description of the development planned in Sympa project for DKIM support. We will focus on : +
-  * How existing DKIM signature can be tested for incomming messages +
-  * Should Sympa sign outgoing services messages (welcome message etc) +
-  * Should Sympa sign messages brodcasted to list subscribers +
- +
- +
-===== Reception message ===== +
- +
-Sympa apply 3 different authentication level for incomming messages. +
-  * **signed messages** : applied to message with a valid S/MIME Signature (or PGP should be possible too) +
-  * **basic authentication** : applied if an email challenge or a password have been used  +
-  * **smtp authentication** : this is not really an authentication,​ sympa just trust the ''​From:''​ header.  +
- +
-== Using DKIM in order to trust From: header == +
-  +
-Sympa could apply **basic authentication** if the incoming message include a valid DKIL signature and : +
-  * ''​From:''​ is part of signed headers +
-  * the optionnal ''​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 adress. +
- +
-<note warning>​ +
-the description of ''​i=''​ tag in RFC 4871 (page 21) include a informative discussion section that recommend to strictly limit this usage. in addition we doubt that that the optional ''​i=''​ tag is used many users overall with a local part. +
-</​note>​ +
- +
-Sympa DKIM signature verification module could add a new var to the object message so specify if the DKIM signature is present or not, verified sucess fully or not and says if the signer entity  +
-  * is an authorized third party signer +
-  * match the sender domain +
-  * match sender address including local part +
- +
-Sympa could use those message properties in authorization scenario. +
- +
-== Using DKIM in order to reject some unwanted messages == +
- +
-Could Sympa use DKIM signature in order to reject or drop unwanted messages ? This depend 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 SSP require a valid signature for the domain of the sender, Sympa could drop or reject incoming message that do not satisfy it . +
- +
-===== sending sympa service messages ===== +
- +
-On a robot 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 : +
-  * if this category of messages message must be signed or not +
-  * the ''​d=''​ tag, default match the robot name +
-  * the private key file location (no default) +
-  * the selector to be used (no default) +
-  * the ''​i=''​ optional tag (default none) +
-  * the list of headers to signed with reasonable defaults : From, subject, date, To, Message-Id, In-Reply-to,​ ... +
-   +
- +
-===== broadcast messages to subscribers ===== +
-  +
- 3 possibilities :  +
-  * configure each robot to sign all list outgoing messages or not : 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 messages is strict (for exemple newsletter) and not for list that are open forum. +
-  * configure each list "​scenario send" in order to apply or not DKIM signature when is to be distributed ​ (the goal could be to sign messages that have been validated by the list editor or messages that have been authenticated with an email challenge.) This would be a bit complicated for most postmaster and may be not used in a nice way. +
- +
-We will probably decide a configuration for each list with a default that can be inherited by the robot config or the global installation. +
- +
-The config will allow the same level of parameters as for service messages. the recommendation should be to use "​i=listname-request@robot.domain"​ +
- +
  • dkim_and_mailing_lists.1236609927.txt.gz
  • Last modified: 2009/03/09 15:45
  • by serge.aumont@cru.fr