Forgot your password?
typodupeerror

How To Fight Spam Using Your Postfix Configuration 158

Posted by kdawson
from the not-welcome-here dept.
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.
This discussion has been archived. No new comments can be posted.

How To Fight Spam Using Your Postfix Configuration

Comments Filter:
  • Yeah, but... (Score:4, Insightful)

    by cp.tar (871488) <cp.tar.bz2@gmail.com> on Thursday September 07, 2006 @10:12AM (#16058988) Journal
    ... aren't blacklists still a bit... tricky?
  • by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Thursday September 07, 2006 @10:12AM (#16058995)
    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.

    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)

    by Anonymous Coward on Thursday September 07, 2006 @10:13AM (#16058999)

    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)

    by Anonymous Coward on Thursday September 07, 2006 @10:16AM (#16059011)
    The layout of the linked site is awful and sticking configuration snippets in text areas is awful. I didn't even see any warnings and if you're doing this, there are plenty of things that could go wrong. IMHO, setting up an MTA to reject spam at SMTP time is an involved process that requires the admin know what they are doing, blindly following a poorly written howto is a recipe for disaster.

  • by Anonymous Coward on Thursday September 07, 2006 @10:17AM (#16059017)
    You clearly have no understanding of how SpamAssassin works. Blacklists are only one of many negative as well as positive factors that SpamAssassin takes into account when evaluating whether a message is spam or not. You can adjust the score threshold to a level you're personally comfortable with.

    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.
  • by Philosinfinity (726949) on Thursday September 07, 2006 @10:23AM (#16059067)
    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.
    The firm that I work for gets something like 160,000 emails from external sources a day. Roughly 10% of these are legitimate. How prudent is it to force users to sift through 90% crap in order to get to the legitimate 10%. Currently, we use Postini as our primary MX host. They forward legitimate messages directly to our Exchange server, filter out 100% guaranteed spam, and drop the remainder into a quarantine that we check every few hours. Basically, all I am getting at is that spam filtering is necessary for enterprise environments and that there are actually some good tools to acheive it.
  • by Ed Avis (5917) <ed@membled.com> on Thursday September 07, 2006 @10:36AM (#16059140) Homepage
    A good way to do it is to always send a rejection back to the sender with a reason why.
    Um, and the 'sender' is who exactly? Please don't tell me you're using the From: address...
  • by repetty (260322) on Thursday September 07, 2006 @10:37AM (#16059147) Homepage
    >> * 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
  • by nblender (741424) on Thursday September 07, 2006 @10:55AM (#16059301)
    To all you greylisters, I don't know what part of the interweb you're from but when I survey my spam, I find that great tracts of it come from zombies via their ISP's mail server which means greylisting is no longer effective. It was effective last year but I think you folks missed the boat. I moderate a mailing list for a popular open source operating system project that uses greylisting and I still get about 100 spam per day as owner-listname...

    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.

  • by shadowmas (697397) on Thursday September 07, 2006 @11:12AM (#16059427)
    You might not care if the spammer doesnt get your rejected message. i dont either, but i certainly do care if you're 'rejected' messages end up in my inbox just because some spammer used my email address as his 'From' address. do everyone a favour either reject any spam at the time you recieve it (via a smtp error code) or dont reject it at all. It would be almost the same as havng a open smtp server since spammers can use your server to send spam as backscatter.
  • by wayne (1579) <wayne@schlitt.net> on Thursday September 07, 2006 @11:40AM (#16059649) Homepage Journal

    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.

  • by wayne (1579) <wayne@schlitt.net> on Thursday September 07, 2006 @11:51AM (#16059734) Homepage Journal
    * Spurious criterions for getting listed. Like "unsolicited bounces" or "sent mail to secret spamtrap"

    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.

  • by AltGrendel (175092) <ag-slashdot @ e x i t 0.us> on Thursday September 07, 2006 @12:14PM (#16059949) Homepage
    Ok, I recognize that you are probably trying to promote Sendmail. But for a variety of reasons, there are folks out there that can't or don't want to use Sendmail. I don't use Sendmail because I consider it overly complex. I use postfix and yes, I use the RBLs before it gets to SpamAssassin (gasp). If you tune it properly, it works just fine, thank you. Also the email list archives are extremely helpful in this matter, as is the list itself if you've done your homework first.
  • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Thursday September 07, 2006 @12:14PM (#16059951) Homepage Journal
    I also do a very quick check on a few sender domains such as yahoo.com A "from" yahoo.com must be from a machine with .yahoo.com. If not, it is rejected.

    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.

  • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Thursday September 07, 2006 @12:18PM (#16059992) Homepage Journal
    Spammers are having their zombies dig through the windows configurations to find the owners email relay and using that to send their spam.

    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)

    by Vellmont (569020) on Thursday September 07, 2006 @12:25PM (#16060049)

    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.
  • by iangoldby (552781) on Thursday September 07, 2006 @01:36PM (#16060648) Homepage
    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.)
  • Re:Yeah, but... (Score:3, Insightful)

    by CerebusUS (21051) on Thursday September 07, 2006 @01:47PM (#16060728)
    I'd agree with you _if_ the only reason a server ever got put onto an RBL was due to relaying and misconfiguration. The trouble is that some addresses are inevitably put on the list due to a disagreement about terms of service or what constitutes "spam."

    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)

"And do you think (fop that I am) that I could be the Scarlet Pumpernickel?" -- Looney Tunes, The Scarlet Pumpernickel (1950, Chuck Jones)

Working...