We have a similar problem here, with students who take a term off
and let the mail spool fill up with ${MANY} bytes of mailing list
messages which are never read anyhow. The problem was very
effectively solved by placing a .forward in the account of the user
as we disabled it:
"|/usr/local/bin/procmail /usr/local/lib/procmail/disabled.rc"
The rcfile contains, very simply (comments, etc, deleted for space):
<clip>
The filtering lets through personal mail while saving us from 90% of
the trouble caused by mailing lists. The first recipe sufficed for
most everything; there were at the time perhaps two more mailing lists
which needed the second recipe.
When I make changes, or when we just want to check how it's doing, I
create a zero-length logfile, chmod it to 666 -- the Permissions of
the Beast[tm], but needed here -- and switch #'s on the LOGFILE entries.
A few days later, I change switch them back.
Never needed formail(1) for any of it. May be completely
inappropriate for your situation, but thought it might help.
An interesting approach! I may use it in the future. However, it doesn't
quite do what I needed right now, which was to just delete the already
existing mail messages without killing the mail server with infinite forks.
I was right. I'm not subscribed, but I will be shortly...
The international students, when gone for a month, tally up about 1000 mail
messages each, and it takes a LONG time to formail then without the -n
flag. Of course, WITH the -n flag, the machine dies a horrible resource-drained
death.
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
doug(_at_)eng(_dot_)auburn(_dot_)edu
Pro is to Con as progress is to congress