Comment by dsr_ | Hacker News Reader

Comment by dsr_ | Hacker News Reader

I used qmail for about ten years. It was remarkably good from a sysadmin's perspective:

- the config system mostly used the name of a directory where lots of software would use a filename (qmail.ini => /var/qmail/conf), the name of a file where other software would use a variable name, and the contents of the file as the value of the variable. This is really, really easy to read and write without writing a parsing library.

- separate executables do separate jobs, with well-documented interfaces between them. Oh, and if a part didn't need root, it didn't run as root, and if a part didn't need to be the same user as another, it didn't share users. While it was easiest to replace something at the edge of the graph, it was entirely possible to replace middle jobs as well.

- qmail was the original design home of Maildir. I approve of various Maildir++ implementations (nesting folders is useful) and you could add support for them by replacing your delivery agent.

- qmail expected to be controlled by daemontools, a supervision system that has inspired/been blatantly copied and improved upon as runit, perp, s6, and nosh. (I have a suspicion that nosh is what most critics of systemd is really looking for.)

- fast.

- nearly bug-free.

What qmail gave up in exchange for all this: modern features and required antifeatures... which, it appears, notqmail is going to implement. Huzzah!

> the config system mostly used the name of a directory where lots of software would use a filename (qmail.ini => /var/qmail/conf), the name of a file where other software would use a variable name, and the contents of the file as the value of the variable. This is really, really easy to read and write without writing a parsing library.

this djb-ism has seriously affected a lot of the ways i unix, to date. envdir is such a great idea.

djb needs his own distro. He's written his own init, has thoughts about package management, config management, etc. He probably doesn't need his own kernel but a BSD or Linux kernel with DJB controlling userland would be interesting.

Agreed. Having had the opportunity to encounter, use, setup, and then later on, read the code and learn from qmail early on in my computer career I think it helped learn about proper system design with an eye towards security. Back when qmail was released there was nothing like it, the most popular MTA at the time was Sendmail and we all know how great that was :)

qmail had a great impact on system design for many years and especially in the mail delivery area. Things like Maildir redefined how even MUAs store and use email. djbdns also provided a breath of fresh air at the time it was released, worked much faster and much more secure than something like bind.

DJB also had many other (likely even more impactful) roles in the software industry, leading the fight against the encryption software export restrictions of the 90s.

https://en.wikipedia.org/wiki/Daniel_J._Bernstein

I liked a lot of things about qmail, but I found it annoying as a sysadmin, like in the 1.07 days, because you had to do all this patching. I eventually wrote a script that would take all the sources and patches that one needed to run a reasonable mail server, and turn them into an RPM that could be installed, because I couldn't just provide the patched, resulting RPMs.

There were a lot of great things about qmail. I really liked the envdir and how secure it was. But eventually I found the attitude behind it very tiring and switched to Postfix, which is a really great program.

Yes, for a long time it's been the case that to run qmail you have to really really want to run qmail. That's why I put so much effort for so many years into cross-platform packages of qmail in pkgsrc, and that's why we have "Meeting all common needs with OS-provided packages" as an explicit goal for the notqmail project.

The question is if notqmail isn't a bit too late. I'm maintaining a qmail setup for a customer and the amount of duct tape we've put on that thing is rather ridiculous. As it is now, I'd rather replace the whole thing with a regular Postfix/Dovecot setup and be done with it.

> As it is now, I'd rather replace the whole thing with a regular Postfix/Dovecot setup and be done with it.

Any reason why you don't (can't?)?

The customer won't allow any non-security related changes to the platform. That's the only reason.

Reply on news.ycombinator.com