Barry Warsaw writes: > Me too. Here's my discussion on the topic, including a concrete > proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the > wiki on in this thread.
I'll try to post to the wiki later (I'm not a member yet and I'm suffering mail delays---I expect I'll need to do an email confirm), but assuming "on" should be "or" I'll reply here first. In "Problems with Mailman signing headers" you write that a Mailman signature could potentially "legitimize otherwise illegitimate message". Technically, this is confusing language. "Legitimate" is a local policy decision and will surely vary from site to site. I would prefer that this kind of idea be expressed as "result in recipients accepting spam and undesired messages that they otherwise would reject." You suggest as a solution not signing gated messages. This has its own problems, specifically that (1) the list is deliberately not signing some of its output, which will cost the host site the advantages of the claim that all of its mail is signed, and (2) many sites that know that this list signs, and will drop all unsigned posts. I think a plausible alternative strategy would be to sign Usenet-gated posts with a different key. I don't think this is generally going to be more than minor extra effort, as any decent signing agent will be prepared to deal with selectors. (I suppose this is mandated by DKIM, but I haven't checked.) In "Proposal", the language for 2.1.9 is excellent. For 2.2/3.0, I think that all RFC 2369 headers must be signed to prevent phishing attacks. Sender should be signed for Mailman's own potential benefit, I think, and of course DKIM itself mandates signing From. The discussion of the DKIM status header should note that DKIM does not even suggest a format for these headers, so they will be implementation-dependent. I think a call for Mailman advocates to participate in specification of a standard header, as well as to help with implementations' headers in the meantime, may be warranted. Regarding the call for verifiers to "look favorably on" verified list signatures, I'm of two minds. Technically, I think it's a bug in the DKIM spec that it doesn't thoroughly distinguish between verifiers and policy agents (not to mention that it fails to mention the role of policy agents for the signing decision at all!) So I don't like language that suggests that verifiers make policy decisions. There's planty of precedent for it in the latest draft, though. :-( I think that language to the effect that verifiers MAY make extra effort to find a valid list signature in the case where broken signatures are found is definitely appropriate, though. As Michael has repeatedly emphasized, very little is known about the pragmatics of re-signing. Nonetheless, I think that a better way to try to accomplish this is to have a Mailman implementation that wants to take responsibility for broken signatures is to sign those signatures. (Remember, it can also create another signature without signing them. Then the signature signature might fail due to an intermediary reordering DKIM signatures, but the signature of the mail itself would succeed.) Then the BCP for policy agents could say that the presence of a broken signature which is nonetheless verified by a valid signature SHOULD be considered an indication that the verified signer verified the broken signatures on the way in, and that the verified signer then broke them. (This doesn't mean that a policy agent should trust the broken signature. That depends on how much it trusts the verified signer.) I think your current language is a non-starter without signing the signatures. It's an obvious veector for reply attacks. _______________________________________________ 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
