Notqmail: Collaborative open-source successor to qmail | Hacker News Reader

Notqmail: Collaborative open-source successor to qmail

github.com

64 pointszdw30 comments

Notqmail is a fork of Qmail, which "begins where netqmail left off".

A good description of their goals can be found on the wiki:

* https://github.com/notqmail/notqmail/wiki

> [Notqmail] will provide stable, compatible, small releases that do not conflict with or break your local site customization or the other software you run in your mail system. notqmail also aims higher: we are developing a qmail-derived system that is extensible, easily packaged, and increasingly applicable to a wide variety of modern needs

An idea of upcoming changes can be found on the roadmap:

* https://github.com/notqmail/notqmail/wiki/Release-Roadmap

There's also an interesting discussion of Notqmail, with responses from many of the team, on Lobste.rs:

* https://lobste.rs/s/2r3stk/notqmail_collaborative_open_sourc...

The release philosophy conflict is interesting. Very rarely do we see "finished" software, but the current "official release" version of qmail was released on June, 15, 1998. This is basically due to DJB's insistence on avoiding bugs by taking the UNIX philosophy as far as possible; everything is done by a small set of processes communicating over pipes, and the attack surface kept very small.

The downside is its limited integration with other systems and especially databases. If you want to configure qmail, it has to be through text files. But if you want to operate one of the common cases of a relay-only host or a single UNIX host delivering mail to its local users, it works very well.

Extensibility is [an explicit goal](https://github.com/notqmail/notqmail/wiki#goals), for reasons such as these. If we introduce some more small interfaces -- 1998 qmail was already ripe with examples -- we'll make it easy for anyone to program extensions. If we make it easy for folks to program extensions, we may find there lots of common extensions available. That's the hope, anyway :-)

Somewhat related, have there any updates or a forked version of daemontools?

https://en.m.wikipedia.org/wiki/Daemontools

http://cr.yp.to/daemontools.html

I’ve been using parts of it for many many years without issue but it does feel odd that nothing has required an update in nearly 20 years. Maybe the Unix philosophy and DJB is just that good!

runit is a modern rewrite folling djb's principals... http://smarden.org/runit/

I use runit for pretty much everything now, I love it, no need to worry about if you're running BSD rc, systemd or sysvinit, there's always a runit package available that integrates with it and it handles logging so nicely.

We still use it under systemd to run our services. I don't trust systemd to work reliably.

Daemontools-encore is a fork with minor feature updates, and there's also a whole ecosystem of choices like Runit, S6, and nosh to look at if you're really interested.

runit is the modern alternative, I guess. But things like this are very simple so I'd be surprised if they needed updates - or rewrites.

   diff -Nur admin.orig/daemontools-0.76/src/supervise.c admin/daemontools-0.76/src/supervise.c
   --- admin.orig/daemontools-0.76/src/supervise.c 2010-02-19 11:08:15.000000000 +0100
   +++ admin/daemontools-0.76/src/supervise.c 2010-02-19 12:53:16.000000000 +0100
   @@ -86,6 +86,8 @@
    
    const char *run[2] = { "./run", 0 };
    
   +int flagfailed = 0;
   +
    void trystart(void)
    {
      int f;
   @@ -94,6 +96,7 @@
        case -1:
          strerr_warn4(WARNING,"unable to fork for ",dir,", sleeping 60 seconds: ",&strerr_sys);
          deepsleep(60);
   +      flagfailed = 1;
          trigger();
          return;
        case 0:
   @@ -153,6 +156,11 @@
          }
        }
    
   +    if (flagfailed && flagwant && flagwantup){
   +      flagfailed = 0;
   +      trystart();
   +    }
   +
        if (read(fdcontrol,&ch,1) == 1)
          switch(ch) {
    case 'd':
   diff -Nur admin.orig/daemontools-0.76/src/supervise.c admin/daemontools-0.76/src/supervise.c
   --- admin.orig/daemontools-0.76/src/supervise.c 2001-07-12 18:49:49.000000000 +0200
   +++ admin/daemontools-0.76/src/supervise.c 2012-12-23 21:54:20.437771704 +0100
   @@ -97,6 +97,8 @@
          trigger();
          return;
        case 0:
   +      setsid();
   +      setpgid(0,0);
          sig_uncatch(sig_child);
          sig_unblock(sig_child);
          execve(*run,run,environ);
   @@ -158,7 +160,7 @@
    case 'd':
      flagwant = 1;
      flagwantup = 0;
   -  if (pid) { kill(pid,SIGTERM); kill(pid,SIGCONT); flagpaused = 0; }
   +  if (pid) { killpg(pid,SIGTERM); killpg(pid,SIGCONT); flagpaused = 0; }
      announce();
      break;
    case 'u':
   @@ -173,29 +175,29 @@
      if (!pid) trystart();
      break;
    case 'a':
   -  if (pid) kill(pid,SIGALRM);
   +  if (pid) killpg(pid,SIGALRM);
      break;
    case 'h':
   -  if (pid) kill(pid,SIGHUP);
   +  if (pid) killpg(pid,SIGHUP);
      break;
    case 'k':
   -  if (pid) kill(pid,SIGKILL);
   +  if (pid) killpg(pid,SIGKILL);
      break;
    case 't':
   -  if (pid) kill(pid,SIGTERM);
   +  if (pid) killpg(pid,SIGTERM);
      break;
    case 'i':
   -  if (pid) kill(pid,SIGINT);
   +  if (pid) killpg(pid,SIGINT);
      break;
    case 'p':
      flagpaused = 1;
      announce();
   -  if (pid) kill(pid,SIGSTOP);
   +  if (pid) killpg(pid,SIGSTOP);
      break;
    case 'c':
      flagpaused = 0;
      announce();
   -  if (pid) kill(pid,SIGCONT);
   +  if (pid) killpg(pid,SIGCONT);
      break;
    case 'x':
      flagexit = 1;

Why killpg?

I suspect to kill all children and not rely on the parent you're supervising to clean up.

https://skarnet.org/software/s6/ is pretty much original daemontools with a couple additions

What is it that you want, which you're not getting? I also use and love daemontools. Stability is a feature.

Some others already mentioned runit which seems feature complete.

There is also s6, s6-rc and its associated tools, done in essentially the same spirit, micromanaged into the smallest possible units. At least it feels like that. Which leads to strange experiences if you lazily try to integrate them into your system, because they are so fast that you almost never see them appear in something like htop, not even as a short blip. Even on some small ARM idling at 200Mhz. One really has to watch the logs, and do it in a systematical way. But i like that. One of the rare pieces of software which don't make me aggressive or want to vomit, like very precise and exact clock work, or very good bicycle gearing. Silent and satisfying!

[1] http://skarnet.org/software/

Then there is

[2] http://web.obarun.org/software/

which is an attempt to ease that micromanagement from an archlinux derivative, which uses this instead of systemd.

Furthermore there is

[3] https://jdebp.eu/Softwares/nosh/

with the same goals, looking very impressive on paper, but written in C++? I don't know what to make of that. But probably try it out some time, even if only for the user space virtual terminal from there.

So... daemon tooling is far from dead!

This would be great if some of the excellent components that work with qmail to make a nice email appliance also got updated. qmail with vpopmail and qmailadmin used to make a great email appliance, but previously the overhead of maintaining it made it un-usable long term so I ditched it for postfix+dovecote+postfixadmin

but there was a lot to like about qmail+vpopmail+qmailadmin

I feel like everyone has moved on from qmail to postfix; I wonder who is still using qmail. I was a huge qmail fan back in the mid '90s, it was a breath of fresh air in comparison to sendmail. But by the 2000s it was feeling largely abandoned, had a lot of hoops you had to jump through, and Postfix was on the scene and had none of those disadvantages.

The last time I used qmail, it was quite a pain to collect up all the required patches and build, just to make a reliable MTA. I'm thinking things like the TCP DNS patch so you could send e-mail to AOL.

I realize netqmail came along later to try to fix this. I guess I had just assumed that everyone had moved on to postfix like I had.

I still run it happily.

Technically netqmail and with some other distribution (Gentoo) patches added, but I still happily use qmail.

(not related to Qmail... but...)

Anyone who used http://xmailserver.org/ ? The project looks dead for many years now. We used the software on production Mail servers for years. It was very-simple to setup and use, and also very-very flexible.

There is also forum https://xmailforum.marketmix.com/ . I loved to read the forum daily :) 10 years ago.

I think the last feature added vas SSL support, back then in 2010. For me this is a masterpiece of software when it comes to mail servers. (I loved the minimalistic approach)

The original qmail was widely known for being very secure and fast. This implementation on the other hand, is apparently marketed using warez slang?

> Netqmail 1.06 is produced by this motley krewe

Does using warez slang automatically make software less secure and slower?

It reduces confidence because warez is associated with running cracked software of which you don't know exactly what was modified/added/etc.

My how far we’ve come in such a short few years.

Eh, not sure what you mean, but yeah some DRM is obnoxious and almost spyware. Warden, World of Warcraft's DRM, is for example profiling your system hard.

It speaks to the priorities, attitude and / or the work ethics of the developers involved. I wouldn't trust people who care about using teenager slang and looking cool to write secure and efficient services that I could use in production with customer data. I may be wrong, but my confidence is still low.

"This implementation" is notqmail, which none of the netqmail people are involved in.

netqmail 1.06, which none of us notqmail people were involved in, was produced by a handful of people I have often referred to as "list elders". They were very informed, very conservative, and very careful.

Nothing wrong with heuristics. It's a busy world out there. I appreciate that you're aware you're using one here, and I thought you might like to know it's led you astray. As a notqmail developer, I hope we live up to the standards set by the netqmail folks.

What's with "netqmail" in the readme vs "notqmail" here and in the project name?

   README netqmail 1.06 4 years ago

I suppose the readme hasn't been edited yet.

   notqmail begins where netqmail left off

Yes, exactly right. One other PR left to merge, then we'll update the docs and cut 1.07.

Reply on news.ycombinator.com