OpenBSD Journal

Spamd setup for OpenBSD 3.9

Contributed by James Graves on from the dept.

I've put up an example for setting up spamd on OpenBSD 3.9 here.

The materials I found on the Internet didn't fully explain what all needed to be done with /etc/pf.conf and whitelists. The setup is for a small office with a WWW and mail server sitting behind a NAT firewall.

(Comments are closed)


Comments
  1. By Jonathan Rockway (66.92.134.156) jon@jrock.us on http://www.jrock.us/

    BTW, the "spamhaus" blacklist doesn't work anymore, so it's effectively a nop. You have to pay them unless you use the DNS blacklist instead.

    Comments
    1. By Pierre-Yves Dampure (80.177.197.237) pierre-yves.dampure@westmarsh.com on

      A comprehensive list of potential Martians may be derived from the IANA-maintained document below:

      http://www.iana.org/assignments/ipv4-address-space


      Comments
      1. By sthen (85.158.44.146) on

        > A comprehensive list of potential Martians may be derived from the IANA-maintained document below:
        >
        > http://www.iana.org/assignments/ipv4-address-space

        please don't block unallocated networks unless you keep the list up-to-date - the teamcymru bogons mailing list is good for this. (if your PF boxes are default-free, there's always 'block from no-route').

    2. By SMB (68.65.115.67) on

      > BTW, the "spamhaus" blacklist doesn't work anymore, so it's effectively a nop. You have to pay them unless you use the DNS blacklist instead.


      Is there any way, with PF, to do an RBL lookup and then route to spamd if it comes back positive... otherwise forward to internal SMTP server behind firewall?

      Comments
      1. By Ben Calvert (66.92.16.195) on

        > > BTW, the "spamhaus" blacklist doesn't work anymore, so it's effectively a nop. You have to pay them unless you use the DNS blacklist instead.
        >
        >
        > Is there any way, with PF, to do an RBL lookup and then route to spamd if it comes back positive... otherwise forward to internal SMTP server behind firewall?

        well, no. that would be a huge waste of effort.

        Not everything should be handled one packet at a time. thus we have proxys like squid and spamd, which deal with one smtpd or http request at a time.

        Comments
        1. By SMB (68.65.115.67) on

          > > > BTW, the "spamhaus" blacklist doesn't work anymore, so it's effectively a nop. You have to pay them unless you use the DNS blacklist instead.
          > >
          > >
          > > Is there any way, with PF, to do an RBL lookup and then route to spamd if it comes back positive... otherwise forward to internal SMTP server behind firewall?
          >
          > well, no. that would be a huge waste of effort.
          >
          > Not everything should be handled one packet at a time. thus we have proxys like squid and spamd, which deal with one smtpd or http request at a time.

          How would that be a huge waste of effort? Wouldn't rejecting with a 451 only to accept it at the next retry be a bigger waste of resources than just letting the request right through? Think of it as doing away with greylisting, almost like a traffic director.

          Requests from non-blacklisted IP addresses are forwarded right on in to the mail server, requests from blacklisted IP addresses are forwarded to spamd and have to go through a painfully gruelling 1 character per every 15 seconds response just to get to a 451 error.

          Perhaps I'm misunderstanding the spamd capabilities and usage, but I was under the impression that once a request makes its way through to spamd, the message will never be delivered. You mentioned spamd as a proxy? I thought it was more of a trap with a few labrea-type features such as throttling.

          Comments
          1. By Anonymous Coward (66.11.66.41) on

            > How would that be a huge waste of effort?

            How about you try adding this moronic "feature" to pf and then you will know how its a huge waste of effort. You really want your kernel having to store packets, do DNS lookups, wait for the results, then forward on the stored packets? This is exactly what a proxy is for. Don't try to put things in the kernel that don't belong there.

          2. By Anonymous Coward (61.95.31.212) on


            > Perhaps I'm misunderstanding the spamd capabilities and usage, but I was under the impression that once a request makes its way through to spamd, the message will never be delivered. You mentioned spamd as a proxy? I thought it was more of a trap with a few labrea-type features such as throttling.

            That functionality 100% belongs in userspace as a proxy. The packet filter should only ever be used to ensure sane traffic flow for several reasons, mostly because loss of simplicity in the kernel leads to bugs which leads to crashing systems and kernel exploits. PF presents an easy mechanism for userspace code to manipulate tables.

          3. By Brian (69.142.26.223) on

            > How would that be a huge waste of effort? Wouldn't rejecting with a 451 only to accept it at the next retry be a bigger waste of resources than just letting the request right through? Think of it as doing away with greylisting, almost like a traffic director.
            >
            > Requests from non-blacklisted IP addresses are forwarded right on in to the mail server, requests from blacklisted IP addresses are forwarded to spamd and have to go through a painfully gruelling 1 character per every 15 seconds response just to get to a 451 error.
            >
            > Perhaps I'm misunderstanding the spamd capabilities and usage, but I was under the impression that once a request makes its way through to spamd, the message will never be delivered. You mentioned spamd as a proxy? I thought it was more of a trap with a few labrea-type features such as throttling.

            There is already documented support for this in sendmail, and qmail, and probably anything else you are running. For sendmail, use the dnsbl 'FEATURE.' It won't redirect the host or 'waste' its time, but it will block the mail. Plus, sendmail can handle multiple DNS RBL lists easily. (more /usr/share/sendmail/README)

      2. By sthen (85.158.44.146) on

        > Is there any way, with PF, to do an RBL lookup and then route to spamd if it comes back positive... otherwise forward to internal SMTP server behind firewall?

        what, you want the kernel to do DNS lookups for every incoming port 25 connection?

        there used to be BGP feeds of some blacklist or other, I'm not sure if they still exist, but they could be used via bgpd and PF.

        Comments
        1. By SMB (68.65.115.67) on

          > what, you want the kernel to do DNS lookups for every incoming port 25 connection?


          Yes! Why not? Heck, most mail servers running Spamassassin do several DNS RBL lookups for each incoming connection. I know mine do. With a caching nameserver either local or on the same local area network, the overhead is nominal. Why not short circuit spammers at the PF level, make the decision on the fly based on DNS RBL lookups, and redirect the SMTP connections from blacklisted IPs straight to spamd to take advantage of the character delay and 451 "logjam the queue" effect mechanisms spamd has to offer?

          Comments
          1. By Anonymous Coward (75.132.114.37) on

            >Why not short circuit spammers at the PF level, make the decision on the fly based on DNS RBL lookups, and redirect the SMTP connections from blacklisted IPs straight to spamd to take advantage of the character delay and 451 "logjam the queue" effect mechanisms spamd has to offer?

            theo said in misc@ once, "Impossible!" Something to the effect that "you want our kernel to do DNS lookups?!?!?" 1.21 gigawatts!

            Then I asked daniel@ about the table limits for pf, as I'd prefer to just load up, for instance, the Composite Block List. If you're on the CBL, I don't want to talk to you at all; you should get tarpitted. Problem is that the pf address entries take up more room than you'd expect (for counters), and they won't all fit in memory.

            Best I could think of (and still haven't done it), is an ex post facto addition of dnsbl-positive ip's to a tarpit table. Watch pflog'ed connects to smtp, running a dnsbl lookup on each address, and add to pf table if positive. Each new ip address on a dnsbl would pass pf initially, but it shouldn't take a couple seconds to prevent/redirect further connections.

          2. By sthen (85.158.44.149) on

            > > what, you want the kernel to do DNS lookups for every incoming port 25 connection?
            >
            > Yes! Why not?

            If you did this, the part of the kernel responsible for deciding what network packets to allow, would itself have to talk relatively complicated protocols over the network to determine how to process those packets. Doesn't this seem a bit convoluted to you?

            Of course, you're welcome to write it yourself, but I don't _think_ it's likely to be accepted into OpenBSD...

            Comments
            1. By SMB (68.65.115.67) on

              > > > what, you want the kernel to do DNS lookups for every incoming port 25 connection?
              > >
              > > Yes! Why not?
              >
              > If you did this, the part of the kernel responsible for deciding what network packets to allow, would itself have to talk relatively complicated protocols over the network to determine how to process those packets. Doesn't this seem a bit convoluted to you?
              >
              > Of course, you're welcome to write it yourself, but I don't _think_ it's likely to be accepted into OpenBSD...
              >

              In that case (and given the comment right above yours), perhaps it would be something to write into spamd instead. Actually extend spamd to act as a proxy. Give it the internal IP address and port of the real SMTP server and have spamd do the RBL lookups. Don't keep any tables. Just DNS cache any RBL results for the given TTL of each record. Then, if the connection is legit, have spamd forward the stream to the real mail server.

              The downside to this is that without some heavy lifting, all mail will appear as if it had originated directly from the internal IP address of the firewall.

          3. By Anonymous Coward (66.11.66.41) on

            > > what, you want the kernel to do DNS lookups for every incoming port 25 connection?
            >
            >
            > Yes! Why not? Heck, most mail servers running Spamassassin do several DNS RBL lookups for each incoming connection. I know mine do.

            Why is braindead shit like this getting modded up? Is this slashdot now? Has everyone here turned stupid? Yes, userland apps doing DNS lookups is no big deal. The kernel doing it is insanely stupid. If you don't even realize this, then you are not in a position to be telling everyone what they should be doing to write software for you.

      3. By Anonymous Coward (64.129.81.169) on

        >Is there any way, with PF, to do an RBL lookup and then route to spamd

        An alternative approach which is not so bad... You can create your own blacklists by having the application that identifies the spam put the IP address into a pf table, the export the table to a specific file for spamd to read..and have spamd have a specific rejection message for that file.... You may ask why not just use pf to block the table directly? well because spamd will not know what custom message to give back, so we have to do something more complicated.

        Example, the port smtp-vilter does can do this. Smtp-vilter can take the IP of smtp servers that fail virus or spamassassin check and add them to a pf table (but not a file). We then could have pf block smtp for that vilter table... but that is not spamd blocking... With a line like below in the file /etc/smtp-vilter/smtp-vilter.conf
        react on spam add to table vilter for 1 day

        To get spamd to give a custom rejection message for the pf table you generated using whatever method, you may have to have a script or cron job save the table to a file then next cron of spamd-setup will pickup the IPs.

        /sbin/pfctl -t vilter -T show > /path/vilter.txt

        Then have spamd.conf pick up that file like..

        vilter:\
        :black:\
        :msg="vilter- Your email rejected--was relayed by %A \
        which has failed SpamAssassin within 24 hrs--:\
        :method=file:\
        :file=/path/vilter.txt


        That way the cusom rejection message by spamd gets used, whereas if we just smtp blocked the pf vilter table or redirected vilter IPs to 8025, spamd would not know what message to reply with.


        Another way to harvest spam IPs is to have poison email addresses and use procmail for the poioson email address use the port relaydb to gather IP addresses and script them to a file for spamd.

        It is easy to get spam email, now start harvesting!

        Comments
        1. By Anonymous Coward (87.78.70.152) on

          > Another way to harvest spam IPs is to have poison email addresses and use procmail for the poioson email address use the port relaydb to gather IP addresses and script them to a file for spamd.

          spamdb -T -a "<spamtramp@example.org>"
          if you want the ip-adresses you can read them via spamdb and grepping for type.

  2. By mvanbaak (80.126.97.112) on

    the table names in your pf.conf are not showing because you used the < and > signs instead of &lt; and &gt;

    Comments
    1. By James Graves (220.130.32.180) ansible@xnet.com on http://home.xnet.com/~ansible

      > the table names in your pf.conf are not showing because you used the < and > signs instead of < and >
      >

      Good catch. That's what you get when you don't write HTML very often.

      Fixed it. I also removed spamhaus because it is useless.

  3. By wbc (68.99.159.145) on


    I just finally got around to implementing this on OpenBSD 3.8 and I think your instructions should work okay for that version also.

    If anyone keeps telling themselves that they should try it out someday - do it now! I kept putting it off, but now that its in - it works so great that I am kicking myself for not doing it sooner.

    Not only was the configuration "OpenBSD-It just works-simple" its reduced our mail servers rejections by about 80%. It has literally gotten my personal inbox down to where I can actually see where the few spams that get through come from and deal with them.

    I pseudo-followed this writeup
    http://www.elwood.net/greyspamd.html

    Which did have some good stuff in it, but yours also has some great stuff in it.

    No matter what you do, try this out - also see the greytrapping

    Great job OpenBSD

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