🚀 go-pugleaf

In article <1992Nov5.194200.3673@news.columbia.edu> dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:
>
>    We are having a problem with a full mail spool. Some users have
>large amounts of mail kept there. I am pretty sure that much of it is
>from mailing lists that they don't want to dump into thier account mbox,
>but don't really want to delete. Well, it is going to have to go now.
>

Here at OSU, we have approximately 8,000 accounts and a one gigabyte
news spool directory in our MAGNUS cluster. We also have a dedicated
mail machine in the cluster. We use home directory quotaing for all of our 
accounts.  We got into the same sticky situation you mention regarding mail
spools and, thus far, we handle it as follows:

1.) We automatically (via "cron") run a script twice a week which sends out 
    warning notices to folks who have more than 128K of mail spool in use 
    (they get *really* tired of seeing these if they are repeat
    "overutilizers"). Of course, this has the downside of
    generating still more mail traffic and spool volume :-(.
    The warning message points out the spool usage policy and
    how to go about accessing it (actually, it quotes the 
    relevant section).

2.) We periodically "migrate" the mail of users who have had over 256K of
    mail spool in use and have gotten at least two warnings. We migrate
    this mail into their home directory as a compressed file and
    send them a note (to their now empty 
    mail spool file) telling them how to decompress the file and how to 
    access the file from the common mail packages. The home directory 
    "quotaing" comes into effect in that they can be driven over quota 
    by not reading & handling their mail. This migration and notification
    is accomplished via a script. This script is run manually when 
    the mail spool usage has become a concern (i.e. >75%). We don't want
    *anyone* losing their incoming mail if we can possibly avoid it.

>   My question in regard to policy is whether it is OK to threaten to
>remove the mail. I intend to write to the active users by e-mail and ask
>them to remove excessive mail (or explain why it is neccessary to keep
>it). If they fail to respond to a reasonable attempt, I intend to delete
>the mail. (probably won't happen).

We try to never irretreivably delete mail. We are presently keeping monthly 
incremental backups in perpetuity. I guess that one thing you could
do as a last resort is have a last step of "migrating" their mail
to tape. Ideally, this sort of thing is done here for accounts inactive for
extended periods or never accessed since creation. It makes a lot
of sense to do this periodically via a script and try to bundle a lot 
of "expirations" on one tape (we use 1.2 GB DATs).

One downside of the "migration" approach is that sometimes we are
at a critical utilization level on the user disks which hold the
home directories. At these times, we can't afford the space on the
user disks to migrate (even compressed) mail to the users home
directories. One of the problems with user quotas is that they never
clean up if they never log in, so the space usage for a user
can exceed even their "hard" quota (the script which migrates
compressed spool mail to the users directory runs as "root" 
so no mail is lost). Of course the answer to this "never login"
problem is the last stage migration to tape & deletion of unused
accounts outlined above. 

Incidently, "popmail" accounts have the potential to complicate 
the whole situation enormously (especially
if the POP client user sets the client to leave the mail at the host, or 
if they never use their POP account). Our tenetive solution to this is the 
addition of a popmail server machine with its' own mail spool.

As you can see, for a large system or cluster of systems, the problem and
solutions to same can become quite complex and involve *many* 
previously unforseen factors.

>   The real question comes up for the occasional users. Some people only
>log on every few months, if that. I don't want to have to track them
>down and explain the problem to them individually. How much effort should
>I take to get in contact with them before deleting the mail as unwanted.
>We don't often remove accounts (being a depertmental machine with not too
>many users).

We get some folks here who go on sabitical for months or *years* and yet 
still want their accumulated e-mail when they get back. It is a problem.

>
>   What about runaway mailing lists? I think some of our users who don't
>log in often have joined mailing lists, but never read the mail. Can I
>look at the mail to determine if this is the case? What should I do if it
>is?

*Very* common problem I suspect. Most of the complaints I've
seen from folks who get "mail spool usage" warnings come from
folks who like to accumulate vast quantities of mailing list
spawned goodies to read in the indeterminate future (they are
generally afraid of missing an unspecifiable "something" :-). 
Usually, migrating the mail into their quotaed home directory causes
them to reevalute what is important enough to keep on disk
in semi-permanent retention.

I hope this helps identify some of the issues and a potential
(and admittedly somewhat creaky) series of solutions. Maybe
one of these days, I'll write a "spool master" package which
incorporates a portable multi-platform set of solutions to these
problems and make my fortune ;-). (Or maybe I'll just go for
"fame" and distribute it freely :0).

Of course, the usual disclaimers concerning the inadvisability
of following my advice/examples/blatherings apply and in no
way should any of this be considered as endorsed by OSU,
it management, or its' system janatorial staff.
-- 
==========================================================================
              Disclaimer: These are my views, not the U's

        "If it's in the paper it must be true!" --- D. Doright