here's finally my next proposal for a less broken but yet very useful
Non-technical users (generally) love defaults. They don't wanna have to
choose between three different kind of reply buttons. And no-way they want
to change their MUA they just got painfully used to (or even their mail
address, as most of them are using webmail providers), just because of a
stupid mailing list. So there's a user base who are mostly using webmailers
and Outlook, and who just want to press "Reply" as they usually do, no
matter if there is even a "Reply-To-All" button right next to it.
Although this is a big pain for us geeks, I think a great software like
Mailman should offer options (not default behavior) to serve such a user
base. That's why I think, that Mailman should offer an option to set the
default behavior of the standard reply button. The question what the default
behavior of the reply button should be has to be discussed in each lists
user base, Mailman should offer the choice. Many list admins are very
thankful, if they don't have to educate their users.
- Proposed solution
There is no RFC-way to set the default address for replies. The Reply-To
header _replaces_ the From address in replies, which is something else than
setting a default. That's why setting the Reply-To completely hides the From
address (regarding replies) and therefore abusing it as a default breaks the
reply-to-all function for instance, as it doesn't include the From address
neither (which is correct, as long as the Reply-To address is an
_replacement_ for the From address). Since there is no other way but to
abuse the Reply-To header to control the default reply behavior,
reply-to-munging has to take care of the From address too.
There are four possible default reply targets that I consider as useful and
should be offered at least as a list-wide option. (If individual mails are
sent out, like with VERP, a per-user option is the best of course.)
3. All recipients and author
4. Explicit address
And this is, what I propose that Mailman should do in these cases:
ad 1) Author is the "default default target" ;-). So no munging needed at
all, no problems.
ad 2) If Reply-To is already set, it is removed. Reply-To is set to the
lists address. The old Reply-To or - if not existing - the From address is
checked if it is a list member. If not, it is added as a "fake Cc" to the Cc
header, in order to make the reply-to-all function work.
ad 3) If Reply-To is already set, it is removed. Reply-To is set to:
- the lists address,
- all addresses in To/Cc headers, that are no list members, and
- the old Reply-To or - if not existing - the From address, if not a list
ad 4) If Reply-To is already set, it is removed. Reply-To is set to the
explicit address. The old Reply-To or - if not existing - the From address
is checked if it is a list member. If not, it is added as a "fake Cc" to the
Cc header, in order to make the reply-to-all function work.
Of course, with option 2-4 you still lose the reply-to-author function, but
at least for 2 and 4 in exchange for a new function, which a standard MUA
with just a reply and reply-to-all button doesn't offer.
Example: Me and two colleagues are the management board of a local radio
station. We use Mailman as a "Deluxe-Alias" for both communication among us
and as Alias for people who want to contact us. So a lot of mails on this
list come from non-members. In these cases I either want to answer only to
the list (my colleagues) or to the author and the list, but _never_ to the
author alone. So it's obvious that in this case we would like to have the
reply button going to the list, and reply-to-all going to all (including the
author, what at the moment doesn't work). We want the default going to the
list, not only because of our MUAs (Thunderbird, Mutt, Webmailer) only Mutt
supports reply-to-list, but also because we want the default reply to be the
least dangerous, which in our case is the list. Funnily enough, the mutt
user wants the most, that the normal reply is going to the list. ;-)
I hope I could make clear my ideas and point of view.