At 11:33 2002-09-25 -0500, listuser(_at_)neo(_dot_)pittstate(_dot_)edu did say:
Can anyone give me a hand with the creation of a recipe to strip bounces
from an existing spool? I have a user with an infected machine. Their
spools has grown to about 620MB with the bounces of the infected messages.
Unless I've botched something here, this is what I'd suggest:
create and test procmail recipe (see my disclaimer link for info on
the "sandbox" approach I use)
Put the filter and procmail into place in user's dir (deal with how
you have procmail configured on your host - LDA versus .forward
invoked)
(now, new arriving email will be subject to the filter)
MOVE the user's mailbox to a new location. If you don't, you have an
endless loop condition which won't improve your situation.
formail -s procmail -Y -d username < moved_mailbox
Now, mail in the user's mailbox is clean (though, newly ariving mail
while processing the old mailbox may appear in a different order).
The core rule which would strip out most bounces will be something like:
# as appropriate
MAILDIR=$HOME/Mail
# because, you want to know what happens
VERBOSE=YES
# somplace to log
LOGFILE=$MAILDIR/log
# if from a recognized mailer account, toss it out as a bounce
:0:
* ^FROM_MAILER
bounced_crap.mbx
Whether you store them in a mailbox or trash them is up to you - if you're
going to trash them, I'd suggest you thoughougly test this, or at least
advise the user that legitimate bounces are going by the wayside as a
result. Also, whether the filter remains in effect after the mailbox is
fixed....
You could choose to only toss large bounces:
:0:
* ^FROM_MAILER
* > 10000
bounced_crap.mbx
You could use a delivery action that stream compresses the mailbox:
:0:
* ^FROM_MAILER
* > 10000
| gzip -9fc >> bounced_crap.mbx.gz
Or, you could choose to truncate the large bounces to some arbitrary number
of lines (here, 120 - the sed operation deletes from line 121 to end):
:0fbi
* ^FROM_MAILER
* > 10000
| sed -e '121,$d'
This truncation would chop large attachments partway - MIME attachments
would be affected, but as what remains is still text, the basic jist of the
bounce should still be intelligible.
If the bounces themselves are coming from a certain domain or another, you
could revise the conditions to reflect that. Sendmail rules could also be
useful in rejecting the bounces for this particular user as well.
Like CPR and fire extinguishers, being familiar with something is a good
idea before you're presented with an emergency situation. After you
resolve this current issue, I'd encourage you to learn to use procmail so
that you'll be better prepared should something similar strike up in the
future.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail