At 07:47 AM 5/19/2002, Greg Fitzgerald wrote:
someone give me a example of how I could take anything :0: * ^FROM: and
then grep a flat text file with a list of email addresses and or
hostnames and then pass them to $SPAM?
1. Maintain (via automated programs) a listing of FROM addresses
in the format: friend(_at_)internet(_dot_)com
email(_at_)gohan(_dot_)huge(_dot_)net
dreams(_at_)wanweb(_dot_)net
etc.
for anyone who has spammed anyone in your company in the past
(easy to do if you use intelligent mail programs such as Zmail
which provide for scripting enhancements).
2. Then add this include line into your $HOME/.procmailrc file:
INCLUDERC=$PMDIR/rc.spammers # vaccinated spammers to be eliminated
3. And write an rc.spammers recipe similar to this excerpt:
##########The following note is from Andrew Beckett, 09/97:
# After hitting the problem last week with long patterns in my rc.spammers
# file, I investigated a couple of suggestions from John Gianni.
#
# One is to use the LINEBUF variable in the procmail file to increase the
# length of the pattern. Whilst this works, it only brings temporary relief
# to the problem.
#
# The second is to use fgrep together with a list of banned addresses (which
# can be a simple list, and don't need any regexp characters, and so is
# easier to maintain). This second method works, and is contained in the
# attached rc.spammers file for you to peruse.
#
# The recipe looks like this:
#
# :0hb
# * ?grep -v '^Subject' | fgrep -s -f $PMDIR/banned
# {
# EXITCODE=77
# :0:
# automated/junk
# }
#
# The reason for using grep -v first is because when using a command
# as the check with the ? operator, the whole header gets passed (not the body),
# and so I wanted to filter out the Subject lines, so that emails sent
# with the subject "Have you received a message from blah-blah(_at_)spam" don't
# get filtered.
#
# Note that I did have fgrep -i -s -f originally, but I discovered that
# whilst this works on SunOS, it fails on Solaris (even though -i for case
# insensitivity is in the man page). I think this is probably a Solaris bug.
#
# This method has the advantage of spotting both From and To lines.
#
# I've also written the attached zmail function, which can be attached to
# your message window as follows:
#
# button -window message "Ban" "abAddToBanned $HOME/.procmail/banned"
#
# Then when you're reading a message that has slipped through, then hitting
# the Ban button will prompt you to add the From address to your
# banned list, as well as the To address if it's different from the
# From address.
###########
# Era Eriksson <era(_at_)iki(_dot_)fi> on 05Oct97, kindly suggested we use
"formail -I"
# instead of "* ?grep -v '^Subject' | fgrep -s -f $PMDIR/banned"
###########
# Shashishekhar Kurki-Gowdara (KG) kindly suggesed we use "tr" to lowercase
# each address in the ban-repeat-spam listing.
###########
# Edsel Adap <edsel(_dot_)adap(_at_)Canada(_dot_)Sun(_dot_)COM> agrees there is
a likely bug in
# Solaris 2.5.1 "/usr/bin/fgrep -i" and suggested the use of
# /usr/xpg4/bin/fgrep instead. The Solaris 2.5.1 ban-repeat-spam filter
# then becomes:
FGREP=/usr/xpg4/bin/fgrep
FGREP_OPTIONS="-i -s -f"
BANFILE=$PMDIR/banned
:0hb
* !^X-Loop: yourLogin(_at_)yourDomain\(_dot_)com
* ? formail -ISubject: | $FGREP $FGREP_OPTIONS $BANFILE
{
EXITCODE=77
:0:
$SPAMDIR/IN.repeatSpam
}
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail