procmail
[Top] [All Lists]

Re: limits on formail

1995-12-13 15:23:23

[cc'd to original chap in case, as he says, he isn't subscribed]


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):

=========================
#LOGFILE=/tmp/procmail.log
## Hope this will kill the logging w/o killing the program...
LOGFILE=/dev/null

:0 i
* ^FROM_DAEMON
/dev/null

# If that failed, but the mail headers contain "digest", dump it anyhow.
:0 EiH
* digest
/dev/null

[few other local recipes deleted]

=========================


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.



Luck++;
Phil

-- 
#include<std/disclaimer.h>               The gods do not protect fools. Fools
finger pedwards(_at_)gamma(_dot_)cs(_dot_)wright(_dot_)edu      are protected 
by more capable fools.
email pedwards(_at_)valhalla(_dot_)cs(_dot_)wright(_dot_)edu                    
        -Larry Niven

<Prev in Thread] Current Thread [Next in Thread>