(postfix) SPAM filter?

[Girish Venkatachalam]

On 14:48:35 Dec 15, Jorn Argelo wrote:
> Greylisting only works so-so nowadays. There was a couple of months it was 
> very effective, but that is long gone. Spammers aren't stupid, and they 
> follow the development of anti-spam techniques as much as e-mail admins do. 
> Greylisting is a start, but from my experience it is not nearly enough.
>

I have heard this said elsewhere too.

> Also I believe that rejecting e-mail is a big point of discussion. We had 
> an internet e-mail environment built about 3 years ago, and there the users 
> were terrorized by spam. We had some users getting 30 spam mails a day at 
> least. This setup was running amavis, spamassassin, postfix, postgrey, dcc 
> and razor. Unfortunately, over time the bayes filter got incorrectly 
> trained, and it sometimes rejected valid e-mails. If there's something you 
> DON'T want to happen it's that. And also troubleshooting those kind of 
> things can be quite hard ...

What about CRM114 and dspam? 

Have you ever tried statistical filtering instead of heuristics with
spamassassin?


> We rebuilt the environment from scratch. Right now we are running OpenBSD 
> spamd + OpenBSD Packetfilter. This functions as greylisting / greptrapping 
> in combination with the PF firewall. We made a couple of scripts to trap 
> invalid / forged e-mail addresses that are greylisted. Also we make use of 
> the uatraps / nixspam traplists, and our own generated blacklist generated 
> from spam being sent to the postmaster. We had some problems with 
> blacklisted entries in the past, but we worked around that. It goes further 
> then that, but I will spare you all the details.

pf(4) has some amazing features that come in handy for spam control. I
guess it forms a key component of any spam blocking architecture. And it
works in concert with the other OpenBSD niceties you point out like
populating the tables with blacklists and whitelists, greytrapping and
using the pf(4) anchor mechanism to automate stuff.

The probability and state tracking options in pf(4) are pretty
interesting too if used creatively.


> On the second line we run Postfix / ClamSMTP / Clamd / Spamassassin. We 
> removed Amavis because it was annoying to upgrade and we wanted to get rid 
> of it, as we had problems with it in the past. With SpamAssassin we use 
> sa-update and sa-learn to keep the rules up-to-date and make sure bayes 
> gets properly trained. So we are marking e-mail as spam and no longer block 
> it. Why? Simple ... we no longer want to block false positives. Again, 
> there is more to this, but I will spare you all the details.

But if you don't update virus signatures wouldn't that cause worms and
malware propagation?

I know I am digressing but I thought signature updation was critical to
malware control...

>
> Right now we have 2500 happy users. Their local helpdesks helped them with 
> getting an Outlook rule in place to automatically move tagged e-mails to a 
> spam folder. Just like their gmail, hotmail or Yahoo account does at home.

Wow, this is great. I am not surprised to hear this. ;)


> The environment we have is certainly not the easiest one, but we automated 
> many things, leaving us with practically no work on it. All the updating of 
> rulesets / blacklists / whitelists /whatever goes by itself. Downside of an 
> environment like this is that you will need quite some knowledge of all the 
> components and how they work together. But hey, I got it running at home as 
> well (a bit simpler though) and didn't had a single spam mail in my mailbox 
> the last 4 months. Sure, the ones I do get are getting tagged and moved to 
> my spam folder automatically, which I do with maildrop (though procmail 
> does the job nicely too). All in all it works like a charm.

Using the X-foobar headers I suppose?

> Well a long story, but maybe it is of use for someone else. As always, 
> YMMV.

Yes, very enlightening, many thanks.

-Girish