Thanks for all your answers.
I agree with John Levine comment on his paper (
http://weblog.johnlevine.com/Email/threemyths.html
). He is true telling that mailing list software will still continue to
modify messages they broadcast in a way that may break signatures.
Those modifications are requested by users. There is a strong social
pressure to add a footer in all messages that
include a "one click unsubscription link" . Of course that's because
MUA does not recognize the List-Unsubscribe: header, but we can't
change this.
I don't think it is acceptable to rewrite the From: . This hypothese
can't be generalized to any mailing list server. Don't imagine that
all mailing list software will change and all users will update there
server. So "discardable is not compatible with domains that may use
mailing list located outside.
Here is what Sympa 6.1b already does with DKIM signature. Any comment
is welcome.
- Verify any incoming signature. Use this result in order to decide
what to do with the message. (may be used to prevent backscattering
when sending automatic answers or may be use to trust the From: before
accepting a message).
- Sign automatic answers (welcome message etc) and digest messages
with it's own signature
- For messages broadcasted to subscribers :
- test if the signature is still valid after message processing,
remove the DKIM-Signature if not.
- add a Sender: listname-request(_at_)domaine header
- sign the message if some conditions are verified. Example if a
email challenge was confirm to prove the validity of the
"From:". The conditions where Sympa add a signature can be tuned for
each
lists. It should not be the same for a news-letter or a open discussion
forum.
Here is what Sympa will do in a near future.
- test incoming ADSP and reject "discardable" messages if the list
is not
configured to preserve incoming signature (even if the signature is
valid)
- add a new list option that globally hide the following features
which
usually breaks DKIM-Signature :
- subject tag,
- add or remove headers that may be part of the signature,
- message footer insert
- some subscriber reception options ("urlize" that replace
attachement by a link to the server, for example)
- message content personalization depending
on each subscriber attributes.
This option will force preservation of DKIM-Signature but I don't think
we will use it for our own service. Daniel, we will develop it just for
you ;-)
Serge
|
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev