[Top][All Lists]
[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 !!!
- sieve, and header_t's api, Sam Roberts, 2001/04/22
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/22
- Message not available
- Re: sieve, and header_t's api, Sam Roberts, 2001/04/23
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/23
- Bug in mapfile_stream.c, Sergey Poznyakoff, 2001/04/23
- Sergey(patch mbx_mbox.c), Alain Magloire, 2001/04/23
- POP3d locking, Alain Magloire, 2001/04/23
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking,
Alain Magloire <=
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/24