Version: (using KDE KDE 3.4.92) Installed from: Gentoo Packages [Probably, there had been another report on this, but I couldn't find it because the bugtracker requires search terms to be longer than 3 chars, but "Bcc" is just 3.] In the identity configuration, default Bcc adresses (two in my case) may be specified to be automatically added when writing a new message using this identity. Since some KDE 3.4.x version, KMail does not automatically remove them when choosing another identity in the message window (!), under the condition that the auto-Bcc'ed identity is the default one (and another one is chosen). This is quite annoying because I have to remove them manually several times a day, and forgetting it sometimes doesn't only bring pleasing consequences.
This works fine for me with 3.5 can anyone else confirm with 3.4?
I think I've got new information: 1.) The problem only occurs with two ore more Bcc addresses - one works fine. 2.) When writing a new message, each auto-Bcc address gets its own header line in the message window. When switching to another identity, they are not removed. 3.) Reproduce this with two auto-Bcc addresses: Start writing a new message and remove all auto-Bcc addresses from the message window. Then, change the identity the message is sent with to another one, and back again. The auto-Bcc addresses appear _in one line_, and switching back to another identity makes them hide. It seems that Bcc addresses are handled correctly if they appear in one line and are splitted when the message is sent. Opening the new message window splits multiple auto-Bcc addresses into multiple lines, so that they aren't handled correctly any more. I think this is because KMail generally splits multiple addresses of one header: When replying to all people, they all have their own Cc: line in the message window, even though there was only one To: header in the original message; if a message has been sent to multiple Cc addresses (in one line), they are splitted to multiple lines in the message window when pressing "resend message". I believe that a solution is to just turn off the header splitting. I cannot see why it should be advantageous at all.
Is this unreproducible?
I think this is the same problem as bug 109074. *** This bug has been marked as a duplicate of 109074 ***