Version: 1.12.2 (using 4.3.2 (KDE 4.3.2), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.30-2-686 To reproduce this problem, create multiple identities, each one with a different signature. Set the program to automatically insert signatures. Then click the toolbar button to compose a new message. The default profile's signature is automatically inserted, as it should. In the composer window, choose "View->Identity" to show the identity field if it is not already shown. Switch to a different identity in the composer window by using the drop-down in the identity field. The signature does not change. It should automatically change to the new identity's signature, but it does not. It gets better. In the composer window, delete the default signature and use "Attach->Append Signature" to insert the current identity's signature. Now switch back to the default identity in the identity field. The signature switches back to the default. It appears that a function is not being called somewhere or the automatic signature insertion is only being applied to the default identity. This worked perfectly in KMail that came with KDE 3.5.*. It could work perfectly now. If the bug can be found and fixed, that would save me several clicks per email and I would be quite grateful. In the meanwhile, once %SIGNATURE is usable in custom templates in current distros, there are ways I could work around this particular inconvenience with custom templates. Until then, I'm stuck with deleting and attaching signatures. BTW, I have purged kmail settings in my home directory and tried with a from scratch rebuild of my kmail settings. It didn't solve the problem. This is caused by some logic error from somewhere within the program.
UPDATE: I have determined more specifically when the behavior is exhibited. Whenever using direct input from the "fortune" program to create the signature, KMail gets stuck on that signature and won't change when the identity changes. It also seems to exhibit the behavior when getting input from a bash script. This has nothing to do if the identity is the default or not. Test this by calling fortune directly for an identity's signature. Load the compose window and try to change to and from the identity that call's fortune. Follow this up by calling fortune from the command line and redirecting the output to a file, like this: $ fortune > sig.txt Then change the identity to read the file or even run "cat sig.txt". Kmail stops exhibiting the erratic behavior when changing identities. This tells me that there is probably something in the direct output of the fortune program (e.g. a stream control character) that KMail is picking up and inserting into the signature, causing it to no longer recognize the signature properly. It also seems to exhibit the behavior whenever running a bash script to extract the signature. I am not sure if this is something new with a more recent version of fortune or if it is something that has changed with KMail. The workaround that I use is to set a cron job that outputs a fortune cookie to a signature file every so often. Then, from KMail, load the signature file for the identity that uses the fortune cookie.
*** This bug has been marked as a duplicate of bug 169702 ***