Closed Bug 684259 Opened 13 years ago Closed 8 years ago

TB6 uses wrong "From:" address in Reply All to Sent message

Categories

(Thunderbird :: Untriaged, defect)

Product:
Thunderbird
Component:
Untriaged
Version:
6 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 704613

People

(Reporter: mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: dupeme)

Attachments

(1 file)

Troubleshooting Information.pdf
360.80 KB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1 Build ID: 20110830092941 Steps to reproduce: I tried to post a follow-up to the same recipients as those in a message I previously sent them by clicking Reply All on the message as stored in my Sent folder. Actual results: TB6 used the wrong identity in the From: field of the Reply All. I have multiple accounts and use a global inbox. My primary account is set as the default, the first identity in that account's identity list is my primary identity, and that is the account and the identify from which I sent the original message. But if I go to that message in my Sent folder and click Reply All, TB6 uses the From email address of a completely different identity from a completely different non-default account that uses a completely different non-default set of servers, and the identity it gets the From address from does NOT also appear in my default account's identity list. The only thing that is the same between the identity it should use and the identity it does use is the From name (e.g. "Firstname Lastname"), but the email addresses are completely different. Expected results: TB should have used the same account and identity for the From: field of the Reply All as was used in sending the original message. Alternatively, it should use the default account and identity. (In this instance, the result would have been the same.) Additional information: TB 6.0.1, Win 7 Pro SP1 64-bit. Anticipating some responses based on reports of other similar problems, it happens whether in Safe Mode with all add-ons disabled or in regular "add-ons enabled" mode, none of my accounts use gmail addresses or servers, installing Correct Identity does not help, setting mailnews.reply_to_self_check_all_ident to true does not help, and setting mailnews_reply_header_authorwrote to null is not an option because it eliminates the name of the sender from the quoted message text. A TB Troubleshooting Information display is attached.
Are you running extensions ? Anything in Tools -> Error console when this happens ?
Are you running extensions? Yes, see below, but this also happens in Safe Mode with all extensions disabled. Anything in Tools -> Error console when this happens? No, nothing at all. Extensions installed: AddressBook Tab 1.4.2 ContactsSidebar 0.9pre Correct Identity 1.3.3 Quicktext 0.9.11.1 ImportExportTools 2.6.2 (disabled) I also have numerous Plugins installed and can provide a list if requested. Additional information: I am now running TB 6.0.2, and it is still happening. (I was running 6.0.1 when I first reported this.)
I'm short on ideas, Wayne, Rsx11 , any ideas ?
Tony may have some insight. I don't use global inbox
Update: I'm now using TB 7.0.1, and it is still happening. I'm no longer running the ContactsSidebar 0.9pre extension, since it is not compatible with 7.0.1., but that is really immaterial, since the problem continues to also occur in Safe Mode with all add-ons disabled. Thanks for continuing to investigate this.
I'm not using Global Inbox (or even POP) either, sorry... > mailnews.reply_to_self_check_all_ident to true does not help That would have been my only suggestion which resolves a couple of issues, but apparently not all of them. The weird part is that the selected identity seems to be completely unrelated to the actual identity used when replying to one's own message as a follow-up.
> The weird part is that the selected identity seems to be > completely unrelated to the actual identity used when > replying to one's own message as a follow-up. Not 100% true. There is _one_ commonality, as stated in my original post: "The only thing that is the same between the identity it should use and the identity it does use is the From name (e.g. "Firstname Lastname"), but the email addresses are completely different." I don't know whether this fact is material to the diagnosis, but I thought I should point it out as a possible clue.
Thanks, I've missed that point. I'd expect the matching process being based on the e-mail address rather than the display name, but maybe that's not the case, though some matching against the address is performed in the identity look-up code: http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#1963 I can't follow what is done there though with respect to setting the actual sender identity.
(In reply to Wayne Mery (:wsmwk) from comment #4) > Tony may have some insight. > I don't use global inbox Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111014 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111014003008 I use the Global Inbox, and SeaMonkey trunk rather than Thunderbird release (shouldn't make much difference though) but most of the time, the "From:" line when replying is the same as whatever the mail being replied to was sent to. The rare times that it isn't, I notice it (if at all) by a "From:" address (e.g. the nobody@localhost address used for the internal Linux Movemail account) being rejected as invalid by the SMTP server. No insight here, sorry.
(In reply to BayouBill from comment #7) > Not 100% true. There is _one_ commonality, as stated in my original post: > "The only thing that is the same between the identity it should use and the > identity it does use is the From name (e.g. "Firstname Lastname"), but the > email addresses are completely different." I have the same problem after "Reply" on just received messages in inbox or local folders: bug 704613 At me, also identities with different display name, but also ones with matching, are wrongly preselected in the composer's From: field. In TB 7 the problem occurred rare, but in TB 8 it happens terrible often now.
In this context I like to share, that TB's Help points to a pretty useless site: http://support.mozillamessaging.com/en-US/kb/configuration-options-accounts. Nowhere I can find what "Set the default email account" really effects besides the fact, that the concerning account is shifted to the top position in the left pane of TB's main window.
This is an ongoing bug that has been around in the Mail core for about 5 years. It is common to bugs 36482, 79455, 122352, 200872, 264626, 327713, 525787, 279846, 394216, 515004, 592935, 466837 that I know of and probably a lot more. No one seems to be interested in fixing this MAJOR bug.
Component: General → Untriaged
Do you still see this in version 17 or newer? If not, please close by setting status to resolved, and resolution to worksforme. If it fails, please supply additional information. Thanks
Whiteboard: [closeme 2013-04-20]
(In reply to Wayne Mery (:wsmwk) from comment #14) > Do you still see this in version 17 or newer? > If not, please close by setting status to resolved, and resolution to > worksforme. > If it fails, please supply additional information. > Thanks Seamonkey 2.17 seems to work correctly with initial testing as long as multiple identities are set up on the first account. I would prefer to do some more testing before saying the bug is resolved.
(In reply to David from comment #15) > (In reply to Wayne Mery (:wsmwk) from comment #14) > > Do you still see this in version 17 or newer? > > If not, please close by setting status to resolved, and resolution to > > worksforme. > > If it fails, please supply additional information. > > Thanks > More testing confirmed the problem still exists. The correct from address and formating etc is determined from the to address of the incoming email, but if the email is moved to another account inbox, then it still uses the to address of the email rather than the inbox where the email is stored to determine the from address etc.
ref comment 3
Whiteboard: [closeme 2013-04-20] → dupeme
(In reply to David from comment #16) > but if the email is moved to another account inbox, then it still uses the > to address of the email rather than the inbox where the email is stored to > determine the from address etc. Suggested solution: In such and similar cases TB should warn the user, e.g. insert a red blinking message label above the From: field. My suggestion for the priority to choose the From: identity on Reply (All): mail in "Local Folders" or global inbox ? + To: identity matches any alias of X-Account-Keys account ? + choose To: identity - To: tag exists ? + To: identity is valid for any account ? + choose To: identity - From: tag exists and is valid for any account ? + warn: "Check sender identity .." and preset From: identity - warn: "Check sender identity .." and preset X-Account-Keys default - warn: "Check sender identity .." and preset X-Account-Keys default - warn: "choose sender identity:" and preset X-Account-Keys default - X-Account-Key matches enclosing folders account ? + To: identity matches any alias of enclosing folders account ? + choose To: identity - warn: ".. originally sent to a@b.c" + preset accounts default identity - To: identity matches any alias of enclosing folders account ? + choose To: identity - To: identity matches any alias of X-Account-Keys account ? + warn: " .. " and preset enclosing folders default identity - warn: "choose sender identity: .. " and preset encl. folders default
Depends on: 704613
A much simpler solution would be to put an option to ignore the X-Account-Key. Take the from address & formatting info from the account the email is stored in.
(In reply to David from comment #16) > More testing confirmed the problem still exists. The correct from address > and formating etc is determined from the to address of the incoming email, > but if the email is moved to another account inbox, then it still uses the > to address of the email rather than the inbox where the email is stored to > determine the from address etc. What it does is, if there's an account key set, all identities of that account will be checked for a match. If no account key is set, it will check all identities globally. In case there's no match, the default identity is used. http://mxr.mozilla.org/comm-central/source/mail/base/content/mailCommands.js#100
Surely the idea of multiple accounts is that an account is setup for each email identity that the user has, ie Home, work, charity etc. Then it make sense to keep the mail relating to that identity in folders in the relevant account, ie any work related emails would be kept in the work\inbox, or work\sent etc. Emails could get there by either downloading from different pop servers, or by dragging from another account if all incoming mails are consolidated to one server. Composing a new message when a certain account is highlighted works correctly, ie the correct formatting is selected (text/html) and the correct from address is selected. When it comes to replying or forwarding a message that is highlighted, it should work the same way, BUT IT DOESNT !! Please correct me if I am wrong, but I believe the solution is blatantly obvious and very simple: 1 Ignore the X-Account-Key, or add an option to ignore the X-Account-Key 2 When replying to a message, or forwarding a message, use the same subroutine that creates a new message. That correctly Opens a new edit window Uses the correct formatting Uses the correct signature, CC and Bcc addresses Uses the correct From address To cater for different setups/users then it would be sensible to have some options that the user could select in their preferences.
I have problem with wrong address used for reply or forward messages when I'm as a CC recipient. This problem comes when I do RE/FWD from main window only. When use RE/FWD from opened message, than From address is used correctly. This problem is in Thunderbird for years, but still not solved. Last tested on version 38.2.0, message have X-Account-Key.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: