[lug] Stopping the New Generation of Spam

[Ken MacFerrin]

Daniel Webb wrote:
> On Mon, Dec 04, 2006 at 11:43:22PM -0700, Ken MacFerrin wrote:
> 
>> Theoretically you're correct, but in the "real world" SMTP-time
>> filtering works fairly well because your average spammer is spewing this
>> stuff as quickly as possible using zombie machines, open relays and
>> temporary servers connected through dishonest ISPs.  It would be unusual
>> for one to spend the effort to specifically try to "traffic shape" their
>> spam just to beat your specific filter..  
> 
> Yes, that's true.  As long as a majority of servers aren't doing this they
> won't bother.  I'll bet they would if their delivery and conversion rates
> start dropping though.  They seem to be adapting as greylisting becomes more
> prevalent (although that may just be me, I don't know if that experience is
> universal).  They are going to lengths now that I doubt many would have
> expected a few years ago, like poisoning Bayesian filters and running zombie
> nets of Windows machines because the blacklists were hurting them.
> 

They are adapting, but it's typically at a larger scale to get the best
ROI.  It seems they do spend time figuring out how to get past SA
filters but I'm guessing they're doing this by examining the more
commonly used rules built into SA and from the SARE sites versus
individual servers.  Even if they're successful here though, your server
might still catch them if your bayes filters are well trained.


>> additionally, most the return addresses are invalid or joe-jobbed anyway so
>> they don't even see the responses.
> 
> Been a while since I played at the SMTP level, but couldn't they do this even
> with a false return address?  The error is during the SMTP session itself so
> the sending server decides what to do with it.  I'll bet I could whip up
> something in Python that would close the feedback loop and bypass filters in a
> few weeks.

Good point. They could. Although I've noticed that many times the
high-speed mailing apps the spammers use often don't even bother to wait
for the "250 OK" or send a "QUIT".  They simply send the DATA and drop
the connection so they can move on to spewing the next message.


>> The real drawback to SMTP-time filtering is the increased exposure for a
>> denial of service attack.  Each smtp session remains open until the filter
>> makes a decision so a DOS on your SMTP service (or even the server itself
>> depending on your limit settings) becomes much easier.
> 
> That makes sense, although it's not an issue for me.  I'll have to look into
> doing this.  It would basically whack my spam to zero without worrying about
> silent false positives.

In postfix, what you're looking for is "Before-Queue" content filtering.
 It can be memory hungry, but effective.

-Ken