1125978 - 31.2 and after doesn't "Reply" from the correct (of several) addresses

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, defect)

Description

[track21_comm]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

To reinact/reproduce:
1. Have multiple email addresses set up in (handled by) Thunderbird. (There are six, here.)
2. Download emails from address that is not the first listed.
3. Reply to one of those emails just downloaded.



Actual results:

In 24.6.0, this works just fine.  In 31.2, the problem showed up.  Still there in 31.4.

Reply is "From" the first listed address, not the actual "To" address of that note, which might be the 2d or 3d, etc., address as sequenced in the Thunderbird display.


Expected results:

Reply should place as "From" the address to which that note was actually sent.  This wasn't as problem in 24.6.

Comment 1

[track21_comm]

2016 April 12

Recurring problem.  Presently fixed, ultimately, by editing the prefs.js file.

Background.  Recently had new problem with delete.  Delete wasn't working.  Part was likely "too many emails" in the system.  Part was definitely an add-on: "confirm delete." Removing the add-on (after massive archiving project) has fixed the problem of inoperative delete and inoperative move.

In the process of fixing the move/delete problem, reinstalled 24.6.0, which was likely unnecessary.  Where 24.6.0 has been quite stable on correct "from" address (message filters from multiple accounts will send incoming emails to same folder in Local Folders), it, too, started producing wrong "from" addresses. Thus, it wasn't just a ver. 31.x problem.  Turns out the this wrong "from" address problem has been around for at least ten years, now.  Most often "Unconfirmed" in nature.

Partial resolution.  Finding that many people have reported a similar issue, namely, given multiple accounts, wrong "from" address is used in reply email, and finding the same condition of "Unconfirmed," this hopes to add some more details so as to identify better the problem within the Thunderbird programming (or in its installation, or work arounds, or add-ons, etc.).

It seems that what is changed (or at least affected) is the X-Account-Key (in the email header).  That is tied to an "account number" (account1, account2, account3, etc). The account number, in turn, is tied to an "id number" (id1, id2, id3, etc.).

The idN's are not necessarily directly numbered with the added accounts, in that id2 may be the Local Folders number.  Thus, with six accounts, there are seven accountN's and seven idN's.

In one particular bug/assistance thread, the TB user had 8 accounts, with a similar problem (wrong "from" address in reply), and he ended up modifying javascript text to solve his issue.  In that thread, the "expert(s)" indicated that altering the javascript in that manner was never recommended.  To some of us, then, that's the clue on exactly where to start looking (next).  It happens that altering the javascript, namely prefs.js, is exactly what ended up fixing the problem experienced recently with 24.6.0., thus, the problem reported in/for ver. 31.x.

There ended up being two of the six accounts in which the idN was switched.  The accounts of "account5" and "account4," with idN's id4 and id3, respectively, were switched (somehow).  Is this a by-product of a different "Add Account" sequence in the re-install?

Whatever the ultimate cause of the switched idN's, thus the mis-assigning of the X-Account-Key (accountN) to the idN used by prefs.js, editing the prefs.js file, by switching the idNs for those two accounts, has fixed the problem experienced with the wrong "from" address in reply (with multiple accounts).

Don't have any ver. 31.x installed. Do have ver. 38.7.2 installed, and it, too, was not correctly using the "from" address, and yet is now identifying correctly the "from" address where the same Local Folder subfolder contains emails from multiple accounts and the To address isn't really known (e.g., BCC note to a list).

Don't have time in the immediate present to do a reproducibility study.  Something changed either the "accountN" or the "idN" in the prefs.js file.  One thought is the re-install and the sequence for adding the additional accounts.  (The accounts show up now in the very same sequence they did originally, but there may be some other way than account installation sequence to produce that presentation sequence, e.g., altering the prefs.js string "value" that indicates the presentation sequence, e.g., from account1,account2,account3, etc., to account3,account2,account1, etc.).  Whatever the cause may turn out to be, the fix involved studying the wrong "from" address error for a pattern, finding a pattern, and then manually editing the prefs.js file, by switching the "idN" for the two accounts that were affected.

Comment 2

[track21_comm]

2016 April 13

Problem.

Still had an issue to fix.  Changing the idN values was a partial fix, but the serverN and accountN data on the two accounts was still not matching.  The X-Account-Key and the "From" address were matching, but the Account Name wasn't matching with the (correct) From email address.

The idN change of the prior entry was reversed (system restored to "original" settings).


Solution.

The present fix involves a change in mail.accountmanager.accounts:

FROM account1,account2,account3, account4, account5, account6 (no spaces in actual "value" setting)

TO   account1,account2,account3, account5, account4, account6 (use of space for emphasis only; no spaces in actual "value" string)


Details.

For this problem and solution, the main items in the prefs.js file are these:

mail.account.accountN.identities

mail.account.accountN.server

mail.accountmanager.accounts



.accountN                       .identities  .server 
account1     email1             id1          server1
account2     [Local Folders]                 server2
account3     email2             id2          server3
account4     email3             id3          server4
account5     email4             id4          server5
account6     email5             id5          server6
account7     email6             id6          server7

accounts 4 and 5 were the ones somehow switched.

Global change on id3 and id4 in prefs.js was only a partial fix.

That change was reversed.

Present working solution is in resequencing the .accountmanager value, switching account4 and account5, illustrated above.

Comment 3

[track21_comm]

2016 April 13

Optimism reigned supreme.

However, the testing continued.  We're right back back to the original problem.  Now, with 38.7.2. AND WITH 24.6.0.


Problem.

Multiple accounts.  Here, 6.

Emails are filtered from all accounts to subFolders in Local Folders.  Some accounts filter emails to same subFolder in Local Folders. That subFolder may have emails, say, from account1, account3, and account5.

The Reply to emails filtered to that Local subFolder are "From" the wrong email address/account, not the address/account indicated by the X-Account-Key in the email header.

Now, even ver. 24.6.0 also has this problem.  Later versions also still have this issue.


So, from the top.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

[from http://www.quirksmode.org/js/detect.html]

Steps to reproduce:

1. Set up multiple email addresses/accounts (this is different from multiple profiles; here, it's one profile that accesses multiple email addresses/accounts) in Thunderbird. (There are six addresses/accounts, here.)
2. Download emails from an address that is not the first listed. Or, Download emails from various addresses, including the first/default one, and filter all to a common subFolder in Local Folders.
3. Reply to one of those emails not from the first-listed account that was just downloaded and filtered to the subFolder in Local Folders.
4. Check the "From" address.  


Actual results:

The X-Account-Key value in the downloaded note being replied to is not always consistent with the "From" address in the Reply note.  In 31.2, the problem showed up.  Still there in 31.4.  Still there in 38.7.2.  Now experiencing this in 24.6.



"From" address in the reply is not the actual "To" address of that note, i.e., not the X-Account-Key account that received the note being replied to.


Expected results:

The default "From" address in the Reply should be the X-Account-Key "accountN" to which that note was actually sent.  That "From" address in the Reply should not default to the first-listed account.  This wasn't as problem in 24.6, until today, and now it's a problem even in 24.6.

Comment 4

[track21_comm]

2016 April 13

Testing on 24.6.0.  It's operating normally, for the Inbox test.

All in 24.6.0.

Closed/reopened TB.  Preferences-->Advanced-->Config Editor-->

Changed (toggled) accessibility.accesskeycausesactiviation (topmost toggle item in the list) 

Changed it back.

Exited. (Exited, Exited.)

Quit TB.  Restarted TB.

Sent test emails, one from each account (to the next account in the list, and last sent to first).

All emails delivered to the proper Inbox. All emails showed correct X-Account-Key value for "From" address.  All Reply notes defaulted to correct "From" address.

Comment 5

[track21_comm]

2016 April 13

Testing.

38.7.2, 24.6.0 (both).

In the subFolders in Local Folders, some "From" addresses/accounts show up correctly for Reply; some don't.  Several common subFolders tested.  Each tested subFolder receives filtered (incoming) emails.  Some from one address/account; some from more than one.

The one material commonality found, so far, is that the "From" addresses that show up correctly in the Reply notes are in notes for which the address/account shows up on the "To" list in the original email received.


38.7.2, 24.6.0 (both).

Spot, random check/test on "From" address in Reply using Inbox emails.  All "From" addresses for replies to notes in Inboxes operate correctly for all six accounts/addresses.

Comment 6

[track21_comm]

2016 April 14

Testing.

Progress Report.

Started from scratch.  Original install (circa 2005?) on G5 (PPC processor) (OS X 10.5.8).  Apple has, of course, abandoned us.  Did the original install, copied over to the Intel system, have settings that wouldn't have been set had the original install been on an Intel system in the first place?

Partial good news -- Apparently no difference.

To test the question, installed TB 3.1.20 (on the Intel system) (MacBook) (10.6.8).  No add-ons. No address book importation. Nothing but thunderbird.dmg file.

Set up the first account and Local Folders.

In that original G5 install, account1 was Local Folders, not the email account.  Therefore, just to find out if it matters, the following manual, hands-on, hard-coding of the prefs.js file, through Config Editor, was engaged:

originally, as set by 3.1.20 (on Intel system)

mail.account.account1.identities        id1
mail.account.account1.server            server1

mail.account.account2.server            server2  (no associated idN, of course)

mail.accountmanager.defaultaccount      account1
mail.accountmanager.localfolderserver   server2


manually changed to these variables and values

mail.account.account1.identities        [reset] (which deletes it, of course)
mail.account.account1.server            server1

mail.account.account2.identities        id1
mail.account.account2.server            server2

mail.accountmanager.defaultaccount      account2
mail.accountmanager.localfolderserver   server1



No inclusion of emails, yet, for either the first email account or Local Folders



"Upgraded" to TB 8.0.  In other words, kept "Thunderbird.app" as the file name, and overrode 3.1.20 with 8.0.

prefs.js remained as set.

No inclusion of emails, yet.



"Upgraded" to TB 12.0.1 (overriding 8.0).

[same]



"Upgraded" to TB 17.0.9 esr (overriding 12.0.1).

prefs.js still as set manually.

Here, the rest of the email accounts were added.

mail.accountmanager.defaultaccount    account6  (which, in 17.0.9, is displayed as the topmost email account in the vertical listing in the left-most TB display panel).

Also, all emails were imported (copied) into their respective folders, both for the accounts and for Local Folders.


Tested the Reply feature.  It worked as expected/hoped.

In this setup, the Reply "From" address is correct (in all circumstances).  Of course, it's correct out of the Inboxes, and, key, it's correct for the notes filtered to subFolders in Local Folders.  Thus, the X-Account-Key value is read correctly and consistently, meaning that notes incoming from lists, e.g., those received as BCC, that are filtered to subFolders in Local Folders, when replied to, are defaulting to the correct "From" address, in all circumstances.

Does it matter that Local Folders be account1 and server1, as were the setup defaults on the G5 (PPC) system?

If so, does that have to be set from "ground zero" and built upon, or may the TB user pick the starting version of a bit more contemporary nature and set those items in that manner?


It comes to mind to mention that given the problems with 31.x, 38.7.2 was not being run as an "override" to 24.6.  Would 38.7.2 have these issues of wrong "From" address in the reply (as 31.x had) if it were installed as an "override" rather than as a separate program (separate install, i.e., not "Thunderbird.app" but "Thunderbird 38_7_2.app")?  The correct "From" address is hugely paramount, and there's now a level of distrust such that risking a non-functional override is risking some amount of time in resetting the email system.  Of course, having the backup of the functional setup at the ready would save that correction time, but, still, there'd be the need for the correction time, which is avoided by running the newer versions as separate apps.  In other words, is this problem self-generated by not trusting the newer TB version to "do right?"


What is being reported is that having started from absolute scratch, and getting to 17.0.9 esr by means of the route described, the filtered notes, both those with stated "To" addresses and those sent "Bcc," when replied to, are using the correct "From" addresses. 

There are no add-ons (extensions, .xpi files) installed, at all.  The address book info is also incomplete.  This allows us to see which of those may be breaking the system.

Comment 7

[track21_comm]

2016 April 14

Testing.

"Upgraded" to TB 24.6.0 (overriding 17.0.9 esr).

All test results are positive.  "From" address in reply notes (Inboxes and Local Folders) is correct in all notes tested, which was a rather thorough sampling.

Still no add-ons or address books imported.  Just email accounts, Local Folders, and emails (with attachments).

Comment 8

[track21_comm]

2016 April 14

Testing.

Just for kicks, "upgraded" to 31.2.0.  This is the version that motivated reverting to 24.6 (and submitting this Bug Report).  (This email issue has already cost a full week.  What's another hour?)

Inbox test.

Notes in the Inbox addressed "Bcc" were addressed correctly in the "From" line in the reply note.


Filtered note test.

However, in the subFolders in Local Folders, the "From" addresses were consistently incorrect in replies to notes received as "Bcc."  In this particular instance, the errant "From" address is the first address set up, i.e., the id1 address (which, due to the hard-coding in prefs.js early on, is associated with account2 and server2).

To summarize for purposes of reproducibility, we have this:

1.  Start with a version of TB that properly addresses the reply notes in all circumstances, in particular notes received as "Bcc," both regarding notes still in the Inbox as well as notes relocated to other folders, either associated directly with the Inbox or in Local Folders.
2.  In that properly working version, have several accounts, e.g., six.
3.  Set up filters to relocate incoming notes to subFolders under Local Folders such that a single subFolder could receive notes filtered to it from one, two, or more accounts.
4.  Reply to the notes sent "Bcc," not only those still in the Inbox (and folders directly associated with that Inbox) but also those relocated to the subFolders in Local Folders.

5.  Now, "upgrade" to 31.2.0 (overriding the working version) and run the tests again.


Expected result: "From" address in a reply note that correctly identifies the address to which the note was sent.

Present result:  Bcc notes still in the Inbox (not filtered) are handled correctly.  However, Bcc notes that are filtered get the (same and) wrong "From" address in the reply note.  Here, that wrong "From" address is always the one associated with id1 in the prefs.js file.

Comment 9

[track21_comm]

2016 April 14

Testing.

Another one just for kicks (because there doesn't seem to be much discussion on testing for this problem; identification of the existence of the problem -- yes;  testing -- not so much). Hopefully, this provides useful information.

"Upgraded" the non-working 31.2.0 version with 38.7.2. 

This upgrade does not fix the problems started in 31.2.0.

In fact, the problem is even worse.


In 31.2.0, some filtered notes still produced a correct "From" address in the reply.  However, by getting into 38.7.2 in this manner, no filtered note gets the correct "From" address.  In all cases in notes in the subFolders of Local Folders, the "From" address, whether the recipient is "To" or "Bcc," is the id1 address.  Thus, where the "To" notes were addressed correctly in 31.2.0 (and the "Bcc" notes were not), replies to notes whether coming in addressed as "To" or "Bcc," are wrongly addressed in the "From" address.

Comment 10

[track21_comm]

2014 April 15

Testing.

Restored the working 24.6.0 set up.  "Upgraded" directly to 38.7.2.

Ver. 38.7.2 has some major "From" address problems.  If the incoming note is filtered to a subFolder under Local Folders, the "From" address in the reply is the id1 address in all situations.  Even if the filtered note is specifically "To" an address, the "From" address in the reply is the id1 (which, here, is account2, server2) address.

Even without the complications found in 31.2.0, 38.7.2 is horrible in this feature.  All "From" addresses for replies to notes filtered to subFolders in Local Folders are the same, and it's the address associated with the first account set up into TB.

The solution for 31.2.0 may also shed light on the solution for 38.7.2.

There's discussion in various forums about the programming desire/goal for the note to take the identity associated with the "moved to" folder.  That's fine were the note is moved to an Inbox or a folder directly associated with that Inbox (e.g., Drafts, Sent, etc.).  But, where the note is filtered to a subFolder of Local Folders, the note must retain association with the original Inbox, i.e., the X-Account-Key value is expected to remain the same.


This is likely the final entry for this phase of this bug report.  The email address for getting in touch is listed.  Should additional info be useful, what is available will be provided as promptly as possible.  The working version of 24.6 is restored, and everything reported about the wrong "From" address in the replies in ver. 31.2 and later is still very much true.  The problem was reproduced, as described above.  (The "upgrades" were not accomplished by the upgrade channel but rather by download from  http://ftp.mozilla.org/pub/thunderbird/releases/  and then installed per than override process.)   At least 31.2 sets the correct "From" address for the notes that come in "To" the address, whether filtered or not filtered.  But, while ver. 38.7.2 set the right "From" address for notes received "Bcc" that are still in the Inbox, it doesn't set the correct "From" address for filtered notes, not even those with the recipient address showing up in the "To" listing.

Comment 11

[Wayne Mery (:wsmwk)]

Does this problem occur if you start with a new profile?
 https://support.mozilla.org/en-US/kb/using-multiple-profiles

Comment 12

[track21_comm]

March 13, 2017

Sorry for this delay.  Somehow, I thought requests came in by email, and if it does, and if it did, I missed it.

Yes, a problem occurs.  New profile does not fix this.

Just tried "new profile," again, in Tbird 47.5.1 and 48.0.  Still having the exact same issue that 24.6.0 didn't have but which all versions afterwards have had.

Reason for checking on this bug, and, again, I apologize for this delay, is that both 47.5.1 and 48.0 (Mac OS X 10.7.5) still have the identical issue.  In other words, it still persists as a (major) problem.

Let's try this for a problem (re)description.  Recipient has six email addresses.  Correspondent A has three of those, each for a different line of communications.  On any given day, Correspondent A has reason to send one note to each of those three addresses.  Recipient receives all notes from Correspondent A and for each different email address Recipient filters notes from Correspondent A to a common folder in Local Folders named "Correspondent A."  But, when Recipient responds to Correspondent A, there's one address that shows up as the "From" address, regardless of which address Correspondent A used to send the notes.  By default, all of Recipient's replies (for all notes in all folders in Local Folders, regardless of actual "To" address) go to the "default" address, which is typically the address for the first mail account set up in TBird.

In 24.6.0, for all folders in Local Folders, Tbird reads the "To" address correctly and uses that "To" address as the "From" address in the reply note.