Open Bug 1173279 Opened 5 years ago Updated 3 years ago

replies on an accout2-emails use account1 email


(Thunderbird :: Message Compose Window, defect)

38 Branch
Not set


(Not tracked)



(Reporter: orwel01, Unassigned)


(Blocks 1 open bug)


User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

I have an account1 (e. g. "") which used own inbox. I have also an account 2 (e. g., which use the inbox of account1.

Actual results:

If I receive an email on account2, it is correctly put in account1-inbox. When replying on this email, the "From:" does not use account2 but changes to the account1. So you answer an email you received as frotm the address if you forget to change the "from" account. 

Expected results:

By answering an email received on account2 ( TB should use ("From:") the account2 and not switch to account1.

Last stable version which is not affected: 24.8.1
Last beta version which is not affected: Thunderbird Setup 29.0b1
- this versions use the correct account for answering

Every TB higher (beta or stable) use the wrong account. Last tested with 31.7.0/38.0b6

In config file I see this info about account2: it is deferred to account1.
account2 is not a alias of account1, it is a separate account, only uses the inbox of account1.
Component: Untriaged → Account Manager
Please select a message received via account2 and view its source (Ctrl-U). Look for the row looking like "X-Account-Key: account1" is the value of the key correct? I.e. does it correspond to your account2?
You can see in the prefs.js file in your TB profile to see which key corresponds to which account.
Component: Account Manager → Message Compose Window
Hi, email received to gmail (in my bug report announced as account 2) has in ctrl+u: "X-Account-Key: account7". In keyconfig I found account7 has id4 and ("mail.identity.id4.useremail", "") so it seem the answer is YES. I checked this in TB 24.8.1 and 38beta6, it is the same.
As mentioned until TB 24.8.1 the behaviour was always correct.
I confirm this behavior in actual version of TB 38.3. Could somebody take a look on this, due this bug I am still on version 24.8.1...
still present in 45.1.1.

more than 1 YEAR OLD BUG....
Blocks: 699681
You need to log in before you can comment on or make changes to this bug.