Open Bug 327713 Opened 18 years ago Updated 2 years ago

From: address in reply is always set using X-Account-Key: header, even though mail folder owner account does not use "Global Inbox"

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

People

(Reporter: cslee, Unassigned)

References

(Depends on 3 open bugs, Blocks 1 open bug,
URL
)

Details

(Whiteboard: [gs]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Thunderbird version 1.5 (20051201) - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

When I reply to a mail in one of my secondary accounts the from address is automaticaly picking up the main account.
This occours when the To address in the received email does not contain the account e-mail address.
e.g.
Main account: cslee@main.com
Secondary:chris.lee@secondary.com
Address in mail I must reply to:
 * chris-list@secondary.com 
 * users@mailinglist.com (i.e. this happens when I am BCCd)
Auto Selected in new mail window: cslee@main.com

Reproducible: Always

Steps to Reproduce:
1.select a mail in a secondary account (one with To: address not in account settings)
2.select reply or reply all
3.new mail shows main account from address
Actual Results:  
new mail shows main account from address

Expected Results:  
New mail should show From: address for the account I am working in.
Related to/duplicate of bug 318195?
This just started happening to me.  I got a new laptop, running Windows XP Pro, installed Mozilla & Thunderbird, and had no problems --- until I applied a filter on one of my secondary accounts, to filter by addressee into another secondary account.  

Now, even if I remove the filter, any time I hit "Reply To" in a mail that's come into the initial secondary account, is listed as being from the second secondary account -- just as described in this bug report.

It's very annoying, but can be worked around, as long as you remember to change the "From" addressee in the drop down box as soon as you hit "Reply".
As far as I know, and my test result says, Mozilla mail and Thunderbird determines pre-set "From:" of reply based on X-Account-Key: header which is put when mail download, after Global Inbox support.
Value of X-Account-Key: is prefs.js entry name("accountX" part) of account who received the mail.
 - mail.account.accountX.identities
 - mail.account.accountX.server
This is required for Global Inbox support, since all mail is moved to Global Inbox(usually "Local Folders"). 

This causes problem if user creates "Multiple Identities" like environment by himself, by defining multiple accounts and filtering mail.
  Even when user moves/filters a mail of "To: mailaddr-2", which is received
  by account-1, to folder of account-2, initial setting of "From:" on reply
  always becomes "mailaddr-1", which is mail address of main identity of
  account-1.
  (This is a problem reported to a forum in Japan.) 

Chris Lee and Kelley, see X-Account-Key: header of the mail and see prefs.js(or "Config Editor").  
Can above descrition explain your problem?

Above problem can be resolved if "default identity for each mail folder" will be implemented.
But before Global Inbox, as far as I remember, the pre-set "From:" was mail address of account where the mail is held, because of no "X-Account-Key:".
So I think, if no "Global Inbox" is choosed for an account, X-Account-Key: header should be ignored on reply, or option to ignore X-Account-Key: header should be provided.
Yes, that is it, some more testing and I see you are correct.
The X-Account-Key: header is causing the problem.
Even though I am in a different account folder structure and do not have global inbox it still uses X-Account-Key: to select from address.

I think it should use X-Account-Key: only when in global inbox otherwise use account address.

Updating Summary to reflect actual problem
Summary: Reply to mail in secondary account gets from: address from default/main account → From: address in reply set using X-Account-Key: header even in other accounts not the "global inbox"
Confirming, and changing to Product=Core because problem occurs on Seamonkey too.
Status: UNCONFIRMED → NEW
Component: Message Compose Window → MailNews: Composition
Ever confirmed: true
Product: Thunderbird → Core
Version: unspecified → Trunk
Assignee: mscott → nobody
Severity: normal → minor
OS: Linux → All
I agree with m-wada's comment about per-folder identities being a solution for this. I don't like always ignoring the x-account-key for everything but the global inbox. Even though the current behaviour is wrong for you, I'm not at all convinced that using the identity for the server that the mail arrived in is not more often what users would want. Adding a pref to turn off this behavior is a possibility, but I think I prefer per-folder identities as being more generally useful.
Adding Bug 200872 in "Depends on:", according to comment #6.

>I don't like always ignoring the x-account-key for everything but the global inbox.

Even you dislike, it was behaviour of Mozilla 1.0. ( Who implemented it? :-) )
For old user like me, this bug is "regression over Mozilla 1.0 by Global Inbox". 
 Before Global Inbox, lack of "per-folder identities" feature can be worked
 around by defining multiple accounts and filtering mail.
 This had been also a workaround of lack of "Multiple Identitiy" for long time.
 But after Global Inbox, this workaround won't work.
 (I was also one of victims of this spec change by Global Inbox feature.)
If "per-folder identities" has very low priority, please reconsider ignoring of X-Account-Key, which seems to be easier to implement than "per-folder identities", for small number of users who have loved Mozilla family's mailer for "large number" years.
Status: NEW → ASSIGNED
Depends on: 200872
Status: ASSIGNED → NEW
(In reply to comment #6)
> I don't like always ignoring the x-account-key for everything but the
> global inbox.

Oh, I've forgotten IMAP cases.
David, please note that some issues occur If IMAP.
   - If accountX in Account-Key: is not defined in other PC,
     error occurs when try to reply to the mail at the other PC.
   - If accountX in Account-Key: at other PC is for different mail address,
     "From:" in reply becomes different one from "To:" the of mail.
See Bug 279846(It was also reported to Bugzilla Japan last year.) or Bug 295956. 

Please read "accountX in Account-Key:" in comment #8 as "IDxxx in 
X-Identity-Key: for accountX in X-Account-Key:".
When "accountX in Account-Key:" is not defined at other PC, default account is used(then different mail adddress is pre-set on reply).
Sorry for spam.

IMAP case are different(mainly on X-Ident-Key:IDxxx), but "ignoring of X-Account-Key:" can be relief in some cases.
Hello WADA and others,  I'm a bit lost as to how to work around this problem so that when I hit "Reply" the From account accurately reflects the original recipient of the email.  I understand I need to modify the perfs.js file, but in looking at mine, I don't have an entr for X-Account or any type of account setting. 

Could someone please post an appropriate edit to the perfs.js file (if that's the best work around) or post some other work around?

Thanks,

Kelley
(In reply to comment #10)
> I understand I need to modify the perfs.js file,

There is no workaround by prefs.js modification when POP3/X-Account-Key: case.
Bug 279846 and Bug 295956 are Draft mail(X-Ident-Key:IDxxx is used) on IMAP server case, and problem when different mail.identity.idNNN.xxxx is defined for a mail address at different PC.
Sorry for misleading comment.

Available workarounds are:
(1)Never forget to change "From" addressee in the drop down box, as you know.
(2)Change all "X-Account-Key: account1" line in <Folder_Name> file of account2
   to "X-Account-Key: account2" by text editor, SED, Shell/Perl Script etc.
   and delete <Folder_Name>.msf file, then restart Thunderbird.

(Correction of a part of my comment #11)
> There is no workaround by prefs.js modification when POP3/X-Account-Key: case.
This was incorrect.
There is third way, editing of prefs.js.
 (3) Change all of N in mail.account.accountN.xxx and all of M in 
     mail.identity.idM.yyy, and change all value of mail related entries which
     refer to above entries (e.g. value of mail.accountmanager.accounts,
     mail.accountmanager.defaultaccount, mail.account.accountN.identities),
     so as to keep consistency with X-account-Key values in mail data,
     without breaking consistency among all mail related prefs.js entries.

Mismatch between accountM of prefs.js and accountN of X-account-Key: may occur  when re-definition of accounts.
(e.g. Profile re-creation and account re-definition, then mail data copy from back up, in order to transfer to new PC.)
This mismatch can occur even when Global Inbox of POP3.
And when Global Inbox, if workaround (1) is not acceptable, workaround (3) is usually required, because workaround (2) is usually difficult due to mixed X-Account-Key: values.
I've found interesting document - "Multiple Identity Support". 
 ( http://www.mozilla.org/projects/thunderbird/identities.html )
This document, which starts with "Tb 0.5 introduces a new feature", says :
> There *ARE* several components of this feature:
>   Intelligent identity detection when replying to or forwarding a message.
>   Thunderbird scans the recipients of the message and chooses the identity the
>   orignal author used when sending the message to you. This identity will then
>   be the default identity in the compose window.
Where have all the "Intelligent identity detection" components gone? Grave yards?
 
Further evidence of why this is a problem.

My preferred method of operation is to forward all my secondary mail accounts to one main account, and download all mail from there.  Mail is then moved to its appropriate account in TBird via filters.  This simplifies downloading mail, and allows all mail to go through my main server's excellent virus filtration and spam marking.  

Since ver 1.5, replies to mail moved into one of the secondary accounts thus receive the default identity for the [i]downloading account[/i].  I can change identity manually of course, but this is a big pain in the [insert anatomical part of your choice] and is all too easily overlooked.  I am constantly sending mail out from unintended accounts, and consequently, the replies come back to the wrong account too.

To get around this problem, I am now no longer forwarding mail to my main account, and am downloading all my mail directly from each secondary account.  This allows correct identity assignment when replying, but I have lost the benefit of the excellent virus/spam filtering/marking at my main account for all my secondary accounts.

Another possible solution, not suggested yet, would be the ability to change the X-Account-Key value as part of a filter operation.  (Or even just the ability to ADD a custom operation as we can currently add a custom filter criterion.) 

As a workaround until something better is devised, is there any way to prevent the X-Account-Key from being inserted in the first place?  Perhaps a user.js entry?
I'm not entirely sure if my case is relevant to this particular bug; if it's not, someone please generate a unique bug from this comment.

"Clicking mailto: link does not retain account identity in Compose window"

I find it perplexing that when I'm reading an e-mail in one account, and I click on a mailto: link in that e-mail, when the compose window comes up, my default account is selected as the From: address, not the account that I was just reading.  This has burned me on more than one occasion.  I've tried using the "Correct Identity" and "TB Change From and Fcc on Compose" extensions, but they don't provide this behavior, and frankly, I think Thunderbird should be behaving this way by default.  Comments would be appreciated.
Is there a way to prevent X-Account-Key being used and forcing the default identity for the account on each mailbox on reply?

I just rebuilt all my prefs because of 352801 and my reply-addresses are a mess... :-(
*** Bug 318195 has been marked as a duplicate of this bug. ***
*** Bug 358324 has been marked as a duplicate of this bug. ***
(In reply to comment #14)
> To get around this problem, I am now no longer forwarding mail to my main
> account, and am downloading all my mail directly from each secondary account. 
> This allows correct identity assignment when replying, but I have lost the
> benefit of the excellent virus/spam filtering/marking at my main account for
> all my secondary accounts.

Forwarding all mail, including spam, does have some detrimental effects, the worst of which would be the site doing the forwarding ending up in somebody's RBL.  This happened at my main mail provider -- they are actively anti-spam, but Earthlink blacklisted them anyway because of the forwarding.


> Another possible solution, not suggested yet, would be the ability to change
> the X-Account-Key value as part of a filter operation.  (Or even just the
> ability to ADD a custom operation as we can currently add a custom filter
> criterion.) 

That's a good idea; how about opening a separate bug (enhancement) for that?
I'd also like to see an enhancement that would allow me to select my default "from" address for a message replay be the same as the "to" address on the message I'm replying to. In my case I have a number of aliases that all go to the same account, but the "to" address reads as whichever alias the e-mail was addressed to. I have all the aliases set up as possible "from" addresses in the pull-down, but it would be helpful if the default selection was whichever address the original e-mail was sent to.
(In reply to comment #20)
> I'd also like to see an enhancement that would allow me to select my default
> "from" address for a message replay be the same as the "to" address on the
> message I'm replying to. 

Wouldn't we all?  :-)

However, see the comment posted by Magnus Melin https://bugzilla.mozilla.org/show_bug.cgi?id=358324#c8

The solution he offered solved this for me when I posted this same request; so it might work for you and others who end up in this no-mans-land of moribund RFE's. 



(In reply to comment #21)
> (In reply to comment #20)
> > I'd also like to see an enhancement that would allow me to select my default
> > "from" address for a message replay be the same as the "to" address on the
> > message I'm replying to. 
> 
> Wouldn't we all?  :-)
> 
> However, see the comment posted by Magnus Melin
> https://bugzilla.mozilla.org/show_bug.cgi?id=358324#c8
> 
> The solution he offered solved this for me when I posted this same request; so
> it might work for you and others who end up in this no-mans-land of moribund
> RFE's. 
> 

Well, that helped in some cases. I still have two problems that it doesn't solve. In one case, when I have things coming to me as part of a mailing list, Thunderbird only reads the list name in the "To" field and defaults to my primary account for replying, even though I'm subscribed to the list under an alias that is one of the options in the pulldown menu. The second problem (which might need to be suggested as a separate enhancement) is that the second account, which I added as an additional identity as suggested, was set up for return receipts and when I send it from the other account, even with that ID, I don't get a return receipt.
Thanks though.
I don't actually see this behavior. If I'm working in a non-default account instead of my umich account and click reply, reply all, forward, or write, I get the identity for that non-default account. Might be because I have SMTP defined for all of them. Bug 375234 is different, but it might be the same issue. Steps:

1. Create default email account.
2. Create identity 1 for it: From a@ex.edu, reply to a@ex.edu
3. Create identity 2 for it: From a@ex.edu, reply to a@2.com (which happens to be forwarded to ex.edu, but a different folder)
4. Id2 happens to show up first in the list so it's default.
5. Send mail from a@ex.edu (Id1)
6. Recipient replies
7. Click reply.

Actual results:
Default identity for reply from step 7 is Id2 (default)

Expected results:
Default identity for reply from step 7 is Id1 (same as original message)
JFY.
If multiple identities are defined for an account, and if identity-x sends a mail to identity-y, and if X-Account-Key: header doesn't exists(old mail received before Global Inbox support), problem of Bug 377998 comment #15 occurs when reply. 
So manual deletion of X-Account-Key: from mail file is very dangerous if multiple identities are used.
With Seamonkey 1.1.2, sightly different(better) result is obtained.
In both cases, mail is copied to different account from original account who downloaded the mail.

(Case-1) To: of original mail = one of main identities of defined POP3 accounts.
   Pre-selected From: when Reply = mail address specified in To: in the mail
   It worked as expected.
(Case-2) To: doesn't contain any defined identity (sent thru BCC:)
   Pre-selected From: when Reply = mail address of X-Account-Key:
(Note-1: Multiple identities of a account case is not checked)   
(Note-2: CC: case is not checked.                            )

Probably improvement by changes in "Reply Self".
QA Contact: composition
Product: Core → MailNews Core
Comment 21 says it all.  This is obviously a problem since many people are logging it as a bug before realising that it is a duplicate of something already logged (as I did).
If I could provide a fix I would, as it is all I can do is add a vote for it to be corrected.
Does anyone know if there is a workaround to cause Thunderbird to either use the "To" field (as it used to do so I read somewhere) or to use the mailbox holding the email being replied to when deciding which account to use for the default "From:" field in a new email?
SeaMonkey, Win2k, POP3. Great to have an updated Netscape, but...
The From address is not the only thing that is wrong. The other settings in the secondary accounts, such as html or not, signature files and placement etc, are also taken from the wrong account when replying or forwarding messages. 
The system works correctly in Netscape 7.2 How about someone just use the code that was used in Netscape 7.2?
Flags: wanted-seamonkey2?
Flags: blocking-seamonkey2?
Flags: blocking-seamonkey2.0b1?
Flags: blocking-seamonkey1.1.17?
Flags: blocking-seamonkey1.1.16?
Not blocking SM 1.1.x those releases are for security & stability only. Doesn't need to block 2.0 beta 1.
Flags: blocking-seamonkey2.0b1?
Flags: blocking-seamonkey2.0b1-
Flags: blocking-seamonkey1.1.17?
Flags: blocking-seamonkey1.1.17-
Flags: blocking-seamonkey1.1.16?
I am one of those who has trouble remembering, every time, to change the "from" address before sending my message.  I disagree that this is a 'minor' problem.  So, to get away from this problem, I will consider going back to Mozilla Mail.
I still believe after 2 years of using Thunderbird that it is more than a minor problem.  To me it seems such an obvious requirement that the reply-to address should tie up with the inbox that held the email being replied to. The fact that it doesn't has caused a string of problems for my other half. If I was good enough to help with the coding I would, but I'm just not good enough to help everyone out by sorting out this problem.
Not blocking SM 2.0 on this request that isn't a focus of the 2.0.x release (and hasn't got anyone working on it).
Flags: wanted-seamonkey2?
Flags: wanted-seamonkey2-
Flags: blocking-seamonkey2?
Flags: blocking-seamonkey2-
This one is causing me all kinds of embarrassment.  I live several different lives (all legit) with different e-mail addresses to go with them.   All my e-mail is filtered through one (very busy) spamblocker and then into the appropriate mailboxes in Thunderbird.   That part is all very tidy.

When I reply, I have to remember EVERY TIME to change the "from" address.  I've managed to kludge things now so that it doesn't reveal my (new) post-spamfilter address, but I REALLY need Thunderbird to use the e-mail address of the mailbox I'm replying from.   Is there a way to do that?
Thanks to those who replied - solution found in https://bugzilla.mozilla.org/show_bug.cgi?id=358324#c8
Add the accounts to the list under "primary receiving account" via Account - Manage Identities - Add, and all is well.   From my point of view, issue closed.
Yes that seems to solve the problem. Please document this clearly in the help files etc., as the default action is different to what users expect and the previous functionality. Also the requirement to duplicate the account information in this section is not obvious.
What the workaround does.
  account1=real account(has real POP3 mbox), account2=dummy POP3.  
    mail.account.account1.identities = id1 -> id1,id21 
    mail.account.account2.identities = id2
    mail.identity.id1.useremail  = addr-1@x.y.z
    mail.identity.id2.useremail  = addr-2@x.y.z
    mail.identity.id21.useremail = addr-2@x.y.z  <- added identity
Note: Tb doesn't prohibit same mail address in multiple identities, because both "aa bb <p@x.y.z>" and "cc dd <p@x.y.z>" should be selectable as From:.

Mail to addr-1@x.y.z and addr-2@x.y.z is downloaded to account1's Inbox, and X-Account-Key:account1 is written. Mail to addr-2@x.y.z is moved to account2's local mail folder.
(1) Composition at account2 : id2 is used.
(2) Reply at account2's folder :
    per X-Account-Key:account1, id21 is (probably) used.

Because Sent,Drafts,Templates are defined by mail.identity.idP.xxx, these settings of id2 and id21 have to be kept same by user. Without this, user confusion is easily produced. Easiest way to keep them identical is;
  At UI, change identity settings of id2(account2) only. After change, Copy all
  mail.identity.id2.xxx in prefs.js to mail.identity.id21.xxx, and restart Tb/Sm.
After further testing I have found that it doesn't fix all the problems. 
If an email is received to one address, and it is moved to a more appropriate folder, and then replied to, it still picks up the wrong formatting and wrong from address. 
Common sense is that it should take the formatting and from address from the settings for the folder the email is sitting in, in just the same way that it does when a new message is composed.
(In reply to comment #43)
> (i) If an email is received to one address, 

POP3 account? If yes, what account number is used for the account who downloaded the mail?

> (ii) and it is moved to a more appropriate folder,

Which account's folder? POP3 account? "Local Folders"? Or IMAP account's folder?
What is account number who owns the folder?
What is set in X-Account-Key: header of the mail?
Is there any other mail address you defined as your identity in From:, To:, CC:?

> (iii) and then replied to, it still picks up the wrong formatting and wrong from address.

Which identity of which account is used for pre-set From: when Reply is done?
How about pre-set To:, pre-set CC:?

Please note that this bug is for next issue.
  At above (iii), pre-set From: upon reply is selected based on value of
  X-Account-Key: in mail data, instead of owner account of mail folder. 
So, workaround in comment #42 is required to bypass this bug, if mail is moved to other account's folder.
If multiple identities you defined are involved in From:/To:/CC:, "reply to self" is kicked(feature requested by users who frequently send copy by CC: to his other mail address), and pre-set From: becomes different from user's normal/ordinal expectation.
This case?
(In reply to comment #44)
Pop3 mail- seamonkey.

eg 3 accounts/ids
id1 a@b.com set as no html composition, signature sig1
id2 d@e.com set as use html composition, signature sig2
id3 f@g.com set as no html composition, no signature 

With a@b.com, d@e.com, f@g.com listed in id1 Manage Identities: (duplication)
all mail is redirected to a@b.com and received into id1 inbox

mail to a@b.com in id1 inbox: reply to works correctly.

mail to d@e.com in id1 inbox: moved to id2 inbox. 
When replied to, the message is formatted in html
  the from address is id2 and the signature is sig2.- works correctly now.

mail to d@e.com in id1 inbox: moved to id3 inbox. (More appropriate)
When replied to, the message is formatted in html - wrong
  the from address is id2 - wrong, and the signature is sig2. - wrong 
My common sense is it should be no html, from address: id3 f@g.com, no sig.
Can change the from address with the pull down box, but not the formatting.
(In reply to comment #45)

Please isolate "account" (mail.account.accountN.xxx) and "identitiy" (mail.identity.idP.xxx).

> With a@b.com, d@e.com, f@g.com listed in id1 Manage Identities: (duplication)

Does "(duplication)" mean that you did "double booking of identity" as workaround? 
  mail.account.account1.identities = id1,id2,id3
  mail.account.account2.identities = id2
  mail.account.account3.identities = id3

> mail to d@e.com in id1 inbox: moved to id3 inbox. (More appropriate)
> When replied to, the message is formatted in html - wrong
> the from address is id2 - wrong, and the signature is sig2. - wrong 

It sounds;
  mail.account.account1.identities = id1,id2,id3
  mail.identity.id1.useremail = a@b.com
  mail.identity.id2.useremail = d@e.com
  mail.identity.id3.useremail = f@g.com
  mail.account.account2.identities = id?
  mail.account.account3.identities = id?
  Mail of To: <d@e.com> (id2) has X-Account-Key:account1.
  Mail is moved to account3's Inbox.
If so, workaround is working as expected.

> Can change the from address with the pull down box, but not the formatting.

It's current implementation/restriction. Once opened in plain text mode, there is no way to change to HTML mode. If opened in HTML mode, option/format can be used. Shift+Reply can change format of composition.
For signature, format, etc., consider use of "multiple identities of an account for same mail address".
Anyway, please keep "one problem per a bug". This bug is for problem of unwanted pre-selected identity due to identity selection based on X-Account-Key: value. Once compose window is opened, this bug has no relation to any problem at compose window.
(In reply to comment #46)
All done in a single user profile.
In the Mail & Newsgroups Account Settings:
1st account: a@b.com set as no html composition, signature sig1
2nd account: d@e.com set as use html composition, signature sig2
3rd account: f@g.com set as no html composition, no signature 

Does "(duplication)" mean that you did "double booking of identity" as
workaround? 
  mail.account.account1.identities = id1,id2,id3
Correct, you shouldn't have to put all the same info in again.

By moving, I mean dragging the email from one inbox to another inbox. 

Yes I realize that the formatting can't be changed once an email is opened, that is why this bug is so annoying. The formatting (+ the return address) needs to be correct when the email is opened. This information should come from the settings for that particular folder from where the email was sitting. 

The best option is to get rid of the X-Account-Key altogether or have an option to turn it off.
(In reply to comment #47)
> Does "(duplication)" mean that you did "double booking of identity" as
> workaround? 
>   mail.account.account1.identities = id1,id2,id3
> Correct, you shouldn't have to put all the same info in again.

"double booking of identity" is a kind of "manual corruption of prefs.js".
UI doesn't support it. If user changes settings of the double-book'ed identity via UI at an account, user has to restart Tb to avoid problem.
If user delete the double-book'ed identity at an account, problem of "no idX although accounN.identities=idX" can happen.
Workaround written in comment #42 is to avoid such problems.
Please never recommend double-booking to other people.
This problem still exists in Seamonkey 2.0 
As stated by  Comment #37 it is a Major problem/bug/annoyance that needs to be sorted out. 
If you click on an email in an inbox (however it got there and whatever To address it has), and click reply or forward, the composition window should use the composition settings, return address, signature file and settings for the account that the inbox was in. It's that simple.
Flags: wanted-seamonkey2.1?
Flags: wanted-seamonkey2.0?
Flags: wanted-seamonkey2.0-
Flags: blocking-seamonkey2.1a1?
Flags: blocking-seamonkey2.0.1?
This bug as clearly described in the previous comment has been a problem for over 2 years, it stops Thunderbird from working properly when used for more than one person, and it should be upgraded to a Major Problem/bug to be sorted out.  It really is that simple.
Not blocking SeaMonkey releases for this.
Flags: wanted-seamonkey2.1?
Flags: wanted-seamonkey2.0?
Flags: blocking-seamonkey2.1a1?
Flags: blocking-seamonkey2.1a1-
Flags: blocking-seamonkey2.0.1?
Flags: blocking-seamonkey2.0.1-
From reading other threads where people are complaining about the same bug, I now accept that always defaulting to a reply-to address that matches the address of the email being answered could cause problems.
Why can't there be a tick box or setting to select "Default reply-to address and From address always match email being replied to"?  That way everyone could have what they wanted.
http://getsatisfaction.com/mozilla_messaging/topics/incorrect_identity_on_reply is another thread that I think refers to the same bug.
I just found a solution that workfor me with TB3. The add on "Correct Identity 1.3.2" makes the default "From" address correct for all people who use my PC.
Although that may fix the from address, it probably does not fix the incorrect formatting (html or not), or the correct signature file attachment. 
The bug needs to be fixed in Seamonkey/Thunderbird.
Regards
David
An add-on introduces new problems, since someone has to maintain it forever. Personally, I can't use TB without "Correct Identity", since people wouldn't recognize me under other identities, so a mistake is really fatal.

Why can't we have some simple options for each account as regarding reply-to:
1. Use "From" of the message, or
2. Always use a specified identity.

Option 1 should be the default, as it's the correct action for the simple case of one account with multiple identities.
This isn't rocket-science after all!
Oups. Option 1 above should read:
1. Use "To" of the received message
No, that's not a good idea. I am not alone in having mail addressed to different addresses (ie business, personal, charities etc), all redirected to a common address so that ISP's spam filters etc can work, and then collected from a common box. Mail can then be moved to the correct account in Seamonkey/TB by dragging etc. When this email is then replied to or forwarded, Seamonkey/TB should use the from address, formatting and signature file of the inbox that the email was sitting.
David is indeed not alone and describes my setup as well (even including charities!). However, I keep all of my mail in subfolders of the common account to simplify things. Setting up all of my alternative accounts as identities of the main account (rather than as separate accounts) works beautifully: The 'from' address in a reply is automatically set to the 'to' address of the message being replied to.
Either option 1 of comment 56 or the idea in comment 57 of always using the
settings & from address of the inbox holding the email would have worked for
me.  My problem (before I started using "Correct Identity") was that TB3 does
neither and does not give the users the option to set either behaviour.
I still believe that the bug needs to be fixed in Seamonkey/Thunderbird but I
am not good enough to do so.
By the way, did everyone wish this bug a Happy 4th Birthday?
It's ridiculous that in 4 years no developer has managed to come up with these two simple options that would have solved everyone's problem.
This problem is more important to many people than the new UI in TB3.
Really shameful.
Right now the behavior of TB3 is inconsistent. I have 2 messages in my Inbox under Local Folders. When using View Source on both messages, neither have a header "X-Account-Key". When hitting reply on one, my default (work) account is used. When hitting reply on the other, my personal account is used.

One message was received from my work account. The second message was sent from my work account and then manually copied to my local inbox.
(In reply to comment #61)
> One message was received from my work account. The second message was sent from
> my work account and then manually copied to my local inbox.

If IMAP, X-Account-Key: header doesn't exist. Adding X-Account-Key: header by Tb is merely waste of band width/server's CPU and rsources/PC's CPU and resources, because fetch(download) of whole mail data, append(upload) of whole mail data with X-Account-Key:, and delete of old version of mail, is needed. And, as account number in Tb's definition is usually different among multiple profiles on multiple Tbs on multiple PCs, X-Account-Key: header at server is useless(X-Account-Key is for Global Inbox support.) 

So, copied mail from IMAP folder doesn't have X-Account-Key: header. It's same in imported mail.

If sent mail, Tb currently doesn't write X-Account-Key: header. It's known issue in Global Inbox environment.
To the developers: You keep blinding yourselves with complexities that are impossible for anybody else to understand. Nobody sees or cares about the header. The user only sees two things: (1) the To address, and (2) the folder the message is in. All the rest is hidden and doesn't count!

I repeat that there are only two options that make sense when replying:
1. Use "To" of the received message (which should be the default)
2. Specify a reply identity for all messages in a folder.

These are the options that everybody is waiting for.
Nobody could care the least about X-Account-Key or other nonsense.
I second that.
This is one of the worst usability problems with TB, I know a few people who have reverted to outlook after sending mail from the wrong address by mistake because of this problem.
While option 1 above makes sense it must fall back to option two as well, as some times the to address is a group address as in the case of BCC.
Everybody who believes this should be fixed: Vote for this bug.
We need votes to get this bug noticed by the developers.
Flags: blocking-seamonkey2.1a1- → blocking-seamonkey2.0.11?
(In reply to comment #51)
> Not blocking SeaMonkey releases for this.

This hasn't changed, we're still not blocking stable updates for this-
Flags: blocking-seamonkey2.0.11? → blocking-seamonkey2.0.11-
Summary: From: address in reply set using X-Account-Key: header even in other accounts not the "global inbox" → From: address in reply is always set using X-Account-Key: header, even though mail folder owner account does not use "Global Inbox"
Blocks: 675509
Bug 36482 looks for me the first report of this kind of problem after multiple accounts & multiple identities in Tb. Setting dependecy to that bug for ease of tracking and analysis.
Depends on: 36482
After 8 years, why does this problem still exist?
Why? One must guess that this bug is in an old part of the software that the developers don't know well enough to fix once and for all. This is the only explanation I can think-of that such a ridiculous algorithm was never replaced by one that non-gurus can understand.
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.
Thunderbird 38.0.1. Vista 64-bit.

Nine years after the first report, this bug is still unresolved. I'm using 38.0.1 now. 39 is coming up soon, apparently, and wonder if it will be fixed then?

When I reply to a forwarded message or to message from an online discussion group, the first address on my list of accounts (right pane), even though that is not the one to which the messages were sent.

I consider this a major problem. For a while, I used an add-on (Flexible Identity) that checked my outgoing address and asked if I wanted to change it, but that stopped working with 38 (I think it was).

Ideally, the outgoing address in a reply should be the same as the address the message was sent to. (This used to work, way back when.) 

Alternatively, it should be possible to designate an account as the default outgoing address (for all messages, or for folders, or for certain recipients).

Harry (comment 64) put it very well.
(In reply to Harry from comment #63)
> To the developers: You keep blinding yourselves with complexities that are
> impossible for anybody else to understand. Nobody sees or cares about the
> header. The user only sees two things: (1) the To address, and (2) the
> folder the message is in. All the rest is hidden and doesn't count!
> 
> I repeat that there are only two options that make sense when replying:
> 1. Use "To" of the received message (which should be the default)
> 2. Specify a reply identity for all messages in a folder.
> 
> These are the options that everybody is waiting for.
> Nobody could care the least about X-Account-Key or other nonsense.

Well said!
I'd assume the decision which From address to prefill is done in the compose window. Magnus, Ian, what do you think of the problem here?
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(iann_bugzilla)
(In reply to :aceman from comment #78)
> I'd assume the decision which From address to prefill is done in the compose
> window. Magnus, Ian, what do you think of the problem here?

Unfortunately I don't have much knowledge around the Global Inbox side of things (thus X-Account-Key), but WADA has done some analysis on this (see comment #62). Neil and/or Mnyromyr might have a view as to the way forward.
Flags: needinfo?(neil)
Flags: needinfo?(mnyromyr)
Flags: needinfo?(iann_bugzilla)
The identity appears to be chosen by the getIdentityForHeader function. (SeaMonkey doesn't have this function. In fact, it doesn't even have per-folder identities.)
Flags: needinfo?(neil)
(In reply to comment #80)
> SeaMonkey doesn't have this function.

Because Thunderbird renamed it for some reason. Sigh...
As Neil already said, that would be getIdentityForHeader. That does try to use the default identity for the server so I don't know why it doesn't work as expected.
Flags: needinfo?(mkmelin+mozilla)
See Also: → 414221
Flags: needinfo?(mnyromyr)
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.