Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On Sep 14, 2013, at 5:16 PM, Stephen J. Turnbull step...@xemacs.org wrote: Franck Martin writes: Unfortunately z= and especially l= are not used practically by senders because they create a risk. One could add an attachment containing malware to the message for instance. Indeed, we have to assume that the MUAs are broken in this respect. See Daniel Gillmor's posts on the problems MUAs have with indicating which parts of a message are signed MIME parts in the testing MUAs thread. The basic state of the art seems to be that MUAs can't handle anything safely except a signature that applies to the whole message. I'm not sure if DKIM was ever meant to be exposed to the end user, but the current trend is to try to protect the end user as much as possible and this is done best by MTAs than MUAs. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
When a list goes bad, usually the members are not blamed but the list admin, therefore making the list the system responsible of the writing of the message. Anyhow, it does not matter, this is a religious discussion. Please feel free to code and test your solution of encapsulating the message in a mime rfc822. This seems an interesting and good alternative. I'd like to see it in practice so we can compare data. On Sep 14, 2013, at 1:27 AM, Stephen J. Turnbull step...@xemacs.org wrote: Franck Martin writes: One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly. Nonsense. Here's what RFC 5322 says: The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The list obviously isn't responsible for the writing of the message body, and you could argue that in adding header/footer and munging attachments and Subject field it's acting as the agent of the author, who is therefore responsible for them too.[1] If that's not convincing, ask any of your users if they think the list is an author of their posts, or anybody else's. OTOH, if you want to make an authorship claim validly, there's an easy way to accomplish it: encapsulate the whole thing in message/rfc822. Steve Footnotes: [1] Note that RFC 5322's phrasing also clearly refutes the same argument when made for Reply-To. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: When a list goes bad, usually the members are not blamed but the list admin, therefore making the list the system responsible of the writing of the message. Please stop being evasive. The RFC's use of responsible is intended to point to the person who wanted the content of the message injected into the email system. You know that, I know that, and you're just looking for an excuse to let your patch escape from its responsibility for undermining the standards on which electronic mail is founded. Anyhow, it does not matter, this is a religious discussion. Religious maybe, but it does matter. Open source lives and dies by open standards. Microsoft can (and does) get away with ignoring standards if they think that will enable them to destroy the competition by making non-Microsoft software inable to interoperate with Microsoft's. (Consider the number of complaints we get about Outlook's brain-damaged handling of the Sender field.) Let's *not* do it to ourselves *if we can avoid it*. Maybe we can't avoid it, but we really ought to try. Please feel free to code and test your solution of encapsulating the message in a mime rfc822. This seems an interesting and good alternative. I'd like to see it in practice so we can compare data. Without funding, I probably can't do it soon. My GSoC student Abhilash might be willing to do it after GSoC though. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
Franck Martin writes: I'm not sure if DKIM was ever meant to be exposed to the end user, but the current trend is to try to protect the end user as much as possible and this is done best by MTAs than MUAs. I disagree fundamentally. It's best done by *both* MTAs and MUAs. Not all threats attack you from the outside, nor can MTAs stop everything that comes at them without help. That's why mail services provide spam folders to quarantine suspect mail. I agree that altogether too many MUA authors agree with you, so we can't expect much good to happen if we try to do things that depend on capable MUAs. That doesn't mean we shouldn't lobby for better MUAs. MUAs have the advantage of interacting with the user, and they can take advantage of the user's knowledge and intuition. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/14/2013 11:18 PM, Franck Martin wrote: this is a religious discussion. Religious or not, it is controversial, and this discussion has raised valid points. Because the issue remains controversial, I will soon release 2.1.16 final with the feature disabled by default, and will consider the message encapsulation approach or other possibilities based on experience with 2.1.16 for a 2.1.17 release perhaps early next year. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
