Quick look at OpenSMTPD on OpenBSD 5.1

I want to have a look at a replacement for my Postfix/Dovecot/OpenLDAP mail server using the OpenSMTPd implementation. Not that it doesn’t work ; in fact I don’t get that much mail and everything works like a charm. I just want to see if I can use as much all-inclusive OpenBSD 5.1 daemons.

Setup basic smtpd configuration

First of all, let’s tell the SMTP daemon that we want to accept every mail for our tumfatig.net domain. I don’t want to mess with configuration on updates so I’ll be using basic directions in smtpd.conf and complex one in smtpd.conf.local:

# vi /etc/mail/smtpd.conf listen on lo0 map "aliases" { source db "/etc/mail/aliases.db" } include "/etc/mail/smtpd.conf.local" # vi /etc/mail/smtpd.conf.local lan_if = "vic0" lan_net = "" listen on $lan_if accept from all for domain "tumfatig.net" deliver to mbox accept from local for all relay accept from $lan_net for all relay

Then stop and disable Sendmail:

# /etc/rc.d/sendmail stop # vi /etc/mailer.conf sendmail /usr/sbin/smtpctl send-mail /usr/sbin/smtpctl mailq /usr/sbin/smtpctl makemap /usr/libexec/smtpd/makemap newaliases /usr/libexec/smtpd/makemap # newaliases # vi /etc/rc.conf.local (...) sendmail_flags=NO smtpd_flags=""

You can now start OpenSMTPd, either with the rc.d script or in debug mode from the console, using `smtpd -d`. From there, you can send e-mail to the external world and any mail for the configured domain will be saved locally. Note that only users known to the system, from the etc/passwd, can receive mail, yet.

Switch to Virtual Domains configuration

I do host several domains. Either as a primary or secondary MX.

From the previous chapter, we’ve seen that smtpd stores the mail with the system user. In a case of virtual domains and users, we use a single users that will store every mail. That particular user will also be used by the POP3/IMAP server to read and manage the mail.

Create the virtual user and set proper permissions on storage:

# groupadd -g 2000 vmail # useradd -m -u 2000 -g vmail -d /home/vmail -s /sbin/nologin vmail # mkdir -p /home/vmail/{carnat.net,tumfatig.net} # chown vmail:vmail /home/vmail/{carnat.net,tumfatig.net}

Modify OpenSMTPd’s configuration to use virtual domain:

# vi /etc/mail/smtpd.conf.local (...) map "vdomains" { source db "/etc/mail/vdomains.db" } accept for virtual "vdomains" deliver to maildir "/home/vmail/%d/%a/"

Fill-in the domains information:

# vi /etc/mail/vdomains tumfatig.net accept carnat.net accept ptijo@tumfatig.net vmail joel@carnat.net vmail # makemap /etc/mail/vdomains

Send emails to the defined users and watch the logs to see them delivered. Note that if you add an entry like “@domain user” in the vdomain file, you’ll get mail for any users on that particular domain.

Virtual aliases can be populated with entries like:

# cat /etc/mail/vdomains (...) carnat.net accept joel@carnat.net vmail root@carnat.net joel@carnat.net abuse@carnat.net root@carnat.net hostmaster@carnat.net root@carnat.net postmaster@carnat.net root@carnat.net webmaster@carnat.net root@carnat.net (...)

The 5 last entries will act as virtual aliases, forwarded to the destination email and “recursively rendered”.

Configure authenticated relay

Before setting up authentication, one should configure encryption. Either install the certificate from some external provider or configure a self-signed one:

# mkdir /etc/mail/certs # cd /etc/mail/certs # openssl genrsa -out openbsd.tumfatig.net.key 4096 # openssl req -new -x509 -key openbsd.tumfatig.net.key -out openbsd.tumfatig.net.crt -days 3650 # chmod 0600 openbsd.tumfatig.net.* # vi /etc/mail/smtpd.conf.local (...) listen on $lan_if smtps certificate "openbsd.tumfatig.net" enable auth

To be able to use that SMTP to relay mail from anywhere, create a map for users to authenticate:

# touch /etc/mail/secrets # chown root:_smtpd /etc/mail/secrets # chmod 0640 /etc/mail/secrets # echo "openbsd.tumfatig.net ptijo:secret" > /etc/mail/secrets # makemap /etc/mail/secrets # vi /etc/mail/smtpd.conf.local (...) map "secrets" { source db "/etc/mail/secrets.db" } accept from all for all relay via localhost smtps auth "secrets"

What else?

There are two or three more features that I was looking for and that aren’t available yet.

Secondary MX

I have a deal with a friend for whom I run a secondary MX. Configuring the secondary MX feature is quite easy:

# vi /etc/mail/smtpd.conf.local (...) map "v2mx" { source db "/etc/mail/v2mx.db" } accept from all for virtual "v2mx" relay # vi /etc/mail/v2mx more.tld accept # makemap /etc/mail/v2mx

From there, OpenSMTPD will act as a secondary MX relaying mail for the configured domains, using DNS resolution. The missing feature I need was recipient filtering. Indeed, I know the valid accounts for the domain I relay. And it would be nice to accept mail for valid users and return “450 – Try again later” for invalid users ; 450 rather than “550 – Unknown user” to not ease directory harvesting.

Such feature is in the pipe and should “happen soon”. I’ll have a look back when OBSD 5.2 comes out.

LDAP integration

Storing information in a shared LDAP directory is really nice as you can share authentication (and more) with many software ; like share the SMTP mailboxes, SMTPs authenticated users, IMAP users, …

I’m waiting for LDAP because I already use it. But storage using a database would be OK too.

Anyway, AFAIK, it is not available yet.

Virtual users

The virtual users configuration as I described it here is not “correct”. If you only have 1 user per domain, you can manage to have it working. But since you have 2 users on a particular domain, both will have their mail stored in the vmail account I created ; which is obviously not what you want.

As I understood it, the only way to deal with users is to create system users ; in /etc/passwd. They don’t have to be able to log in ; they just need a home, to store email, and a password, for authenticated smtp.

Monitoring features

There is a smtpctl show stats that will give you information about what happens on your smtp daemon. But this is more about what is happening, in terms of session and errors, than about mail counters. I was expecting things like pfctl from which you can stats “received mail”, “rejected mail”, …

The log file has some information about received and sent mail but I found them a bit hard to read when it comes to tracing the exact path of email delivery. It is obviously a matter of getting unused to the postfix way of logging and learn the OpenSMTPD way. So just learn it child.

Final thoughts

All-in-all, OpenSMTPD seems ready to deliver email in production. Using it with spamd will obvisouly make a good relay server, in and out. If you don’t care using system users to managed your email services, OpenSMTPD is ready too for it.

The only missing feature is, from my point of view, options to interface with a remote directory to manage users and domains. You can deal without it if you’re a UNIX GuRu or if you have a small number of users but, as far as I’m concerned, OpenSMTPD won’t make it in “the Enterprise” until it can get part of it’s configuration from a remote repository.

Talking about configuration, syntax is still evolving. I’ve already been taught that ‘{}’ have been dropped in -CURRENT. So expect some more changes regarding syntax ; and as soon as 5.1-CURRENT.


Author: Joel Carnat

@work Technical Architect and SysAdmin ; @home OpenBSD and FOSS, Karate, Kobudō, Jōdō, Bodyweight workout, Photography & Music

11 thoughts on “Quick look at OpenSMTPD on OpenBSD 5.1”

  1. Hi,

    I’m referring ‘Configure authenticated relay’. I did follow the steps you described and created a user in this ‘secrets’ file. Now, when using evolution from a remote linux box, I was able to relay via my e-mail server an e-mail but using a different account from the one I defined in the ‘secrets’ file!!! What am I doing wrong?


  2. how can I check that?

    here is the logfile output:

    Jul 31 12:33:19 [my_machine] dovecot: imap-login: Login: user=, method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, mpid=15887, TLS
    Jul 31 12:33:41 [my_machine] smtpd[7154]: b57b4253: from=, size=510, nrcpts=1, proto=ESMTP, relay=[domain] [x.x.x.x]
    Jul 31 12:33:42 [my_machine] smtpd[28244]: b57b425380fc3549: to=, delay=1, relay=[domain] [x.x.x.x], stat=Sent (2.0.0 q6VFefFJ002151 Message accepted for delivery)
    Jul 31 12:34:18 [my_machine] dovecot: imap(user): Connection closed bytes=111/717

    here is the smtpd.conf.local file:

    listen on rl1
    listen on rl1 smtps certificate “example.com” enable auth
    map “secrets” { source db “/etc/mail/secrets.db” }
    accept for local alias aliases deliver to mbox
    accept from all for domain “example.com” deliver to mbox
    accept for all relay
    accept from all for all relay via localhost smtps auth “secrets”


  3. just want to mention that the non-existent ‘secrets’ user who’s sending the relayed e-mails is a regular openbsd user! The e-mail client is asking me for the right password before invoking the openBSD SMTP server. Is not like any remote user can relay via my e-mail server!


  4. another bit of info! I saw the following entry in my maillog file:

    MTA|208b98227211a13c|-|0503@msa.hinet.net|superedm001@yahoo.com.tw|1343763449|345600|7|190 secrets lookup failed

    so the ‘secrets’ file is been used after all?



  5. Thank you Joel for this article. I’m using it although I’m having some issues.
    You have made a mistake, you have omitted the keyword map for the virtual configuration. So it should be virtual map “vdomains”. It took me a good hour to understand that =)
    Or maybe, my opensmtpd version is to recent (I’m following current)

    1. Glad to hear it helped.

      I think the “error” is due to opensmtpd version being different. AFAIK, changes are applied very often right now. Between to source sync, I also had t change a few configuration directives.

      I’ll redo that whole work when opensmtpd comes to OpenBSD 5.2.

  6. Pingback: Unix:Is this enough for a working mail server? – Unix Questions

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.