Fighting bogus news spam
mouss at netoyen.net
Sun Jul 27 15:33:38 EDT 2008
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
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
> 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. :)
More information about the Bogofilter