This is an old revision of the document!


This document is not a reference document and may not fully reflect the discussions that took place in ietf-dkim@mipassoc.org mailing list. Please check current IETF draft and ietf working group archive. The following document is a working document trying to have a summary of the “DKIM and mailling lists” discussion issue. You are welcome to comment or modify this document.

You may be disappointed reading such document because of a lack of any conclusion. That's the problem : no conclusion was sent. I hope next IETF meeting will help.

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.

A good overview of the LS thread was submitted by Stephen Farrell. Please read this message first. Unfortunitly this summary cover only half of the discussion, ther was a lot of comment after it was sent.

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

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 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 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.
  • dkim_and_mailing_lists.1141197252.txt.gz
  • Last modified: 2006/07/11 15:48
  • (external edit)