Open
Bug 1173279
Opened 10 years ago
Updated 3 years ago
replies on an accout2-emails use account1 email
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: orwel01, Unassigned)
References
(Blocks 1 open bug)
Details
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. "@abc.com") which used own inbox. I have also an account 2 (e. g. @gmail.com), 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 @gmail.com frotm the address @abc.com if you forget to change the "from" account.
Expected results:
By answering an email received on account2 (gmail.com) 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.
Updated•10 years ago
|
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", "xxxx@gmail.com") 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...
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•