Slashdot Mirror

← Back to Stories (view on slashdot.org)

How To Fight Spam Using Your Postfix Configuration

Posted by ryuzaki0 on 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.

42 of 158 comments (clear)

  1. Why to Use this by neonprimetime · · Score: 2, Informative

    The HowtoForge guide is great for everything however if you have a very busy mail server running Spam Assasin on 1000s of message per minute is a CPU killer. The best answer is to stop the mail before it hits Spam Assasin with a range of RBL (Realtime Blacklists) and RHBL (Same but different), Greylistings and Helo Checks.

    1. Re:Why to Use this by DaveGuy · · Score: 3, Informative

      The system I setup for my company uses as little "spam-scanning" as possible:
      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.

  2. Yeah, but... by cp.tar · · Score: 3, Insightful

    ... aren't blacklists still a bit... tricky?

    --
    Ignore this signature. By order.
    1. Re:Yeah, but... by bogado · · Score: 2, Interesting

      The only problem is that the customer never knows that his email is being droped. He things that the receiver got the email and choosed to ignore it, simply because it never got returned. And you know what? He is right to think like that, if an email has not returned it should be assumed as delivered.

      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 people not receiving emails. I had a friend that almost could not get into an international congress because she did not got any replys from the congress email because it's university was in one of those black lists.

      I do not advise anyone to use black lists. There are many good ways to get rid of spam that do not have false positives, like gray listing. Check this out , this guy has a very good analisys of the problem and the solutions he used.

      --
      []'s Victor Bogado da Silva Lins

      ^[:wq

    2. Re:Yeah, but... by jrockway · · Score: 3, Interesting

      I'm having excellent luck with OpenBSD's spamd blacklisting and greylisting. Haven't lost any important mail, but my SPAM has been cut by about 98%. It's truly amazing.

      http://www.openbsd.org/spamd/

      --
      My other car is first.
    3. Re:Yeah, but... by jank1887 · · Score: 2, Informative
      did you even read the post you replied to? either way, a response:

      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.

    4. Re:Yeah, but... by CerebusUS · · Score: 2, Insightful

      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)

    5. Re:Yeah, but... by ePhil_One · · Score: 2, Interesting
      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."

      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 banned gets an email back explaining why and is logged, I pull daily reports with the IP's, RBL, Subject lines, etc from the logs (with a nice summarization header) so I can easily spot check their effectiveness. All client domains are whitelisted by default, most "leads" come in via webforms. Any list that blocks something I want gets scrutinized and removed, thans to the summaries I know RBL #4 is only blocking 150 spams a day anyway, so I can delete it (it might have caught more, but RBL #1 blocks 14k a day before #4 ever gets a shot at it). Another handy trick, use tighter controls on your lower priority servers, real mail almost never goes there, but spammers like to use them because they are less monitored, sometimes poorly configured, and less loaded.

      Worked wonders. But implying all RBL's have low false positive rates in irresponsible.

      --
      You are in a maze of twisted little posts, all alike.
    6. Re:Yeah, but... by Kazoo+the+Clown · · Score: 2, 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.

    7. Re:Yeah, but... by XNormal · · Score: 2, Interesting

      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.

      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 one other provider.

      The best place to put spam filtering is at the endpoint - that's where the most information is available to make the decision and the end user can intervene and provider feedback to the classifier (e.g. gmail). If I start filtering spam, in the hope of reducing the chances of being blacklisted, I will be doing a disservice for my users.

      --
      Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
  3. Useless by Anonymous Coward · · Score: 2, Insightful

    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.

  4. What the heck are you talking about? by Anonymous Coward · · Score: 2, Insightful

    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.

  5. Re:RBLs and not getting your mail by slapyslapslap · · Score: 2, Interesting

    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. Most start out thinking this way. Then they get so burried in spam that they start to think much differently. It CAN be done properly with minimal collateral dammage. A good way to do it is to always send a rejection back to the sender with a reason why. In the event that a real user is rejected, at least they know and can try again via another account, fax, or phone.

  6. bad idea... by Vellmont · · Score: 3, Informative

    If you do this, and you're an ISP (which you likely are if you're getting 1000s of spams a minute) you're very likely to block legit mail from ever getting to subscribers. Realtime Blacklists aren't reliable enough to use alone in blocking spam. You'd serve customers better by buying more/faster machines to handle the load.

    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.

    --
    AccountKiller
    1. Re:bad idea... by Vellmont · · Score: 2, 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.

      --
      AccountKiller
  7. Re:RBLs and not getting your mail by grasshoppa · · Score: 5, Informative

    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.

    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.

    --
    Mod me down with all of your hatred and your journey towards the dark side will be complete!
  8. Re:RBLs and not getting your mail by Philosinfinity · · Score: 4, Insightful
    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.
  9. Hard Filter by RBL -- A NoNo by Kirth · · Score: 4, Informative

    Don't filter by RBL. Use them to give scores to Spamassassin, but don't reject mail on basis that some host is in some RBL.

    * 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.

    --
    "The more prohibitions there are, The poorer the people will be" -- Lao Tse
    1. Re:Hard Filter by RBL -- A NoNo by repetty · · Score: 3, Insightful

      >> * 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

    2. Re:Hard Filter by RBL -- A NoNo by wayne · · Score: 3, Insightful
      * Spurious criterions for getting listed. Like "unsolicited bounces" or "sent mail to secret spamtrap"

      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.
    3. Re:Hard Filter by RBL -- A NoNo by iangoldby · · Score: 3, Insightful

      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.)

  10. I'll Do It One Better... by Beefslaya · · Score: 2, Interesting

    Here is a link setups to build servers with postfix, amavisd, SpamAssassin, ClamAV, Razor (you could also use these settings just for postfix to add better spam resistance).

    I not only am I the President, I'm a user.

    http://www.freespamfilter.org/

    Enjoy...I love it...

  11. A good RBL experience? by autocracy · · Score: 4, Informative

    I am aware there's definitely a fair number of over-zealous blacklists, but I've had an extremely good experience using cbl.abuseat.org as a blacklist source, and haven't encountered any false-positives while perusing my mail logs.

    --
    SIG: HUP
  12. Great guide, ... NOT by xming · · Score: 2, Informative

    There are more explaination on the postfix.org than this FA (fine article). Wisely using good RBL (for open proxies) and graylisting and some helo/header checks should reduce a lot of spam.

  13. Re:RBLs and not getting your mail by Ed+Avis · · Score: 3, Insightful
    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...
    --
    -- Ed Avis ed@membled.com
  14. Greylisting + a bit more by stabiesoft · · Score: 2, Interesting

    I use a combination of greylisting (10 mins for normal IP addresses and an hour for dynamically assigned IP addresses). 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. Works quite well with less than one spam per day. Given that yesterday had 466 spam's that got rejected, I'm pretty happy. I cannot recall anyone complaining they can't get in. Greylisting works really well because real mail servers try hard to deliver whereas spammers don't try that hard for delivery.

    1. Re:Greylisting + a bit more by Just+Some+Guy · · Score: 2, Insightful
      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 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.

      --
      Dewey, what part of this looks like authorities should be involved?
  15. sendmail tweaks by ltjohhed · · Score: 5, Informative

    A far more effective and less faulty way to filter out some spam can be done by using the new features added in sendmail 8.13.

    FEATURE(`great_pause',5000)
    That one is given in your .mc file.

    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.

    --
    All generalizations are false
    1. Re:sendmail tweaks by leighklotz · · Score: 2, Interesting

      It's FEATURE(`greet_pause',5000) not FEATURE(`great_pause',5000).
      The previously-referenced Acme page mentions it.

  16. Re:RBLs and not getting your mail by raddan · · Score: 3, Interesting

    We block somewhere around 200k spam emails a day. And we have a very similar setup sitting in front of our Exchange server. The kinds of things we can do with Postfix simply aren't possible with Exchange, and once we learned the ins and outs of Postfix, we found it to be easier to use than Exchange. For one, Postfix has real documentation. Not to mention that the main developer posts regularly on the mailing list. Ever talk to MS's corporate support people for Exchange? Exchange is so huge and complex no one person knows the entire program. Postfix is a model of simplicity by comparison.

  17. Monitor the results of your blacklists! by reed · · Score: 2, Interesting

    Warning, I used to use RBLs to reject mail, but occasionally all of yahoo or somethnig gets added to a blacklist, and so mail from yahoo would start bouncing (including yahoo groups -- they really ought to use a seperate network for yahoo groups as their free webmail!). So instead of rejecting mail, I started just inserting a warning header, X-Spam-Blacklists:, which is easy to do with Exim. (I assume also with Postfix). Then I could filter the message in Thunderbird into a "probably spam" folder. You could also set up SA to increase a messages score if it's in a blacklist, I think, but I've never tried it.

    So if you do set up RBL rejection, make sure you pay attention to what it's rejecting. Skim through the log file a few times in the week or two after doing it, otherwise you'll never no that it's being rejected.

  18. greylisting not all that useful. by nblender · · Score: 4, Insightful
    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.

    1. Re:greylisting not all that useful. by Just+Some+Guy · · Score: 3, Insightful
      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?

      --
      Dewey, what part of this looks like authorities should be involved?
  19. Some words of wisdom by bfree · · Score: 3, Informative

    Here is an insightful blog posting from Justin Mason about using RBL's (and bl.spamcop.net in particular which this HOW-TO mentions) for filtering spam. You could see a staggering amount of false positives unless any rbl is only one part of a scoring system which decides whether a mail should be rejected.

    --

    Never underestimate the dark side of the Source

  20. Re:RBLs and not getting your mail by shadowmas · · Score: 2, Insightful

    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.

  21. Re:RBLs and not getting your mail by just_another_sean · · Score: 3, Interesting

    As someone who uses Exchange I can say that setting spam filtering up is easy. You can use RBLs or not. You can set thresholds that let a lot in or block a lot with many false positives. If you're worried about losing business mail then you can configure it to be safe about that and never outright refuse or delete mail.

    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 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.

    --
    Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
  22. greylisting will always be useful by wayne · · Score: 2, 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.

    --
    SPF support for most open source mail servers can be found at libspf2.
  23. Filtering against dictionary spam by knarfling · · Score: 2, Informative

    At my last company, we had a big problem with spam. But because the company did some online marketing, there were people in our marketing department that WANTED to get some of the spam so they could see what tactics the competition was using. At one point our mail gateways were so clogged, mail was being delayed by up to 4 or 5 hours at our gateway.

    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.

    --
    Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
    1. Re:Filtering against dictionary spam by DrGalaxy · · Score: 2, Informative

      Agree with parent.

      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.

  24. Shame the article is about Postfix. by AltGrendel · · Score: 2, Insightful

    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.

    --
    The simple truth is that interstellar distances will not fit into the human imagination

    - Douglas Adams

  25. There are better guides on the Postfix site. by ThatDamnMurphyGuy · · Score: 4, Informative

    The better place to looks is the Howtos and FAQs.

    One of my favorites: http://jimsun.linxnet.com/misc/postfix-anti-UCE.tx t

  26. Re:RBLs and not getting your mail by MadMidnightBomber · · Score: 2, Informative
    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.

    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.

    --
    "It doesn't cost enough, and it makes too much sense."