Barry Warsaw wrote:
>> This is not the spec -- and it's not been widely vetted.
>
> Fair enough; it's also out of date as Stephen pointed out. Still, it
> does indicate that the DKIM authors acknowledge that there are
> compatibility issues with mailing lists. The updated section 4 that
> Stephen posted seems to be moving toward resolving those issues.
I'm afraid that there's not much consensus on how to deal with the
mailing list issue; the people who say "resign" are guessing as there
is little/no evidence that resigning is actually a viable strategy. In fact,
up until I found that your new version removed signatures I had pretty
much figured that this was a tempest in a teapot because the vast majority
of first party DKIM signatures pass verification through lists in an actual
large deployment.
Let me float this though: how about a "signature friendly" knob that
configures the list to not do things that are known to be harmful to
signatures (including s/mime and pgp for that matter). I don't think
this needs to be _especially_ complicated, but it would probably need
to be fleshed out.
>
> I really want to see the spec address mailing list issues in a
> thorough way, with clear instructions on what such remailers must and
> should do. Then we can say "Mailman is broken wrt to the spec" or
> "Mailman complies with the spec" or "Can someone please contribute
> code to comply with the spec" or "the spec is broken, we don't agree
> with it, so we won't support it and everyone should abandon Mailman" :).
I think it would actually work a lot better the other way: with real life
experience and real life running code we can make a much better case
for what constitutes a best common practice. Part of the problem right
now is that a lot of the speculation is just that.
>>
>> The bottom line here is that you are removing signatures that are not
>> broken. In fact, you don't even check to see if they're broken at all.
>> That's bad all around.
>
> We're removing signature that we know nothing about. As I said, IWBNI
> we had code that could check DKIM signatures and sign messages. So a
> question to ask, in the face of no available code to do the verifying
> or signing, is it better to possibly break signatures because of
> Mailman transformations or better to not have a signature at all. And
> why?
Do you remove PGP ascii armor just on the offhand chance that you might
destroy a PGP signature with some configurations of mailman? By removing
signatures you go from having about a 99% success rate to a 0% success
rate.
You don't have to have 100% success rate with filters to bias them to do the
right thing, but removing signatures makes it stand out for the *lack*
of its
signature, especially given filters trained on signing all of their
mail. As I
mentioned, we are planning to annotate messages that don't verify from our
domain. With this change there will be a lot more people getting useless
false positives. Is that of no consequence?
But let's turn this around: why do you think practice is helpful? I really
don't understand the motivation at all. Destroying information -- especially
when you're charged with forensic exercises like spam filters are -- is
*rarely* the right thing to do. It seems to me that the burden of proof
should be on why removing them is the right thing, not the other way
around.
Mike
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
