If you start writing a message draft in one instance of TB, and then switch to another instance of TB to finish the draft, there's a good chance that the identity from which the message gets sent will be wrong unless you notice that it has changed and fix it. The issue is that the identity is stored in the message draft as a number, but of course there's no guarantee that identities will be in the same order in two TB instances or even that the same identities will exist in both. Thinking out loud, I see three possible ways of addressing this issue: 1. Store the email address of the identity in addition to the # in the draft. When loading a saved draft for editing, check if the email address stored in it matches the email address of the identity stored in it. If not, then use the default identity for the Drafts folder in question and pop up a dialog warning the user to check the account sending the message. 2. Associate a GUID with each identity, and store the GUID in the draft instead of an identity number. If the GUID doesn't match any existing identity when loading a saved draft, then use the default identity for the Drafts folder in question etc. 3. Same as (1), but if the email address and identity # don't match, then try to find an identity that *does* match the email address in the message, and use that instead of the default entity for the Drafts folder.

(In reply to Jonathan Kamens from comment #0) > If you start writing a message draft in one instance of TB, > and then switch to another instance of TB to finish the draft, (snip) IMAP? If yes, rediscovery of bug 279846, which is listed in dependecy tree for meta bug 699681? (the meta bug is put in Blocks: field of this bug)

Yes, agree that this is the same as bug 279846. Sorry, didn't find that bug when checking to see if it had already been reported.