Re: mutt/2304: reply / group reply behavior broken WRT $reply_to and $reply_self
The following reply was made to PR mutt/2304; it has been noted by GNATS.
From: Derek Martin <code@xxxxxxxxxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc:
Subject: Re: mutt/2304: reply / group reply behavior broken WRT $reply_to and
$reply_self
Date: Wed, 19 Jul 2006 11:31:13 -0400
On Mon, Jul 17, 2006 at 05:45:02PM +0200, Thomas Roessler wrote:
> > If I can summarize very succinctly, the problem is this:
>
> > 1. The point of $reply_to is to tell mutt to either honor
> > or not honor the Reply-to header.
>
> More or less -- the actual logic is a bit more complex. e.g.,
> reply-to is completely overridden upon group-reply to a message
> with a mail-followup-to header, and some such.
Indeed, which is perfectly sensible, well documented, and as such that
case can be ignored (left alone). As my patch does... Likewise for
cases where $ignore_list_reply_to is in effect.
> More precisely, mutt will not honor a reply-to header when
> replying to messages written by oneself unless reply_self is
> set. The inference that's going on here is that the reply-to
> header is an address that points to the message's sender, so if
> the sender is removed from the recipient list, so is the
> reply-to header. Strikes me as the right thing to do.
NO NO NO NO NO! You keep saying that, but I can not emphasize enough
that reply-to IS NOT an address which is the sender. It is not
described that way in the Mutt manual, nor is it described that way in
the RFCs. In fact, RFC 822 specifically states:
The "Reply-To" field is added by the originator and serves to
direct replies, whereas the "Return-Path" field is used to
identify a path back to the originator.
It quite clearly draws a contrast between the Reply-to header and
your idea of the sender address (Return-path)... thus you have no
valid basis to make such an assumption, other than perhaps your own
opinion of how that feild should be used[*]. Nevertheless, the RFCs
dictate that it is the address to which the sender wants replies
directed. That address may or may not be the sender. There are many,
many reasons why the sender might want these to differ, and I have
already supplied several examples. Mutt can not and must not make the
assumption that the reply-to address represents the sender, as the
RFCs dictate otherwise. Given Mutt's history of near-blind adherence
to the RFCs, this should be a no-brainer.
> In any event, I'll admit that I don't have a good sense what
> I'd expect mutt to do in this particular case -- probaby
> because I've never even tried to do a non-group reply to a
> message of the kind that exhibits the behavior that you
> describe.
One case of that is broken also, though I don't recall which off hand
(but most likely group-reply when $reply_self is unset -- my earlier
posts have the details). But regardless, given the above, the
required behavior seems extremely clear-cut to me...
[Excepting the above previously mentioned cases of mailing list
reply-to and mail-followup-to...]
- honor $reply_to if it is set, unconditionally.
- honor $reply_self if it is set, unconditionally.
- which means honor both, if both are set (original sender plus
reply-to)
- Otherwise, reply to the sender if it is not oneself, and to all
other recipients if it is oneself.
In case of group-reply, additionally copy all recipients in the CC:
header, regardless of how those variables are set.
My patch does all of the above. Please apply.
-=-=-=-=-
[*] I myself used to belong to the camp who thought that Reply-to
should be used only for returning mail to the sender. However 10+
years of system administration experience have taught me that a) lots
of people use it in other ways, and b) there do happen to be very
useful ways this can be used other than to return mail to the sender.
Frankly, it almost makes me cringe that I'm arguing in favor of this,
but it seems clear that despite my inclination to reject the notion,
when approached with a mind toward reason, this is a Good Thing.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D