This seems to happen under specific circumstances, when using multiple setups of Claws Mail. Steps to reproduce: You'll need two e-mail accounts, Account1 and Account2, each one SMTP + IMAP Set up two instances of Claws Mail, Client1 and Client2 on different machines, as different local users, or just do: $ mkdir /tmp/client1 && HOME=/tmp/client1 claws-mail & $ mkdir /tmp/client2 && HOME=/tmp/client2 claws-mail & Set up Client1 for use with Account1 only. Set up Client2 for use with Account2 and Account1. (In this order!) Now compose a new message using Client1. Save it as draft. Switch to Client2 and open the drafts folder of Account1. Open the message. Note, that the message now is configured to be sent using Account2 instead of Account1. This is weired enough and shouldn't happen, as the message did never belong to Account2. Change that by setting "From:" to Account1. Now sent the message. It will be sent using the SMTP server of Account1, but it will be saved in the sent folder of Account2. As you see, Claws Mail is totally confusing different accounts in this case. I think this is very weird behavior and shouldn't happen. Mail sent with Account1 should always be saved in the sent folder of Account1, unless configured otherwise.
Every account is identified in ~/.claws-mail/accountrc with a number, which is stored in drafts using the X-Claws-Account-Id header. If you have 2 installs of Claws Mail and want them to share a remote draft, they should use identical accounts, or at least with identical account numbers, so that the X-Claws-Account-Id number identifies the right account. You could either copy the accountrc file from a setup to another one (make sure you don't have drafts documents), or edit the accountrc file and make sure account IDs match in both accountrc files.
(In reply to comment #1) > Every account is identified in ~/.claws-mail/accountrc with a number, which > is stored in drafts using the X-Claws-Account-Id header. If you have 2 > installs of Claws Mail and want them to share a remote draft, they should > use identical accounts, or at least with identical account numbers, so that > the X-Claws-Account-Id number identifies the right account. That ID number is based on a local configuration, and should not be used in remote storage such as IMAP. Doing so is a bug, IMO. The account identifier in a draft should change to something that can identify the account globally; for instance, something based on username, hostname and port of the IMAP or POP connection. The account's email address would probably be sufficient, and at least superior to a magic number. What you suggest may be a decent workaround, but it's something I would not expect most users to be able to do.
Yes, this isn't ideal, and should be fixed.
I'd add that identifying an account by email/host/port is not enough. People can have multiple accounts where all of these are the same, especially smtp-only accounts, where only the settings vary. (with/out GPG, etc) generating and using UUIDs to identify accounts would be more correct. The other instances, not recognizing an existing account from the UUID, would then fallback to the normal account selection (by From, by folder, by default).
(In reply to comment #4) > I'd add that identifying an account by email/host/port is not enough. > > People can have multiple accounts where all of these are the same, > especially smtp-only accounts, where only the settings vary. (with/out GPG, > etc) Yeah, now that you mention it, using the email address or host/port would mess up a pretty typical use case... to fix this corner case. Oops. :-) > generating and using UUIDs to identify accounts would be more correct. > The other instances, not recognizing an existing account from the UUID, > would then fallback to the normal account selection (by From, by folder, by > default). For sure. The UUID would still give perfect matching to the same account on the local client, and would avoid false positives on other clients. Then with the fallback, you may have covered off every case!