User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040925 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040925 After sending a few email messages (5 to 10 or so), attempts at saving the message to the sent folder hangs for a very long time. Eventually, you are told that the message could not be saved to the sent folder (no reason is given why), "do you want to save it to the drafts folder instead". If you say yes, the first 5 to 10 emails are successfully saved to the drafts folder. After this, any attempt to save the message as a draft fails. It is also impossible to save the email message, the only option is loss of mail. To workaround: exit both the browser and mailnews and start again from scratch, allowing you to send another 5 to 10 emails again without losing them. This problem happens both when the Sent/Draft folders are local, AND when the Sent/Draft folders are stored on an IMAP server. Reproducible: Always Steps to Reproduce: xxx

> This problem happens both when the Sent/Draft folders are local, AND when the > Sent/Draft folders are stored on an IMAP server. But it's always a IMAP account, no POP, yes?

Have only tried it with IMAP accounts, yes.

Graham, what imap server are you using? Cyrus 2.1.5 has this problem especially if using ssl, and you just have to upgrade the server. Otherwise, have you tried a more recent mozilla build, like 1.8a4?

The IMAP server is courier-imap-3.0.3-1.3ES, and SSL is being used yes. Will try upgrade the IMAP server (if an upgrade is available) and see if there is any improvement.

Upgraded the IMAP server to courier-imap v3.0.8: On a RHEL3 machine running Mozilla v1.7.3, the freezing has stopped - the hanging messages still happen, but these succeed after hanging for a while. On a Yellowdog Linux (PowerPC) machine running Mozilla v1.7.3, attempts to send any message freeze when the message is copied to the sent folder. It is impossible to save sent mail, or mail in a draft on this machine.

Running the latest Thunderbird on MacosX against courier-imap v3.0.8 shows the same problem. So far it seems Mozilla / Thunderbird is a dead loss for mail, though there are few alternatives. Considering the fact that this bug has remained ongoing and unfixed for weeks, I will start investigating scrapping the courier-imap server and switch it to something else (dovecot?). This is assuming that a courier-imap bug is triggering a mailnews bug, rather than mailnews being broken for all attempts at secure LDAP.

secure LDAP? did you mean secure IMAP, or are you using LDAP over SSL as well? Are you currently doing fcc to an imap folder or a local folder? Are you running the imap server on the same machine as the mozilla/thunderbird client?

D'oh!!!!! I mean secure IMAP. As to the copy to an IMAP folder or local folder, it does not seem to matter - sometimes it never works (immediate hang), sometimes a few messages work, followed by nothing further ever works until thunderbird is exited and restarted. The thing that seems to be common is that the mailbox is always secure IMAP - the minute this is true, copy to any folder, be it IMAP, local, whatever does not work.

Once you're in this state, can you move/copy a message between arbitrary folders? e.g., folders that aren't Sent mail folders? If I'm understanding you correctly, what triggers this is a failure to copy to the imap sent folder, and then once that fails, other move copies fail as well. Does cancel work on the copy/fcc status dialog? Have you tried bonking the online/offline button when this happens? If that frees things up, then that's a sign that it's the server that's simply not realizing that we've sent all the data that we promised to. an imap protocol log - http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap would also help tell if that's what's going on. Ideally, we could time out on our blocking read waiting for the imap server to respond, but I don't think our streams support that. Using an external timeout would be tricky with our threading model but maybe it's possible.

Imap copying / moving carries on working as normal - in your main mail window, you can fetch mail, you can click on a mail message and view it (downloading it from an IMAP server if necessary), you can copy mail, you can move mail between folders. The _only_ thing that breaks is the saving of sent mail both to an IMAP folder, or locally. After this breakage - everything else still works. It's _only_ the saving of sent mail that is broken from this point on, followed shortly afterwards by the breaking of the saving of draft mail. At this point, all outbound mail is unsavable and therefore lost. I followed the instructions for MacosX to get an IMAP log, but dragging the file created onto Thunderbird has no effect on Thunderbird (both before or after Thunderbird is invoked, the instructions are vague for this). Not sure that the log is useful, as in my case the mail is trying to save itself locally, which should in theory not touch IMAP. I have tried tried a number of things to see if I can find the event that triggers the bug: - I started thunderbird from scratch, and it connected to the imap server. - I changed the number of cached connections to 1, to see if it affects things, and restarted thunderbird. - I started sending blank test messages to myself, one after the other. - All the blank test messages worked, I could not recreate the problem. - I fetched mail while sending messages, and I could not recreate the problem. - I jacked up the cached connections back to the original 5, and could not recreate the problem. To exponentially increase the annoyance, I cannot seem to replicate the case where the message sent save event is attempted at the same time as mail gets fetched. This is probably because the sent mail event takes too long in my case (mail is delivered to an mta "far away"), and the mail fetch is too quick. (I am temporarily on a fast network and the imap server is "nearby" and I am fetching only 5 to 15 messages at a time). I think (but cannot confirm) the problem happens if an attempt is made to save the email to a local folder while an imap folder is being accessed. In theory, interaction with a local folder should have nothing whatsoever to do with IMAP, but in this case it seems to. I am normally on a dead slow network (slower than modem speed) with mailboxes that contain thousands of messages, so I think I am running into race conditions that are masked on fast networks.

Right, after a whole lot more research into this, I can see that this problem is caused by the combination of a number of locking bugs in MailNews. To work around the problem - simply ensure that all interaction between the human and mailnews is serialised, in other words never do anything in mailnews while mailnews is "busy" doing anything. Stick to this and mailnews always works. It basically boils down to locking problems - it seems the mailnews IMAP locking support is hosed. If any IMAP operation of any kind is happening while an attempt is made to save an email message to either an IMAP folder or a local folder, the attempt to save the email message deadlocks. From this point onwards all further attempts to save mail to the sent mail folder (local or IMAP) deadlocks. At this point it is still possible to click to close the email sending window, resulting in the question "do you want to save to the drafts folder". Again, if any IMAP operation of any kind is happening while an attempt is made to save the email to the drafts folder, the attempt will deadlock until the browser is restarted. It is not possible to recover from this condition, and the mail is lost. If you are on a fast network, or if IMAP folders are small, the chances of trying to save a message simultaneously while Mozilla is accessing an IMAP folder is slim, and the bug is masked. If you are on a slow network, or have IMAP folders that are large (or in my case both), you are almost guaranteed to run into this race condition every time. Due to the effect of bug 248927 (stop button has no effect on IMAP, or is greyed out), it is impossible to reset the IMAP connections, and the deadlock remains. This might be academic, as apparently selecting offline followed by online simulates the effect of "IMAP stop", but this has no effect on the deadlock - once a mail folder is deadlocked, this situation remains until mailnews is shut down. It looks like the fix is to correct the mailbox locking - access to a) an IMAP folder and b) any other folder (IMAP or local) at the same time causes a deadlock.

possible dup of bug 287658 - which was fixed today and should appear in trunk builds tomorrow.

Graham Leggett: Recent fixes for bug 287658 (as of 28-Mar) and bug 123063 (as of 30-Apr) may have addressed issues people are seeing for IMAP; please try a current nightly build of Mozilla or TB, whichever you're using -- be sure the build is dated May 1st or later before bothering to download, as the nightlies on ftp.mozilla.org are not getting regular updates. Please mark this as a dupe if your problem appears to be solved.

Incidentally: is this reporting a different symptom than bug 185955, which you also opened?

Tested the nightly build and this issue appears solved. There are a number of other issues, but I will open separate bug reports for them. *** This bug has been marked as a duplicate of 287658 ***