Michael Thomas writes: > I'm not saying I think that resigning is a Bad Thing, I'm saying that it's > speculative whether it's a Good Thing. You seem to keep ignoring the > inherent attack involved with resigning:
Have you actually read my posts, or just enough to feel defensive? I have specifically referred many times to the user-list trust relationship implicit in a double-opt-in list. I have provided examples of how the receiving system can acquire information about such relationships, as well as acknowledging that getting such information is a nontrivial problem in the context of busy admins and slow implementation cycles. The standard specifies that whether to trust a signature is a local policy decision. It seems to me that Mailman's decisions about whether to put signing and verification capabilities into Mailman itself will depend on the developers' estimate of whether list signatures will be trusted in those local policies. It seems to me that Mailman's decisions about how to default the signature-stripping functionality depend on our estimate of whether broken signatures will be given negative weight compared to no signature. My position is that Mailman lists[1] SHOULD participate in the DKIM protocol, because I think that if Mailman lists are important to users, they will respond to DKIM-related obstruction of their traffic by demanding that their MTAs trust their Mailman lists. If that's a PITA for the admins, too bad---that's the flip side of the admin benefits that come with use of DKIM to filter spam. And of course admins and MUA developers *will* develop trust management tools. Maybe you have less confidence in your vendors, of course---I *know* mine will rise to the occasion. So far, you talk out of both sides of your mouth. On the one hand, you fault my proposal because of the attacks inherent in trusting any old re-signature; on the other, you claim that you don't have trust in anybody's signature, and you don't even treat your own specially! Elsewhere you have implied that for you verification == trust if "From == signing domain". Just generalize that to include "List-Id == signing domain" in the policy agent software! And "Sender == signing domain". Users need never know that the "sender" who was verified is not the >From header. Why not recommend that UIs SHOULD treat *any* of the three conditions above as "sender verified", until experience shows that's a bad idea? I suspect that naive users will happily accept it if policy agents tell them "sender was verified, so we present you with this mail for your consideration." They may misconceive that the >From header was verified, but why should that matter? If it *does* matter to them (eg, because they know that "Mom would never send me porn spam"), then here's the recommended UI for spam discards when the sender has been verified as a mailing list: Treat similar messages as spam? [[yes]] [no] Note: this message was verified to have been relayed by the Mailman Developers mailing list at python.org, which accepts responsibility for relaying it to you. ( ) I am not a member of this list. Treat messages from this list as spam in the future. (o) I am a member of this list. Carefully scan messages from this list in the future. Something similar could be recommended for other cases where the verified sender is in a different domain from "From" (as I am, for example). Isn't that the way it's supposed to work? Do you really think that users will care as long as you explain that they're not blacklisting their mothers, and the spammer does get blacklisted? Footnotes: [1] Whether Mailman itself should be a signer or verifier is another question; I'm agnostic on that. _______________________________________________ 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