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. The
idea of going to a lower grace period such as 1 has crossed my mind
before. I couldn't find anywhere in the AIX instructions for how to do
this, but assuming I can, I may give this a try to see if it helps minimize
the problem though it is certain that any time a person is popping their
email, the door is open for more mail to arrive regardless of soft and hard
quota settings.
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.
Tim
At 01:03 PM 02/14/2002 -1000, Clifton Royston wrote:
>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
Tim Tyler
Network Engineer - Beloit College
[EMAIL PROTECTED]
