890941 - reply does not use correct account (where email is stored)

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, defect)

Description

[john]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

I have multiple accounts.   These accounts have moved from machine to machine, some crashed, and the profiles are moved, over the years.   The accounts are NOT in the same order over the years, and have different "accounts" in the email header.

Today, I opened an older email, originally received on a prior laptop, and hit reply

I also note that, from time to time, I will receive an email sent to me on the wrong account, and I will move it to the correct account.   I used to do this to simplify searches, and also on the assumption that if I replied, it would go to the correct account.   For some reason, I thought it worked that way in recent prior TBird versions, that is within the last year or so, following long ago bug reports, though now I am not sure.


Actual results:

The send-to account does not match the account in whose folder the emails sits.  This surprised me, and led to a bit of research.

For reasons stated above, the x-account-key for that email does NOT match the current account key for the folder in which it sits.   (Note: while the account key doesn't match, the email is in the proper inbox folder)


Expected results:

When I reply to an email which is stored in a folder, TBird should use the email account connected with the stored location.

I am assuming that TBird currently uses the Account-Key found within the email header, and if that key exists, uses the current matching account key

This also makes me wonder what happens if the account key doesn't currently exist? (similar to when one opens a brand new email ?).   Or, what happens if it is an email that is in a NON-account folder, an archive, or other folder in the local folders?   Or if the email is imported from another email client?

I would have assumed that there would be some reliance on the folder location of the email, in these cases, and wonder why it doesn't in my bug-case.   This leads me to believe that the fix would be relatively minor, since the code for 'default' emails' send-to must exist in various forms in various places.