Closed Bug 992617 Opened 10 years ago Closed 8 years ago

right click menu option "reply to sender only" replies to entire mailing list anyway

Categories

(Thunderbird :: Message Reader UI, defect)

24 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 988794

People

(Reporter: gessel, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Right click on a message coming from a google groups mailing list (presumably other mailing lists as well), select "reply to sender only" expecting to compose a message to the sender of the message rather than the whole list (as in "sender only").


Actual results:

To header is filled with the mailing list reply to address only.  If sent the message goes to the list not to the "sender only."


Expected results:

To header filled with the address of the sender of the message, not the list.  While arguably the message actually came from the list manager, this is not the expected behavior since "sender only" implies a different result from "reply to all" and "reply to list," both additional valid menu items which generate exactly the same result.

This bug can result in not merely embarrassment but legitimate and significant security problems.
Component: Untriaged → Message Reader UI
I haven't looked at TB source about this, but I suspect the issue might be that the mailing list software is setting the "Sender:" header to the list address, and "Reply to Sender" is using the "Sender:" header address (as would make some sense from the literal interpretation of "Reply to Sender"), instead of the address in the "From:" header, which is probably the actually desired use case of such a function.

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".

Personally, I would really like this, as I'm kinda tired of copying-and-pasting the "From:" address on mailing list messages when I want to reply to the message author off-list.

If anyone wants to mentor me on implementing this change, I'd be happy to work on it ...
Attachment 8397825 [details] [diff] from bug 988794 may be a good starting point for the "Reply to Author" change I suggested.
See Also: → 988794
See Also: → 77304
This one has been bothering me for some time.  


SOME BACKGROUND:

First off, "Reply to Sender Only" via right click is functionally equivalent to "Reply" via the buttons appearing in the header part of the message pane.  The word "sender" does not seem to rely on the SENDER header which is not always present.

Second, the "bug" is actually broader than the behavior of Reply To Sender Only with Google Group messages.  It lies in unexpected selection of recipients when replying to messages that arrive from mailing lists, depending on (1) whether the user selects Reply (or Reply To Sender), Reply List, or Reply All, (2) whether there are other recipients to the message, and (3) on the mailing list in question.  


WHAT IS THIS BUG, REALLY?

For Google Groups, there are (at least) two issues. The first is the one described above:  replies are addressed to the list only, no matter which reply option is selected.  This only happens, however, with the initial message from the Google Group address.  At least on my Groups, the FROM header shows human_being@address.com, not the Google Groups address, and the TO header is group_name@googlegroups.com instead of me.  I don't really understand how MTA's parse mailing list messages, but it seems like TB is unable to pull out the underlying to/from addresses in order to sensibly address replies.

Once a recipient replies to the initial message and includes the original sender manually as a TO, then that reply, once delivered by Google Groups to the person who just sent it works as follows:  Reply List sends to the Google Group only, but both Reply and Reply All will address messages to both the list and the original sender.  In other words, Reply List and Reply All do what is expected, but Reply now duplicates Reply All.  

Yahoo Groups is a little different.  The initial Yahoo messages typically have no Reply List option at all.  Reply and Reply All work correctly:  Reply replies to the user who posted the message, and Reply All to both Yahoo and the original human poster, simultaneously.  

But, sometimes, Reply All is missing entirely.  When that happens, no address is selected when the user clicks Reply.  This seems to happen only when replying to one's own message received via the list.  (Why would I reply to a message I had just sent?  It happens . . . .)

In all of these situations, the SENDER header appears as a star in TB, and the FROM, TO and CC headers vary. 


IS IT REALLY A BUG?

Some of these results are not bugs, in the sense that TB is probably addressing messages in accordance with the RFC.  A reply should go to the sender, even if the sender is a group mailing address, and not the original human being who previously wrote to the mailing list.  I don't really remember how the RFC specifies all of this or how mailing lists are allowed to be different.  

The problem is that the three possible choices:  Reply List, Reply and Reply All, don't match the user's expectations.  The "bug" is in the labeling of the buttons, and the solution is to make the buttons do what users expect!

WHAT DO USERS EXPECT?

Consider a message sent to a mailing list from (case 1) a non-member of the list (like an end user e-mailing a help desk, where the message is distributed to all team members), and (case 2) from a member of the list.  In each case, TB displays the message as being FROM the original sender, human@address.com.

In both cases, because TB displays the message as "FROM" the original sender, the user's expectation is that Reply (or Reply To Sender ONLY) will reply to that human sender, and not to the list.  Instead, Reply usually addresses messages to the list.  Again, that is not a bug in the sense that the message is actually from the list.  The bug -- if it is a bug at all -- is that the FROM field displays the original sender instead of the address from which the message actually came.  

I think that most people would prefer to see the human being's name, not the list address.  This may even be specified in some RFC.  So, again, the issue is really whether the Reply / Reply All / Reply List does, and consistently does, what the user sensibly expects, rather than the formal correctness of what TB presently does.  


WHAT WOULD BE A GOOD RESOLUTION?

A good resolution to these UI issues would select differing recipients for a reply depending on which type of reply the user selects.  The three choices are (1) reply to the original sender only, (2) reply to the list only, and (3) reply to both.


ARE ALL THREE CHOICES NECESSARY?

No.  But if there is going to be a "Reply List" option then it should do what it says:  reply to the list and only to the list.  Likewise, "Reply All" should do what it says:  reply to the everyone visible in the From and CC fields displayed in the TB message pane.

That leaves "Reply."  But process of elimination, Reply sends a message only to the most recent sender.  

Unfortunately, IMHO, the logical function for "Reply" varies with each case described above.


WHAT SHOULD "REPLY" DO?

In case 1, the recipient will certainly want the option to reply to the original sender (with or without the list address), since that sender is not a list member and has no way of receiving replies via the list.  Reply All seems like the obvious choice to simultaneously address both the original human sender and the list.  That leaves the simple Reply (or Reply to Sender) as the mechanism to get back to the human only.

Unfortunately, in case 2 the user's expectation for Reply and Reply All may be reversed.  The user knows that the sender is on the list and probably wants Reply to reply to the list and only the list, to avoid duplicate messages back to the human sender.  Reply probably means "reply to list only" in this case.  

CONCLUSION

TB may never be able to know for sure whether a message came from a person or a list, but it could probably do a better job of offering reply options when it senses that a message was list-generated.
If anything, the phrasing of "Reply to Sender only" is really confusing: many mailing lists force Reply-To to point to the mailing list address, causing "reply to sender only" to address the mail to the mailing list.
Fixed by bug 77304.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
(In reply to Magnus Melin from comment #6)
> Fixed by bug 77304.
> 
> *** This bug has been marked as a duplicate of bug 77304 ***

This is NOT a dupe of bug 77304, and the fix to bug 77304 does NOT fix this bug.

To fix this bug, there needs to be code that when `type == nsIMsgCompType::ReplyToList` is true, it looks for a `Sender:` header and if not empty, does a `compFields->SetTo(sender);` else does a `compFields->SetTo(from);`.

Can we please re-open this bug?
This bug 992617 is actually a dupe of bug 988794, neither of which are fixed by bug 77304.

The issue represented by these two bugs (988794, 992617) is the inability to use the "Reply to Sender" functionality to actually reply to the Sender/From address if there are other headers (e.g., Reply-To) in the original message.
You need to log in before you can comment on or make changes to this bug.