On Wed, 2009-10-14 at 08:41 -0400, Barry Warsaw wrote: > On Oct 14, 2009, at 4:19 AM, Michael B. Trausch wrote: > > > * MLs that require "reply all" instead, and instead of sending _one_ > > message in threading context, send N number of messages where N is > > however many people are listed in various headers. > > This is not a bug in mailing list software, it's a bug in the MUAs. > Despite, as Stephen says, *decades* of complaints such as this, very > few MUAs support the mailing list RFCs that have exists for at least a > dozen years. Fix the MUAs first please.
As I mentioned in the post you replied to, this is impossible because the List-* headers won't be received at all in many normal operating circumstances. > It's actually easy too. An MUA need only recognize List-Post and add > a Reply to List button which would strip all the recipients and put > the List-Post value in the To header. Problem solved. And therein lies the rub. There are several ways to make the system work more deterministically overall (the list style that seems to be on the side opposite me here is _rarely_ deterministic, though it often kind of works). There are means by which accidental leakage can be avoided on lists that use the Reply-To header as I have already suggested, while not breaking what a non-technical end-user perceives to be expected behavior. I'm talking about user experience as it pertains to mailing lists and everything that there is to them. I cannot consistently reply without making something incorrect, nor can I consistently filter mailing list posts, because when posts arrive without a header to filter on (as is the case when I recieve someone's reply directly, and not from the mailing list) the filter breaks. Such breakage should be the exception, not the rule. Furthermore, such breakage cannot be fixed in a system where there isn't a single component to be fixed. Suggesting that this can be done MUA-side fails to address several issues that I raised in the post that you replied to that are programmatically impossible to solve consistently. I was unaware of RFC 5322's clarifications. That does change what I understand to be current standard a bit, but it does not change what I think is proper behavior in terms of how users interact with mailing lists. While both approaches can have inconsistencies about them, there are less of them in a system that uses reply-to with a sane default and does things like I discussed in the parent of your reply, and if any of the mechanisms were adopted that would virtually kill the "Oh, I posted stuff I shouldn't have" problem. I can think of many situations where it'd also be beneficial---say, in a flamefest, where someone sends off a message that they wished they could take back (impossible normally), or accidentally press Send by accident before finishing message composition (such as I did earlier in this thread), or in those few minutes just after someone hits Send and goes "Oh, I _really_ oughtn't to have done that." It is technically possible to solve these problems. What I don't understand is why there seems to be a large active disinterest in doing so. The mechanisms I mentioned earlier would all solve those problems for all but a very small subset of users---it'd fix the mailing list "user interface" for more users than the current methods do. Again, I think that _what is_ is being ignored for what is perceived to be _what ought to be_. I'm more interested in the practical concerns at play. Though, it seems that doesn't matter. That said, if mailing list software _did_ choose to modify/remove/replace/append to the reply-to header (mere creation of the header is _not_ munging) it's entirely possible that the ML software could be configured to handle such things gracefully. If the mailing list posts always go through the ML server, it _is_ possible to fix nearly every imaginable use-case, but for that to work, there would have to be some level of interest. IMHO, it's more important to Just Work regardless of what sort of MUA the user has than it is to be pedantic and play the blame game. If there is a technical solution that can be reliably implemented in an MUA-independent fashion that doesn't depend on any of the things I mentioned in this post's grandparent, I'd be interested in going after it. However, programmatically speaking, I don't see it being possible without saying, "MUAs, these are the standards that you must adhere to," in a separate standards document, describing exactly what sort of behavior is expected to make things transparent and just work, and also sending duplicate messages such that MUA software can recognize the duplicate and show them as a single message. I think that trying to fix it in the currently apparently accepted architecture, though, is terribly much more complex than it needs to be. What I am proposing is that depending on the MUA to be anything more than a program to send and receive messages is fundamentally flawed, and it doesn't fit in with the UNIX philosophy of program design. The job of managing the mailing list should be on the mailing list management software, no part of it should depend on the MUA. The MUA _should_ be able to provide help in doing so, but everything that the MUA is capable of doing automagically for its users should also be able to be done without depending on the MUA for extra help, in such a way that even very ancient MUA software that still exists out there (albeit in very rare usage) can provide the functionality, using nothing but messages to manage the flow of things. Maybe what I need to do to really show what I'm talking about is to create an implementation that does what I am talking about so that it can be looked at and discussed? --- Mike -- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/ “The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” —Michelangelo _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://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: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9