> > > 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?
