Re: Mutt group reply

[Rich Felker <dalias@libc.org>]

On Tue, Jul 15, 2014 at 09:27:09AM -0500, Rob Landley wrote:
> On 07/13/14 22:51, Rich Felker wrote:
> > On Mon, Jul 14, 2014 at 12:58:59AM +0400, Solar Designer wrote:
> >> On Sun, Jul 13, 2014 at 07:59:04PM +0100, Laurent Bercot wrote:
> >>> On 13/07/2014 17:34, Solar Designer wrote:
> >>>
> >>>> An alternative is to reconfigure the list so that it doesn't set the
> >>>> Reply-To header, but this may result in many replies being inadvertently
> >>>> sent off-list.  I think it's better for Mutt users to adopt a habit to
> >>>> answer that question with "n".
> > 
> > Thanks! I had been looking for a solution to this issue for a long
> > time but didn't bother to really look into it.
> 
> Thunderbird's "reply all" will _only_ reply to the reply-to, and I wind
> up manually copying in individual email addresses to cc: when I bother.
> (Yes, it has a 'reply list' button, but the reply-to header overrides
> the difference.)

Reply-to headers should not override the 'reply to all' feature in a
mail client. If they do, this is a bug. What use is 'reply to all' if
it behaves the same as plain 'reply'?

> So it breaks other mail clients too. Largely because reply-to seems to
> be used so seldom, and thus isn't particularly debugged. (This is the
> only list I've followed in the past 5 years at least that uses reply-to.)

In lists I've been active on, I've seen both approaches. oss-security
and all the mplayer and ffmpeg lists are other examples that use(d)
Reply-to. Busybox and uclibc and libc-alpha (glibc) are some that
don't. I can use both (especially now that I found a good solution for
avoiding messing up replies myself) but I pretty strongly prefer the
use of Reply-to, because it tends to avoid having people accidentally
reply off-list and losing the continuity of threads on the list. And
since it's easy to detect Reply-to generated by the list (e.g. just
look for the To and Reply-to addresses matching), any good client
should be able to override this default for power users who really
want to override it.

Rich