Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported. If anything, qmail is known as the most annoying MTA to package, since no modifications to the source are permitted, and the application has to be built using a massive patch tree instead. The quirky management daemons required to run qmail were also obnoxious and at odds with everything else on the system.
Salient quote below:
>In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
[snip]
>Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
>>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."
I used to install qmail fairly often on different Unix-like systems. I remember the installation instructions clearly setting out the limits that should be set on its processes, and I remember following them.
It sounds like the Debian packager didn’t follow the instructions. That doesn’t seem like the fault of the software.
> Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported.
qmail is a great demonstration that if you declare enough things out of scope, you can claim that the software is secure.
Reminds me of the era when dual-core processors started becoming generally available. Suddenly the bugs in multi-threaded software were much more apparent.
Vendors replied to complaints with: “We don’t support those processors”.
No buddy, you don’t support stable software. It’s buggy even on a single core, it’s just less obvious.
The title of the actual paper is "Some thoughts on security after ten years of qmail 1.0". The post currently has the made-up title "How to Write Software with Zero bugs – 25 years after qmail 1.0 – D. Bernstein [pdf]".
Sorry, that's actually how I jokingly refer to that paper whenever I quote it, I didn't know the title should match the link title exactly. Now I see why it's flagged
I agree with the argument about reducing lines of code. Whenever I write code, I spend quite a bit of time thinking about different ways of implementing it before I start coding and the most important characteristic I look for in a solution is succinctness.
Correct code is easy to read because it's close to its theoretical minimum size. It reminds me of the quote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
I ran several Qmail systems. Daemontools worked rather well. They had a habit of delivering email reliably. "Life with Qmail" was a very decent primer.
I also ran several other mail systems at the same time (and still do). Exchange's smtpd is still a bit of a pain and I never put it on the internet directly.
Nowadays (last 15 years) I use Exim for a MTA/proxy - at home and at work.
Any reason you prefer Exim? I've enjoyed running Postfix forever and though the config is a bit baroque, have had no issues with running it in my somewhat weird setup.
It didn't make the transition to 64 bits worth of memory with the record intact. https://lwn.net/Articles/820969/ Although the CVE _is_ from 2005 so perhaps it doesn't count.
hdmoore|2 years ago
Salient quote below:
>In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
[snip]
>Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
>>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."
1. https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...
edit: added quote from referenced url
tokamak-teapot|2 years ago
It sounds like the Debian packager didn’t follow the instructions. That doesn’t seem like the fault of the software.
rodgerd|2 years ago
qmail is a great demonstration that if you declare enough things out of scope, you can claim that the software is secure.
jiggawatts|2 years ago
Vendors replied to complaints with: “We don’t support those processors”.
No buddy, you don’t support stable software. It’s buggy even on a single core, it’s just less obvious.
jeffbee|2 years ago
setproctitle is enough logging for a mailer, said nobody ever.
kens|2 years ago
SushiHippie|2 years ago
jrpelkonen|2 years ago
bykhun|2 years ago
jongjong|2 years ago
Correct code is easy to read because it's close to its theoretical minimum size. It reminds me of the quote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
gerdesj|2 years ago
I also ran several other mail systems at the same time (and still do). Exchange's smtpd is still a bit of a pain and I never put it on the internet directly.
Nowadays (last 15 years) I use Exim for a MTA/proxy - at home and at work.
Karrot_Kream|2 years ago
GauntletWizard|2 years ago
lockhouse|2 years ago
latenightcoding|2 years ago
daneel_w|2 years ago
troutwine|2 years ago
commandersaki|2 years ago
technick|2 years ago
johnea|2 years ago
So much could be learned in modern *nix distributions from this philosophy...
unknown|2 years ago
[deleted]