[NCLUG] Re: Spam Help

Bob Proulx bob at proulx.com
Thu Dec 4 13:37:54 MST 2008


Matt Rosing wrote:
> Bob wrote:
>  > By the time that you have received the mail it is really too late and
>  > very problematic.  If you can't reject at smtp time then it is just a
>  > bad situation.
> 
> Here's where I prove I'm dangerous: Does spamassasin sit too far down
> the pipe to reject it at smtp time? I use Postfix and I'm not sure how
> spamassasin fit in. I assume the configurations you're talking about
> should be in postfix?

It depends upon where you have SpamAssassin configured in your mail
path.  If it is configured into your MTA and runs at SMTP time and can
cause a rejection at SMTP time then that is okay.  If your MTA
receives the mail and then spools it off to be read into your mailbox
and you have SpamAssassin configured to be run when mail comes into
your mailbox through procmail or some such then that is too late to
send a bounce message.

Configuring SA into procmail is very easy.  That is probably the
default case.  There are other advantages too.  I do it this way.  I
save three months worth of spam in a caught spam folder.  I can at any
time reach in there and look for mail that might have been
misclassified.  Configuring SA into the MTA is a little more
difficult.  There is the benefit of being able to reject there.  But
it is a performance hog and can slow things down quite a bit too.  I
bet there are a lot of people reading this list who would strongly
prefer one way or the other and have good reasons for it.

But once you have received the mail and closed the connection to the
client host sending you the message then it is too late to reject it.
Most spam has forged from headers.  If you reject it and send a bounce
back to the victim who was forged then they get a backscatter spam.

  http://en.wikipedia.org/wiki/Backscatter_(e-mail)

After you have received the spam about the best thing you can do is to
discard it.  Report it to an anti-spam organization.  Whatever.  But
don't generate a bounce for it.  I am sure you have gotten bounces
from spam from people who have rejected/deflected it to you.  It is
rude.  It will get you on blacklists for being a spam source yourself.

I reject at smtp time based upon various DNSBLs.  This is safe from a
backscatter point of view because you are not generating a message.
The client host who is forwarding mail to you may be an open mail
relay or it may be an virus infected spambot.  Whatever.  Let them be
the bad host sending spam.  Currently I am using these three DNSBLs.
YMMV.

        reject_rbl_client dul.dnsbl.sorbs.net,
        reject_rbl_client sbl.spamhaus.org,
        reject_rbl_client cbl.abuseat.org,

Plus my own local hard blacklist.  These are the only ones that I
reject at smtp time.  Plus greylisting, which isn't a hard reject.
Greylisting is just temporary, like a full disk or a dns failure, and
will retry.  The rest come through and are delivered to my mailbox.

At delivery time to my mailbox I run SpamAssassin via procmail.  If a
message is classified as spam I file it into a caughtspam folder in
maildir format.  In maildir format every message is an individual
file.  Then I run 'find' on it by cron to expire messages older than
three months.  I rarely look at it.  But messages are there if I want
to peruse it.

  find caughtspam -mtime +90 -type f -exec rm -f {} +

This is fairly maintenance free.  Except for keeping SpamAssassin
rules updated, and training Bayes on error, I rarely need to do
anything about it.  I run sa-update by cron to install the latest SA
rules automatically.  I use the sought.cf rules automatically updated
which do quite a good job on topically changing spam.

  http://wiki.apache.org/spamassassin/SoughtRules

There are many different ways to do spam filtering with pros and cons
associated with each.  Opposing techniques are good because they
evolve into better techniques over time.  Darwin's observations on
evolution could be applied to software development as Good versus Evil
do battle.  :-)

Bob



More information about the NCLUG mailing list