Subject: PINE & Disk Quotas

From: Debra Crowe <[email-masked]>
Date: Tue, 20 Jul 1993 15:41:30 -0700 (PDT)

Pine-folk,
We've recently implemented disk quotas on our mail spool area in an
attempt to control the problem of users who let their mail inbox get out
of control (10MB...). Interestingly enough, we've noticed a quirk with
pine not allowing users who've reached their mail spool limit to delete
any messages from their inbox. Elm and mail will allow the messages to be
deleted, but pine won't 'expunge' them. We're running pine vsn 3.05 on a
DEC 5900 w/Ultrix 4.3. Anyone else aware of this problem/feature and it's fix?
Will an upgrade to 3.07 fix this? Thanks,

Debra Crowe, User Services                 Email: [email-masked]
University Computing Services              Phone: (503) 737-2998
Oregon State University
Corvallis, OR 97331

---

From: Mark Crispin <[email-masked]>
Date: Tue, 20 Jul 1993 16:09:57 -0700 (PDT)

Hi Debra -

     That particular quirk isn't fixed yet, but it is on my list (= I'm the
turkey to beat up about it).

     The problem is that Pine makes a worst-case guess of how much disk space
it will need to complete a checkpoint or expunge before it will do it, and if
it cannot obtain that worst-case space it will decline to do the operation.
Pine's estimate is a bit too conservative; it multiplies the number of
messages by the size of a maximum-sized Status:/X-Status: pair of lines and
adds that to the current message size.  It makes no adjustment for messages
which may already have Status:/X-Status: lines; doing this via kludge is easy,
doing it right (safely) is hard.  Worse, it makes no adjustment in expunge for
messages which are deleted.

     The concept to fix the latter is easy; an implementation that is
guaranteed safe is much harder.  In particular, I am worried about the
scenario of what happens when the user does an expunge, but even after the
expunge she is still over quota.  [This is particularly likely to happen in
transition to quotas, such as you are doing now.]  Some systems will not
permit you to rewrite data over quota, even if the result of the rewrite is to
make you be less over quota.

     In other words, I am very worried about the prospect of leaving the user
with a damaged mail folder.  Although it's bad to force the user to seek
expert help when she is over quota, it's worse to risk destroying her mail
folder.  It's one thing to accept the risk by running Elm or mail; it's quite
another for Pine (which is advertised to be a safe ``rubber room'') to make
such decisions...

     The workaround for this problem is to be sure that the user is alerted to
the problem when she crosses her soft quota, so she doesn't reach her hard
quota.  This isn't the final word on this issue.

-- Mark --

---

From: Dan Schlitt <[email-masked]>
Date: Wed, 21 Jul 1993 08:52:41 -0400 (EDT)

Disk quotas are a good thing but they are not the answer to all disk
useage problems.  I lean toward the position that they are not a good
solution to the system mailbox size problem.  The solution that I have
used is to monitor the useage on a regular basis.

In most cases the disk partition that contains the system mail spool also
has other spools in it.  Quotas will control the aggregate use of all of
these spools and not just the mailboxes.

On our Sun systems we NFS mount the mailspool.  The Sun quota suite is not
good about warning users of quota problems on NFS mounted directories.

I would not want mail to fail and be lost because of quota problems, even
for an uncooperative user who insists on keeping a very large system
mailbox.  I value e-mail service too highly to allow this kind of problem.
It is my impression that sendmail will not know about the quotas on the
system mail spool when it accepts mail from a remote site.  Such mail will
be queued in sendmail's spool directory for local delivery.  If these two
spools share the same partition then what has the quota gained you in
saved disk space?  It has just delayed the delivery of the mail at best.

Generally mailboxes grow fairly slowly so regular monitoring will allow
the manager to detect problems before they become critical.  Exceptions
are cases where a user is the subject of a "mail bombing" or does
something dumb like having a 10 Meg file mailed to them.  Those cases will
probably require intervention even in the presence of quotas.

I monitor disk useage on a partition basis ( df(1) ) daily.  The spool
partition needs to have enough free space that I can detect and deal with
problems before they create real problems.  At weekly intervals I use a
public domain program called cobwebs to list large and old mailboxes.  You
can probably write an awk script or a perl program to do the same thing. 
I have adopted a variety of methods of dealing with large mailboxes which
range from notification of the user to immediate active intervention.

Once users realize that there are limits to what is acceptable in the way
of keeping mail in the system mailbox they will tend to keep thing
reasonable.  Monitoring overall disk useage is good management so that is
not really added time spent on mail.  It doesn't take much time to scan
the list of big and old mailboxes.  I spend very little time in managing
this proble.

This is not to say that Mark shouldn't fix the things that he says he
would like to fix.  It does suggest that quotas may be a meat axe approach
to a problem that is better treated more delicately.

Dan Schlitt                           School of Engineering Computer Systems
[email-masked]        City College of New York
(212)650-6760                         New York, NY 10031

---

From: "Lisa M. Frye" <[email-masked]>
Date: Wed, 21 Jul 1993 11:17:46 -0400 (EDT)

Another possibility is the program mailclean.  We have just starting
using this program here at Kutztown and I am finding it works well.  You
can set a size of how large an inbox can become and run mailclean.  If
mailclean encounters an inbox that is larger than the specified size, it
will save the inbox in the /tmp (by default, which can be changed)
directory.  The user will receive a mail message indicating that their
inbox was too large and it will tell them where there inbox was saved and
how they can access it.  Then you can clean the /tmp directory as you
wish.  The "folder" created in the /tmp directory is accessible by pine. 
So far, this is working great - it keeps our inboxes to a manageable size
and still allows the user ample time to retrieve the "other inbox".

       Lisa Frye                    683-4474          
       Computer Services            LMS Annex Room 105
       Kutztown University          [email-masked]

  "You can bring a person to the university, but you can't make them think."