Randall, qpopper, Well, once again, if server mode occassionally can write to a temp file, then it seems to me that occassionally I have the same problem that I currently have without server mode (No?). If server mode never wrote the file out to a temp file, then the integrity of the system quota could be maintained. There may be more than one way to accomplish a cure-all: 1. No temp file unless it is merely to duplicate (not zero out the mailbox). The mailbox must maintain its size until the client directly requests removal. This way system quotas can be allowed to stop incoming messages when appropriate. 2. If a temp file is necessary or desired, then system quotas cannot be part of the solution. Either qpopper or the mta must keep track of the sum of both the temp file and mailbox as to whether new incoming email is allowed. The number one thing that screws up the intent of quota system is when new mail is delivered in the middle of a popping session. Large hard quotas minimize the problem, but don't remove the problem. The mta is probably a better candidate for keeping track since it is more aware of what it has to deliver and check against. But I doubt they are as eager to find a solution for this. Tim
> >At 2:14 PM -0600 2/15/02, Tim Tyler wrote: > >> 2. I presume that in server mode there is no temp file any more. > >There still is a temp file, Qpopper uses it for mutual exclusion as >well as a temporary spool location. In server mode it avoids copying >the spool to and from it in many cases (essentially, those where all >messages are deleted, or no messages were deleted and no messages >were read for the first time). > -- Tim Tyler Network Manager - Beloit College [EMAIL PROTECTED] Go Packers! Go Badgers! 1999&2000 Rose Bowl Champions!
