Version: 1.6.2 (using KDE KDE 3.2.2) Installed from: Gentoo Packages Compiler: gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) Thread model: posix OS: Linux Admittedly unusual circumstances, but very important to resolve nonetheless. I lost about 6 hours worth of work composing a draft email message because KMail didn't do what I think it should have done. Circumstances: 1) KMail configured as client for Cyrus IMAP server; 2) A message has been composed and stored for additional revisions in the drafts folder of the IMAP server and KMail has been configured to save draft messages to that IMAP folder; 3) Kmail is launched, draft message is opened for editing (which seems to cause the message to be deleted from drafts folder which in itself is fine IMO); 4) While editing the message that had previously been stored in the drafts folder, the partition on the IMAP server that is used as the mail store for the drafts folder fills up completely; 5) After completing some editing of the draft message (but it's still not ready for sending), one uses the "Message->Save in Drafts Folder" menu command to store the message in the drafts folder again, but the mail store partition on the server is full so KMail cannot save the draft message there. In these circumstances, KMail just throws away the draft message. It does pop up an error message informing me that it cannot access the file, and I can acknowledge the message by pressing the "Ok" button, but KMail makes no attempt to keep the composer window open (so that I could save the message somewhere else or decide how I should save the content in some other way), or to save the message to a dead.letter file in the user's home directory on the client computer, or to do anything at all to attempt to save this content. I see that as a big problem. Draft messages are frequently documents that the author has already spent (or will spend, or both) many hours composing. As such, I believe that KMail should take extra precautions on how to try and make sure that this content is never lost. If KMail crashes, it should be saved to a dead.letter file (or draft.letter or something) ASAP while KMail is still resident in memory if at all possible (as Emacs does with unsaved buffer contents), and if some attempted action fails that would otherwise lead to the loss of the content of a draft message, then KMail should go to extraordinary measures to ensure that the content is saved somewhere, somehow, and if all methods to save the content fail and KMail has not crashed, then the composer window should not be closed no matter what or else the content is lost irrevocably. I see this as a bug but I suppose one could also see the behavior that I'm describing as a really valuable feature. In any case, I think it's a really important thing for any mail client to do. I'm interested in feedback from the developers on this notion. Thanks for making a mail client that (in just about every other way) is truly delightful. You folks do amazing work and if I knew anything about programming I would love to help out by writing code to implement this notion above or some other stuff. -Kevin
Confirming this on KMail 1.6.2, KDE 3.2.3 on Mandrake Linux (latest cooker packages). I were composing an e-mail, and my identity's configuraion Drafts were set to be saved in the IMAP "Drafts" folder. After typing some paragraphs, I've selected "Message"->"Save in Drafts Folder". The I've received a message box "Cannot find server MY.MAIL.SERVER.FQDN" (MY.MAIL.SERVER.FQDN substituted with my server's fqdn, of course, the message might be a bit different - it stopped appearing at all after some retries). The only option was to click the "OK" button. After "OK" was clicked, the mail compose window has closed without a warning, and all my work was lost. I were getting the "Cannot find server" messages later (might be some network problem), and later they have stopped appearing at all - currently when I compose a new message and try to save it, it disappears without ANY indication at all! This is a major issue, KMail drops the user's work on the floor against any common sense. At the very least, mail compose window should never be closed as a result of saving the message to Drafts! The other way, when saving to Drafts is triggered by closing the compose window, is different of course, and should result in closing window. But the explicit "Save to Drafts" should _never_ close the compose window, especially without a prompt!
BTW, bug 46540 seems to be related, however, it's supposed to have been fixed for KDE 3.2. I'm using KDE 3.2.3 and see this, so it looks like a different issue.
Raising severity to grave due to dataloss. See also bug 50462, which is the same thing for maildirs.
I am using KDE 3.5.7 (fc6) and KMail 1.9.7 and this bug made me loose about 20 mails. And this ALTHOUGH I am using dimap. I saw the mails disappear, closed kmail, removed all the indices and restarted kmail again. The lost mails came back from my harddrive. However, as soon as kmail had connected itself to imap (which is automatic), it deleted the mails on my local account (because they have been deleted on imap). I live with this bug for years now (first POP3 http://bugs.kde.org/show_bug.cgi?id=50462, now IMAP). On many different systems. Please solve this. Loosing mail is very annoying. Thanks in advance.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.