funsec mailing list archives

Re: 95% of User Generated Content is spam or malicious


From: Drsolly <drsollyp () drsolly com>
Date: Sun, 14 Feb 2010 22:11:36 +0000 (GMT)

I do a lot of stuff using regexs after the mail has got to me, but the 
final despamming uses a weird old tip discovered by a mom. I sort the mail 
alphabetically by subject.

On Sun, 14 Feb 2010, Rich Kulawiec wrote:

On Wed, Feb 10, 2010 at 10:24:27PM -0500, Dave Paris wrote:
Where the trick (to the extent it's a trick, I suppose) lies here is 
what it takes to knock down this volume.  

I use my firewalls/routers.  Beginning with the DROP list, followed up
by a large number of country, so-called ISP/webhost (spammer front,
e.g., Eonix), so-called ESP (spammers, e.g., iContact, Uptilt) blocks.
And I use passive OS recognition to treat anything that's running
Windows differently -- because the the odds are in the 10e4-10e6
to 1 range that it's not a real mail server, depending on how I
construct the metric.

Then I enforce DNS/rDNS existence and consistency checks on the connecting
host and the HELO parameter.  Then I use a large set of rDNS patterns
that's been very carefully developed to match non-mail-sending
hosts (e.g. end-user systems) and refuse everything from them outright:
real mail systems have real names, not generic ones.

Then I use a local blacklist of domains, sender LHS, senders, hosts,
networks, etc.  Then several DNSBLs.  And a few other things.

This is an extremely effective, efficient and very accurate setup.
It's effective because it doesn't waste time trying to figure out if
the same abusers who sent spam yesterday are sending some more today:
of course they are.  It's efficient because it rejects/accepts outright
-- and when it rejects, it does so before seeing the message-body.
It's accurate (a) because it's based solely on deterministic criteria
(b) because I've been doing this for a very long time (sadly) and
have learned a few things by now and (c) because it's correlated against
my own mail logs, a necessary but seldom-performed step that helps me
understand what the spam and non-spam components of my mail stream are.

I've gone into considerably more detail about this on mailop, if you
want the extended writeup, but the bottom line is that this kind of
approach beats the pants off more complex/trendier ones in terms
of performance, simplicity, resistance to attack, FP rate, FN rate,
maintainability and predictability.  But it does require pretty
good knowledge of what *your* spam/not-spam mail mix looks like:
you've got to understand it well before deploying something like this.

---Rsk
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.


_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.


Current thread: