On Thu, Feb 14, 2002 at 02:32:05PM -0600, Tim Tyler wrote: > Qpopper experts, > We are running qpopper 4.03 on aix 4.3.3 systems. I am in a quandary about > how to handle setting soft and hard quotas for incoming email for 1500 > users and am open to different suggestions. We have set a 10mgb quota on > the mailbox files for each user in /var/spool/mail. If we have the temp > pop files located in /var/spool/mail, then they are unable to retrieve > exisiting email if they hit their quota limit. If we put the temp file in > another filesystem without a quota such as /var/spool/pop, then users can > still retrieve their email, but on occasion an incoming message comes in > while they are popping their email and if they have "leave on server" they > can exceed quota while retrieving.
Remember that if they have "leave on server" they are likely to end up exceeding the quota > This results in the inability to write > the entire temp file back to /var/spool/mail. Hence, the temp file gets > stuck in the /var/spool/pop directory which has no quota and can grow very > large as new mail appends to it. We could set a quota on /var/spool/pop, > but even that wouldn't allow the ability to write back to /var/spool/mail > if new mail comes in. Any thoughts on this dilema? Try this combination: 1) Enable server mode (eliminates some of the multiple copies); 2) Put /var/spool/pop on a separate file system with no quota or a larger quota; and 3) set a hard quota on /var/spool/mail to at least 2x the soft quota; 4) (Optionally) to compensate for having the hard quota set high, and prevent them running up to that limit, you could lower the grace period for the soft quota to a relatively short interval (e.g. < 1 day) 5) (Optionally) implement a script which promptly notifies users (before the expiration of the grace period!) that they are over quota and must reduce their mailbox size ASAP. Be aware that quotas do not make administration completely painless and automatic. There will still be windows where something can happen at just the wrong time (mail arriving during the POP session and pushing the user just over quota) and you will need to manually intervene to restore functionality for that user. There will always be users who ignore the quotas until their incoming mail starts bouncing and they also can't POP it, and then flip out. It's better to approach quotas as simply reducing, on average, the amount of system administration and support work you have to do, and shifting that work from panicky "we're out of disk!" type crises which affect everyone, to work on user education and support. > Ideally, it would be nice if no new incoming email could get delivered > to /var/spool/mail while in the process of retrieving email (popping). But > this might be a bad idea if it actually gets rejected. Thoughts? > > Second question, does qpopper increase the size of the mailbox file > slightly when popping by adding in any headers, etc? Yes, actually it does - it inserts X-UIDL headers. There are boundary cases where this could cause the mailbox to expand over quota. Quotas are not a panacea, but implementing them did finally eliminate certain types of crises which we used to have periodically. (E.g. a mail forwarding loop gets accidentally set up, and someone's mailbox balloons to 500MB before we can break the loop.) -- Clifton -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
