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.
Yeah, but... (Score:4, Insightful)
RBLs and not getting your mail (Score:1, Insightful)
RBLs are notorious (especially SpamAssassin) for blacklisting entire domains when only a small subset of those users are actually sending spam.
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.
But you gotta hand it to the Unix folks for making the task of setting up a spam filter this difficult. I am curious how difficult it would be to set up a spam filter on an Exchange server.
useless article (Score:1, Insightful)
a single page article that tells you how to filter internal domain mail from external ?
there is nothing on this page about how to use RBL (which is a lame way of filtering as it is) or whitelists or anything else, did the submitter actually what this article covers ?
useless, now wheres my point and click interface ?
Useless (Score:2, Insightful)
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 the server, DO NOT BOUNCE EMAIL BACK TO SENDERS if you're not rejecting at connect time. If someone used my email address to send spam (not to be confused with my server), I don't want to receive the bounces for it.
Re:RBLs and not getting your mail (Score:5, Insightful)
Re:RBLs and not getting your mail (Score:4, Insightful)
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
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.
Re:RBLs and not getting your mail (Score:3, Insightful)
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, and that's a plus but, as you mention, making sure the email gets retried isn't that hard.
Greylisting is not a Final and Ultimate Solution to the Spam Problem, but it will always be a useful tool.
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.
Shame the article is about Postfix. (Score:3, Insightful)
Re:Greylisting + a bit more (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: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?
Re:bad idea... (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. But there's very good reasons to not use your ISPs mailserver.
Re:Hard Filter by RBL -- A NoNo (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 addresses. He can then send just three emails, the contents of which need not be 'spammy' in the least. The ISP's server will then be blacklisted for at least 48 hours, but usually much longer. An ISP has absolutely no defence against this kind of thing.
You could easily think of other examples where the ISP has no possible way to recognise that malicious email is being sent until after it has gone out of the door.
But the real issue is that the people who suffer are the other customers. They are completely disempowered, because they will just be ignored if they contact the RBL operator (since they are not the administrator of the blacklisted server). They could in principle find another ISP, but that is usually an unacceptable solution due to the disruption involved. If they don't have their own domain, they lose their email address, which means they will continue to lose emails. They can't win.
ISPs should be fighting against spam, but not with RBLs. The only time it is justified to use an RBL as a single criterion for rejecting email is when the administrator of the filter is also the only consumer of the filtered email. (Or perhaps if you have the explicit approval of all consumers that missing some non-spam emails is acceptable.)
Re:Yeah, but... (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 detection)