OpenBSD Journal

Installing an OpenBSD mail filter gateway with smtp-vilter, Clam AV, and SpamAssassin

Contributed by grey on from the extensive write ups are great dept.

Thanks to Peter Matulis for bring our attention to his detailed article on fighting spam using OpenBSD and related tools:

In this article we will look at a way to mitigate the problem of email-borne viruses and Unsolicited Bulk Email (UCE) otherwise known as "spam". The OpenBSD server will act as what I will call a mail filter gateway or MFG. The purpose of such a machine is to protect a network that lies behind it from viruses and spam.

The anti-virus and anti-spam software that will be used will be the popular Clam AV and SpamAssassin programs respectively. They will communicate with the Sendmail MTA via the smtp-vilter milter. This milter comes equipped with its own internal email attachment filter.

Peter also has some other tutorials that may be worth checking out here.

(Comments are closed)

Comments

  1. By Anonymous Coward (200.175.1.1) on

    What would you (others) recommend? Spamd or Spamassassim?

    Comments

    1. By Brian (205.161.0.11) on

      Its not really a question of "or", as they have completely different functions.

      Spamd filters out connections to mail servers from known spammers and uses greylisting to filter out connections from spam software/viruses.

      Spamassassin uses many techniques to determine if a given message is spam after the message has been sent to the mail server.

    2. By marco (149.169.52.82) on http://www.public.asu.edu/~hondaman

      spamd(8) by a landslide

      even with sa (w/bayesian filtering), i was still getting 40-50 spams/day after filtering on SPAM: YES (SA would correctly tag 400-500)

      after turning on spamd(8), that number dropped to maybe 4 or 5 getting through to the MTA, which SA then tagged

      i'm upgrading my mailserver to 3.6 tonight, so i'll have a writeup on my homepage in case anyone is interested in chaining openbsd spamd, sendmail, clamav, and sa all together

    3. By Lennie (212.204.168.146) on

      the right answer to that question would be mailscanner. :-)

      http://mailscanner.info/

      That's what I prefer.

    4. By Petr Ruzicka (212.65.210.6) pruzicka@openbsd.cz on

      Both working in tandem.

    5. By Dom De Vitto (217.169.21.119) on

      I would recommend using BOTH, and reading some manual pages, because you don't understand what spamd does.

      In order:
      1. spamd will tarpit blacklisted hosts causing them pain, forever.
      2. Hosts not caught by spamd will be checked by spamassassin and the email content checked.
      3. Finally the content is passed to ClamAV to virusscan.

      Easy.

    6. By Denis Solaro (81.249.99.156) sorry... on

      Cause ok, many have pointed out the completely different nature of both (although both have a process called spamd) but normaly the fight is between Dspam (fast) and the CPU hog spamassassin is. My experience with spamd and greylisting in a small office setup was that big providers tend to send mail from different IPs, often not twice the same so big their volume is and so many sendmail queueing bozes they have. It's the hotmail/yahoo problem multiplied by a thousand fold if the site in question is a shipping firm getting email from tons of people with legit accounts all over Asia, Middle East, South America and Europe. I basicaly had to add most of the national ISPs of big size in a white list to prevent important mails from being delayed. I also had to ok any mails from China, Korea (they love ssh in Korea, most ssh login attempts came from there). But after one month of adding stuff I had it pretty well managed. In the end I've turned off spamd cause management was getting nervous because of one or two delayed mails from a custom officer a month. Email waise it's nothing, legaly I was in deep problems. See lotsa people thought Email is as guaranteed as a Telex. Mmmm... But I did learn a lot about spam and about Italian or Brazilian ISP ;-) In the end, for regular use I'd say spamd is the dog's bollocks, the bee's knees, it's f***ing ace! But beware of the sort of place you instal it in, make sure it's not an international import export firms.

  2. By Anonymous Coward (216.220.58.205) on

    Could someone point me to a good article about tuning a server that is configured as a mail filter?

    I attempted a similar setup a while ago on a OpenBSD 3.4 box, but I kept on running into resource exhaustion problems. The box periodically got hit by gobs of virus filled spam which would bring the server down. This would usually happen around 2 or 3 in the morning ... very annoying. I'd like to know how to *properly* tune an OpenBSD box, but haven't found anything that clearly explains what issues need to be addressed.

    Comments

    1. By Brian (205.161.1.46) on

      If you call spamassassin rather than spamc for each instance, large bursts of mail traffic will eat your box alive.

      It is very important to have procmail/smtp-vilter call spamc which will connect to spamd(1). This way, spamd(1) will queue the messages instead of trying to process them all at once.

      Old versions of spamd(1) didn't default to this behavior and required -m on startup.

      Comments

      1. By Anonymous Coward (216.220.58.219) on


        Actually, I wasn't filtering spam. I was just filtering out viruses using clamav w/ milter. The problem (if I can remember correctly) was that when the box got hit with spam, the milter would eat up all available resources trying to scan those messages. Part of the problem was that the kernal wasn't tuned properly (still had default maxprocs, etc). Even when setting that to (what I thought were) reasonable defaults I still had problems.

        Part of the problem for me is that I am not experienced with running production level boxes that do heavy duty email processing, etc. and I have not found any guides that explain how to properly tune these services. And when I ask it seems that I get replies such as "You idiot, didn't you do *BLA BLA BLA*?? Everyone knows that!!!". This, after hours on google trying to find a solution.

        I would just like to learn about this stuff so I don't have egg on my face when I try to replace a Windows NT Service running on a 5 year old machine with a OBSD solution and fail. I fully understand that it can take a bit more time to setup than that old MS solution, but it's really frustrating when the knowledge to do so is so inaccesable.

        Comments

        1. By tedu (64.173.147.27) on

          then setup clamav so that it doesn't start 900 processes at one time.

          Comments

          1. By Anonymous Coward (216.220.58.219) on


            Do ya think so? Oh Jebus, I would never have though of that on my own.

            Actually I did try that, but the setup still had problems. It would work perfectly for two weeks, and then crash. I abandoned it in favour of Postini's service, since it was far cheaper to implement than spending more time to get my box right. I'd still like to know how to make it work properly though.

            Comments

            1. By Brian (205.161.1.46) on

              From clamd.conf: # Maximal number of threads running at the same time. # Default: 10 # MaxThreads 15

              Comments

              1. By Brian (205.161.1.46) on

                Oops, thought plain text was the default.

                From clamd.conf:

                # Maximal number of threads running at the same time.
                # Default: 10
                # MaxThreads 15

    2. By Luiz Gustavo (200.164.214.127) on http://hades.uint8t.org


      That's not rocket science, what did you can expect of a daemon written in perl?
      Learn to proper tune your daemon behaviour before blaming the OS, since it just give the resource you have made available.
      Use pf as your first line of defense, taking out those Windows 95 and 98 source emails. Later let spamd(8) make things even worse for then and only after that pass emails to spamass. I bet the results will be a lot better.

      Comments

      1. By Anonymous Coward (216.220.58.219) on

        You're not being helpful.

        I do not see anything that I wrote in the previous post that could be taken as me "blaming" the OS for these problems. I clearly blamed it on my lack of knowledge on this subject and asked for help.

        Comments

        1. By tedu (64.173.147.27) on

          of course he was being helpful. he said to use pf and spamd to limit the damage at the door.

          Comments

          1. By Anonymous Coward (216.220.58.219) on


            If you read the original comment you would realize that he wasn't, and neither are you.

            Comments

            1. By tedu (64.173.147.27) on

              tuning is not always a synonym for "recompile your kernel with these l33t options". sometimes it means "use the right tools in the right combination".

              Comments

              1. By Anonymous Coward (216.220.58.219) on


                a) you still haven't read the original comment
                b) who said I wanted to recompile a kernel?

                What I'm really looking for is a sort of "best practices guide". I don't need any tips on what was wrong with my old setup (it was abandonned sometime ago).

                Really, this is turning out to be a waste of time if I am to be treated like some sort of Gentoo ricer.

                Comments

                1. By Luiz Gustavo (200.164.209.132) on http://hades.uint8t.org

                  I apologize if my post wasn't right to the spot, but tedu is right.

                  Most people lack the big picture of trying to have a pletora of system tools helping each other to avoid certain problems, once you get the idea things like a huge new worm or virus slamming your door could not make your server a dead brick.

      2. By Jammer5 (219.88.102.227) on

        Use pf as your first line of defense, taking out those Windows 95 and 98 source emails.

        Could you elaborate on this please ? Are you suggesting using the OS fingerprinting capabilities of pf to block connections to port 25 from Win95/98 machines ?
        Do you have an example ruleset (or would something like this work) ?
        block in on $ext_if proto tcp from any os "Windows 95" to any port 25

        Can I use wildcards in the OS field or should I create a list ?

        Comments

        1. By Luiz Gustavo (200.164.209.132) on http://hades.uint8t.org

          Yes, that's right. 3.6-current added another layer of possible defence.

          Also use spamd to make your main MTA avoid junk email as possible and your mail server will end up doing less useless work.

          Learn to tune your sendmail/qmail/postfix better, each one has loads of good resources and well known mailing list archives.

  3. By Anonymous Coward (80.58.9.107) on

    is really good :)

  4. By 808blogger (17.255.241.38) on http://blog.evogts.com

    nice article. anyone played with DSPAM? not for anything other than that pretty interface for clients.

    Comments

    1. By Anonymous Coward (69.17.22.33) on

      Check out this howto: http://www.phpinsider.com/dspam/

      Also http://www.ijs.si/software/amavisd/ which is a "better" way of running
      Spamassassin.

      Another howto: http://www.flakshack.com/anti-spam/wiki/index.php

    2. By Anonymous Coward (69.197.92.181) on

      Yes, DSPAM is an order of magnitude better than SA. Its far more accurate, and more importantly MUCH less resource hungry, being written in C, not perl. SA takes about 20 MB of RAM per proccess, with a single proccess being spawned per email, and running for 15-30 seconds. So on a busy server, you really can't use SA at all.

      Comments

      1. By Anonymous Coward (213.118.35.44) on

        How does it take 15-30 seconds for one email to be processed? Are you running this on a 286 or something?

        Comments

        1. By Denis Solaro (81.249.99.156) on

          Oh yeah, if you set the maxsize for an article to be processed via spamc it can take that much on a 733 Mhz. Granted, it's also running hatchet, syweb, etc... Found the Papamike article a bit before (it wasn't accurate as it is) and did a row of mail injections, thousands in all sizes... To work with vilter you need to set your milter timeouts to incredible heights if you don't want SA to block the thing. But I have seen those times mentioned above in some extremes.

        2. By sthen (81.168.66.229) on

          It can easily take 20-30 seconds if querying unavailable DNS blacklists...

      2. By Anonymous Coward (67.34.129.203) on

        aren't lots of those pages shared though? (assuming you didn't build a static perl) either way it's still a lot more than pure C. just wondering... 20MB sounds big even for apache/mod_perl processes.

        Comments

        1. By tedu (64.173.147.27) on

          shared or not, they still need to be mapped. and perl's init time is many times slower than a compiled executable's.

      3. By 808blogger (66.91.22.5) on http://blog.evogts.com

        yeah i see this on one of the servers i currently admin. its an ULTRASPARCIIi running @ 300mhz and SPAMD is S... L... O.... W.... however on a regular machine CPU load is not an issue

  5. By submicron (68.89.198.16) submicron@inherently-evil.net on

    You can also substitute Postfix+amavisd-new into this equation with the same result (minus the insecurities of Sendmail). In fact I installed an OpenBSD based firewall with spam/virus filtering at work and have gotten nothing but accolades for it. I highly recommend it.

    Comments

    1. By Anonymous Coward (69.197.92.181) on

      Minus the insecurities of sendmail, but plus the insecurities of postfix. Wow, that's really helpful. You do realize this isn't 1995 right? And that sendmail's security record really isn't that bad this century?

      Comments

      1. By Anonymous Coward (213.118.35.44) on

        Isn't it so that most of sendmail's security problems were (or are?) related to buffer-overflows and whatnot? If so then OpenBSD's compiler tools (and W^X if your hardware supports it) should care of most of them :).

      2. By submicron (64.207.228.181) submicron@inherently-evil.net on

        Insecurities of postfix? *chuckle* I think I'll take the postfix track record compared against sendmail's any day. The point of the post, however, was more that amavisd-new+postfix integrates really nicely into a mail filtering gateway, not to say that postfix is superior to sendmail.

        Comments

        1. By pravus (24.248.120.76) on

          The point of the post, however, was more that amavisd-new+postfix integrates really nicely into a mail filtering gateway, not to say that postfix is superior to sendmail.

          then why malign sendmail at all? your statement would have been just as valid and more effective had you left the derogatory statement out of it. the fact that you are having to re-explain your intent indicates that the original message's purpose was lost.

    2. By Luiz Gustavo (200.164.209.132) on http://hades.uint8t.org

      I don't have a good experience with amavisd. I have my concerns about running daemon written in perl in a mail server, damn resource hungry piece of scum. :D </rant>

      Comments

      1. By submicron (64.207.228.181) submicron@inherently-evil.net on

        Spamassassin is also a perl script and is still heavily used, and with excellent results. I've been very successful with amavisd-new despite the fact that it does use more than its fair share of memory.

        Comments

        1. By Luiz Gustavo (200.217.62.218) on http://hades.uint8t.org

          Perhaps It's just a point-of-view, but I dislike the resource usage.

          In my conception a mailserver should be light and fast, mostly I/O based.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]