Fighting bogus news spam

[mouss]

Sven Hoexter wrote:
> On Sat, Jul 26, 2008 at 03:19:54PM -0700, paul at paulbeard.org wrote:
> 
>> I have never gotten bogofilter to work in my Postfix-based setup, but what
>> has been so far 100% effective is greylisting. Assuming spammers get no
>> smarter, it should work just as well for some time to come.


Spammers have started to retry since some time. so the big benefit from 
greylisting is if the zombies get listed in a DNSBL before they retry 
(assuming you use a DNSBL. zen.spamhaus.org is a recommended one).

of course, GL has its problems. Mostly, delaying mail, thus possibly 
"breaking conversations" (when many people communicate, but you don't 
see the response of one of them because you GLed him, but others see his 
mail so as a user, you'll have a "bad mail experience", which maybe ok 
for you, but is not for "common users"). And when the user tells you "I 
just got foobar on the phone and he sent me the important barfoo 
document. all the other recipients have received it. wtf did our admins 
doing?"...).

That said, if used selectively (only greylist if you see some patterns 
in the envelope), then it should be ok (and in this case, you can 
increase the delay to give DNSBLs the time to list the annoying zombie).

> 
> Well bogofilter wasn't developed to work at the SMTP level like greylisting.
> The approach is slightly different. :)
> 
> Beside that I remember a paper from a few years ago where two guys build
> some smtp level filtering with qmail and bogofilter. I don't know if someone
> ever tried it but something like this should be also possible with a postfix
> policy service or through the milter interface.

not with a policy service (it only see the SMTP envelope), but you can 
either use milters or proxy_filter (content_filter during the smtp 
transaction, before mail is queued). that would be feasible, but 
filtering during the smtp transaction is not without problems (timeout 
if filtering takes time, possibly resulting in duplicate mail. DoS 
vulnerability since it is the attacker who drives when you run the 
filter. no more FP review. ... etc). so it's unclear whether the 
advantages (reject at smtp time, thus no quarantine/disposition to care 
for) outweight the drawbacks. at this time, I think not.

> 
> 
>> I'd like to engage bogofilter as well, but this will do until it gets
>> easier or I get quicker in the uptake.

the simplest way it to run bogofilter from the MDA (at delivery time). 
at this time, you only deliver one recipient at a time, so per user 
filtering is simple.

that said, you can still run bogofilter from a wrapper script as a 
content filter (or run it from proxsmtp or the like). If I have the 
time, i'll test this. the problem here is what to do with multi 
recipient mail: assume site-wide filtering or split the message? or run 
bogo multiple times and put multiple headers that a later program would 
process?

> 
> It works like a charm and isn't that hard. Maybe you should open another
> thread and describe how you'd like to deploy bogofilter and where you
> failed so far. Just because the list is mostly silent that doesn't mean
> you're not allowed to disturb the silence. :)
> 
> Sven