Slashdot Mirror
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.
... aren't blacklists still a bit... tricky?
Ignore this signature. By order.
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.
AccountKiller
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
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.
"The more prohibitions there are, The poorer the people will be" -- Lao Tse
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.
SIG: HUP
-- Ed Avis ed@membled.com
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.
.mc file.
FEATURE(`great_pause',5000)
That one is given in your
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.
All generalizations are false
We block somewhere around 200k spam emails a day. And we have a very similar setup sitting in front of our Exchange server. The kinds of things we can do with Postfix simply aren't possible with Exchange, and once we learned the ins and outs of Postfix, we found it to be easier to use than Exchange. For one, Postfix has real documentation. Not to mention that the main developer posts regularly on the mailing list. Ever talk to MS's corporate support people for Exchange? Exchange is so huge and complex no one person knows the entire program. Postfix is a model of simplicity by comparison.
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.
Here is an insightful blog posting from Justin Mason 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.
Never underestimate the dark side of the Source
As someone who uses Exchange I can say that setting spam filtering up is easy. You can use RBLs or not. You can set thresholds that let a lot in or block a lot with many false positives. If you're worried about losing business mail then you can configure it to be safe about that and never outright refuse or delete mail.
But I don't like it because once you check the boxes, set the sliders and press OK, that's it. Unless you then get into scripting or third party products or any other solutions I can't think of you don't get to customize it any further. In other words, at that point, if you want more, it's just like Unix. I've never worked with any but can't you buy Sendmail or OpenExchange and get a lot of the point and click stuff for free too? And for a lot less then the dragon's horde a small business spends on MS Exchange?
One last thing to mention, we feel the same way as you about losing a customer's mail. So our users don't get anywhere near the spam they used to but the IT Admin that works for me spends anywhere from an hour to two a day checking the spam filter to see what gets tagged. Whitelisting? So far we found a few half ass solutions in forums that for various reasons don't do exactly what we need.
All in all, like most Window's based solutions in my experience, Exchange is easy to set up, hard to customize. We're working on a OpenBSD solution as a front end in our spare time. Hopefully we can get it to get the worst of the spam and then set Exchange to be a lot more lax when it gets in... Anything that keeps us from checking the spam filter all day.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
The better place to looks is the Howtos and FAQs.
x t
One of my favorites: http://jimsun.linxnet.com/misc/postfix-anti-UCE.t
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.