On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote: > Michael B. Trausch writes: > > [This was me, stephen, but the attribution was dropped:]
The attribution was _not_ dropped, it was at the top of the message in standard inline-reply fashion. You may want to double check the message to verify that: http://www.mail-archive.com/mailman-developers% 40python.org/msg11590.html Short link to the same resource, in case of breakage: http://is.gd/4iD4o > > > The upshot is that there is no RFC-sanctioned way for a list to say > > > "please respond here", and no way at all that doesn't usurp *both* the > > > author's and the receiver's options. > > > > The best way to do this far simpler, I think: > > > > 1. Mailer software should reply to From or Reply-To as currently. > > 2. ML software should set Reply-To _UNLESS_ there was _already_ a > > Reply-To. Then, Reply-To isn't truly broken, because the author > > has control over it still, and it just defaults to the list. > > Reply-To still is truly broken. The author wants personal replies to > go to her, but now they go to the list. The recipient must > *specifically avoid reply-to-author* in order to reply to the author. > This is so Orwellian. Permit me to rephrase so that you understand what I said: There are two major uses of email, discounting automatically generated messages, corporate crap and spam: email from one person or to one person or a group of people, and email from one person to a mailing list (presumably with people on it). Whether the emails are in a personal, hobbyist, collegiate, educational, or professional context, the patterns are largely the same. In both events, 95+% of the time, there is no reply-to header attached by the authors MUA. However, the primary use-case for a mailing list is _group_ _discussion_. Or at least, so I thought. Call me silly, but if it's not meant to be group discussion as the primary role, maybe mailing lists should stop using server software and become ad-hoc, old boys' club style, personally shared and replicated distribution lists, nothing more. Being that is the case, and that is what users of mailing lists _expect_, it is reasonable to assume that the way reply-to is handled would be thus: * I send an email to the mailing list to start a thread of discussion. I send no reply-to header on the message, so the list processing software appends one redirecting replies to the group. This facilitates group discussion. It's not Orwellian, it's common sense---if, of course, we make the assumption that mailing lists are for, you know, group discussion and not private communication. If I want to communicate privately with someone, I won't be sending the mail to a mailing list; if I need to communicate with someone who is on a ML privately, and I don't have their address, that's what ML archives are for (or, sending a mail to the ML to ping them, or searching my own archives, if the public archives have that information stripped). * During the course of the thread, it becomes clear that some sensitive information must be sent (to address your use case from your Web page from earlier in this thread). That's totally not a problem: The person asking for the sensitive information simply adds a reply-to header to their outbound message. The mailing list _sees_ this reply-to header, and then refuses to replace it, transform it, or supercede it, because the rule SHOULD be "Only add a reply-to to a message if it does not have one already." I don't know if there is _any_ software that does this currently out there, but if there isn't, that's something that is at least easily fixed in any system even if it's horribly designed. It translates to nothing more than a single if statement in code. It'd be trivial for users of non-proprietary systems to adopt even if they don't want to upgrade their mailing list software. Now, there is of course an alternative mechanism that could be used to meet the same need: Have a header, say, X-List-Please-Reply-To-List, that a MUA could add in a generic fashion to all mail messages. That could signal to the list processing software, "Yes, Please, I WANT people replying to my messages to reply to the list." However, I don't see that as at all likely to occur. For me to fit into your suggested solution, I'd have to wait for both your algorithm to be ubiquitous in MUA software _and_ all mailing list software to be upgraded or replaced to make the headers it depends on to be ubiquitous. Still, to get truly sane behavior, I'd have to use Alpine. Why? The MUA _can_ do what I meant, and it can do it _easily_. There is _nothing_ that will fix the situation of no-duplicate-posts and the associated "Oops, I sent that to you and I meant to send it to the list as well," unless the MUA does one of the following (either by default, or by configuration): - Uses "reply to all" as the default behavior (config item), or - Asks you what you want to do when there are multiple recipients to the message that you're replying to (could be a sane default _and_ a config item) Alpine does the latter by default. I have used no MUA that does the former (that I am aware of; some of them perhaps did, but I've tried many and quickly fled any that are buggy in areas that I cannot fix and impact my usage patterns), and I don't know of any other ones that behave the way Alpine does. If Alpine fit better into my workflow overall, I'd use _that_ instead, solely for that single feature. Why? Because while it may not be smart enough to do what I meant for it to do, it is smart enough to recognize that fact and _ask_ what I mean for it to do. Unfortunately, most MUA software seems to take as an axiom that humans are infallible and will always do The Right Thing. Call me silly, but I have software to help me to do that in many ways; if I didn't want that, I'd type my messages directly into a socket, speak SMTP myself, and likely do so using an 8088 with DOS running a tiny network stack and with frequent calls to INT 0x21 and INT 0x60. Thankfully, that's not required, nor do I desire it. > > IOW, reply-to only makes sense in its default (none, that is, reply to > > from) in interpersonal communications or self-made "distribution lists" > > where From == To and the recipients are all Bcc'd. > > Stop deprecating use cases that you don't use. They exist, are > important to their users, and what you are advocating is tyranny of > the majority. Not on our Internet, please. I didn't deprecate _anything_. I'm going to give you the benefit of the doubt and assume that you must have had a really bad day or something.* > I have no objection to the functionality you want, but I take *strong* > exception to having the very useful Reply-To field *hijacked* so that > you don't need to wait for my proposal to be implemented.[1] > > > So, in the end, I think that the algorithm you mentioned is a good step > > in the right direction, sure. But I think the ultimate solution is even > > simpler than that: > > Except that it is *not* an ultimate solution, because the function of > the Reply-To field is lost in important cases. A new Reply-To field > that third parties are prohibited from munging would have to be > defined. Why do that when we already have one? Citation, please? I already quoted the part of RFC 2822 that shows that semantically speaking your assertion is incorrect. If there is an RFC that supersedes the definitions of RFC 2822, I'd like to see it. At present, I am not aware of one. (Further, if there is additional clarification that I've missed in my readings of RFC 2822, I'd like a pointer to that, as well; I've already read it once today, maybe I'll review it again later for things I missed in today's reading.) In my (admittedly, limited in terms of global and topical coverage) personal experience, _most_ mailing lists are poorly configured on the extreme of users not being able to specify a reply-to at all, because the reply-to is stripped and subsequently replaced by the mailing list software. Clearly, this is _bad_. Is it wrong? Not according to RFC 2822, because the mailing list processor is the logical origin of a message and thus it is clear to send the header---or not---as it sees fit. However, what sparked this thread was a practical concern regarding a very common usage pattern, not a concern that everything be 100% idealistic and precisely fit some standard as interpreted by random person X. In other words, what we're talking about is left---according to the ambiguous text in RFC 2822---as an implementation detail of mailing list processing software. > Footnotes: > [1] The problem of the wrong dupe being eliminated is *not* a problem > with Reply-To, although it may be made more frequent. It's simply the > case that if access to the List-Post field in every message is > desired, the mailing *cannot* do dupe elimination. *Not* *at* *all*. > Your use case here is broken. Badly. I never *said* it was a problem with reply-to. I _did_ say that by adopting a sane default (but able to be overrode by the sender _simply_ by using the header him/herself) value is a practical thing to do, is useful, and fits 95% of the people's workflows, 95% of the time---maybe more, maybe less, but I don't believe I'm terribly far outside of the ballpark. In _ANY_ system there is going to be exceptions, but guess what? That's because we are human, and no matter how pedantic or technical we are, we're going to screw up occasionally. If this conversation is going to degrade into slinging and retaliation based on emotion-provoking arguments instead of grounded ones, I think it's best that it stops here. If you want to talk about 1984, there's a place and time for that; if you want to overlook details, I'm sure there's one for that, too. I was talking about a practical matter, and it was just a comment (regarding my MUA, which I am _well_ aware could behave better, and I simply do _not_ have the time to make that happen right now). It wasn't supposed to blow up into a huge argument of religion and who can interpret RFCs more conservatively or liberally than the other. Have a better day tomorrow,* Mike * My wife seems to think that I come off sarcastic in those statements. In case that is how you read it, allow me to assure you, that is not my intent. -- 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
