3 ms·

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 s

by dsr_ 7y ago

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!

sneak 7y ago
> 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.
- nailer 7y ago
  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.
linsomniac 7y ago
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.
- schmonz 7y ago
  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.
ahje 7y ago
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.
- throw0101a 7y ago
  > 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?)?
  - ahje 7y ago
    The customer won't allow any non-security related changes to the platform. That's the only reason.
d1zzy 7y ago
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 https://en.wikipedia.org/wiki/Daniel_J._Bernstein

by dsr_ 7y ago

sneak 7y ago

> 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.

nailer 7y ago
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.

linsomniac 7y ago

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.

schmonz 7y ago
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.

ahje 7y ago

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.

throw0101a 7y ago
> 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?)?
- ahje 7y ago
  The customer won't allow any non-security related changes to the platform. That's the only reason.

d1zzy 7y ago

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 https://en.wikipedia.org/wiki/Daniel_J._Bernstein