How To Fight Spam Using Your Postfix Configuration

hausmasta writes, "In this guide you will learn how to tweak your virtual Postfix setup to better combat spam by stopping the mail before it hits SpamAssasin, using RBL (Realtime Blacklists) and RHBL (slightly different), greylistings, and Helo Checks." A clear, step-by-step guide to a complex subject.

Comments

Re:RBLs and not getting your mail

[grasshoppa]

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.

New to the business? You don't block anything in this situation; You mark it with a header ( that's part of the email message that you would likely never see. Most mailers won't display them unless you ask it specifically to do so ), and leave the blocking/filtering up to the end user.

For my uses, I have spamassassin running with a couple RBLs ( both in house and external ). I don't delete any mail; It is instead redirected to a specific folder when it's identified as spam. Over the past 6 months spam has made it into my inbox twice, and i've had no false positives.

If you know what you are doing, this is the ideal solution.

RBLs are notorious (especially SpamAssassin) for blacklisting entire domains when only a small subset of those users are actually sending spam.

Uh, no they aren't. Spamassassin isn't an RBL.

There are a few RBLs that are notorious for their blocking behavior, and as such, few use them.

If you're running your own mail server at home, then a whitelist would probably be more useful than a blacklist since you already know who you want to contact you.

I'd agree with this; Automated whitelists are the way to go.

But you gotta hand it to the Unix folks for making the task of setting up a spam filter this difficult.

It's only difficult when you don't understand the process.


I am curious how difficult it would be to set up a spam filter on an Exchange server.

Curiously enough, most of the time I hear people recommending placing a spamassassin enabled email server in front of an exchange server if you want decent spam protection.

Overall, I'd give your post a 9/10 on the troll scale. It wasn't bad, had factual data twisted in such a way as to be completely false. I even bit, not to argue with you but to make sure innocents don't read your post and get confused.

Re:RBLs and not getting your mail

[Philosinfinity]

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.

The firm that I work for gets something like 160,000 emails from external sources a day. Roughly 10% of these are legitimate. How prudent is it to force users to sift through 90% crap in order to get to the legitimate 10%. Currently, we use Postini as our primary MX host. They forward legitimate messages directly to our Exchange server, filter out 100% guaranteed spam, and drop the remainder into a quarantine that we check every few hours. Basically, all I am getting at is that spam filtering is necessary for enterprise environments and that there are actually some good tools to acheive it.

Hard Filter by RBL -- A NoNo

[Kirth]

Don't filter by RBL. Use them to give scores to Spamassassin, but don't reject mail on basis that some host is in some RBL.

* There are RBLs nearly impossible to get out from, and you might actually get an IP assigned months earlier to somebody who never requested a removal.
* False positives. Mails misidentified as spam (typically: newsletters which the signed up person no longer wants, vacation-mails in foreign languages) might bring you onto an RBL.
* Collateral damage. A shared server with 1000 users and 2000 domains might turn up in an RBL because one of those users had an inscecure formmail running a night long. And even after removal by the sysadmins in the morning, 1499 users can't mail you the next 18 hours.
* Spurious criterions for getting listed. Like "unsolicited bounces" or "sent mail to secret spamtrap"

So while RBLs are really a useful tools for deciding whether a mail might be spam, using them as THE ONLY reference on whether something is spam or not is just foolish.

A good RBL experience?

[autocracy]

I am aware there's definitely a fair number of over-zealous blacklists, but I've had an extremely good experience using cbl.abuseat.org as a blacklist source, and haven't encountered any false-positives while perusing my mail logs.

sendmail tweaks

[ltjohhed]

A far more effective and less faulty way to filter out some spam can be done by using the new features added in sendmail 8.13.

FEATURE(`great_pause',5000)
That one is given in your .mc file.

Wait's 5000ms to say HELO (EHLO) and all MTA's starting to send data (spambots not being all that RFC-aware) before that is discarded.

I've measured that it atleast cuts 15-20% of the total amount of spam.

greylisting not all that useful.

[nblender]

To all you greylisters, I don't know what part of the interweb you're from but when I survey my spam, I find that great tracts of it come from zombies via their ISP's mail server which means greylisting is no longer effective. It was effective last year but I think you folks missed the boat. I moderate a mailing list for a popular open source operating system project that uses greylisting and I still get about 100 spam per day as owner-listname...

Spammers are having their zombies dig through the windows configurations to find the owners email relay and using that to send their spam. It's not that difficult and combats greylisting.

There are better guides on the Postfix site.

[ThatDamnMurphyGuy]

The better place to looks is the Howtos and FAQs.

One of my favorites: http://jimsun.linxnet.com/misc/postfix-anti-UCE.tx t