|Wed 1998-12-09 Peter Jay Salzman
<psalzman(_at_)landau(_dot_)ucdavis(_dot_)edu> list.procmail
| > -I "X-Mailer: Spam Complaint"
|
| 1- this recipe will probably grow quite large. is there a way to hold
| known spammers in a separate file? does someone have a file like this?
List of known spammers is not very efective way to catch UBE. There are so
many throwaway accounts. If you really want this, see from pm-tips
ftp://cs.uta.fi/pub/ssjaaa/pm-tips.html
(order .txt version from File Server, see X-info header)
15.13 Kill: simple killfile recipe with procmail
Kill files are widely used with newsreaders to delete uninteresting
posts when you enter a newsgroup. A kill file usually contains one
single entry per line to match the message content and this can be
easily done with procmail. Remember however that for every message
procmail forks a process, so before you apply the killfile rules to
the messages, be sure your recipes are in this order: the killfile
rules are applied only to *unknown* messages
SINK MAILING-LISTS
SINK ANNOUNCEMENTS
SINK WORK MESSAGES
OTHER DELIVERIES
apply killfile rules and UBE recipes to the rest
Recipe will drop the message (i.e. consider it 'delivered') if one
of its headers matches a pattern in killfile.
:0 hW: $HOME/.killfile$LOCKEXT
| egrep -i -f $HOME/.killfile
I would suggest using more sophisticated fileters that out there, like
Catherine's Spambouncer, Grogory's Junkfilter and others
4.7 Procmail code to filter UBE
Or you could go non-procmail way. The "RBL lookup tool" is very efficient
way or doing check against list of known bad domains
3.0 Anti-UBE pointers
| 2- is there a way of writing something like "an email from <FOO(_at_)BAR> was
| deleted off hand" when this recipe gets run?
You just have to derive the address of the sender from From_ or Sender
field
# Notice, I don't recommend using $FORMAIL -rt -zxTo:
# Because it starts extra process that we don't need. The procmail
# MATCH feature is enough and 10x more efficient.
* From \/.*
If you need help with exploding line to components, like pure EMAIL address,
see module pm-jaaddr.rc from pm-code.shar kit. (See X-info and File server)
| 3- most likely the reply will go to a bogus address.
Yes. Ignore the From/Sender etc addresses.
| is there a way of of
| cc'ing it to:
| 1- the postmaster of the host listed in From:
| 2- the postmaster of the host listed in the first Received:
| (which is probably the right person to send it to).
Wrong move. See stories from pm-tips
2.3 UBE and bouncing message back
Rule number one
Never send automatic complaints.
It will go to wrong address someday and your apologizy is needed to several
hundreas of people. (imagine the worst scenario, where the complaint
went to mailing list)
Rule two
Manually investigate the trapped messages and select the ones that need
actions.
To help the postmasters do reverse lookups and traceroute and all
possibly things that you can to help the sysadm to plug in their relay
hole and kick that idiot from net.
| > # legitimate mail, we'll leave a back door open. Any email with a subject
| > # of "spam error" will be accepted. also, we want to keep any email that
| > # originates from ucd.
| > :0:
| > * ^Subject.*spam error|^From.*ucdavis
| > $DEFAULT
I would put the recipe here. Here is new section from pm-tips
6.20 Order of the procmail recipes
When you start writing lot of procmail recipes, you soon find out
that it matters a great deal in which order your put your recipes. When
each group of recipes starts growing too big, you usually move each
group handling to separate rc file. He is recommended order:
- backup important messages
- cron-subroutine,
- handle duplicates
- handle DAEMON MESSAGES
- handle plus addressed message (RFC plus or sendmail plus
addresses)
- handle server requests (file server, ping responder...)
- drop MAILING LIST messages
- send possible vacation replies only after all above
- apply kill file
- detect mime and format or modify the message body
- save private messages
- and last: FILTER UBE.
The backup, cron and duplicate handling go naturally to the beginning
of your .procmailrc. Next comes a grey area where Daemon, plus handling
(#REF #using_rfc_comment_trick_for; Note plus;); and server messages can
be put.
Mailing lists should be handled as early as possible, but after the
server messages, because you want your services handled first.
Do not send vacation replies before you have handled mailing lists.
After that you are left with "known" private messages and those of
unknown origin. A kill file (you block the sender) for rapid
spammers, who send you message or several per day needs to be
addressds before checking other messages.
Last but not least: Put your UBE checkers to the end to avoid mishits
of valid mail. DO NOT SEND AUTOMATIC COMPLAINT BACK. Drop the
UBE to folder, manually select the messages that need actions
and send message to postmasters in the Received chain explaining that
their mail relay has been hijacked.
| 4- would the prefered way of expressing this be
|
| * ^(Subject.*spam error | ^From.*ucdavis)
|
| is there a prefered way of expressing this?
The de facto way to complaint is to prepend word
ABUSE:
in front of original subject when you're returning the message to postmaster.
| much thanks. if anyone has some really neat spam filters, i'd love to see
| what other people are doing with this wonderful program.
You fill find many "tested and tried during years" from section "4.7 Procmail
code to filter UBE"
jari