bug-mailutils
[Top][All Lists]
Advanced

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

Re: POP3d locking


From: Alain Magloire
Subject: Re: POP3d locking
Date: Tue, 24 Apr 2001 11:32:47 -0400 (EDT)

> 
> > 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).
> Yes, it seems to be necessary. I have already come across the situation
> where pop3d refused to update user's mailbox after arrival of
> some new mail during the session. I am going to implement this.
> By the way, by this time pop3d is running 2 days under a rather
> heavy load, the only problem I have seen so far is that of grown
> mailboxes.


I've put a fix for that, but I'm starting to think
that we should follow RFC 1939.  And lock the mailbox the
entire session.

I do not like the Qualcomm(QPopper) way of moving the mailbox
to $SPOOLDIR/.user.pop.  In case you wonder what I'm talking
about qpopper is the free POP3 server implemented by Qualcomm(Eudora)
It moves the entire user mailbox to .user.pop and truncate the
/var/mail/user to 0:

-  lock the mailbox
- move it to .user.pop
- truncate the original to 0
- unlock the mailbox

.... session started
.... end of session UPDATE state.

- lock the mailbox
- append any new mail while the pop sesion
  to .user.pop
- move back .user.pop to mailbox
- unlock the mailbox

This pros:
- Will let you receive emails even during
  a length POP session.
- Redundant in the face of crash:  if qpopper
  crashes, the next session will detect the .user.pop
  and do the right thing by "cat"ing the new mails to
  the old .user.pop so no mail is lost.
- You can detect another pop session and exit gracefully.
   -ERR mailbox in use.

The cons:
- security problems
    # touch /var/mail/.user.pop
    # cat junk > /var/mail/.user.pop
  i.e. if the spool mail is writable by all
  there is a race condition where other user could
  play nasty tricks on mailbox.
- When you reach your quota cat'ing back the file can
  be problem.
- Moving files around.  

So my proposition:
- lock the mailbox the entire session: i.e the lock
  is only advisory %.lock not fcntl (F_LCK )
- Check in the TRANSACTION stage for corruption
  some program may not respect the lock.
- update the lock (touchlock) .. touch the file %.lock
- unlock the mailbox rm %.lock at the end of the session.

Thoughts?

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!




reply via email to

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