Jeffrey Lee wrote:
> Are they any rules to stop this type of spam? It is continually
> growing and doesnt ever let up.
>
> Thanks,
> Jeff
The Account #'s constantly change in batches, we tried
a few rulesets to nail them and they work for a small period
of time. After that, more keep streaming in.
Have found two things that seem to work effectively:
#1 - Spamhaus. We tweaked the MailScanner side of our
MS/SA package so that if a 'From' has 1 list hit it's Spam
and WAS delivered to the receipient as a UCE attachment. We
then had 2 or more lists going straight to bogus spam.
After awhile the UCE's were growing and rather pointless
as 99% were spam so we modified it a bit more like this:
We use MailWatch, so now a 1-list hit is quarantined
for review. A 2-list or more is also quarantined but flagged
as Hi-Score spam. Why? So that we can review them if they
look legit (we find 1-2 per 100 that are kosher) and also
then SA-Learn them or review the content to write better SA
rulesets to catch the crud. SA kicks in after MailScanner
in our config, so the less we have to make SA work - the better
the load average reduction.
By adding Spamhaus's 'lite' list (forget which one, but
will look that up) it seems to catch a ton of these types of
mails that are getting reported by ISP/HSP's and therefore
they're not being delivered. Usually it's the only one that
appears in the Spam Test, otherwise if it's really bogus it
shows up with 2+ hits on UCEL1, CBL, DSBL, BLITZED, etc.
Spamhaus also seems to catch most of the mail forged
with Cable & DSL providers so we can see if it's legit before
releasing it to the customer. We simply created a release
message that has the original as an attachment and tells
the customer 'This is blocked. If it's kosher send us a
reply stating so, if it's spam this is your only notice of
the block and it stays in place'. That seems to work much
more effectively than trying to train monkeys to feed Bayes
or muck with their e-mails forwarding them somewhere as
most just are lucky to know how to READ their e-mails.
#2 - Firewall. We added an external PCI card based
firewall to our setups that has it's own CPU and essentially
gives us a GUI version of IPTables. Most of the crud you're
asking about tends to come from certain regions or IP ranges
and using MailWatch to trace those back we've been able to
block just the SMTP traffic from those areas so we don't see
most of these. I note that the 1.txt slew of spam crud has
also not appeared on our systems at this point primarily as
I think we're blocking the forged or legit sources with this
firewall.
The firewall helps as it reduced the load averages on
the box by 50%+, the packets never make it to MS/SA so we
don't waste timecycles processing sludge.
HTH!
David J. Duffner
President
PSCGi
Paradise Shore Communications Group
www.pscginternet.com
I--I
Message scanned by MailScanner, and is believed to be clean.
CONFIDENTIALITY NOTICE: This transmission intended for the
specified destination and person. If this is not you, this
e-mail must be deleted immediately. www.pscginternet.com
