Launchpad mailing list Reply-to should reply to list not sender

[Nizar Kerkeni]

When sending a replay to an email from a launchpad mailing list, the replay is by default to the last sender. It should be by default to the mailing list.
I'm an administrator of a team on launchpad and I cant find such option to configure the mailing list.

[Barry Warsaw (barry)]

Reply-To munging is generally a bad idea. Launchpad doesn't, and shouldn't support this.

http://www.unicom.com/pw/reply-to-harmful.html

[Karl Fogel (kfogel)]

This is an old and controversial idea. Personally, I think it's not a good idea to munge Reply-to: it can cause private mails to accidentally be sent to a public list. That is a very bad failure mode!

The two canonical documents on this topic are:

 "Leave Reply-to Alone", by Chip Rosenthal
 http://www.unicom.com/pw/reply-to-harmful.html

and

 "Set Reply-to to list" by Simon Hill
  http://www.metasystema.net/essays/reply-to.mhtml

IMHO, the way to implement this is as a per-subscriber feature, with the default being to leave Reply-to alone. (http://producingoss.com/en/mailing-lists.html#reply-fantasies)

Closing as "Won't fix", but someone else can re-open if they think it needs more consideration...

Best,
-Karl

[Nizar Kerkeni (nizarus)]

Any discussion in mailing list is by default for all subscribers. So when one need a private replay, here he can change the replay-to address.
In all cases why not giving the choice to the mailing list administrator as it's the case for lists.ubuntu.com.

[Karl Fogel (kfogel)]

Please read the document we referenced (http://www.unicom.com/pw/reply-to-harmful.htm). It answers your exact questions.

[Karl Fogel (kfogel)]

Sorry, paste error. That's: http://www.unicom.com/pw/reply-to-harmful.html

[Cristian Gafton (gafton)]

Just because it is harmful (or has the potential to be disastrous) sometimes it doesn't mean that's _always_ the case. Rather than sit in the middle of the controversy, being forced to take one side, why don't you offer a choice and let the users fight it out?...

[Barry Warsaw (barry)]

Because it will be a war that will never end. The real fix is to improve mail clients so that they understand long standard List-* headers and make it easy for their users to do the right thing.

It's true that Reply-To munging may be useful for some lists, but the use cases are *very* limited, such as an announce-only list that redirects to a discussion list. Launchpad's mailing lists are primarily intended for discussion lists, and reply-to munging is generally not appropriate in those cases.

[Cristian Gafton (gafton)]

I fail to see how this will turn into a neverending war if you let the
users make their own choices. Especially since these are discussion
lists, and the reply-to header encourages discussions to be kept public
instead of being taken private by hitting the regular reply in most
email clients.

The very fact that you are still trying to educate users that "what you
want is wrong" proves my point - you'd have much more free time if you
didn't have to play referee every time this issue comes up.

--
Cristian Gafton <email address hidden>
Canonical USA

[Matthew Paul Thomas (mpt)]

Cristian, even if the Launchpad developers introduced an option, they'd still need to choose a default, and then people would argue about what the default should be in exactly the same way as they currently argue what the behavior should be. More complex code, negligible benefit.

Besides, making it a per-user option would be a granularity error. It would make private replies extremely difficult, but whether a reply should be private or public depends much more on the message than on the sender.

[Cristian Gafton (gafton)]

> Cristian, even if the Launchpad developers introduced an option, they'd
> still need to choose a default, and then people would argue about what
> the default should be in exactly the same way as they currently argue
> what the behavior should be. More complex code, negligible benefit.

I don't think so. Currently you are completely taking away the choice. I'm
trying to point out that there are legitimate cases and groups of
developers, topics of discussion, things that are debated that could
benefit from a "by default we talk in public" setting. You can always
explain to me taking the conservative route for the default setting, but
that will never be equivalent to not having a choice at all...

> Besides, making it a per-user option would be a granularity error.

I don't think it should be per user, it should be a property of
the community/project.

Even as I agree generally with the "reply-to is harmful" sentiment, the
lack of a choice and the enforcement of that singular point of view I find
troubling.

[Fabien Chéreau (xalioth)]

I know many people refuse to allow to munge Reply-to, however I and my co-developer don't care: we simply liked it that way (we always worked that way on our previous mailing list).
If an admin could change this for our mailing list (<email address hidden>) we would be all VERY grateful. Otherwise we will move back to sourceforge.
Thanks,
Fabien

[Karl Fogel (kfogel)]

1) @Cristian Gafton in comment #10: I think making it a per-user option *is* the right granularity, ultimately. It's the user who will be harmed if they send a private mail to a public place, more than anyone else. We can choose the "safe" default, and users who prefer the "more collaborative but somewhat less safe" option can just choose that and affect no one but themselves.

2) Launchpad is open source now. If someone wanted to hack this up, they'd find many willing mentors in the Launchpad development community! Please see https://dev.launchpad.net/ for more information on how to participate.

3) @Fabien Chéreau in comment #11: Don't move back to SourceForge -- improve Launchpad instead! :-) (Yes, I realize that's ignoring the actual work involved, which I don't mean to minimize, but it's a serious invitation.)

[Karl Fogel (kfogel)]

Fabien, also: is it that hard for people to just use "Follow up to all" in their mailreaders when that's their intention?

[Barry Warsaw (barry)]

So, while I'm still against any kind of reply-to munging, I'll say the following for the benefit of anybody who wants to hack on this.

The essential handling of the Reply-To header is in Mailman, so the easiest route to take would be to expose the 3 or so options that Mailman has to control this in the Launchpad web interface. That would actually not be that hard to do, but it would mean that munging is at the granularity of the mailing list. Mailman 2 does not and will not support per-user reply-to munging.

Note that the reason reply-to munging is in Mailman at all is to appease the vocal community who really want this. Oh and to support the very limited set of legitimate (IMHO) use cases.

If you want per-user reply-to munging your task is harder. Launchpad uses stock upstream Mailman, with a set of monkeypatches to communicate with Launchpad over XMLRPC. Your challenge then would be to implement the per-user reply-to munging policy in a monkeypatch, and then expose that in a natural way in the Launchpad user interface, probably on ~person/+editemails. I think this will be tricky.

Eventually, Launchpad will be integrated with Mailman 3, and if you really want per-user reply-to munging, that's where your efforts should go. If you decide to help with this, please engage with <email address hidden>. It's a controversial topic, well mined in the Mailman community, so our guidance over there is your best bet for success. I won't say it's /likely/ to make it in, but I won't completely discount the possibility here.

Hope that helps!

[SirVer (sirver)]

I won't work on this in launchpad, but the widelands team is used to reply-to munging and liked it so far. We'd also appreciate an option to turn it on. +1 for the per mailinglist option

[Jeremy Nickurak (nickurak)]

"Reply-To munging does not benefit the user with a reasonable mailer. People want to munge Reply-To headers to make "reply back to the list" easy. But it already is easy. Reasonable mail programs have two separate "reply" commands: one that replies directly to the author of a message, and another that replies to the author plus all of the list recipients. Even the lowly Berkeley Mail command has had this for about a decade."

- This doesn't actually apply in most mailing lists. The normal mailing list behavior is NOT to include the author in the reply, since they'll already get a copy of it via the mailing list.

"If you use a reasonable mailer, Reply-To munging does not provide any new functionality. It, in fact, decreases functionality. Reply-To munging destroys the "reply-to-author" capability. Munging makes this command act effectively the same as the "reply-to-group" function. We haven't added anything new, we've only taken away. Reply-To munging is not merely benign, it is harmful. It renders a useful mail capability inoperative."

- Not really, you can always reply to the author. Sane mail clients make it easy to fill that address in, either from past history with completion, or by selecting who you want to reply to from a list.

"If the Reply-To is munged by the mailing list, the value provided by the original sender is lost. Reply-To munging can make it impossible to reach the sender of a message."

- No, if you're replying to a message on a mailing list, the author's email is there in the From: field. You can get it just fine.

In general, this "considered harmful" document misses the most common case: replying only to the mailing list. That is quite difficult to do without Reply-To.

The "Principle of Least Surprise" dictates that a reply to an ongoing thread should be attached to that thread. That the thread is a shared mailing-list makes no difference. Without reply-to, the default behavior is to take a message off-list, or CC everyone involved, causing many extra copies that most people seem to find annoying.

This happens regularly on the ayatanna list, where threads diverge for a large number of messages before anyone even realises they're not on the mailing list any more.

"Guess what feature more and more people are asking for? A third reply command -- one that ignores any existing Reply-To header!"
- That's fine. The default shouldn't be to reply "to the author" but "to the message". If you want to get away from that default, and relpy in private to the author, that's a very different and non-normal behavior than replying to a thread on a mailing list.

I'd suggest this get reopened.

[Barry Warsaw (barry)]

On May 27, 2010, at 10:06 PM, Jeremy Nickurak wrote:

>In general, this "considered harmful" document misses the most common
>case: replying only to the mailing list. That is quite difficult to do
>without Reply-To.

It's actually quite easy to do without munging Reply-To. If you have a mailer
that supports RFC 2369 - which became a standard in *1998* - then your mailer
has a "reply-to-mailing-list" button that fills the To field of the reply with
the value of the List-Post field of the original message.

For example, Claws does this and it works beautifully. Replies go to the list
and only to the list, and there are no duplicates.

>I'd suggest this get reopened.

I respectfully disagree.

-Barry

[Jeremy Nickurak (nickurak)]

On Thu, May 27, 2010 at 18:08, Barry Warsaw <email address hidden> wrote:

> It's actually quite easy to do without munging Reply-To. If you have a
> mailer
> that supports RFC 2369 - which became a standard in *1998* - then your
> mailer
> has a "reply-to-mailing-list" button that fills the To field of the reply
> with
> the value of the List-Post field of the original message.
>

Ubuntu's default mail client (Evolution) lacks this on the toolbar, although
there's an entry for it buried under a menu.

Again, the common case is wrong.

Launchpad bugs, btw, handle this sensibly, with a reply-to on bug mail, so
follow-up messages sent by mail (like this one) go to the bug tracker,
instead of to you. That's where the conversation is, and that's where the
common-case reply should go. Now, you can make an argument that *every
single mail client in the world* should be updated, but given how long
evolution's gone with this being broken, I'd argue the right option is just
to have the messages specify where mail goes.

--
Jeremy Nickurak -= Email/XMPP: <email address hidden> =-

[Jeremy Nickurak (nickurak)]

A useful reading from the other side: http://marc.merlins.org/netrants/reply-to-useful.html

[Karl Fogel (kfogel)]

Jeremy, that's actually the same document I linked to in comment #2 :-).