How To Fight Spam Using Your Postfix Configuration 158
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 (Score:3, Informative)
bad idea... (Score:4, Informative)
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 (Score:5, Informative)
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 (Score:5, Informative)
* 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? (Score:5, Informative)
Great guide, ... NOT (Score:2, Informative)
sendmail tweaks (Score:5, Informative)
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.
Some words of wisdom (Score:4, Informative)
Filtering against dictionary spam (Score:2, Informative)
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... (Score:3, Informative)
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. (Score:5, Informative)
One of my favorites: http://jimsun.linxnet.com/misc/postfix-anti-UCE.t
Re:Filtering against dictionary spam (Score:2, Informative)
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 (Score:2, Informative)
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 (Score:3, Informative)
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.