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
