[tpop3d-discuss] Maildir locking, to prevent more than 1 simultaneous access?

[Rich, WhidbeyNet NOC]

Chris, List,

"I'll put in an option to lock the maildir, and make tpop3d error if the
message has already been deleted."

I'm glad I wasn't overlooking something obvious. We really appreciate
your work Chris!!

Rich Sandberg
mailadmin@whidbey.net
WhidbeyNet Network Operations

> -----Original Message-----
> From: tpop3d-discuss-admin@lists.beasts.org 
> [mailto:tpop3d-discuss-admin@lists.beasts.org] On Behalf Of 
> Chris Lightfoot
> Sent: Thursday, January 23, 2003 1:25 AM
> To: Rich, WhidbeyNet NOC
> Cc: tpop3d-discuss@lists.beasts.org
> Subject: Re: [tpop3d-discuss] Maildir locking, to prevent 
> more than 1 simultaneous access?
> 
> 
> On Wed, Jan 22, 2003 at 06:04:50PM -0800, Rich, WhidbeyNet NOC wrote:
> > >From the documentation, tpop3d relies on "the atomicity of certain
> > filesystem operations" for managing Maildir locks. And that 
> apparently 
> > works; no two clients can actually modify a file at once. However, 
> > according to RFC 1939, tpop3d should be preventing two or 
> more clients 
> > from authenticating at all:
> > 
> > "Once the POP3 server has determined through the use of any 
> > authentication command that the client should be given 
> access to the 
> > appropriate maildrop, 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."
>     [...]
> > Keep in mind we have 5 POP3 machines, who each access Maildirs over 
> > NFS. So the only authentication lock I can think of would be with a 
> > dot-file. In the future, could tpop3d be told to 
> "maildir-auth-lock = 
> > $home/Maildir/tpop3d.lock"? Or is there some way around this issue?
> 
> That's certainly feasible, though it's worth remarking
> that you may run into problems if you have other clients
> which don't obey whatever locking semantics tpop3d
> implements.
> 
> A better alternative may be to return an error in the case 
> where the message has been deleted. This requires a few small 
> changes to the code. So in your example you would see
> 
>     RETR num
>     -ERR message already deleted by another instance
> 
> -- I don't know in practice which of these would work
> better. The latter is probably neater, but as you observe 
> locking the mailbox exclusively is what the spec demands. 
> Does anybody know what qpop3d does here?
> 
 
http://www.ornl.gov/cts/archives/mailing-lists/qmail/1999/10/msg00168.ht
ml

-- doesn't lock, apparently.

I'll put in an option to lock the maildir, and make tpop3d error if the
message has already been deleted.

-- 
``Then it occurred to me that I was standing there pissing on Nancy
Reagan's
  life work, and that made me feel better about it.''
  (Jamie Zawinski, commenting on a urinal soap bar marked `Say No To
Drugs!')

_______________________________________________
tpop3d-discuss mailing list
tpop3d-discuss@lists.beasts.org
http://lists.beasts.org/mailman/listinfo/tpop3d-discuss