Open Bug 1390518 Opened 8 years ago Updated 3 years ago

Wrong account used when replying to list

Categories

(Thunderbird :: Message Compose Window, defect)

52 Branch
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: yan, Unassigned)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170612122310 Steps to reproduce: I click "reply" or "reply to list" (in an e-mail that I received through a mailing list). Actual results: The composer windows opens with the default account selected as sender. Expected results: The same account as the one that received the e-mail should be used as sender. This happens in Thunderbird 52.2.1 on Kubuntu 16.04. I started TB in safe mode with all add-ons deactivated, but it's the same. The problem started to occur at the same time with the behaviour described here: https://bugzilla.mozilla.org/show_bug.cgi?id=1386211
As weird as bug 1386211. You should create a new profile and see what happens there.
yan, did you get this sorted out?
Flags: needinfo?(yan)
Hi Wayne, unfortunately not. I created a completely new profile, but the problem from bug 1386211 persists. I haven't checked if the reply-to-list problem also stays, but it seems both bugs are connected.
Flags: needinfo?(yan)
Is version 60 available for you to try?
See Also: → 1386211
Yes, I cannot note any change regarding the problem with TB 60.
Any more insights here after you corrected your account setup in bug 1285694 comment #15?
(In reply to Jorg K (GMT+2) from comment #6) > Any more insights here after you corrected your account setup in bug 1285694 > comment #15? No, unfortunately not. I also hoped for a solution for this issue, but it persists. I haven't checked with a new profile, though, because I had only added one account so far.
Ok, I can confirm now that it does NOT happen with a clean profile. So as in bug 1285694, this probably has to do with some configuration of my Thunderbird profile. Any ideas how I can find the cause?
So in the new profile you configured two accounts at least? Care to attach a screenshot of the account settings. And do those profiles use the same shared inbox?
My first test with the clean profile was with two separate accounts. Now I tried with both account in the global inbox (not sure what's the name in English). The result: The problem appears again. This is what I did: 1) Configure two accounts with POP, both included in global inbox 2) Set one account to be default account 3) Click on "reply to list" in an e-mail of the account that is not default. Result: The default account is set as sender address. Expected result: The e-mail of the account that received the e-mail is set as sender. I'll attach the settings of both accounts (with anonymized username)
(In reply to yan from comment #10) > My first test with the clean profile was with two separate accounts. Now I > tried with both account in the global inbox (not sure what's the name in > English). I'm confused now. So you made two test cases? First without a global inbox and then a second one with a global inbox? I'm more interested in the case of no global inbox since that's what I use myself. I have various POP inboxes and replying from a particular *inbox* always uses the account associated with that inbox. I thought that's the part that already doesn't work for you? Or are you not replying from the inbox? Maybe you're replying after the e-mail got moved to a local folder? Then the system cannot associate that mail with any account and uses the default account. If you want this to work after moving the e-mail to a local folder, you need to set pref mailnews.reply_to_self_check_all_ident. Repeating: There must something you're not telling us. I am using exactly your setup, various inboxes associated with various accounts and replying just works from the inboxes. I enable a better reply-experience from folders other than the inbox, I use the said pref. I have no experience with a global inbox, but I could set that up if you wish.
Thanks for your reply and sorry for the confusion. I will try to explain. The original problem suddenly appeared in a setup where I use multiple accounts that all go into the same inbox (Local Folders) and are then moved to folders using rules. That worked just fine for years, but all of a sudden, the described problem appeared. I am also using accounts that are separated from the global inbox, but I noticed the problem with lists inside "Local Folders". For testing purposes, I created a new profile and added two accounts that were separated, i.e. not in a global inbox. And they were configured using IMAP which seemed easier to me. In this setup, the problem did not appear (see comment #8). I then noticed that the setup was different from my original one, deleted the accounts and added them again as POP using a global inbox. In this setup, the problem did occur (as I described in comment #10). And it did occur with e-mails in the inbox since I hadn't created any folders and rules. Is that clearer? I just tested setting mailnews.reply_to_self_check_all_ident to TRUE, but that doesn't have the desired effect, neither in the clean profile nor in my original setup. As I said before, for years I had no problems, when I clicked "reply to list", the correct account was selected as sender. I supposed that it was based on the address that appears as receiver in the mail header.
Just a quick shot in the dark. Mailing list replies got changed in bug 77304 in TB 50, so included in TB 52. That change was hotly contested, so we introduced a preference to revert back to the original behaviour in bug 1392371: mail.override_list_reply_to. I don't see anything that would have changed to affect behaviour that worked "for years". I'm not sure that preference affects account/identity selection for the reply, but worth a shot. Summarising the problem: - only occurs with POP global inbox - only occurs with "reply to list" or also "normal" reply? (days later: oops, that comment never got posted)
Sorry for the delay. Changing mail.override_list_reply_to to false doesn't have any effect on the mentioned problem, neither in my "normal" profile nor in the clean one. It still occurs both with "reply to list" and "normal" reply.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: