Clifton, Alan, Ok, perhaps moving to server mode is a good idea. I have a couple questions: 1. What is the consequence of elm and popping at the same time? How easy is it to repair? -note: I agree that it is probably rare that it would happen simultaneously, but I am sure it eventually will. 2. I presume that in server mode there is no temp file any more. How does one keep track of the last time a user popped? This is important for me in finding stagnant accounts. Thanks for the attachment! Tim
> >On Fri, Feb 15, 2002 at 10:19:06AM -0600, Tim Tyler wrote: >> Clifton, >> Thanks, most of what you and Alan Brown stated is pretty much how I was >> leaning. I think you are correct that the best I can do is to minimize my >> problem, but never eliminate it. I had already doubled the hard quota on >> one of my servers. I will do it with our student server as well. I also >> wrote a script earlier this week to warn users that were in their grace >> period about exceeding quota. This will help to some degree. >> I can't really go to server mode because we still have shell users. > > So do we. I think you need this patch I wrote against 4.0.3 last >year, which I'm including as an attachment. > > It hasn't been incorporated into the main release as of 4.0.3, but >maybe in one of the upcoming ones - what it does is let you manage >server mode on a per-user basis based on what shell is assigned to the >user in /etc/passwd. Thus if you assign /sbin/nologin or /bin/false as >the shell for users who don't actually have shell access, or even if >you assign /bin/sh for users who theoretically have shell access but >never use it, you can specify that to qpopper and have it jump into >server mode for those users after they authenticate. > > IMAP interaction with qpopper server mode is still a problem, *but* I >am now well along with debugging a patch that provides interoperability >of qpopper server mode and UW imapd (and pine!), by adding an option >for qpopper to use UW-style mailbox locks on the user's mailspool for >the duration of the POP session. It turned out to be much more work >than I thought, but I now have it running on a test server while I beat >on it and finish debugging some interactions. Still some weeks away >from general release, most likely, but it will get finished because an >important internal project here depends on it working. > > >> I would like to comment that quota issues have become increasingly more >> difficult to manage with everyone sharing music, graphics, videos, etc. It >> would be nice if someday Qpopper were able to implement its own internal >> quota system where the sum of the mailbox file (prior to popping) and any >> new incoming email cannot exceed a given limit during the popping >> process. That way system hard limits wouldn't be thwarted by qpopper so >> easily. > > To niggle a bit, really the problem is that qpopper *can't* thwart >the system hard limits and therefore requires the admin to stretch the >limits for it; and the MTA or mail delivery agent don't know that they >must respect the lower limits. > > Nonetheless, these are good comments. A good well-integrated patch >to implement them would of course also be welcome! :-) Otherwise, well, >it'll happen when it happens. > > -- Clifton > >-- > Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] > WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau > -- Tim Tyler Network Manager - Beloit College [EMAIL PROTECTED] Go Packers! Go Badgers! 1999&2000 Rose Bowl Champions!
