Why doesn't this happen with imap? Why can't we make pop3 do what imap does? Even if it's inefficient, it's better than hanging all incoming mail delivery while deliver eats up our local concurrency limits.
IMAP unlocks mbox after each command is done. But POP3 clients typically just run RETR, RETR, RETR, .. so unlocking + locking again later is just extra work that slows things down. I guess there could be a timeout that if no RETR has been run for a few seconds it unlocks the mailbox.
But I've never before heard POP3 clients behaving that way, so I'd like to know what exactly are they doing. Are they not sending anything? Are they NOOPing? I don't see any reason for them to be doing either..
In the cases I've looked into, the client seems to be connected and not doing anything. I don't have access to the clients or end users, but ktrace on the pop3 process basically is producing no output or very little output over an extended period.
Could it be an interactive client which maintains an open pop connection, even when no one is actively doing anything with it?
The "unlock after a few seconds" option would be great.
Do you have any documentation or hints on how to identify or debug connecting pop clients without involving the end user?
Could it be some (older?) webmail clients that use pop3 instead of imap?