Closed Bug 77304 Opened 23 years ago Closed 8 years ago

Cannot reply to From: when Reply-To: field appears in header (handle reply-to munging on mailing lists)

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 50.0

People

(Reporter: richip, Assigned: mkmelin)

References

Details

Attachments

(1 file, 1 obsolete file)

bug77304_reply_to_unmung.patch
7.34 KB, patch
jorgk-bmo
: review+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.8.1+) Gecko/20010423
BuildID:    2001042323

In a mail containing both a Reply-To: and From: header entries, replies cannot
be made to address in From: field. Dunno if this is a bug or an actual mail
specification

Reproducible: Always
Steps to Reproduce:
1.Send an e-mail to oneself with a Reply-To: field
2.Reply to it (using Reply All)
3.
From RFC 822 (STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES), which can
be found at, say http://web.mit.edu/rfc/rfc822.txt:

 4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO

        For systems which automatically  generate  address  lists  for
        replies to messages, the following recommendations are made:

         If the "Reply-To" field exists, then the reply  should
         go to the addresses indicated in that field and not to
         the address(es) indicated in the "From" field.

         If there is a "From" field, but no  "Reply-To"  field,
         the  reply should be sent to the address(es) indicated
         in the "From" field.

Marking invalid.  We are doing exactly what we are supposed to be.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
marking verified (invalid)
Status: RESOLVED → VERIFIED
I want to reopen this bug.  I really think Mozilla should provide an option to
reply to the From: even when there's a different Reply-To:.  The RFC you quote
says that the current behavior is only a recommendation, not a hard rule.

I subscribe to mailing lists that set the group as the Reply-To field, which
means all replies go to the mailing list, no matter what.  I used to use the
MR/2 email client which gave me a choice of sending replies to Reply-To: or to
From:, and this is a very useful feature.  If Mozilla supported it, then I could
send my replies either to the entire group, or to the original sender.

I don't understand why Mozilla should restrict me like this.
RFC822 is obsoleted by RFC2822 and the latter states in section 3.6.2
"Originator Fields":

The originator fields also provide the information required when replying to a
message.  When the "Reply-To:" field is present, it indicates the mailbox(es) to
which the author of the message suggests that replies be sent.  In the absence
of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es)
specified in the "From:" field unless otherwise specified by the person
composing the reply.

Thus: RFC2822 says that the Reply-To header is only a suggestion and does not
restrict to the Reply-To header!
Can we re-open this bug now?  Since RFC 822 is obsolete, comment #1 is no longer
valid, and therefore there should be no objections to implementing this feature.
Product: MailNews → Core
*** Bug 249455 has been marked as a duplicate of this bug. ***
Reopening - this would be a very useful feature (due to list-munging), as well
as not being prohibited by the newer RFC.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Severity: minor → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
*** Bug 316729 has been marked as a duplicate of this bug. ***
"Reply-to-all" (or a new, separate "Reply to ..[addresses in this mail]") optionally should provide a popup window, with checkboxes (one for each address found in that mail), initially checked..
And/or: some keyboard shortcut(s). E.g. Ctrl-alt-R (or some combination) for
"Reply to the 'From'"..
(Note: I (we) do not want to redefine the 'Reply-to' field semantics, nor the (plain) 'Reply'-behaviour.)

Think of it as a "temporary address book". Grabs (all!) the addresses in the mail (headers. or, theoretically, why not the body as well?..). For single use.

///Now it is *very* cumbersome to..:
Initiate a reply; go back and over the From address, right click and 'Compose mail to', go to the Recipient's line, select and copy the address; close and "Do not save" the mail; go back and replace the address..

The new version of thunderbird 1.5 b1 doesn't address the problem.  However, the file isn't corrupted -- that I am certain of because opera can read the files and all the messages.
*** Bug 338448 has been marked as a duplicate of this bug. ***
Assignee: ducarroz → nobody
QA Contact: esther → composition
Product: Core → MailNews Core
Adding CC: clarkbw@gnome.org
Nominating Wanted Tb 3
Suggest evaluation of Comment #9
Flags: wanted-thunderbird3?
in bug 45715 comment #155 I tried to lay out a solution that I believe fixes this.  Once the patches in that bug land I don't think this will be an issue anymore.
since bug 45715 has landed we now have all the options necessary for choosing between reply-to or from in the message reader.  The second part to fixing this bug I believe now lies in getting bug 248681 fixed such that there are options to toggle between the different reply types in the compose window.

bug 248681 doesn't address reply-to / from directly but handles the more common case of reply / reply all.  When that bug lands we might have a method for handling this case.
Actually I think this bug is waiting on bug 498448 for clearer reply, reply-to, reply-all, reply-list labels and then it can be closed / marked fixed.  The reply toggle is a nicer way to complete the interaction story but not necessary to fix this.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1pre) Gecko/20090628 Shredder/3.0b3pre
We have to check coming Thunderbird ~ Shredder/3.0b3pre because it does not work as I expect.

Here are some headers extracted from a message I can't handle easily if I want to reply to the author/sender but not the list. This mailing-list is set to make people easily reply to the list (the opposite setting is to make it easy to reply to the author/sender)

------------------ 
Mailing-List: blaw blaw; Liste geree par ezmlm (ovh)
List-Post: <mailto:List@>
List-Help: <mailto:List-help@>
List-Unsubscribe: <mailto:List-unsubscribe@>
List-Subscribe: <mailto:List-subscribe@>
Reply-To: List@
From: Sender@
To: List@
-------------------

The reply toggle gives three options :
- reply to list
- reply to all
- reply

All three of them reply to List@
I was looking for a bug related to this and I think this is it.  Using Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.7) Gecko/20100127 Lightning/1.0b1 Shredder/3.0.2pre right now, in a mailing list that has the reply-to header set by the list server, pressing "reply" will only send to the list address (in the reply-to field) which is the same behavior as the "reply list" button.  Is there supposed to be a choice to reply only to the address in the "from" header and ignore the "reply-to" header?
This won't fix all cases of reply-to munging, but it should work for mailing lists that set both List-Post: and Reply-To: to the list address.
Attachment #814447 - Flags: review?(mnyromyr)
Assignee: nobody → tbertels+bugzilla
Status: NEW → ASSIGNED
(In reply to Thomas Bertels from comment #21)
> Created attachment 814447 [details] [diff] [review]
> Use From: address if Reply-To: is the same as List-Post:
> 
> This won't fix all cases of reply-to munging, but it should work for mailing
> lists that set both List-Post: and Reply-To: to the list address.

I've talked about this over in bug 925756, but I really think it would be best if we fixed the mailing list software rather than Thunderbird. While getting list administrators to stop Reply-To munging is a futile effort, we could certainly patch GNU Mailman to add a user-configurable pref to toggle Reply-To munging (list administrators would then only set the *default*).

I think that's a better solution, because it's totally fine for the *author* of a message to set Reply-To == List-Post if, for instance, the author really doesn't want you to mail them directly. We should try to respect that.

That said, if it turns out to be an impossible task to get mailing list software to let users disable Reply-To munging, then the strategy in this patch seems ok (but we might want to have a pref to turn it off for the lucky folks who don't have to deal with servers that munge Reply-To).
Well, the case we fix is the Reply All. 
For a list mail Thunderbird  displays only [Reply] and [Reply List  v] buttons so only when the user goes out of his way to find the Reply All option it would make any difference. At that point I think the user has made his choice - especially given that the reply-to munging is common.
See Also: → 988794
Is there meanwhile an extension which just does reply-all like one expects (i.e. using all headers it finds and does it's thing)?
For those referring to RFC822, this rfc was written when mail clients didn't have a reply-all button :-)
This bug is in TB for 14 years? Woah... thats crummy.

What's the big deal? 
• We have a "reply list" button – which answers the list. Great! only thing working.
• We have a "reply" button – which answers, if a "Reply-To" is set, to the "Reply-To", which seems ok.
But actually: ITS NOT! The expected behaviour fails if the Reply-To equals the list address. TB should check if this is the case and if it is, TB should take the original "From" instead. If I would answer the list, I would already have taken the other button!
• And we have a "Reply all" button – which DOES NOT WORK! (if a "Reply-To" is set). It says reply ALL, so it should work like it. Take the list address, _and_ also the "From" address. If I would like to only answer either the original sender or the list, I would have taken the other buttons.


So, to sum it up: This is some mean UX. Really, it can't get anymore whacky!
Only in 1 of 3 cases the user gets what he expects. This is so bad I have no words for it.
Comment on attachment 814447 [details] [diff] [review]
Use From: address if Reply-To: is the same as List-Post:

Changing the reviewer.
Attachment #814447 - Flags: review?(mnyromyr) → review?(Pidgeot18)
Comment on attachment 814447 [details] [diff] [review]
Use From: address if Reply-To: is the same as List-Post:

Review of attachment 814447 [details] [diff] [review]:
-----------------------------------------------------------------

Would you be so kind as to add a test? Based on visual inspection, such a test would discover a bug in your code, although I can't say for certain it didn't have that bug when you wrote this patch several years ago.

<https://dxr.mozilla.org/comm-central/source/mail/test/mozmill/composition/test-reply-addresses.js> is the main test file for this block of code, and it ought to be easy to figure out how to cargo-cult your way to a working test. If you need help with writing the test, please feel free to ask me specific questions.
Attachment #814447 - Flags: review?(Pidgeot18) → feedback+
Please tell me, you have fixed this 14 year old bug....!?
Nope, latest Thunderbird (31.7.0) still has it.
(In reply to Alex Abdugafarov from comment #32)
> Nope, latest Thunderbird (31.7.0) still has it.

That's not the latest Thunderbird; the latest is 38.0.1.

As for this bug, if it were fixed, it would be marked "RESOLVED FIXED". However, there's a patch, but it needs tests, and I think it should have a pref to disable it if possible. Also, as I argued in comment 23, a better place to fix this would probably be in the mailing list software (e.g. GNU Mailman), since the real bug is that mailing lists are manipulating headers without the consent of the author or the recipient.
(In reply to Jim Porter (:squib) from comment #33)
> As for this bug, if it were fixed, it would be marked "RESOLVED FIXED".

Yes, I know this. I just wanted to bring back some attention.

> However, there's a patch, but it needs tests, and I think it should have a
> pref to disable it if possible. Also, as I argued in comment 23, a better
> place to fix this would probably be in the mailing list software (e.g. GNU
> Mailman), since the real bug is that mailing lists are manipulating headers
> without the consent of the author or the recipient.

Well, you are right. But you don't have control over the mailing list software everytime (…like me here…) and just have to live with it.
And on the other hand: It's still bad UX if the expected not happens. So yes, it's fixing something you're not responsable for, but it's nice. Like taking out the garbage even when it's the roommates one... ;)
See Also: → 860072
My bug 860072 comment #1 seems to show that the bug has been fixed for Thunderbird 43.0a1 (2015-09-13)
status-thunderbird43: --- → fixed
See Also: 860072 →
See Also: → 992617
I made this recommendation on bug 992617 before I discovered this bug:

> An enhancement to TB would be to introduce a new function, "Reply to Author", using the "From:" address.  I suggest using the descriptor "Author" to be consistent with RFC 4021 which describes the "From:" header as "Mailbox of message author".

I think adding "Reply to Author" as a menu option would adequately address the recommendation in RFC822 (the default "reply" behavior obeys Reply-To: header if available) but provides the good user experience of making it easy to reply to the From: address.

FWIW, apparently "Reply to Sender" and "Reply" are the same thing, so please don't suggest "use 'Reply to Sender'" as a fix for this bug, as it currently isn't.  (c.f. https://dxr.mozilla.org/comm-central/rev/076c24f6d01d0a5f0b14fb1cc80c17ff24dc9074/mailnews/compose/src/nsMsgCompose.cpp#2563)
I'll join to the question - Is there meanwhile an extension which just does reply-all like one expects (i.e. using all headers it finds and does it's thing)?
Yes, please. Make Reply-All reply to ALL people including the sender.
Assignee: tbertels+bugzilla → mkmelin+mozilla
Flags: wanted-thunderbird3?
Joshua, have time to review this? It was your suggestion to the council list, and it makes good sense to me.

For munged reply-to headers:
 - on Reply, reply to From
 - on Reply-all, include From in "all".
Attachment #8767149 - Flags: review?(Pidgeot18)
Attachment #814447 - Attachment is obsolete: true
Attachment #8767149 - Flags: review?(mozilla)
Comment on attachment 8767149 [details] [diff] [review]
bug77304_reply_to_unmung.patch

Review of attachment 8767149 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good and logical to me. Two nits. I haven't run the test, I assume you have and you've also made sure that nothing else broke.

::: mailnews/compose/src/nsMsgCompose.cpp
@@ +2680,5 @@
>          else if (!replyTo.IsEmpty())
>          {
> +          // default reply behaviour then
> +
> +          if (!listPost.IsEmpty() && replyTo.Find(listPost) != -1)

kNotFound ?

@@ +2727,3 @@
>              allTo.Assign(replyTo);
>              needToRemoveDup = true;
> +            if (!listPost.IsEmpty() && replyTo.Find(listPost) != -1)

kNotFound ?
Attachment #8767149 - Flags: review?(mozilla)
Attachment #8767149 - Flags: review?(Pidgeot18)
Attachment #8767149 - Flags: review+
https://hg.mozilla.org/comm-central/rev/b91eb48f1dae -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 50.0
Replying with SM to a mail from a mailing list with ^r used to go to the mailing list. Not anymore. Backing out bug77304_reply_to_unmung.patch restores the old (and highly desired) behavior.

Should the Bug be reopened or a new one filed?
The whole idea of this bug was to *change* the behaviour so that the reply to a message with Reply-To: some-mailing@list.com would *NOT* automatically go back to the list if the sender was not the mailing list. For example replying to
  From: president@list.com
  Reply-to: some-mailing@list.com
now goes back to the president. If you want to reply to the list, you need to click "Reply List".

The behaviour has changed, neither will we reopen this bug nor will we return to the previous behaviour in a new bug.
Strange. The recipient of a reply to a list mail is almost always the list. ^r is standard for a reply. To argue seems hopeless.
Well, I got caught by this bug. I got a message from Kent James, I replied with some personal thoughts and bang, it went to the whole mailing list (and I looked like an idiot).
Introducing a pref to change the behavior would be enough. Though this would require either reopening the bug or filing a new one. This was declined. So let us stop now.

For myself I have a new private patch. Without pref. ;)
You can file a new bug for a preference. In general, Magnus dislikes preferences. Magnus?
Flags: needinfo?(mkmelin+mozilla)
Yeah, sounds like something an add-on would do if you really want it.
Flags: needinfo?(mkmelin+mozilla)
I understand that this behaviour is (unfortunately, IMO) intentional and won't be changed back.

Is there any point in me filing a bug to change the Reply button to read "Reply off-list" or similar, rather than just "Reply" (only when in a mailing-list context with "Reply to list" enabled, of course)?
But the "Reply List" is clearly visible. Why would "Reply off-list" bring any benefit?
Because until recently "Reply" on its own implied the traditional reply behaviour. 

The change of semantics means that people are now accidentally sending private messages when they intended to reply to the mailing list. A change of label to accompany the change in semantics would have reduced the risk of that happening.
I do disagree with this behavioral change.

In the case of a Github email as follows:

From: John Doe <notifications@github.com>
Reply-To: INRIA/spoon <reply+000c4352400071c00011414710392a169ce0adc6133@reply.github.com>
List-Post: <mailto:reply+000c4352400071c00011414710392a169ce0adc6133@reply.github.com>

Two out of three headers (the majority) clearly say to send a reply to reply+000c4352400071c00011414710392a169ce0adc6133@reply.github.com and TB still makes the wrong default choice.

As a result, Github email communication is broken.
Magnus, would you like to address these comments?

As I said in bug 1309486 comment #1, you need to use "Reply List" now.

I actually think that the new behaviour is better, but this shows that whatever change you make, there will be someone affected who liked the old way better.
Flags: needinfo?(mkmelin+mozilla)
I think most of you know xkcd no. 1172…
It's always like this. But really, read comment #27.
This was a bug for now 15 years. Finally we have the software acting it should, and you guys want this messy failure back?! WTF
(In reply to Jorg K (GMT+2) from comment #58)
> Magnus, would you like to address these comments?

This is why, in comment 33, I said there should be a pref. While I appreciate our goal to keep prefs to a minimum, when we're intentionally violating RFC recommendations to produce a better experience for the common case, we should have prefs to disable the new feature and follow the RFC. From RFC 5322:

   Note the "Reply-To:" field in the above message.  When John replies
   to Mary's message above, the reply should go to the address in the
   "Reply-To:" field instead of the address in the "From:" field.

To be sure, the "should" isn't in all caps, so it's not an official part of the RFC, but it's pretty clear what the intent is. We're also only doing this to work around the fact that mailing lists violate the RFC very clearly: "Reply-To" is a field that should be set by the *author*, not the *sender* (i.e. the mailing list).
(In reply to martin.monperrus from comment #57)
> In the case of a Github email as follows:
> 
> From: John Doe <notifications@github.com>
> Reply-To: INRIA/spoon
> <reply+000c4352400071c00011414710392a169ce0adc6133@reply.github.com>
> List-Post:
> <mailto:reply+000c4352400071c00011414710392a169ce0adc6133@reply.github.com>
> 
> Two out of three headers (the majority) clearly say to send a reply to
> reply+000c4352400071c00011414710392a169ce0adc6133@reply.github.com and TB
> still makes the wrong default choice.

Well it's not a vote.
Semantically the new behaviour also makes a lot of sense: you would press reply-list for a mail like that - you're NOT replying to a user personally but it's a reply that can be seen by anyone following the issue.

It's unfortunate they user noficiations@.... instead of a no-reply@ like most places.
(In reply to John Wilcock from comment #55)
> The change of semantics means that people are now accidentally sending
> private messages when they intended to reply to the mailing list. 

Hopefully that's basically a one-time thing though. 

Re pref: well if someone sets the pref they would still have broken behaviour for all the munged list mails they get. The current behaviour gives you a run-time choice (using the appropriate button), which the pref would not.
Flags: needinfo?(mkmelin+mozilla)
That's a choice that I think people should be able to make. Since we're violating RFCs, we should give people the option to use the standard behavior, if only because it would match the behavior of other MUAs the user might use. I don't think it's reasonable to expect users to remember that they're using Thunderbird today (instead of Outlook, Evolution, Gmail's web UI, etc) and that the behavior of the "reply" button is different as a result. It should be possible to make all your MUAs work roughly the same way.

I still believe a better long-term solution to this is to fix the mailing list software (patching GNU Mailman would be a good start). Currently, I'm pretty sure Mailman has reply-to munging determined by the list maintainer, but it should be an option for each subscriber. Then they can set reply-to munging to match their MUAs' capabilities.
You're advocating a solution that actually gives users broken behaviour, with no run-time way to fix it. If you want to change it, please find a solution that is not just papering over a certain problem to give you another problem instead.
> This was a bug for now 15 years.

This is where we disagree. A number of us think that the previous behavior was the right one and that the new one is the broken one. We simply disagree on the expected behavior.
I'd say consistently broken is better than inconsistently broken.

As already mentioned, the *best* solution is to fix the mailing list software to give subscribers control over reply-to munging. On our end, we're just choosing between two broken implementations: the old behavior was broken if the list set Reply-To, but the new behavior is broken if the *author* set Reply-To (e.g. to send all replies to the list because they don't want private correspondence). 

The current code produces unexpected behavior given that a) people are used to the old way (partly because of how other MUAs behave), and b) that some systems like GitHub produce emails with reply-to munging because the From field is a phony address. In cases like (b), "reply to From" makes no sense, and we shouldn't be making it easy for users to send their mail into a black hole. For GitHub, their usage of reply-to munging is both sensible and RFC-compliant: the From field (which is identical for all notifications to make filtering easier) is a fake address, so the *author* (GitHub) has indicated that replies should go to the "list". GitHub is a pretty popular service, and our current behavior produces confusing results with it so that broken mailing lists get unmunged. As a result, I believe users are in the best position to decide which behavior works for the kinds of mail they receive.

The proper way to fix this in Thunderbird would probably be bug 498448, but that's considerably more work than adding a pref, and given that it would require new strings, we probably don't have time to land it for 52.
Another aspect of this controversy is usability

Previously, for replying, the user had to make a decision between two options (reply-simple, reply-to-all). Now there are three options (reply-simple, reply-to-all, reply-to-list), and the cognitive load for each email to be answered is higher. Less is more.

Now consider the number of wrong decisions taken: for example the classical reply-to-all instead of reply-simple. With three options, I expect to the number of wrong decisions to increase, and maybe significantly.

To sum up, the new behavior can be considered worse from the viewpoint of least astonishment, backward compatibility, and usability.
Uh, we had the tree different types since maybe 10 years now.
The new thing is that now, one has to know whether a message comes from a list or not to make a decision. Before one could simply live one's Thunderbird life without knowing the existence of "Reply to list".

For the  Github example, there is no reason to believe that the message is a list mesasge (but to open the message source which is not what the average user does). So there is no hint at all to press "Reply to list".

For all messages for which the user is not aware of this list-nature, the new behavior is not satisfactory.
If "Reply List" is present in the message header toolbar, it's a list message. If not, it isn't.
OK, I see. It's not graphically visible but it's in the menu.
Is there a way to ask for reconsidering this change? before the bug hits the masses at the next release?
I suggest some simple enhancements to the 'Smart Reply' button (currently only available in the message header pane) that will let users have full control over their replies:

1. Since the only reason I ever use a reply button in the message pane header is to make use of the Smart Reply button, please make the 'Smart Reply' button - currently only available in the Message Pane Header - available to standard toolbars (bug 868961).

2. Provide a way to configure the 'Smart Reply' buttons behavior.

For example, I prefer to always honor an explicit 'Reply-To' header, so that should be an option (bug 1280424).

3. Add additional conditions that the user could set that make sense, based on the feedback in this (and related) bugs. I imagine there would really only be one or two more in addition to the one I specified above.

Oh, as a keyboard power user, I'd also like to see my request for a keyboard shortcut for the 'Smart Reply' function provided (bug 979447).
I have created bug 1322136 to follow through with my suggestion...
I got the 52.0 update last nite and now the behavior is even more broken.  Normal lists with the "munged" reply-to no longer use the reply-to when reply is clicked.  Reply to List must be used.  Now try that on a Yahoo Group List.  Reply to List doesn't even light up - it stays grayed out.  Reply, replies to the list.  Smart Reply doesn't even give any choices.  To use TB as I always have, I now have two more buttons, had to create a new toolbar, moved things from the main toolbar to the new one, ...

So tell me Magnus, is this the new, improved, correct behavior you were looking for?  It appears to me it's a total fail.
What's special with a Yahoo Group List? Forward me a sample?
Jörg sent me a sample. Anyway, there is not List-Post header in those mails so
 - it has nothing to do with this bug
 - it all appears to work like it should, and like before (of course no reply-to-list option, since there's no List-Post header in the mail)

Please file a another bug if there's a problem with something related.
(In reply to vev from comment #75)
> I got the 52.0 update last nite and now the behavior is even more broken. 
> Normal lists with the "munged" reply-to no longer use the reply-to when
> reply is clicked.  Reply to List must be used.

The (admittedly limited) testing I just performed shows it to now be working as expected with respect to this bug.

When using Reply-All on a message with a valid From: header AND an explicit Reply-To set, the reply now goes to all recipients in the Reply-To and the From:/sender.

Further testing - a list message that was sent To: an individual OP anc CC'd the list, and had explicit Reply-To header to reply to both the list and the sender, did just that when I clicked the normal Reply button, and when clicking Reply-All, also included the other recipient that was in the To: header - and finally, when I did Reply-to-List, that replied to only the list, as expected.

> Now try that on a Yahoo Group List.  Reply to List doesn't even light up -
> it stays grayed out.

Ahem... Reply-to-List has never worked on Yahoo groups.

> Reply, replies to the list.

This is how it has always worked with Yahoo groups (and others that don't use proper List headers that the Reply-to-List button requires to function).

> So tell me Magnus, is this the new, improved, correct behavior you were
> looking for?

Answering for Magnus - yes, this 16 YEARS old bug is now fixed!

> It appears to me it's a total fail.

Making it clear that you simply cannot please everyone.
It has nothing to do with the bug?  It has a lot to do with the fix for the bug.  There's no "List-Post" header, but there is a "Mailing-List" header.  The behavior is inconsistent.  

By your own logic, if it's a list you should use the "Reply-to-List" option, not "Reply" since "Reply" should go to the author.  The yahoo list is a list but "Reply-to-List" isn't an allowed option and "Reply" doesn't go to the author like it's supposed to.
(In reply to Charles from comment #78)

> Ahem... Reply-to-List has never worked on Yahoo groups.

That's not an answer.  That's a blow off comment.  If the new behavior is that "Reply-to-List" is supposed to reply to the list, then it should whether it's Yahoo or not.  

> Answering for Magnus - yes, this 16 YEARS old bug is now fixed!

Actually it's more broken now than it was because it's inconsistent.
If Yahoo would like to get correct behavior for their emails, they should probably use the correct headers. "List-Post" is the correct header per RFC 4021[1], whereas "Mailing-List" doesn't appear in that RFC at all. I would suggest filing a bug with Yahoo, since they appear to be making things up as they go and expecting the rest of the world to accommodate them.

[1] https://tools.ietf.org/html/rfc4021
RFC4021 references RFC2369 for the definition of the List-Post header.  Neither RFC states it MUST be there, therefore it's optional.  RFC2369 even goes as far as stating it's not widely applicable, so why depend on an optional field?
> Answering for Magnus - yes, this 16 YEARS old bug is now fixed!

Not exactly, it was marked as invalid for a number of years, and some of us do think that the proposed and now implemented behavior is indeed invalid.
(In reply to vev from comment #79)
> It has nothing to do with the bug?  It has a lot to do with the fix for the
> bug.  There's no "List-Post" header, but there is a "Mailing-List" header.

No, but I do see a 'list-id' header'.

But what you are missing is, the List-Post header specifically provides the address for posting messages to the list. The 'list-id' header isn't an email address. E.g., the one list I found that has reply-to munging enabled has this:

list-id LVM general discussion and development <linux-lvm.redhat.com>
List-Post <mailto:linux-lvm@redhat.com>

> The behavior is inconsistent.

No, it isn't.  It just doesn't try to guess at what the List-Post address might be if it isn't present, it assumes that since it isn't present, that list doesn't want you posting to it.

In this case, Yahoo is, and always has been, broken.

> By your own logic, if it's a list you should use the "Reply-to-List" option,
> not "Reply" since "Reply" should go to the author.  The yahoo list is a list
> but "Reply-to-List" isn't an allowed option and "Reply" doesn't go to the
> author like it's supposed to.

And again what you are missing is, Thunderbird is not trying to 'guess' about what is and is not a list, it is using the headers defined for the purpose.

So, if you want Reply List to work with Yahoo groups, get Yahoo to add the list post headers, or open a Thunderbird bug to add the ability to create 'special cases' to workaround certain broken list managers.

Regardless, it has nothing to do with this bug.
(In reply to martin.monperrus from comment #83)
> > Answering for Magnus - yes, this 16 YEARS old bug is now fixed!
> 
> Not exactly, it was marked as invalid for a number of years, and some of us
> do think that the proposed and now implemented behavior is indeed invalid.

I went back and read some of your comments, and see what you are getting at, but this bug is not the appropriate place to fix the things you are complaining about.

You might, however, be interested in bug 1322136 I opened a while back to make the 'Smart Reply' button 'smarter'.

I'm now working on a much more detailed and cleaned up 'Summary' for that bug, will be posting either tonight or tomorrow...
I just read through all these comments on this bug. As an administrator of mailing lists and a network with many people I got flooded with complaints about the misdirected messages and about Thunderbird in general (after explaining that they now have to use Reply To List).
I personally think that this change comes unexpected and breaks the intended behaviour. 
If a mailing list (be it ezmlm or mailman) explicitly sets an reply-to header I then the default reply button should send messages to the list.

Why break the user experience for most people (with less experience) and not fix the usability for power users by adding a "reply to author" button? 

I will roleback Thunderbird for the time being to 45.8 because I have better things to do than explain 5-10 people a day why their MUA has changed a basic functionality to a (in the users eye) broken way.

I don't need an answer explaining to me for the nth time why this was changed. I just wanted to add my voice to this bug that I think it is broken _now_.
There is a question in the Support Forum regarding the issue of 'Reply-List' button and loss of 'Reply-to' functionality.
https://support.mozilla.org/t5/Thunderbird/Changed-in-52-0-when-replying-to-a-mailing-list-reply-will-be/td-p/1386633/page/2
which is now causing no end of problems.
Perhaps it would be helpful to read some of the comments to understand what is going on and why the 'Reply-List' button is not necessarilly available.
They also included helpful info on the headers.
Note: this bug was about a broken Reply All function.

This bug is now fixed. If you are experiencing other problems, open a new bug.

(In reply to Nicki Messerschmidt from comment #86)
> If a mailing list (be it ezmlm or mailman) explicitly sets an reply-to
> header I then the default reply button should send messages to the list.

Well, for me, the regular Reply works exactly as expected - it replies to the sender if there is no Reply-To header set, and it replies to the Reply-To address if it is set.

But, I do now see that this bug is in fact still not fixed.

Reply All does NOT reply to both the From: and Reply-To: addresses, it only replies to the Reply-To address.

So, this bug is not fixed.
Aaaargh! Sorry, I was in the middle of posting about how this bug was fixed when I decided to test directly by sending myself a message from a different account, with a Reply-To set, and found it wasn't.

So, to make it clear, this bug - the one opened by the OP - is not fixed.

Reply All does NOT work when a Reply-To is set.
Both Reply and Reply All work for me, and we even have a test that proves they both work. 

Please file new bugs, with attached test case and steps to reproduce if some case isn't. This bug is closed.
Restrict Comments: true
Just to clarify, this bug only changed things for mailing lists (the mail must have the List-Post header).

The case for normal mail is a separate issue.
Summary: Cannot reply to From: when Reply-To: field appears in header → Cannot reply to From: when Reply-To: field appears in header (handle reply-to munging on mailing lists)
FYI:

If someone manages a Mailman list and wants to restore the behavior the listusers have been used to for the last 16 years, you can disable 'include_list_post_header' for every list you manage (set it to 0). The setting is found on the 'general' page of the list settings webinterface.

Alas, there is no default to set this, so you have to remember to set it for all lists you manage (you can always use 'config_list' on the commandline.

This might have changed in Mailman 3.
Comment from Mrten via private message:

Today, I tested the behavior of major mailers to test the behavior of "Reply" when all three headers From/Reply-To/List-Post are present in an email.

Here are the results:

Gmail: "Reply" goes to reply-to address
Zimbra: "Reply" goes to reply-to address
Horde/IMP: "Reply" goes to reply-to address
Outlook Web: "Reply" goes to reply-to address
Yahoo: "Reply" goes to reply-to address
Roundcube: "Reply" goes to reply-to address

Evolution: "Reply" asks a question about the intended behavior (see below)
For the sake of open debate, would you post this data on the bug page?

More about Evolution: "Reply" asks the following question and saves the answer, hence the behavior is configurable:
You are replying to a message which arrived via a mailing list, but you are replying privately to the sender; not to the list. Are you sure you want to proceed?
Reply Privately -> goes to reply-to address
Reply to List -> goes to list-post address
Reply to All
Discussion continues in bug 1309486.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: