OK so I made another test:

I opened a mailbox with IMAP, removed the connection to the network from the computer running the IMAP client, and closed the IMAP client. The connection was still up in Mercury's console, and the lock file was still there. I reconnected the network and opened the mailbox again. Mercury now showed two concurrent IMAP connections to the mailbox. The mailbox was fully accessible, except messages could not be deleted (which is expected behavior with more than one IMAP connection).

Multiple IMAP connections to the same mailbox are allowed, so if one connection is lost due to client side failure it makes no difference for creating a new one.

The best shot at finding out what actually happens when your user gets locked out is probably still to try to catch it in a session log. 

Have run into a situation where remote IMAP users loose connection at what would appear to be the most inopportune moment for whatever reason, usually crappy wireless connection.  After this has happened no other IMAP client can connect to the account for some period of time, presumable a half hour although I have not timed this exactly.  Have TCP/IP timeout set to 120 seconds and IMAP idle Timeout set to the minimum 30 minutes. This seems to have started happening since the release of the final version of 4.80.  Does not happen real often, but I see it every few days happen to someone.  Was there a change in behavior with the most recent release or is there some other solution?

Gus

There were a number of updates for IMAP in v4.80 beta and I think one in the final release, but multiple IMAP connections to the same account are allowed in this version just as it was in the previous version. I haven't noticed any similar issue here, but if it would be possible for you to provide a session log we could try to track it.

Rolf,

If a connection problem caused reconnect failures due to some sort of credential issue would that temporarily block access for a period of time?

Since this only happens once every few days, chance of catching a log is really low.  I usually only find out after a user complains after the event.  I do know that it does not happen every time thus my comment about inopportune moment.  I do know that mailboxm.lck exists in the users mail folder for the duration of the event.  I would hope that a dropped connection would back out any processes requiring a lock and remove the lock. 

Gus

Configuration > MercuryI IMAP4 Server > General tab > and fill out all the Logging info, making sure to tick the 'Enable Session Logging' checkbox. You'll capture all IMAP events and will be able to easily track down a problematic connection.

The mailboxm.lck file is as far as I can see supposed to prevent Pegasus Mail from directly accessing a mailbox that is in use by IMAP, but shouldn't prevent another IMAP connection to the mailbox to be established.

Brian: If there was some shortterm blacklisting (due to multiple login failures) in place I would expect to see log entries about that. A broken connection shouldn't really trigger blacklisting. I'm not sure how MercuryI handles blacklisting though as I don't think I've ever seen it happen. Anyway, it's possible to exclude IP ranges from it in MercuryI configuration.

Thanks Rolf.  I was curious because when troubleshooting a couple of iPhones I could see connection attempts in the MercI window but then they would stop even though attempts continued to be made by the phone.  It appeared the attempts started being blocked so I just told the users to come back in an hour.  I eventually got them both working but remain curious whether Mercury had indeed blocked after some number of failed attempts.

For what its worth, the instance that I actually observed occurred when a copy of Outlook suddenly lost network connection and was not able to reconnect, device was unexpectedly powered down.  Starting a copy of Thunderbird on another computer that was set up to the same account was not able to connect for a long time, probably about a half hour.  During that time period the mailboxm.lck file existed in the mail folder for that account.  In other words it took Mercury at least a half hour to figure out that the first connection had gone away and remove the locks on the account.  A quick look at netstat on the Mercury box showed that all connections from the dead box were indeed gone.  Have had enough complaints from users with similar circumstances that I am confident this is happening  regularly.

Gus

I tried to replicate that by forcing an IMAP client to close from the task manager when connected to a mailbox, but the mailboxm.lck file was still removed. I then copied the lock file back to the directory and attempted to reconnect with the IMAP client, which worked as well. If there is some other way to replicate the problem please let me know.

If IMAP idle is set to 30 minutes Mercury will presumably close any connection that hasn't been properly closed by the client after 30 minutes of inactivity.

Task manager is going to send a shutdown message to the IMAP client and cause it to disconnect normally, try pulling the network cable or power cable to the IMAP test machine, more likely to cause the problem. From what I have seen, it does not happen every time so as I said, luck of the draw as to whether the connection is lost at a moment that causes it to happen.

Yes, IMAP idle will clear the lock after 30 minutes, however would expect a lost TCP connection to back out and clear any locks that connection had set up.  Users get frustrated and give up if they have to wait as long as 30 minutes.

Gus