Ticket #2934 (new defect)

Opened 16 months ago

Last modified 16 months ago

does not honor Reply-To when replying to message from self

Reported by: adeodato Owned by: mutt-dev
Priority: minor Milestone:
Component: mutt Version:
Keywords: Cc: 433829-submitter@…

Description

This comes from http://bugs.debian.org/433829.

When replying to a message sent by yourself, Mutt does not honor the Reply-To header, and sends the reply to the original recipients instead (as per $reply_self=no). This is coming from the assumption that the address found in te Reply-To header would be an alternate address of yourself, and hence should not receive the reply.

However, it may as well be the case that the address in the Reply-To header is some other address, or one's address plus some other address. While I'll agree that (r)eplying to Reply-To instead of recipient on self messages can be discussed (please make a decision nonetheless), I strongly believe that it should be included when (g)roup-replying.

In other words, please include non-self addresses from Reply-To when (g)roup-replying a message from self, and either do the same when (r)eplaying, or state that as WONTFIX.

Thanks in advance.

Attachments

part0001.pgp (189 bytes) - added by Derek Martin 16 months ago.
Added by email2trac

Change History

Changed 16 months ago by Lars Hecking

Mutt writes:
> #2934: does not honor Reply-To when replying to message from self
 
 Is this related to

   http://marc.info/?t=118173738800002&r=1&w=2

 by any chance?

Changed 16 months ago by Adeodato Simó

* Mutt [Thu, 19 Jul 2007 20:09:14 -0000]:

>   Is this related to

>     http://marc.info/?t=118173738800002&r=1&w=2

Yeah, seems the same, and the same as #2304.

Changed 16 months ago by Derek Martin

On Thu, Jul 19, 2007 at 07:23:42PM -0000, Mutt wrote:
>  When replying to a message sent by yourself, Mutt does not honor the
>  Reply-To header, and sends the reply to the original recipients instead
>  (as per $reply_self=no). This is coming from the assumption that the
>  address found in te Reply-To header would be an alternate address of
>  yourself, and hence should not receive the reply.

It seems obvious to me that if you've bothered to set a reply-to
header on your messages, you want all replies to go to that address,
including replies from yourself...  But one or two people complained
about that idea when I raised it before.

>  However, it may as well be the case that the address in the Reply-To
>  header is some other address, or one's address plus some other address.
>  While I'll agree that (r)eplying to Reply-To instead of recipient on
>  self messages can be discussed (please make a decision nonetheless), I
>  strongly believe that it should be included when (g)roup-replying.

I agree completely, and I think even the (r)eply case is an easy fix.
Just check whether the addresses in Reply-To: match alternates, and
remove the ones that match (assuming you've configured mutt not to reply
to yourself).  If you're left with an empty list (Reply-To can contain
multiple e-mail addresses), then use the original recipients instead.

Alternately, if you find a match to alternates, you could just always
copy the original recipients, in addition to whatever addresses didn't
match alternates.  I think this behavior is kind of stupid, but it may
be what some people want, and it eliminates a special case.  I suppose
it's easier to remove addresses which Mutt added, than it would be to
add addresses it decided not to add (particularly if they are not
addresses you have in your address book).

Changed 16 months ago by Derek Martin

Added by email2trac

Changed 16 months ago by Paul Walker

On Thu, Jul 19, 2007 at 05:42:38PM -0400, Derek Martin wrote:

> It seems obvious to me that if you've bothered to set a reply-to
> header on your messages, you want all replies to go to that address,
> including replies from yourself...  But one or two people complained

Really? I'd have said it was equally obvious that I'd want it to go to the
same set of people as the original email, since it would presumably be a
follow-up to that.

One of those things, I guess. :-)
Note: See TracTickets for help on using tickets.