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.

Why to Use this

[neonprimetime]

The HowtoForge guide is great for everything however if you have a very busy mail server running Spam Assasin on 1000s of message per minute is a CPU killer. The best answer is to stop the mail before it hits Spam Assasin with a range of RBL (Realtime Blacklists) and RHBL (Same but different), Greylistings and Helo Checks.

bad idea...

[Vellmont]

If you do this, and you're an ISP (which you likely are if you're getting 1000s of spams a minute) you're very likely to block legit mail from ever getting to subscribers. Realtime Blacklists aren't reliable enough to use alone in blocking spam. You'd serve customers better by buying more/faster machines to handle the load.

If you DO decide to do this, be VERY carefull about the RBLs you use. Some RBLs list entire blocks of IP addresses of ISPs that have hosted spammers, and some even list every DSL/Cable modem static IP address. I've had me mail blocked by overzealous ISPs before (for just being on a cable modem static IP), so I'm not a big fan of using RBLs or other simple techniques to block spam at the postfix/sendmail level.

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.

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.

Great guide, ... NOT

[xming]

There are more explaination on the postfix.org than this FA (fine article). Wisely using good RBL (for open proxies) and graylisting and some helo/header checks should reduce a lot of spam.

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.
   

Some words of wisdom

[bfree]

Here is an insightful blog posting from Justin Mason [taint.org] about using RBL's (and bl.spamcop.net in particular which this HOW-TO mentions) for filtering spam. You could see a staggering amount of false positives unless any rbl is only one part of a scoring system which decides whether a mail should be rejected.

Filtering against dictionary spam

[knarfling]

At my last company, we had a big problem with spam. But because the company did some online marketing, there were people in our marketing department that WANTED to get some of the spam so they could see what tactics the competition was using. At one point our mail gateways were so clogged, mail was being delayed by up to 4 or 5 hours at our gateway.

We fixed the problem by having postfix discard any mail that was not addressed to a legitimate email account. We ran a script that would pull all valid email addresses from exchange and told postfix to reject anything else. We set that script to run every hour to catch any changes to email addresses. Our emails that went through spamassassin dropped by almost 90%.

Our only trouble was that if we rejected with NDR, there were tens of thousands of Non-Delivery Reports being sent out, and if we rejected without an NDR, people who mispelled email names (sean@domain instead of shawn@domain) never got a report stating that their email did not go through.

Overall, it was a huge success and we didn't have to mess with greylistings or blacklists.

Re:Yeah, but...

[jank1887]

did you even read the post you replied to? either way, a response:

1)The only problem is that the customer never knows that his email is being droped
Very true, and a sign that the mailserver is making poor use of blacklists. A rejection notice should always be sent. Proper use of blacklists will, as I mentioned above, either allow the message through, but tag it, or notify the sender that it was rejected, providing alternate means of contact or correction.

2)The problem with those black lists is that is quite easy to get in one of those and is near impossible to get out
Quite easy to get in: if your mailserver is sending out lots of spam, yes it is, and it should be. It is the sign of a mailserver that is misconfigured, insecure, or just has bad policies.
Near impossible to get out: It seems you have moved to describing BL's, not RBL's. A Realtime BlockList is supposed to list a mailserver upon significant spam amounts coming from it, and then de-list after the problem has been corrected. Correction doesn't equal "Hey, we have ligit mail over here, let us through please!!!" It means ending the flood of spam from the server. the onus is on the server operator to be a good net-citizen. otherwise, our servers don't want to talk to his servers. Some blocklists are overagressive, and have poor de-listing practices. It's the implementing admin's job to understand the lists he implements and the potential impacts of those lists.
As I mentioned above, alternate forms of contact and customer whitelisting capability are crucial if you are actually blocking mail. RBL's are very effective when used conscientiously. Combined with grey listing, they can cut your 'processed' spam (i.e., what you pay to handle) down to almost nothing.

There are better guides on the Postfix site.

[ThatDamnMurphyGuy]

The better place to looks is the Howtos and FAQs [postfix.org].

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

Re:Filtering against dictionary spam

[DrGalaxy]

Agree with parent.

I call this technique "early recipient rejection". As soon as the SMTP client sends "RCPT TO:" our postfix systems check a database list of valid recipients and drop the message immediately if it is not valid.

To set up early recipient rejection with postfix, read the docs about "check_recipient_access" and apply that directive to your "smtpd_recipient_restrictions" section in main.cf.

Re:RBLs and not getting your mail

[MadMidnightBomber]

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.

Exactly. It is not viable to deliver all email to user's inboxes at this stage. When I orked at the local Uni we were dropping ~60% of mail using SBL+XBL, and dropping anything from machines which HELO'd as us (this was impossible because the MX's only got external email).

This left a sane amount of email for MailMarshal to do content-filtering on - removing another ~50% of what was left.

Re:Why to Use this

[DaveGuy]

The system I setup for my company uses as little "spam-scanning" as possible:
1) greet-pause (reject mode)
2) IP-blacklist (reject known bad sending IPs)
3) SPF (reject if indicated)
4) TLS (temp-fail if indicated)
5) greylist (temp-fail mode)
6) rcpt (reject user unknown)
7) max-rcpts-per-envelope (temp-fail overage)
8) max-connect-per-interval (temp-fail overage)
9) IP-whitelist (known good sending IPs skip directly to virus filter)
10) Domain-Spoofers (quarantine - sender can't trip this unless coming from wrong IP)
11) Spam Classifier (quarantine if score is too high)
12) Custom Content Filters (quarantine on hit)
13) Virus Filter (delete on hit)

Log analysis on a regular basis reveals IPs to white list and to black list. We validate these candidates against WhoIs, and other tools (Senderbase is good) before committing them to an actual list. We consolidate lists to network segments whenever possible.

The end results are: no false positives, no viruses, rare false negatives, small quarantine volume, no outbound bounces from us, very few content filters, and a volume block rate of over 95% of about 7 million emails per day. False positive mitigation is extremely simple (and recoverable). False negative mitigation is likewise extremely simple.