On Thursday 01 October 2009 00:08:24 Serge Aumont wrote:
Thanks for all your answers.
thank you for asking and careful consideration.
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.
acknowledged. despite it limiting the ADSP=ALL usefulness.
Those modifications are requested by users.
meeting user demand is core business.
There is a strong social pressure to add a footer in
all messages that include a "one click unsubscription link" .
well signers could use a body length tag in the signature, however like most
options, its more work for implementers and administrators.
Of course
that's because MUA does not recognize the List-Unsubscribe: header, but we
can't change this.
Can only request features and hope for a cleaner future.
https://bugzilla.mozilla.org/show_bug.cgi?id=29041 (or just wait)
I don't think it is acceptable to rewrite the From: . This hypothese can't
be generalized to any mailing list server.
I'm not sure what you mean '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.
Those that change and update will reduce burden on receivers maintaining
whitelists of trusted third party dkim signatures or senders. Those receivers
then can place stricter ADSP=all filtering rules in place.
So "discardable is not compatible with domains that may use mailing list
located outside.
good to have that clarified (as least for me - others seemed to have grasped
that already)
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.
have you decided what to do with:
signature=invalid,adsp=unknown?
signature=invalid,adsp=all?
my preference is reject as I don't expect the input to a maillist to have
broken signatures. Don't know if this is suitable for all. Consider it at
least as the default option.
(may be used to prevent backscattering when sending
automatic answers
Giving the list-owner the chance of reducing the rules going to request_auth
for subscribers is a good thing.
if dkim can be included in the default scenarios it would save breakage when
dkim_feature is turned on(I assume).
As long as there is no default scenario lines with true()...dkim... -> do_it
it should be fairly anitspam safe and putting some scenario documentation on
the dangers of this configuration would be good (aka dkim spammers welcome).
maybe even only process ' true()...dkim... -> do_it' rules in scenarios if '
'true()...smtp... -> do_it' also exists.
or may be use to trust the From: before accepting message).
i'm not sure I understand the 'before accepting message' part and how that
effects processing.
Sign automatic answers (welcome message etc) and digest messages with it's
own signature For messages broadcasted to subscribers :
great!
test if the signature is still valid after message processing, remove the
DKIM-Signature if not.
this was the mailman approach. It was the easiest solution with receivers
rejecting failing signatures.
its consistent with http://tools.ietf.org/html/draft-ietf-dkim-deployment-08
8.4
add a Sender: listname-request(_at_)domaine header
Not quite the same as what rfc5322 says but not totally incompatible either.
I curious as to the purpose of this? To support a third party signing policy?
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.
I'm not sure there should be a condition. Just sign all messages.
http://tools.ietf.org/html/draft-ietf-dkim-deployment-08 5.5
It gives downstream verifiers a nice field to whitelist on.
test incoming ADSP and reject "discardable" messages if the list is not
configured to preserve incoming signature (even if the signature is valid)
quick thought - low priority
send a warning to the subscriber on subscription attempts that:
1. have a ADSP discardable policy
2. on lists that will not preserver signatures
3. where the subscriber will have permission to post
add a new list option that globally hide the following features which
usually breaks DKIM-Signature : subject tag,
(cut)
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
;-)
yay - /me does a happy dance. Thank you. I'm sure others will find this useful
too.
Thank you Serge,
--
Daniel Black
Infrastructure Administrator
CAcert
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev