OpenSMTPD: a portable SMTP server, with an upstream caveat

A small server with a portable build

OpenSMTPD is a free implementation of the server side of the SMTP protocol as defined in RFC 5321, with some additional standard extensions. It allows ordinary machines to exchange mail with other systems speaking SMTP.

What makes it interesting is the combination of a small feature set and a wide portability claim. The project lists Linux, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD and macOS as supported systems, and the code is written in C with a build system that is deliberately portable rather than tied to one platform. There is even a directory of OpenBSD compatibility code in the tree, which is the practical evidence that the portability is real and not aspirational.

The licence is ISC, which is short and permissive. The project also has a Coverity scan badge and a packaging status badge that shows which distributions ship it and at what version, which is useful if you are deciding between building and installing.

The project is structured around a wiki for people who want to build their own mail server, a set of manual pages published online, and a small set of community channels: a mailing list, an IRC channel on libera.chat, the GitHub issue tracker and a discussions page.

This tree is not the OpenBSD tree

The first thing in the project notes is a warning, and it is the most important thing to read before you deploy this on a machine that matters. The repository may be out of date compared with the OpenBSD smtpd source code, and downstream package maintainers should be aware of that when backporting security fixes and other changes.

That is a specific and unusual thing for a project to say about itself, and it deserves unpacking. OpenSMTPD originates in OpenBSD, where it is developed as part of the base system. This repository is the portable version, and the two move at different speeds: fixes land in OpenBSD first, and the portable tree catches up when somebody does the work of carrying them across. The result is that the version you get from a package, from a container or from this repository is not necessarily the same code that OpenBSD users are running.

The practical consequence is a maintenance commitment. If you run this, you need a way of knowing when a security fix lands upstream and a way of applying it, and you should assume that the portable tree is not the first place it appears. That is the trade for the convenience of a portable, packageable server, and the project is upfront about it rather than leaving you to discover it.

Three ways to install it

Many distributions already package OpenSMTPD, and the project says all you need to do is install it with your package manager. The commands it lists are the obvious ones, one per system: the Debian and Ubuntu package, the Alpine package, the Fedora package, the openSUSE Tumbleweed package, and MacPorts on macOS. There is also a dedicated wiki page for Arch Linux, and container images are published on the project's GitHub packages page.

Building from source needs a set of dependencies that the project lists precisely. The runtime ones are a pkg-config implementation, libevent, and either libressl or OpenSSL for TLS. When you are not building from a release tarball, that is, when you are building from the git repository, you also need autoconf, automake, bison or byacc, and libtool. The project also warns that some distributions split a library into separate packages, so you should install the dev or devel variant, for example libevent-dev or libevent-devel.

The build itself is a familiar autotools sequence, with one step that only applies to a git checkout:

    cd opensmtpd*
    ./bootstrap  # Only if you build from git sources
    ./configure
    make
    sudo make install

For macOS there is an extra flag, because the library lives in a different place under MacPorts, and the notes also point out that the bison in the base system is too old, so a newer one has to come from MacPorts as well.

smtpctl, and the historical interface problem

OpenSMTPD provides a single utility, smtpctl, that controls the daemon and the local submission subsystem. Everything the old mail system offered goes through it.

To accommodate systems that expect commands like sendmail, newaliases or makemap, smtpctl can operate in a compatibility mode when it is called with one of those historical names. On systems with mailwrapper, that is done by editing the mailer configuration file to point each name at the same binary:

    sendmail        /usr/sbin/smtpctl
    send-mail       /usr/sbin/smtpctl
    mailq           /usr/sbin/smtpctl
    makemap         /usr/sbin/smtpctl
    newaliases      /usr/sbin/smtpctl

On systems without mailwrapper, the same effect is achieved with symbolic links pointing at the binary, one per historical name. The project is explicit about who owns that job: it leaves it to the package maintainers to set up the links in their packages, because it is very hard to accommodate every system with the preferred method in a clean way.

That is a fair division of labour, and it is also a hint about where to look if a cron job or a monitoring check calls mailq and gets nothing.

Two users, and why the split is worth it

To operate, OpenSMTPD requires at least one user, by default _smtpd, and preferably two, by default _smtpd and _smtpq. The project's comment on this is unusually direct: using two users instead of one will increase security by a large factor, so if you want to voluntarily reduce security or have more faith in the code than the project does, use one.

The reason is privilege separation. One user runs the daemon and owns the queue, so anything that can reach the daemon as that user can also reach the mail spool. With two, the process that accepts connections and the process that owns the queue run as different accounts, and a compromise of the first does not automatically give access to the second.

The instructions assume the defaults, but the configure script lets you override them with the user smtpd, user queue and group queue options. Creating the accounts is per platform, because the user management tools differ:

    mkdir /var/empty
    useradd -c "SMTP Daemon" -d /var/empty -s /sbin/nologin _smtpd
    useradd -c "SMTPD Queue" -d /var/empty -s /sbin/nologin _smtpq

On the BSDs the same two accounts are created with the platform's own user tool, and the macOS instructions add a step for the group.

One configuration file, one manual

The daemon is configured through a single file, and the project tells you where the format is documented: the complete format description of smtpd.conf lives in the configuration file manual page published by OpenBSD.

That is worth a second of thought, because it means the portable tree and the OpenBSD tree share a configuration format, which is the point of the portability. A configuration that works on one works on the other, and a document written for OpenBSD is authoritative for both.

The manual pages for the whole project are published online, and the project explicitly asks for contributions to them. For a server whose configuration is a single file, the manual is the documentation that matters, and having it online and maintained in one place is a genuine advantage over a daemon that ships an unmaintained example file and no explanation.

The project around the code

The release trail shows a project with a steady point release cadence: 7.8.0p0 in November 2025, 7.8.0p1 in March 2026 and 7.9.0p0 in September 2026, with the last push to the repository on 2026-09-14. The version numbers use the p suffix for the portable releases, and the version badge in the project notes tracks the current one.

The repository layout shows the usual pieces for a portable Unix project: an autotools build with a configure script and a bootstrap script for git checkouts, a compatibility directory for the OpenBSD specific code, a scripts directory, a contrib directory, a Makefile, an INSTALL document, a changes file, a build configuration directory and a directory of macro files, plus a continuous integration directory and a build configuration directory for the CI systems.

The community side is small and conventional: a mailing list, an IRC channel on libera.chat, the issue tracker and the discussions page on GitHub, plus a wiki aimed at people building their own mail server. The description of the repository notes that this is the official portable repository, and that forks, pull requests and other contributions are welcome.

Editorial conclusion

OpenSMTPD suits a site that needs to receive and relay mail on a Unix machine and prefers a small, auditable daemon to a larger mail suite, and the split between the daemon user and the queue user is a genuine security property rather than a formality. It is the wrong choice if you need the full feature set of a modern mail server, and it is the wrong choice if you want the same code that ships inside OpenBSD, because the portable tree can lag the OpenBSD source and the project says so plainly. Before you deploy it, read that warning and work out how you would pick up an OpenBSD security fix, because that is a maintenance commitment you are taking on, and configure the two users rather than the one, since the difference in privilege separation is large. The licence is ISC, the current release is 7.9.0p0 from 2026-09-13, and the last push was on 2026-09-14.

Frequently asked questions

Official sources

1. Issues
2. OpenSMTPD/OpenSMTPD on GitHub
3. Project website
4. README
5. Releases