OpenBSD Journal

OpenSMTPd Now the Default MTA in OpenBSD

Contributed by tbert on from the a-demoostik-once-bit-my-sister dept.

After a long time spent in the shadow of Sendmail, OpenSMTPd is now the default MTA in OpenBSD:

CVSROOT:	/cvs
Module name:	src
Changes by:	tedu@cvs.openbsd.org	2014/03/12 12:21:34

Modified files:
	etc            : crontab mailer.conf rc.conf 
	etc/mail       : smtpd.conf 

Log message:
switch over to smtpd by default.
ok deraadt gilles todd

A great deal of thanks to the OpenSMPTd developers for their work in making this possible!

(Comments are closed)


  1. By Anonymous Coward (134.59.158.7) on

    Great news! The first thing I had to do when I install an OpenBSD was to switch to OpenSMTPd.
    Now the fresh install is even faster!

  2. By Blake (78.192.104.249) undeadly@2112.net on 2112.net

    The king is dead! Long live the King!

    Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.

    Big congrats to all the developers!

    1. By Brad (brad) on

      > The king is dead! Long live the King!
      >
      > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
      >
      > Big congrats to all the developers!

      Sendmail gone, Apache gone, BIND is next.

      1. By Anonymous Coward (200.5.117.242) on

        > > The king is dead! Long live the King!
        > >
        > > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
        > >
        > > Big congrats to all the developers!
        >
        > Sendmail gone, Apache gone, BIND is next.

        ...hm BIND being replaced with?

        1. By Brad (brad) on

          > > > The king is dead! Long live the King!
          > > >
          > > > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
          > > >
          > > > Big congrats to all the developers!
          > >
          > > Sendmail gone, Apache gone, BIND is next.
          >
          > ...hm BIND being replaced with?

          NSD / Unbound.

          1. By Anonymous Coward (200.5.117.242) on

            > > > > The king is dead! Long live the King!
            > > > >
            > > > > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
            > > > >
            > > > > Big congrats to all the developers!
            > > >
            > > > Sendmail gone, Apache gone, BIND is next.
            > >
            > > ...hm BIND being replaced with?
            >
            > NSD / Unbound.

            cool!

          2. By Amit Kulkarni (68.116.146.128) on

            > > > > The king is dead! Long live the King!
            > > > >
            > > > > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
            > > > >
            > > > > Big congrats to all the developers!
            > > >
            > > > Sendmail gone, Apache gone, BIND is next.
            > >
            > > ...hm BIND being replaced with?
            >
            > NSD / Unbound.

            This is cool, Brad. Smooth switchover.

          3. By Sebastian Rother (srother) on https://www.mercenary-security.com

            > > > > The king is dead! Long live the King!
            > > > >
            > > > > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
            > > > >
            > > > > Big congrats to all the developers!
            > > >
            > > > Sendmail gone, Apache gone, BIND is next.
            > >
            > > ...hm BIND being replaced with?
            >
            > NSD / Unbound.

            Awesome....

            I am specialy happy that OpenSMTPd now is used by default.

            The only thing wich nginx does not ship with are 2 tools I'd would prefere to stay.

            logresolve + htpasswd

            You might like to keep those tools in the base system.

          4. By Sean Cody (sean) on I don't work here.

            > > ...hm BIND being replaced with?
            >
            > NSD / Unbound.

            As much as I'm not a fan of BIND... I not convinced NSD & Unbound are reasonable enough replacements.

            Then again I've been purposely suffering with IPv6 and tinydns for longer than is sane.

            Though if you can explain why they are better aside from the 'they are not BIND' argument I'm all ears. I want to be convinced.

            1. By Anonymous Coward (86.171.253.50) on

              > > > ...hm BIND being replaced with?
              > >
              > > NSD / Unbound.
              >
              > As much as I'm not a fan of BIND... I not convinced NSD & Unbound are reasonable enough replacements.
              >
              > Then again I've been purposely suffering with IPv6 and tinydns for longer than is sane.
              >
              > Though if you can explain why they are better aside from the 'they are not BIND' argument I'm all ears. I want to be convinced.

              I'm not using BIND so heavily that I see major drawbacks in it. Yet, the split-horizon feature is something I like BIND for, and that NSD/Unbound can't do. Can someone explain what they don't like about BIND?

              1. By henning (180.42.49.96) on

                > Can someone explain what they don't like about BIND?

                Other than fundamental design issues like the absurd trial to do authdns & caching resolver in one daemon, lack of limits for the cache, awkward onfiguration and bad code: no.

              2. By Anonymous Coward (2001:470:b01e:3:214:51ff:fe67:4efb) on

                > > > > ...hm BIND being replaced with?
                > > >
                > > > NSD / Unbound.
                > >
                > > As much as I'm not a fan of BIND... I not convinced NSD & Unbound are reasonable enough replacements.
                > >
                > > Then again I've been purposely suffering with IPv6 and tinydns for longer than is sane.
                > >
                > > Though if you can explain why they are better aside from the 'they are not BIND' argument I'm all ears. I want to be convinced.
                >
                > I'm not using BIND so heavily that I see major drawbacks in it. Yet, the split-horizon feature is something I like BIND for, and that NSD/Unbound can't do. Can someone explain what they don't like about BIND?

                Then use BIND if you want to or need it for certain features. No one is forcing you not to.

              3. By Anonymous Coward (2001:8b0:648e:cc01:f2de:f1ff:fef9:a752) on

                > I'm not using BIND so heavily that I see major drawbacks in it. Yet, the split-horizon feature is something I like BIND for, and that NSD/Unbound can't do.

                Well actually... It depends what you're using it for. If you'd like to provide one view of a zone to clients using your resolver (for example a zone with a number of internal hostnames) and a different one to external requests (e.g. with just A records for webserver and some MXes) this is actually quite straightforward to do with Unbound and NSD. Run the authoritative server on NSD, unbound for resolver clients, and override the relevant zone in Unbound. It's not flexible enough to fully replace BIND views (and as was said in another post, nobody's forcing you not to use BIND), but it's very easy to configure this for what I think is the most common case.

                > Can someone explain what they don't like about BIND?

                The version of BIND in OpenBSD base is several years old and due to local changes (largely for privilege separation and using safer string handling functions), tracking upstream updates is now difficult. Additionally the next major version of BIND is really not going to be suitable to include in the base OS due to the many dependencies. Unbound and NSD seem to be a better fit for what's needed in the OS.

                1. By Anonymous Coward (199.185.137.1) on

                  > The version of BIND in OpenBSD base is several years old

                  That is false.

                  > and due to local changes (largely for privilege separation

                  BIND itself has some privsep / privdrop, but it is unrefined. The OpenBSD privdrop is a little more refined than upstream, mostly because it is always enabled and is cleanly interegrated. NSD and Unbound do it better, though there is room for improvement.

                  > and using safer string handling functions)

                  No, false. Such changes are typically pulled in by upstream projects; for the good reason that ignoring them would be pretty embarrassing. An example of ignoring security changes would probably be the tcpdump crowd.

                  The major innovation in the OpenBSD version is a better way of handling port randomization. This is done by utilizing features of the kernel network stack, rather than having the daemon itself pick random ports (and create a mess for other services on the same machine).

                  1. By Anonymous Coward (2001:470:b01e:3:214:51ff:fe67:4efb) on

                    > > The version of BIND in OpenBSD base is several years old
                    >
                    > That is false.

                    BIND 9.4.2 (which is what is in base) is from 28/11/2007. That is over 6 years old.

      2. By Anonymous Coward (172.56.6.166) on

        > > The king is dead! Long live the King!
        > >
        > > Seriously, this is a big deal. It's as big a change as switching the default HTTP server from Apache to Nginx; possibly even more significant as OpenSMTPd was written in-house.
        > >
        > > Big congrats to all the developers!
        >
        > Sendmail gone, Apache gone, BIND is next.

        How long 'till gcc is gone?

    2. By Free Bird (37.0.95.173) on

      > It's as big a change as switching the default HTTP server from Apache to Nginx;
      When did that happen?

      1. By Fred Crowson (fredcrowson) on http://www.crowsons.net/puters/zaurus.php

        > > It's as big a change as switching the default HTTP server from Apache to Nginx;
        > When did that happen?

        It hasn't happened yet - but it's in the pipeline....

  3. By Anonymous Coward (2001:470:89e9:1:15ad:9267:a1e6:d9d6) on

    Excellent news! Thanks to the OpenSMTPd developers, testers and documenters.

  4. By Rich (62.232.9.62) on

    I hope the devs don't move on to something else anytime soon - the code leaves rather a lot to be desired. But, sadly, that seems to be about average, especially with open source. That's not a troll by the way (I have used OBSD for many years); it's just an observation.

    1. By Anonymous Coward (2001:470:89e9:1:15ad:9267:a1e6:d9d6) on

      > I hope the devs don't move on to something else anytime soon - the code leaves rather a lot to be desired. But, sadly, that seems to be about average, especially with open source. That's not a troll by the way (I have used OBSD for many years); it's just an observation.



      Instead of slamming the code, why not offer your ideas for ongoing enhancements to the code?

    2. By Anonymous Coward (91.154.66.65) on

      > the code leaves rather a lot to be desired

      Could you point to some concrete problems in it?

      1. By Rich (62.232.9.62) on

        > Could you point to some concrete problems in it?

        Take a quick look at it. If you still have to ask after that then I wouldn't admit it to anyone if I were you.

        1. By Anonymous Coward (77.7.41.111) on

          > > Could you point to some concrete problems in it?
          >
          > Take a quick look at it. If you still have to ask after that then I wouldn't admit it to anyone if I were you.

          This proves to anyone who was still in doubt that you are in fact a troll.

          1. By Rich (62.232.9.62) on

            Eh? It proves nothing of the sort. Ok - look at it and if you still think it's ok then don't keep it to yourself - cite it as a top example of quality in your next job interview - it makes no difference to me.

    3. By Anonymous Coward (12.175.4.5) on

      > That's not a troll by the way...

      It sure reads like a troll.

      1. By Rich (62.232.9.62) on

        > It sure reads like a troll.

        No it isn't - I'm just pointing something out. I think code quality is important. I feeling not shared by all, it seems.

        1. By Anonymous Coward (2001:8b0:648e:cc01:f2de:f1ff:fef9:a752) on

          > > It sure reads like a troll.
          >
          > No it isn't - I'm just pointing something out. I think code quality is important. I feeling not shared by all, it seems.

          Seeing as you have read some of the code and spotted issues, why not put an email together detailing some of the specific problems that you've seen? This isn't developed in a vacuum, people do take comments on board.

          Just saying "the code leaves rather a lot to be desired" is rather demotivational and doesn't really help anyone.

          1. By Anonymous Coward (91.154.66.65) on

            > > > It sure reads like a troll.
            > >
            > > No it isn't - I'm just pointing something out. I think code quality is important. I feeling not shared by all, it seems.
            >
            > Seeing as you have read some of the code and spotted issues, why not put an email together detailing some of the specific problems that you've seen? This isn't developed in a vacuum, people do take comments on board.
            >
            > Just saying "the code leaves rather a lot to be desired" is rather demotivational and doesn't really help anyone.

            Evil Theo is trying to trick us into actually reading the code.

  5. By Sean Cody (sean) sean@tinfoilhat.ca on I don't work here.

    I've come out out hiding to wish you congratulations on slaying the demon that is sendmail!

    1. By Anonymous Coward (77.247.181.165) on

      > I've come out out hiding to wish you congratulations on slaying the demon that is sendmail!

      Well said! This is great news.

      i suppose this means 5.5 -release is indeed to be released with OpenSMTPd as the default mailer?!

      1. By Brad (brad) on

        > > I've come out out hiding to wish you congratulations on slaying the demon that is sendmail!
        >
        > Well said! This is great news.
        >
        > i suppose this means 5.5 -release is indeed to be released with OpenSMTPd as the default mailer?!

        No, 5.6 will come with OpenSMTPd, nginx, NSD/Unbound as default.

        1. By Martijn Rijkeboer (81.24.98.206) on

          > No, 5.6 will come with OpenSMTPd, nginx, NSD/Unbound as default.

          Are you sure about Unbound? Unbound isn't currently linked to the build or did I miss something?

          1. By Anonymous Coward (2001:470:b01e:3:214:51ff:fe67:4efb) on

            > > No, 5.6 will come with OpenSMTPd, nginx, NSD/Unbound as default.
            >
            > Are you sure about Unbound? Unbound isn't currently linked to the build or did I miss something?

            Yes.

  6. By Peter van Oord van der Vlies (81.207.16.117) peter.vanoordvandervlies@gmail.com on

    Great work guys ! but...

    Not sure if i like this yet....
    I mean the smtp daemon works great and i using it on several places but on many places i can't use it because it lacks supports for things like clamav and spamassassin.

    ps. Anyone got a working version of check_mailq nagios plugin to check the opensmtpd mail queue ?

    1. By tbert (tbert) on

      > Great work guys ! but...
      >
      > Not sure if i like this yet....
      > I mean the smtp daemon works great and i using it on several places but on many places i can't use it because it lacks supports for things like clamav and spamassassin.
      >
      > ps. Anyone got a working version of check_mailq nagios plugin to check the opensmtpd mail queue ?
      >

      This is one of the reasons why this change was done this early in the 5.6 release cycle: to allow for the time to find and resolve any shortcomings, errors, omissions, or thinkos that may be lurking. For instance, the check_mailq plugin is likely to pop up relatively shortly, as someone meeting their own need for it solves the problem for everyone else who had it. Could that someone be you? Only time will tell! ;)

    2. By Anonymous Coward (2001:470:b01e:3:214:51ff:fe67:4efb) on

      > Great work guys ! but...
      >
      > Not sure if i like this yet....
      > I mean the smtp daemon works great and i using it on several places but on many places i can't use it because it lacks supports for things like clamav and spamassassin.
      >
      > ps. Anyone got a working version of check_mailq nagios plugin to check the opensmtpd mail queue ?

      You do know the MTA and other components can be changed to something else if you really need it or want it?... no one is holding a gun to your head saying you have to use these components. They're just the defaults.

    3. By Gilles (93.31.21.178) gilles@poolp.org on poolp.org

      > Great work guys ! but...
      >
      > Not sure if i like this yet....
      > I mean the smtp daemon works great and i using it on several places but on many places i can't use it because it lacks supports for things like clamav and spamassassin.
      >

      Actually, I've used it with ClamAV and some people are using it with SpamAssassin using SpamPD.


      > ps. Anyone got a working version of check_mailq nagios plugin to check the opensmtpd mail queue ?
      >

      You should ask on our list, maybe someone has done the work.

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