[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

POP3d locking

From: Alain Magloire
Subject: POP3d locking
Date: Mon, 23 Apr 2001 20:43:54 -0400 (EDT)


> Finally, what seems to be a real problem is simultaneous access to
> the maildrop. All locking/unlocking works just fine, but I have
> come across the following situation: two sessions access the same
> mailbox simultaneously, both do LIST, then one of them does
> DELE on some message, then QUIT. The remaining session does a RETR
> and dies miserably, since its internal indices are already out of sync
> with the real maildrop contents. The comment on mbox_is_updated()
> function addresses this but the function itself is never called.
> So I added a call to mailbox_is_updated() to the pop3_mainloop()
> function just before the processing of a keyword. Also I have added
> ERR_MBOX_SYNC define to help handle the situation when
> mbox_is_updated() bails out.
> After these changes, the second session just gets the message
>       -ERR Mailbox updated by other party or corrupt
> and the connection is closed. This behaviour seems to be compatible
> with RFC, but maybe it would be better to deny simultaneous
> accesses altogether?

Good question.

The RFC just says:

                        the POP3 server then acquires an exclusive-
   access lock on the maildrop, as necessary to prevent messages from
   being modified or removed before the session enters the UPDATE state.
   If the lock is successfully acquired, the POP3 server responds with a
   positive status indicator.  The POP3 session now enters the
   TRANSACTION state, with no messages marked as deleted.  If the
   maildrop cannot be opened for some reason (for example, a lock can
   not be acquired, the client is denied access to the appropriate
   maildrop, or the maildrop cannot be parsed), the POP3 server responds
   with a negative status indicator.  (If a lock was acquired but the
   POP3 server intends to respond with a negative status indicator, the
   POP3 server must release the lock prior to rejecting the command.)

Which I find annoying, because some POP session can be rather


1- Your popose solution.

2- Follow the RFC, and completely lock the mailbox for the entire session.

3- The Qualcomm solution (QPopper) which is to move the mailbox to a new
   location ${SPOOLDIR}/.user.pop for the duration of the session.

I vote for -1- until we found a better mechanism.
We could still play it smart and keep the connection alive
if we know that the mailbox did not __shrank__ but only __grow__
(new messages delivered).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]