User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Scenario 1: If user 1 has accounts "a@foo.com" and "a@bar.com" (in that order) and user 2 has an account "a@bar.com" (using IMAP): user1 writes an email using "a@bar.com" user2 cannot open that email Scenario 2: If user 1 has accounts "a@foo.com" and "a@bar.com" (in that order) and user 2 has accounts "a@baz.com" and "a@foo.com" (in that order): user1 writes an email using "a@foo.com", and saves it in an IMAP draft folder. user2 opens the draft email, and it appears to be from "a@baz.com". If user2 now sends the email it will go out with the wrong address. The problem appears to be that thunderbird keeps track of the identity used to address an email by inserting headers (X-Identity-Key?) into the message. When opening the message, it uses this key to index into the local account configuration. So depending on the order of account configuration, it can potentially use the wrong account. Reproducible: Always Actual Results: Messages cannot be opened, or opened with wrong from address. Expected Results: Since the sender information is written in the header (From:), thunderbird should not try to override it automatically using its own keys. Perhaps list the original from in addition to any configured identities during an edit session?

Same problem/result has been reported to Bugzilla Japan. ( http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4605 ) => CONFIRMED. (1) When mail.identity.idNNN.xxxxxx are NOT defined for user2, where idNNN is value of X-Identity-Key: header of the draft mail. "An error occurred while creating a message compose window. Please try again." was issued and editing of the draft mail is impossible. (2) When mail.identity.idNNN.xxxxxx are also defined for user2, where idNNN is value of X-Identity-Key: header of the draft mail. Editing is possible, but pre-filled mail address is changed from "From:" header of the draft mail. - Original "From:" header in the draft mail was ignored, and mail address specified in mail.identity.idNNN.useremail of user2 is pre-selected. - Selection of "From:" by user2 is possible. Bug repoters says that the problem occured on both "Thunderbird 1.0.6 release build" and latest-trunk nightly - "Thunderbird version 1.6a1 (20050915)". Phenomenon (1) is IMAP only problem. Phenomenon (2) can be observed on POP3 account, when a draft mail is imported or copied from other profile or other PC (or by editing "Drafts" file). Phenomenon (2) is not a problem if POP3, and can be said "work as desinged" if POP3. But when IMAP, original "From:" in the draft mail should be honored, even when idNNN for the IMAP account is different among Thunderbird's profiles.

Easy (to describe, not to implement) solution. (1)If IMAP, put mail address(string in mail.identity.idXXX.useremail at user1) only in "From:" header when saving as draft. ==> From: aaa@bbb.ccc.ddd (no other data, no encoding) (2)If IMAP, when editing a draft mail, search mail.identity.idNNN.useremail for aaa@bbb.ccc.ddd in From: header of the draft mail. - If found, say idYYY, use new idYYY as X-Identity-Key: value. - If not found, or if no "From:" header, warn user for undefined mail address, then open compose window with idNNN value for identity currently used at user2. I think there is no problem on send, because current logic for send (probably) determines "From:" header data based on X-Identity-Key: value currently using. Considertions on compatibility. (A)When draft mail created by old Thunderbird / editing by new Thunderbird - when "From:" contains mail address only No problem. - when "From:" contains other data or encoded Warinig of "no mail address is defined" is issued, but it's not a big problem because user can choose From: again. (B)When draft mail created by new Thunderbird / editing by old Thunderbird - There is no problem because no difference from current. X-Identity-Key: is not changed. (C)When draft mail created by other than Tb / editing by new Tb - same as case (A). (D)When draft mail created by new Tb / editing by other than Tb - There is no problem because no difference from current, except lack of additional data(first name or last name etc.) in some cases. There is no reason/need to apply above solution for POP3.

See Bug 295956 for problem when accountX in X-Account-Key: is not defined at other PC.

Correction. Sorry for spam. Difference between two bug was IDxxx in X-Identity-Key: is defined or not-defined when accountX in X-Account-Key: is defined at both.

see also bug 394216 and bug 291452 for the same problem.

SeaMonkey (1.1.13) mail composition bug. I think this bug in SeaMonkey is common to bugs 264626, 79455, 122352, 462589, 279846, 394216 that I have found. The mail in Netscape 7.2 works as expected. In a SeaMonkey mail program with multiple accounts, quite often the wrong account and "From" address is used when a message is replied to or forwarded on. For example: An email is recieved in account1's inbox. It is moved to account2's inbox It is selected and replied to (or forwarded). Netscape correctly uses account2's "compose in html" setting and the reply-to address. SeaMonkey incorrectly uses account1's settings and uses account1's reply-to address. The "from address" can be over-ridden with the pull down box, but the incorrect formatting etc is used when the reply (or forwarded) message is initially generated. Selecting a new composition from each account works correctly. I think that the account settings, from address and formatting etc used when the reply or forwarded message is created, should be from the account where the initial message is currently stored (inbox, draft, template, sent etc), not some obscure address in the header.

FYI. Problem (2) in Comment #1("sent with wrong address" part in bug summary) is Bug 264626. Setting dependency. (In reply to comment #6) > An email is recieved in account1's inbox. > It is moved to account2's inbox > It is selected and replied to (or forwarded). > Netscape correctly uses account2's "compose in html" setting and the reply-to address. > SeaMonkey incorrectly uses account1's settings and uses account1's reply-to address. IMAP? POP3? POP3 isn't it? It's Bug 327713, isn't it? David, please never confuse POP3/X-Account-Key related issue (Bug 327713, reply to POP3 mail, no Global-Inbox use) with IMAP/X-Identity-Key related issue (Bug 264626 & this bug, Draft mail of IMAP).

Sorry, maybe you should put IMAP in the bug heading.

I have 2 IMAP accounts. If I Edit As New a message from my Sent folder associated my Default SMTP server, the Reply To Address is filled in with the identity associated with my other SMTP server. I expect that the Reply To Address should remain the same as what was used to originally send the message.

Randolph: you should add the Keywords dataloss, as for bug 499274, as in some situation happen to lost some saved mail. The product should be "MailNews Core" as happen on Thunderbird and Seamonkey Mail.

Still broken in SM 2.2. Please understand the issue here: 1) at my work computer, I draft an Email in an IMAP account. 2) I go home. At my home computer, I go to drafts folder. Email to/from look correct. 3) I open the draft to send it. The From address has changed to whatever the next one down is on the drop-down associated with the from address) 4) I don't notice the change (hard to see - small black type on blue background). 5) the work email goes to 15 people from a personal Email address. Please give this some attention when you can? It's killin' me 8-} Thanks! /j

No offense guys, but some of the bugs in 2.5 (like "fixing" mail icons so that they reflect message status) seem pretty trivial compared to this one. Is there anything I can do to get this fixed???? pretty please??? /j

Exactly. It is a major bug that has been there for almost 5 years!!!

is it possible to copy some internal file from one installation to another that would keep the identity lists in sync? I already do this with places.sqlite so that would be an acceptable workaround

This is still biting me in Thunderbird 17. :( The values of the two headers below are numeric. Woudn't it be possible to use something smarter? X-Identity-Key: id1 X-Account-Key: account2 The folder from which I open a draft is also known... why not look at the account settings related to that?

Still a problem in SM 2.30, still bites me occasionally. Will no one fix? Alternately- is it possible to copy some internal file from one installation to another that would keep the identity lists in sync? I already do this with places.sqlite so that would be an acceptable workaround

Get rid of the X-Identity-Key: and X-Account-Key:

(In reply to Jeff W from comment #22) > Alternately- is it possible to copy some internal file from one installation to another that would keep the identity lists in sync? (1) Simplest/easiest one : Copy Tb's profile directory. Copy Tb's profile directory of PC#1 to X:\ABC\DEF of other PC#2, thunderbird.exe -ProfileManager create new profile(call ProfX), with choosing the X:\ABC\DEF as profile directory of the new ProfX on PC#2. start Tb using the new ProfX. X:\ABC\DEF can be any directory, excluding OS's directory. Needless to say, X:\ABC\DEF can be a directotry under Tb's standard profile directory location. C:\...\Thunderbird\Profiles\ProfX (2) Easy one : Copy account definition only. copy prefs.js of Tb#1 on PC#1 to user.js of Tb#2 on PC#2. Edit copied user.js, and delete all entries which is not account definition in Tb. Keep mail.root.???-rel, mail.accountmanager.???, mail.account.???, mail.account.account#.???, mail.identity.id#.???, mail.server.server#.???, mail.smtpservers, mail.smtpserver.smtp#.??? Restart Tb at PC #2 => account definition is replaced by content of user.js, and is written in prefs.js Terminate Tb, remove user.js, restart Tb. As far as mail.server.server#.directory-rel for same server is same in both Tb's profile, already saved mail data is accessible. (3) Simple one : Copy identity definition only. copy prefs.js of Tb#1 on PC#1 to user.js of Tb#2 on PC#2. Edit copied user.js, and delete all entries which is not identity definition in Tb. Keep mail.identity.id#.??? Choose an accountN which has mail.account.accountN.identities in prefs.js of Tb#2 on PC#2, Put all id# of kept mail.identity.id#.??? in mail.account.accountN.identities. Restart Tb at PC #2 => identity definition is replaced by content of user.js, and is written in prefs.js Terminate Tb, remove user.js, restart Tb. Any identity can be an identity of any account, as far as accountN already has mail.account.accountN.identities definition. If you need, you can move id# in mail.account.accountX.identities to mail.account.accountY.identities, as far as accountY already has mail.account.accountY.identities definition.

Thank you - Sorry for the delay (I don't seem to get notified when this thread is added to) I'm having a little trouble following your workarounds, but they all seems like they will require many steps whenever I modify my identities, and perhaps require the additional complexity of multiple profiles? Please understand the issue: I use Seamonkey at home and at work. My work Email is IMAP and I access Email from both places. If I draft an Email at work, and then open/edit/send it later from home (a very common occurrence), I always have to remember to check the "from", because once I open the Email to edit it at home the "From:" is changed(!) by the program. It seems like an architectural weakness: The Email can be accessed from multiple machines, but the From address is referenced to a machine-LOCAL table that can be different on different machines. It seems like for Drafts, the From: address should be added to the message when it is created, and should itself (not an indirect reference) stay associated with the Email wherever else it's opened. Now, that being said, I already transfer some files (likes places.sqlite) from the work installation to the home one periodically to keep Bookmarks and Address Book in sync. If there's a file at the work installation that I could just COPY to the home installation (with no editing), that contained the "indirect map" for From: addresses. That would be an acceptable workaround. I do add to my Identities list, but it's rare enough, and I do the COPY often enough, that this would be a helpful fix (at least for me, probably for others). In any event, I do appreciate those with a better understanding of the issue finally paying some attention to this. I'm a Netscape/Mozilla/Seamonkey user since the 1990s but sadly am a HW designer so I'm helpless in this regard. :-) Best Regards & Thanks! /j