>> LISTSERV now offers DK support.
>
> Can you summarise what it does?
If anyone is interested, our MTA also includes a list exploder that has
had to deal with this issue for a year now (starting with DK and now
with DKIM). I'm hoping that the collective wisdom on this list can
eventually give us a BCP as I'm certain that I've gotten it wrong here.
Currently, I've taken the easy road (I guess) and the software will
resign all list submissions on the theory "you break it, you sign it"
and my list exploder always "breaks it". I've experimented in the field
(200 test customers) with stripping and leaving existing signatures in
list messages. There were no technical problems either way that I
recall. Due to an increase in queries regarding the presence of
multiple signatures in the message I elected to make this an optional
behavior and defaulted the software to strip.
It's been suggested that we recommend list vendors refrain from any
modification of validly signed submissions (this was the thin model if
memory serves?). Although there's nothing wrong with this as an option
and I would be willing to implement it - I don't think it would get much
actual use in the field because I believe users want a visual indication
in the inbox of list versus regular traffic. Modifications to the
subject are often the only way this is achieved. Secondly, it's been my
experience that MUA filtering is mostly done on the content of the
subject line. It would be nice if the List-ID were used for that
purpose but that header isn't typically visible and so users don't
always know to use it. So, the subject is normally what they use.
I would love to eventually see us figure out what the best practices for
list servers are and recommend those in some documented fashion.
--
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html