Version: (using KDE 4.2.96) Installed from: Ubuntu Packages This bug exists at least since RC1. When I write a mail and send it the composer window remains open (but greyed out) and the mail remains in the outgoing posts folder. I am not 100% sure, but I believe in most cases the mail is actually already sent and there is a copy in the sent folder. It is possibile to stop sending of the kmail via pressing (-) in the status bar, but the composer window remains open. I am able to press close (x) on the composer window. Then I am asked if I want to save as draft, but the composer window does not close. This bug does not happen with every mail, I can not reproduce which mails are affected.
This bugs seems stil present in RC3. But in a way different. When I reported it first, it allways happened the first time when I sent a mail. Now I had RC3 running for days without this happening. Now it happened the first time again.
This bug is present in 4.3.1 (1.12.1 kmail) as well. Monitoring the mailserver logs indicates that it isn't even trying to send the message, despite repeated commands to process the queue and repeated checks for new mail. The only way out is to close the composer window (telling it to discard the message) which it doesn't do, fortunately, but is probably another bug and restart kmail. When I kill the kmail program and go through the various file deletion and configuration file stripping actions required to start it again, it will connect to the server and actually send the email. The only error I see with the send is that since it hasn't connected to the IMAP server I have told it to store sent messages on when it restarts, it stores them instead in the local folder.
This bug is still present in KDE 4.4 RC2 and it has even become worse. It now happens with every mail. Work around is to use "send later" and then send the mail from the outgoings-folder. Would be really nice if this could be fixed.
the bug is still present in kde 4.4.0 mails are send out now, but the process is very slow using top shows that nepomukservices and virtuoso-t are the cpu-drainers here as well as in bug #224037 could someone reassign this bug then to the nepomuk-folks?
*** This bug has been marked as a duplicate of bug 219687 ***