OpenSMTPD(opensmtpd.org)
opensmtpd.org
OpenSMTPD
https://www.opensmtpd.org/
6 comments
This had a showstopper bug a few years ago that could completely compromise a host.
I don't usually need this, so I disable it.
https://blog.qualys.com/vulnerabilities-threat-research/2020...
I don't usually need this, so I disable it.
https://blog.qualys.com/vulnerabilities-threat-research/2020...
The postmortem is worth reading:
https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissec...
It's worth reading through the systemic mitigations that would make a clone of this bug impossible in the future.
https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissec...
It's worth reading through the systemic mitigations that would make a clone of this bug impossible in the future.
Interesting that the problem was introduced in a major architecture change to external MDAs, invoked with system(), and was specific to mbox format that requires elevated privilege.
I think that I will keep this disabled.
I think that I will keep this disabled.
They actually had a few really bad code execution bugs in a tight space of time a few years ago when someone was auditing it. It's a good idea to subscribe to [email protected] if you run this daemon to get notified of issues.
I was running it out of ports on FreeBSD at that time, and wound up patching from source because i didn't want to wait for the ports tree to update.
I still see attempts to exploit these bugs in my logs. Even though they've been patched for years.
That said, it's good that these were exposed and fixed, as opposed to not found. It's a relatively new daemon compared to other mail servers and it was still ironing things out.
I was running it out of ports on FreeBSD at that time, and wound up patching from source because i didn't want to wait for the ports tree to update.
I still see attempts to exploit these bugs in my logs. Even though they've been patched for years.
That said, it's good that these were exposed and fixed, as opposed to not found. It's a relatively new daemon compared to other mail servers and it was still ironing things out.
The problem I find with this line of reasoning is at the end of the evaluation I've disconnected from all networks and powered down the devices after uninstalling all of the operating systems.
This project looks cool but:
https://maddy.email/
https://blitiri.com.ar/p/chasquid/
https://maddy.email/
https://blitiri.com.ar/p/chasquid/
but what?
Ah sorry —- but these are easier to run, come with imap, automatic dkim and other awesome features
How does it compare to postfix?
As with most things, it depends on your use case. Except for some very high-volume or ancient features, it has pretty much everything.
However, unlike Postfix, you can actually configure OpenSMTPD yourself without breaking it. Postfix suffers heavily from a Byzantium configuration that everyone is copy-pasting because understanding how to create a configuration from scratch requires man-months of reading their docs.
The biggest downside to OpenSMTPD is the portable version is weakly supported, so it's only useful if you are running it on OpenBSD, which is a shame, really, because it's probably what most people would prefer if they could run it on their preferred OS.
However, unlike Postfix, you can actually configure OpenSMTPD yourself without breaking it. Postfix suffers heavily from a Byzantium configuration that everyone is copy-pasting because understanding how to create a configuration from scratch requires man-months of reading their docs.
The biggest downside to OpenSMTPD is the portable version is weakly supported, so it's only useful if you are running it on OpenBSD, which is a shame, really, because it's probably what most people would prefer if they could run it on their preferred OS.
We run Postfix at a large, high-volume scale and I can confirm OpenSMTPD does not have the feature/configuration set to work as a replacement. Postfix is great in this regard because it has near endless configurability, but it comes at the cost of complexity.
> We run Postfix at a large, high-volume scale
At the other end of the spectrum, Postfix is incredible - it's FOSS, and it does all that.
At the other end of the spectrum, Postfix is incredible - it's FOSS, and it does all that.
I remember when postfix was the "easier" MTA software meant to replace Sendmail and all of its m4 macros for rules. Getting Sendmail to do anything other than be a completely open relay was not easy.
Compared to that sendmail.cf and M4 macros that would generate it almost anything is "easy".
Leaps and bounds simpler and faster to configure. A basic setup for receiving and sending mail is about 10-12 lines of human-readable config.
That's what people used to say about Postfix vs Sendmail
And then about Exim4 vs Postfix
I'm a very happy user of Maddy (https://maddy.email/). It's a single executable that contains everything you need for a send-and-receive email server, including all modern anti-spam features. In my experience, the configuration is simpler than Postfix, Exim and OpenSMTPD, and falls back to sane defaults.
Another nice feature is what I would call its architecture: it does not try to be a service manager (instead, you are supposed to spawn it from your own favorite service manager, be that systemd, docker, or anything else, and you can hence really lock it down), hence it does not require root to run and does not rely on using system accounts by default.
I've only used it for very basic setups, but for those I can highly recommend it.
Another nice feature is what I would call its architecture: it does not try to be a service manager (instead, you are supposed to spawn it from your own favorite service manager, be that systemd, docker, or anything else, and you can hence really lock it down), hence it does not require root to run and does not rely on using system accounts by default.
I've only used it for very basic setups, but for those I can highly recommend it.
> How does it compare to postfix?
I haven't done a detailed comparison, but going how the OpenBSD guys go with other re-implementations (e.g. LibreSSL vs OpenSSL), I'm going to guess that it will have a reduced feature-set and capabilities.
I've nothing against the OpenBSD guys, but sometimes its a case of "right tool for the job". OpenBSD is great for firewalls and routers. Of course OpenSSH is without competitor, its just awesome.
But (some of) the rest of the OpenBSD toolset I'm not too sure ... for example Chrony is lightyears ahead of OpenNTPD etc.
Postfix is an excellent MTA. Written from a security-first mentality. Its widely deployed, and hence battle tested. As a result of its wide deployment its pretty much a case of "everyone knows how it works", the Postfix mailing list is excellent in terms of getting support.
TL;DR personally I see no reason to replace Postfix with anything, be it OpenSMTPD or anything else.
I haven't done a detailed comparison, but going how the OpenBSD guys go with other re-implementations (e.g. LibreSSL vs OpenSSL), I'm going to guess that it will have a reduced feature-set and capabilities.
I've nothing against the OpenBSD guys, but sometimes its a case of "right tool for the job". OpenBSD is great for firewalls and routers. Of course OpenSSH is without competitor, its just awesome.
But (some of) the rest of the OpenBSD toolset I'm not too sure ... for example Chrony is lightyears ahead of OpenNTPD etc.
Postfix is an excellent MTA. Written from a security-first mentality. Its widely deployed, and hence battle tested. As a result of its wide deployment its pretty much a case of "everyone knows how it works", the Postfix mailing list is excellent in terms of getting support.
TL;DR personally I see no reason to replace Postfix with anything, be it OpenSMTPD or anything else.
I use OpenNTPD on my router. Apparently time on local network is "exact" (off by some 50 ms) which is good enough for me. I don't need my clocks to be light years ahead indeed.
I would guess that the IBM/Eclipse license was a major problem from a BSD perspective.
"OpenSMTPD is a fairly complete SMTP implementation."
"OpenSMTPD is a fairly complete SMTP implementation."
Some might say "fairly complete" is in the eye of the beholder. ;-)
Technically OpenNTPD is a "fairly complete implementation" too, but its a waste of time compared to Chrony.
Technically OpenNTPD is a "fairly complete implementation" too, but its a waste of time compared to Chrony.
It's simple, works, synchronizes my clock, and doesn't have a manpage thousands of lines long.
It's also explicitly intended not to solve every NTP use case but rather just the common "I want my laptop's clock to be roughly accurate" use case.
It's also explicitly intended not to solve every NTP use case but rather just the common "I want my laptop's clock to be roughly accurate" use case.
It refuses to deal with a clock running fast, resulting in my laptop not being accurate. (It usually hovers around 10 minutes in the future)
Oh okay, I never had any problems with it, and I've been using it for many years.
That's fair; it might be that my hardware clock runs fast and if you don't have that problem it's not a problem.
Not sure why you need a separate NTP client running when systemd has systemd-timesyncd.
OpenSMTPD is the right answer if you want a general purpose mail server [1] that is secure by default. [2]
[1]: https://poolp.org/posts/2021-01-31/january-2021-opensmtpd-li...
[2]: https://www.openbsd.org/security.html
[1]: https://poolp.org/posts/2021-01-31/january-2021-opensmtpd-li...
[2]: https://www.openbsd.org/security.html
OpenSMTPD is far easier to configure and far harder to mistakenly misconfigure.
Much easier to configure and operate. I don’t know performance wise since I only run my personal smtpd on both more than 10 years ago.
I was hoping for this to be openttd but for routing email.
self-hosted: wrote my own at the right scale.
A shame that DKIM wasn’t built in too, but there’s a filter/plug-in architecture and you can add a third party filter to do DKIM for you.
Sometimes a commitment to supporting a plug-in architecture can be a little overzealous. Yes, it’s a nice general purpose puzzle to solve if you are the engineer writing the code. When DKIM is such a critical part of email in 2022, I wouldn’t mind if it were treated as a special case and supported by default.