Sven Anderson writes:
Stephen J. Turnbull, 11.03.2007 19:34:
Sven Anderson writes:
There is no RFC-way to set the default address for replies.
Of course there is. For authors, it's Reply-To. For lists, it's List-Post.
No, it's not. What I was referring here as the "default address" (and I hoped this was clear) was the address, which is used by the normal reply button/function of the MUA. There is no way to define a default adressee for that function, it is always hardwired to the From header, which can be overridden by a Reply-To header.
Let me note that that's false for all of the dozen or so different (Emacs-based, so not usable for the masses, but proof of concept) MUAs I've used over the last 15 years.
What you're missing is that the best-practice-based RFCs *presume* your point. *There is no way to force the recipient's MUA to do anything.* Therefore, the RFC headers under discussion are intended to provide ways for *authors* and other agents (mailing lists) to *express* their wishes. The use of Reply-munging, and even more the other changes you propose, subvert this expression, so that well-designed conforming MUAs do not (and if you remove the author's reply-to entirely, *cannot*) do what is expected by their users.
Here's a good (bad?) example:
That's why my proposal replaces the From by an author-set Reply-To whenever it is used.
Which is again a non-conforming use of the originator headers. From is *not* Reply-To, it identifies the author of the message. So you've broken Reply-To, it no longers tells where the author wants replies sent as it's supposed to. Now you break From, too! Like this:
Suppose that because I'm traveling, I set my reply-to to careof@somewhere.net. Then my headers will look like:
From: stephen@xemacs.org Sender: steve@uwakimon.sk.tsukuba.ac.jp Reply-To: careof@somewhere.net
but what you'll see is
From: careof@somewhere.net Sender: mailman-users-bounces@python.org Reply-To: mailman-users@python.org
That's *wrong*, it confuses both my faithful audience, and the killfiles of those who never want to hear from me again. Furthermore, it identifies me as being "at" an address that is evidently temporary.
You simply can't get this right. I really don't think attempts to do so should be included in the Mailman distribution at this point in time.
I don't get the point in referring to another software, while Mailman offers 95% of what that use case needs and is installed already. All these fuzzy classifications like CRM shouldn't prevent a software to cross the border, if it easily can do.
I don't want to "prevent" anything. And couldn't if I wanted to! You have the source, you can do what you want. I'm saying if you want something that violates the RFCs, use something that has no stake in being seen to be a conformant implementation of them.
I see the use case. But what I don't see is a body of experience to point out best practice. Your proposed facility will be used in contexts you don't expect, and it *will* break, in ways that you (or I!) cannot predict. I don't think it's a good idea for Mailman to accept that maintenance burden, until best practice starts to be understood.
Also, Mailman 3 will involve substantial refactoring as I understand it. It will be much more friendly to such experiments.