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.
-- Ed Avis ed@membled.com
>> * 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.
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
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.
Neither sending bounces to forged email addresses (backscatter) 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.
SPF support for most open source mail servers can be found at libspf2.
I agree that ISPs should to some extent be held accountable, but to hold them 100% accountable ignores the fact that it is virtually impossible to pre-emptively stop all forms of email abuse.
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.)