Advanced Reply-To-Munging
Hi all,
here's finally my next proposal for a less broken but yet very useful reply-to-munging:
- Motivation
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.)
- Author
- List
- All recipients and author
- 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 member
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.
Cheers,
Sven
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. There is nothing that says the MUA can't offer other choices; just the that MUA should offer the address list in Reply-To to the user by default because *that's what the author is explicitly requesting*.
The fact that the MUAs used by the mob don't offer other choices is a completely different issue.
ad 2) If Reply-To is already set, it is removed.
That's definitely a violation of the RFC. The author has explicitly requested delivery of responses to that address, and this proposal prevents it from working correctly.
Reply-To, like the other headers, accepts multiple addresses. The list's address should be added in this case, and users who bitch should be told that it's required by "the rules" since it was already present.
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.
This is insufficient. Somebody who actually sets Reply-To to an address that's on the list in a post to the list clearly Really Means It. It's not my place to explain why; you should ask *them*.
Your assumption is that such users don't exist on the list in question, at least not in numbers large enough to matter. Why not let them have their way?
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.
It's not a new function, it's a new bug. Much of the specification for MUAs is in RFC 2822, including the use of the Reply-To function. Your proposal prevents conforming MUAs from performing the function that their users ask of them.
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. ;-)
This is a valid use case, but not for Mailman as currently designed. What you want is customer relations management software. If you really want this, then you can write a custom handler for it. It should not be provided with software intended for general use in discussion lists on the Internet IMO.
Hi Stephen,
thank you for reading and commenting my proposal.
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. That's something different, as the Reply-To overrides the From for _any_ reply function, that is also the reply-to-all function for instance. There is no RFC way to replace the
From address only in the "normal" reply, but not in any other reply functions.
The fact that the MUAs used by the mob don't offer other choices is a completely different issue.
You complained, that I don't care what my users want, and at the same time you call them "mob"? ;-)
ad 2) If Reply-To is already set, it is removed.
That's definitely a violation of the RFC. The author has explicitly requested delivery of responses to that address, and this proposal prevents it from working correctly.
I don't agree. Reply-To tells, which address you should use _if_ you want to contact that user. Reply-To is not meant to force you to _whom_ you want to reply to. That's why my proposal replaces the From by an author-set Reply-To whenever it is used.
Reply-To, like the other headers, accepts multiple addresses. The list's address should be added in this case, and users who bitch should be told that it's required by "the rules" since it was already present.
Which rule? A list processor is not an MTA. And don't forget, we are talking about an _option_. List admins, who want to treat their users like this, don't have to (and won't) switch on reply-to-munging.
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.
This is insufficient. Somebody who actually sets Reply-To to an address that's on the list in a post to the list clearly Really Means It. It's not my place to explain why; you should ask *them*.
Your assumption is that such users don't exist on the list in question, at least not in numbers large enough to matter. Why not let them have their way?
A user sending a mail to a list processor cannot expect, that his headers will be kept in any case. A list processor is munging anyway in many aspects. The only clean solution here (also in respect to digital signatures for instance) would be to nest the complete email including headers into a new email. Then you have to levels of headers, and everything is kept.
I think the interests of the users to have a mailing list, which behaves like they think it's the most practical way, outweigh the interest of single users, who are not happy, that their Reply-To is touched. And I bet, that the latter is not true for most users, who set the Reply-To, as my proposal regards their Reply-To in the way it is usually meant.
And again, it's an option. Let the list admins choose.
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.
It's not a new function, it's a new bug. Much of the specification for MUAs is in RFC 2822, including the use of the Reply-To function. Your proposal prevents conforming MUAs from performing the function that their users ask of them.
No. The users didn't ask for "if the receiving users presses 'Reply', the mail should go to whatever I put into Reply-To". They ask: "If you want to reach me, don't use the From address, use the Reply-To instead." And this is done by my proposal.
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. ;-)
This is a valid use case, but not for Mailman as currently designed. What you want is customer relations management software. If you really want this, then you can write a custom handler for it. It should not be provided with software intended for general use in discussion lists on the Internet IMO.
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.
Regards,
Sven
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.
Hi Stephen,
Stephen J. Turnbull, 15.03.2007 17:19:
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.
Just a short pre-answer to that point, because you got it wrong:
Of course it's wrong. I don't propose that. Sorry, my quoted sentence above was not clear enough, please stick to the proposal I made.
Assuming you chose the option "reply to list" (option 2) according to my proposal, the headers would look like:
From: stephen@xemacs.org Sender: steve@uwakimon.sk.tsukuba.ac.jp Reply-To: mailman-users@python.org Cc: careof@somewhere.net (added to existing Cc:, but only if careof@somewhere.net is not a member of mailman-users@python.org)
I don't see how this additional Cc: can be more dangerous, than what Mailman is doing right now. The opposite is true, it fixes the reply-to-all function, because the answer would also go to careof@somewhere.net, what you explicitly requested by your Reply-To.
All my proposal is about, is bringing the reply-to-munging closer to the RFC _and_ usability than it is now.
Reply-to-munging _is_ heavily used in existing Mailman installations. Why not fix it then?
Regards,
Sven
-- http://sven.anderson.de "Believe those who are seeking the truth. tel: +49-551-9969285 Doubt those who find it." mobile: +49-179-4939223 (André Gide)
Sven Anderson writes:
All my proposal is about, is bringing the reply-to-munging closer to the RFC _and_ usability than it is now.
Well, there is a difference of opinion about this, but my opinion is that Reply-To munging is absolutely broken vis-a-vis the RFC: it's an originator header, and unless the mailing list can claim to be the author (eg, announce list or digest), the mailing list should never touch it.
Whether you can get an effective reply-to-all is a separate question.
Reply-to-munging _is_ heavily used in existing Mailman installations. Why not fix it then?
Even the reply-to -> cc proposal isn't a fix, at least in the sense above.
And whether it makes things more usable, especially for the maintainers and list admins, is an open question, until it's tried in practice. Among other things, the behavior becomes more complicated, varying across lists. Consider our disagreement about whether Mailman removes subscribed addresses from the CC, the ease of confusing the no-dupes option with not-metoo, and the frequent confusion between Mailman's no-dupes and Gmail's behavior with respect to reflection of own posts by mailing lists.
There's such a thing as being too smart for your own good, and I think it's very easy to cross that line here.
participants (2)
-
Stephen J. Turnbull -
Sven Anderson