I had been having the following problems with Mercury:

1. All the problems with IMAP on Android and Apple clients not disconnecting as described in detail by Gusg, above.
2. Problem with Thunderbird IMAP client: when opening an email with attachments Thunderbird fetches and displays only the body of the email and waits for the user to open an attachment before fetching it from the server. Intermittently, when fetching an attachment Thunderbird would report that "the server has reported the attachment is empty". Closing and restarting Thunderbird would allow the user to fetch the attachment from the same email. The problem was that either Mercury or Thunderbird had "lost its place". I tried running Mercury with logging enabled to diagnose the problem, but, because it was so intermittent, I would end up with gigabytes of useless log files. Pegasus does not have this problem because it fetches the whole message including the attachments, whether you want to open the attachments or not.
   
3. These problems may be solved by Mercury V5 with a new file

   system that allows one file per message so locking of whole "folders"

   will no longer be necessary. However, on March 31, 2011 David Harris

   announced that "We hope to release V5 sometime in 2011", and this

   was already mid 2015. It had become clear to me that the "one man band"

   development model of Mercury and Pegasus was no longer sustainable.
   

4. My server was running Windows XP and upgrading the OS required buying new hardware.

I solved all of these problems: I bought a Raspberry Pi, installed Postfix as the mail server and PopFile for mail filtering (I even copied its database from the PC the the Raspberry), ported the PopFile daemon I wrote many years ago for Mercury, copied all my users email folder structure to the new server, copied all their emails and then shut down Mercury. My Raspberry Pi server has not needed rebooting in 9 months.

Mercury was a great program. It deserves better support than David Harris all by himself has been able to provide and, in my opinion, he needs to find a development model that allows him to involve other programmers and still feel comfortable keeping control of his "children". Perhaps something similar to what Linus Torvalds does with the Linux kernel might satisfy David too?

We have been fighting IMAP problems for some time now.  Probably the worst has been users who are trying to connect with more than 1 device at the same time.  If one of the clients is Thunderbird, It will regularly report "Folder in use by other connections".  Others will fail in more subtle ways.  Very commonly a user will delete (move to trash or whatever their deleted messages folder is named) a bunch of messages from the inbox and all will be well for a while and then the user notices that the deleted messages have all come back into their inbox and there is a copy in the trash folder.  We know that this is caused by the remote client being connected when Mercury crashes.  This situation is compounded by the fact that it is difficult at best to shut down the email client on cell phones and tablets, either IOS or Android, and even more difficult to get users to even consider trying to stop the client on whatever device.  I see a few recent threads hinting that others are seeing similar issues.

  It would be very helpful if there were an option to force Mercury to expunge at the very least the inbox either as soon as a message is moved out or very soon after doing so instead of waiting for all of the connected clients to disconnect.  As I mentioned above it is almost impossible to get phone users to disconnect which compounds the problem.  A quick test shows that having a desktop client compact the inbox immediately after deleting a bunch of messages out of the inbox does help, however again a training issue for remote users scattered all over the globe.

  As to the cause of the crashes, the occasional ones that happen sometimes only every several days and other times several times a day.  The situation has improved considerably after the updates that were done just before the release of 4.8, however with increased traffic we are getting back to the point of lots of angry users.  We have identified one source of Mercury crashes that was less than apparent.  Running in Netware mode, if someone sends and email addressed to a Netware user that has no home directory defined, a user that should never receive email but .... Mercury will start to crash repeatedly until the message that caused this situation is removed from the queue.  I would expect it would be fairly easy to implement a simple test in the code to detect and mitigate this issue.  We believe we have a band aid solution, however we probably have a lot more users on the system that have no reason to do email or have a home directory than those that do. 

   One more related question, we have the Windows machine that Mercury is running on configured to reboot every night in the middle of the night.  Can anyone address whether or not Mercury handles dealing with messages in the inbox that may have been marked for deletion properly when it is shut down gracefully?  In other words, should we loose the midnight reboot?  It was added some time ago as it seemed to make things a bit more stable.