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)
Re: (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
Yeah, but... (Score:4, Insightful)
Re: (Score:2)
RBL's are rather reliable, having few false positives from a server listing point of view. That said, you will have collateral damage from other users of shared spamming mailservers. There's no way around that, and less-than-clueful business customers will get upset about non-delivery of email. Most issues can be avoided by making customers fully aware of your mailhandling policies, and offer easy whitelisting,
Re: (Score:3, Interesting)
The problem with those black lists is that is quite easy to get in one of those and is near impossible to get out. The number of false positives that those RBL produce is huge, and this means a huge number of p
Re: (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
Re: (Score:3, Insightful)
As the network admin for a consulting company, I'll never use an RBL on our mail because any lost communication from a customer or potential customer costs us more than potentially allowing some spam through (or buying larger hardware to handle better spam
Re: (Score:3, Interesting)
The RBL's all have different policies. Some are very explicit & limited, some are personal toys (I recall one that blocked all of MCI/UUnet). I start with the most restrictive, falling through about 4-5 total whose policies seem reasonable. Anything ba
Re: (Score:3, Interesting)
My server is sending out lots of spam but it is not misconfigured or insecure and I don't believe my policies are bad.
I have set up forwarding addresses for some people and some of them are receiving lots of spam. This means that my server is sending out lots of spam and I think it has already been blacklisted by at least
Re: (Score:2)
If that's the case, there's a mail admin in the equation somewhere that needs to be fired. What you're describing has exactly nothing to do with RBLs, and everything to do with the server configuration.
My mail server is running sendmail with 4 DNSBLs, plus a locally-run internal. If a mail message hits those lists, it's rej
Mod Parent Up, Please. 5xx Reject is exactly right (Score:2)
As long as the receiving mail server rejects the message with a permanent failure notice, a correctly configured sending mail server will give the user an appropriate response, and if it rejects it with a temporary failure notice, a correctly configured sending server will keep trying, and eventually let the user know if delivery hasn't happened in some time period.
If the receiving mail server accepts the message,
Re: (Score:3, Interesting)
Oh, we don't care if our email is unreliable, we're BLOCKING SPAM. RBLs are largely counter productive in that regard-- avoid them.
Email reliability essentially *means* that some spam will get through. GET USED TO IT. Do not trade reliability away to be spam free. False positives are unacceptable, PERIOD. If a filtering system is subject to false positives, it's worse than the problem it is trying to solve.
Those who would sacrifice a little email reliability for spam security deserve neither.
Re:Yeah, but... (Score:4, Interesting)
http://www.openbsd.org/spamd/ [openbsd.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sure, if by "everyone," you mean "a small minority."
But I'm always willing to share insight with the sightless masses.
Actually, I'm doing you a favor. Just like someone would be doing the President a favor if they mentioned to him that he was pronouncing "nucular" incorrectly.
Re: (Score:2)
SPAM stands for SPiced hAM.
Re: (Score:2)
Re: (Score:2)
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state
Useless (Score:2, Insightful)
postgrey (Score:2)
Re: (Score:2)
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: (Score:2)
Because when I hook my laptop up to the net away from home using wifi or gprs, it can't get to my ISP's smarthost. So instead I have a publicly accessible server with authetication and SSL set up that I can use from anywhere. This is way better than the last 8 years where I've had to manually change the outgoing server.
I've had to stop this approach because of some RBL lists blocking my
Re: (Score:2)
The question remains - why aren't you using your ISP's smarthost.
There's no reason you can't run an SMTP server at the end of your cable modem - it, however should still pass it's traffic
Re: (Score:3, Insightful)
it, however should still pass it's traffic directly to your ISP's smarthost for onward delivery.
And why would I want to have to rely on my ISPs mailserver to be up to send outgoing mail? I like reliability, I don't like outages. I also don't want to rely on them to route my mail properly, decide I'm a spammer and block me, or whatever. Also, why would I want to make it easier for my ISP to snoop on my mail? (who knows if they'll send targeted advertising, etc).
If you don't mind all those things, fine.
Re: (Score:2)
Then you're probably violating your T
Re: (Score:2)
Mail should NOT be coming from end-user dynamic IPs directly. Period. No excuses.
Blah blah blah.. Frankly I don't care about your opinion. It matters to me about as much as what ice cream you prefer. There's no law that says I can't run my own SMTP server on my own internet connection. As far as your universal terms of service, they aren't so universal. Most ISPs prohibit spamming, but there's plenty that have no problem with running a SMTP server on your ip address. If my ISP starts whining about it,
Re: (Score:2)
I bet if you checked the ToS, it does prohibit servers.
Unfortunately very few ISPs (not even the one I admin) block outgoing smtp from anything but known servers. That's the best way to go. If your ISP is fine w
Re: (Score:2)
Gee.. how did I possibly guess that? You're the hard-ass sysadmin that needs to control everything, and you get all uppity when you can't. Being a sysadmin is about managing risk, not control.
Me running my own SMTP server has exactly zero impact on spam. I don't run an open
Re: (Score:2)
1) He mentioned a static setup. 2) His ToS with his ISP is of no relevance or importance to you, nor should it be to the decision to accept mail. 3) You're an optimist. I have watched many people try to have static IP addresses delisted from many RBLs with no success whatsoever (and not due to spam coming from them, but because the RBL administrators said "stati
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.
Re:Hard Filter by RBL -- A NoNo (Score:4, Insightful)
>> 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.
Good point. On the other hand, I don't fucking care. I don't hear anyone knocking on my door, offering to help me filter out my spam. RBL's work GREAT on a tough problem, which is why they haven't gone away.
And the collateral damage? If a user/subscriber abuses a service then the service provider SHOULD be held accountable and those other 1499 users are better off elsewhere.
--Richard
Re: (Score:3, Insightful)
For example, SORBS have a policy that they will blacklist a server if they receive three or more emails to their spam trap addresses. These addresses are kept secret, so the ISP can't know what these spam trap addresses are. Suppose a malicious client of the ISP discovers (or guesses) one or more of these spam trap addr
Re: (Score:2)
And the collateral damage? If a user/subscriber abuses a service then the service provider SHOULD be held accountable and those other 1499 users are better off elsewhere.
Imagine you're a colo provider. One or your users gets hacked and starts spamming like mad. Your alert admins (perhaps you) cut them off within an hour. Obviously, you deserve to watch your business go down in flames for stupidly failing to hire a psychic to stop the spam before it started. And your 1499 other customers are equally dese
Re: (Score:2)
The real RBLs don't list based on single incidents, but patterns of abuse. Comcast, for example, is one of the worst in this regard. At one point (I don't know if this is still the case), they actually claimed connecting a firewall/router between the cable modem and PC was a violation of thier TOS.
Re:Hard Filter by RBL -- A NoNo (Score:4, Insightful)
Neither sending bounces to forged email addresses (backscatter [wikipedia.org]) nor sending email to spam traps is a "spurious criteria" for getting listed. If you are doing either of these, you are part of the spam problem and you deserver to have your email blocked.
Configure your mail server to reject *during* the SMTP session, or only send bounces after the fact if the email passes something like SPF. Using SPF's "best guess" default record of "v=spf1 a mx ptr" when there isn't an SPF record may by safe, but you are still risking sending backscatter to innocent people. Domainkeys and DKIM validate the From: header, which isn't where you should send bounces to, so it can only be used when the Envelope-From and the From: header match. Really, the easiest thing to do is just to always reject during the SMTP session and not accept-then-bounce.
Re: (Score:2)
And sans SPF, manual intervention, how does one programatically tell that a from address is forged so as to not send a reject?
Clue: fixing the spam problem should not involve neutering legitimate functionality of the mail server - it's a bandaid.
Re: (Score:2)
Generating the bounce is the responsibility of the sending server, since it's not relying on easily-faked headers to pick its target.
Re: (Score:2)
Re: (Score:2)
From the other side:
Consider it in terms of overhead.
DNSBL:
Connection opens
Rec. Server sends banner
Sending Server HELOs/EHLOs
Rec. server responds
Sending server begins MAIL transaction
Rec. Server queries DNSBLs for sending IP.
Rec Server sends 550 (permanent failure) error.
Rec. Server ends connection, leaving Sending mail server to deal with the 550 error.
Spamassassin using DNSRBL checks:
Connection opens
Rec. Server sends banner
Sending
I'll Do It One Better... (Score:2, Interesting)
I not only am I the President, I'm a user.
http://www.freespamfilter.org/ [freespamfilter.org]
Enjoy...I love it...
A good RBL experience? (Score:5, Informative)
RBL-based rejection can be a BAD thing (Score:2)
Rejecting mail outright based on RBL results is an invitation for loads of false positives. If you're getting "1000s of messages per minute," chances are you are a large business or an ISP. Either way, your customers sending mail from foobaz.net (for example) won't be happy when their no longer gets through because some boneheads at spamcop or spamhaus put them on the RBL.
If you don't have the proper setup to accept that many messages and do adequate "tag-and-forward" spam analysis, or at least reject la
Re: (Score:2)
Great guide, ... NOT (Score:2, Informative)
Greylisting + a bit more (Score:2, Interesting)
Re: (Score:3, Insightful)
If by that you mean that you're using SPF [openspf.org] or similar, that's a great idea. If it means that you wrote your own code that does something like "if fromdomain != helodomain: reject()", then your system is pathologically broken and needs to be updated.
Re: (Score:2)
Exactly. My dedicated server runs mail, too, and has a A record of hostx.isp.com. Though it handles mail for a dozen domains, all with SPF (and Sender ID) records, the number of bounces / drops I get from people who do this is scarily high.
Re: (Score:2)
To the contrary, it looks like we're interpreting you quite well.
Your system is broken - full stop. There are many, many reasons for an email to come from a s
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.
Shame the article is about Postfix. (Score:3, Insightful)
Re: (Score:2)
Please don't get the impression that I'm trying to evangelize you... but Sendmail used to be overly complex. More recent versions are actually pretty good from the configuration perspective, especially if you're using a binary distribution such as a slackpackage or deb package. It's really just a question of changing your sendmail.mc file, and compiling it. Copy to the right location, and restart Sendmail. Poof. It's done.
Enabling a RBL or RHBL in Se
Re: (Score:3, Interesting)
The previously-referenced Acme [acme.com] page mentions it.
Re: (Score:2)
There are many legitimate applications that will die if you do this. To recommend this as a general solution is a mistake. Sure, we would all love it if the legitimate apps worked properly, but that isn't the real world. The real w
Monitor the results of your blacklists! (Score:2, Interesting)
greylisting not all that useful. (Score:5, Insightful)
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.
greylisting will always be useful (Score:3, Insightful)
Greylisting will always be useful, at least to a certain degree. When you get email from an unrecognized source, one that you can't judge as being a source of legitimate email or if it is a spam source, greylisting lets the reputation systems like DNSBLs and DCC/Razor/etc. catch up. Also, good ISPs and mail admins have tools to watch for likely spam runs. Again, greylisting gives those tools time to act and purge the spam.
Sure, greylisting also gets rid of spam from spambots that don't retry email, an
Re:greylisting not all that useful. (Score:4, Insightful)
In other words, greylisting makes zombies relay spam through their ISP, forcing said ISPs to deal with the problem to keep their mailserver from being both overwhelmed and added to every DNS RBL in existence. In what possible way is this not a Good Thing?
Why I love slashdot (Score:2)
Rating: +5 "insightful"
Reply to above comment: "X works because Y happens"
Rating: +5 "insightful"
And neither post showed any actual insight; just observation.
Re: (Score:2)
Some words of wisdom (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Using the default scores?
I've got the scores tweaked somewhat, and we tag at 5 and reject at 15. RBLs (including ones we wouldn't reject on outright), URIBLs, Razor checks etc are all good for five points each. No PTR gets 10 (although that one's hacked together in our mimedefang filter). Try skewing the scores somewhat for tests that look super-spammy, and reject
More of this kind of thing (Score:2, Offtopic)
Although we've got our share of trolls and fanboys ruining it for the rest of us, I daresay that there are at least a few slashdotters out there who could write guides at least as good as this on a number of geeky and related subjects and present them on the front page, in much the same vein as the original content presented in book reviews etc. It might even be worth paying the a
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
Re: (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.
Another HOWTO that I'm biased toward (Score:2)
Re: (Score:2)
Re: (Score:2)
I can't claim to have invented it, but I've been advocating it to everyone who will listen. We're rejecting over 90% of incoming mail with greylisting (as measured by the number of entries in the greylist database that never returned for the second attempt). An unexpected side effect is that SpamAssassin now rejects less mail than before because all of the "low hanging fruit" has already been filtered out, and because it has less data to feed into its Bayesian trai
There are better guides on the Postfix site. (Score:5, Informative)
One of my favorites: http://jimsun.linxnet.com/misc/postfix-anti-UCE.t
Better way - bleed spammers dry (Score:2)
Personally I'd like to make the spammers pay - in CPU cycles - using methods like this. Of course I'd rather beat them witha
What the heck are you talking about? (Score:2, Insightful)
I have 3 tiers, ham (non-spam), possible spam (that gets moved into my junk folder), and true spam (really high scores) that gets rejected at the mail server. Also, for anyone else running anti-spam software at
Re: (Score:2)
How can I just block out IP addresses instead of domain names without using an external firewall?
Re: (Score:2, Interesting)
Re:RBLs and not getting your mail (Score:4, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Actually, spam will rather often have a valid address in the "From" field. Unfortunately, it rarely ever has any true association to the originating spammer, but is instead usually simply yet another address culled from their list of potential recipients. Sometimes that address will even be yours.
As such, this practice to which you adhere actually makes you part of
That's what SPF is for. (Score:2)
Don't confuse SPF with Microsoft's fake "sender-ID" crap, though. That's essentially useless, you want SPFv1 aka "SPF classic", then DKIM as soon as it's ready.
Worked for me...
Re: (Score:2)
Re: (Score:2)
That way, your mail server never sends bounces. If a server delivering mail to you starts sending backscatter bounces, it's their problem, and they
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.
Re: (Score:2)
for my work domain. I have two virtual slackware boxes running that do nothing but take mail clamav and spamassassin and then forward it to exchange.. we get about 1-2 messages a second per box and most of them are spam - exchange is a very nice work group server and the integration between outlook - mobile devices and OWA is quite nice - it has it's issues and security holes but I find that using linux spam filters and having exchange only
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Two reasons;
1) In my environment,if I don't acknowledge an email I get follow ups from the person until I do. I have never come across a situation where their email has been in the spam folder.
2) I glance at my spam folder on occation ( about once a week ). I look at the senders and the subjects. Takes me a minute ( usually less ).
If so, then what is
Re: (Score:2)
Most businesses do not do this. Most use a spam-filtering appliance that uses a very conservative blacklist (often run by the appliance provider in conjunction with a service contract), fingerprinting and some heuristics to as
Re:RBLs and not getting your mail (Score:5, Insightful)
Re: (Score:2, Informative)
Re: (Score:2)
> If you're running the mail servers for a business, how prudent is it
> to run a spam filter in the first place?
Many businesses feel that they have a responsibility to block a certain amount of spam, especially porn spam.
> RBLs are notorious (especially SpamAssassin) for blacklisting entire
> domains when only a small subset of those users are actually
> sending spam.
Um.... SpamAssassin != a RBL. It is a spam filter that uses multiple algorithms to try to identify spam. RBL's ar
Re: (Score:2)
The other thing is to blackhole email that the domain name in the From field (e.g. comcast.net) does not match the sending IP. This reduces spam (which invariably has a fake From address) by another 20 percent. Whatever gets past these is handled at the lo
Re: (Score:2)
I don't think this is very wise. What about hosted virtual domains? Maybe my email domain is mydomain.com but my mail server's PTR is mail.provider.com.
I have found that making sure PTR and A match cuts a lot of incoming spam from dynamic addresses.
Re: (Score:2)
For our U.S.-based business, we simply blacklist all email from IP addresses outside the U.S. and Canada. We do not do business with any foreign interests, so we receive no legitimate email from other countries. This cuts our spam load by about 70 percent.
Increasingly, businesses in the US and Canada will find it impossible to do this (depending one one's business). The economy and business is global and, as time goes forward most non-local industries will need to be able to communicate across national
Re:RBLs and not getting your mail (Score:4, Interesting)
Re:RBLs and not getting your mail (Score:4, Interesting)
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 [flakshack.com] 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.
Re: (Score:2)
99% means losing one legit email per 100, in all likelyhood it wasnt important,
I use ASSP, automatic whitelists are built as people send emails so email has become useable for my organization. They understand if an email is
Re: (Score:2)
Re: (Score:2)
Well, the sender should get a notification if a message was blocked by an RBL. Same can be done with SpamAssassin+Amavisd. Send a bounceback for low scored spam and drop