You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Mailing lists and DKIM

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.

DKIM and MLM general issues

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 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.

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 discussion that could be read first. A [[an overview of the discussion. Unfortunately this summary covers only half of the discussion, there were lots of comments after it was sent

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.

LS modifying messages

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 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 Sender Signing Policy (SSP) of the sender : the SSP must be checked before applying a signature at the LS level because the SSP may forbid third party DKIM signature.  In such case the message should be rejected (not because the original signature is altered but because the message can't be distributed according to the SSP). Have a look at Hector Santos position.
  • but remember the initial goal : be able to check LS origin against 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." Other contributors agreed with him, proposing various solutions that do not sign the message itself but just sign a part of it with the semantic that proves which service did forward the message. This seems a good solution for any forwarder but I could not identify a conclusion.
  • No labels