[pmoriarty]

My biggest takeaway from qmail has nothing to do with security, but rather that excessively restrictive licensing, highly opinionanted/unusual setup, and unwillingness to collaborate on its development squandered its potential.

If it wasn't for all that, we might well all be using qmail-based mail servers today, as qmail was really ahead of its time in so many ways.

It was kind of like the Amiga of mail servers, back in the day. It could have easily dominated the market, but it wound up a mere historical curiosity.

[geocar]

> …highly opinionanted/unusual setup…

That setup contributed to security.

It also made qmail very easy to extend: I operated a medium-sized mail service a while ago and qmail's pluggability meant I could add features that didn't exist in other mail servers (like postfix or exim) without forking the entire project.

* I had SMTP AUTH when the only other mail server to support it was Netscape; before RFC2554 was written.

* My qmail-popup proxied to another machine so it didn't need root (making me immune to the Guninski vulnerability) so my users only needed to know about a single hostname regardless of where their mail was stored, and without needing to use something icky like NFS.

* I had a web interface with auto-enrolled client certificates for authentication and confidentiality for SMTP, POP, and IMAP.

* My qmail-remote recognised certain suggestions our IP was being blacklisted and would retry immediately with a new IP.

* My qmail-remote recognised certain greylisting error messages and rescheduled retry for that time.

* I had multiple mail queues based on the number of retries the message had seen.

And so on. I didn't start out to make those features, they just grew over a decade or so organically. At no point would I have forked postfix or exim to add any of those features because once you fork it you own it unless you can get your changes upstream. I had shit to do, so the real alternative was simply buy more servers and/or pay for commercial software.

I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later...

> …and unwillingness to share and collaborate on its development…

Dan absolutely collaborated, and I certainly was using betas back in 1996.

If my memory/anecdote isn't enough: There are a number of explicit points of evidence in the changelog distributed with qmail.

What he doesn't do is let people save face when they say something incredibly stupid and then try to backpedal when it's obvious how wrong they are. This bruised more than a few egos, and contributed to a campaign to actively smear his name and discredit his software.

> It could have easily dominated the market…

I think if Dan had let the peanut gallery have their way, we probably wouldn't have gotten postfix, but then qmail wouldn't have been qmail except in name. What's the value in the qmail brand if it isn't secure anymore?

[Steeeve]

Having strong personal convictions about security and architecture was one of the primary reasons that tinydns and qmail were the staples that they were.

Yes, they have been feature locked for a long time. But let's not pretend that collaboration in 1996 was anything like it is today. And let's not pretend that there haven't been a plethora of security issues in all kinds of software that simply haven't befallen Bernsteins' software as a direct result of how he managed the projects.

I had the distinct impression that "dominating the market" was never a thought in his mind. He wrote the software he wanted to write and shared it. It was good software. It's still being used by many people.

The man isn't infallable. He isn't always right. But whenever I paid attention to him, he was right a lot more frequently than he was wrong.

The fact that he wasn't driven by dollars or market dominance was a good thing.

I, for one, admire the man and his software.

[oblio]

> I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later...

Can you elaborate?

[geocar]

Which part. The model? The article explained it well enough. I think of it as two main parts: (1) make fewer bugs, and (2) show your users the correct way to do things (which is the inverse of getting the correct requirements).

Or are you asking what took me fifteen years to understand?

Dan basically planned the whole thing. When the whole thing was too big, he would break off a piece that wasn't and develop it as a wholly separate thing.

I understood this strategy worked, but I didn't fully understand why this strategy was successful until I realised source code matters more than I thought[1]: If your program is short enough, there won't be any bugs in it. This is why learning how to read and write dense code[2] can make your programs better -- and that's what I learned how to do[3].

[1]: http://www.jsoftware.com/papers/tot.htm

[2]: http://www.nsl.com/papers/origins.htm

[3]: https://github.com/geocar/dash/blob/master/d.c#L62

[hursortue]

> learning how to read and write dense code

> and that's what I learned how to do

This is good code?

  for(i=b=0;i<r;++i){switch(p[i]){
  case'\n':if(!e)e=i;if(!q){q=kpn(p+w,g-w);if('\r'==(cf=p[i-1]))cf=p[i-2];}else if(!c){w=!!strchr("kK1",cf);if(!o)sc(d,0,sd);else if(w){if('g'==o)cwrite(f,OK("200","keep-alive")BLANK);else cwrite(f,OK("204","keep-alive")END204);}else{if('g'==o)cwrite(f,OK("200","close")BLANK);else cwrite(f,OK("204","close")END204);close(f);}a=k(o?-d:d,"dash",knk(2,q,xD(a,v),0),0,0);b=i+1;if(!o){if(!a){poop(f);R 0;}if(10!=a->t){r0(a);poop(f);R 0;}writer(f,kC(a),a->n);r0(a);if(!w)close(f);}if(b==r)R 1;q=0;o=0;a=ktn(11,0),v=ktn(0,0);}else{if((c-m)==10&& !strncasecmp(p+m,"connection",c-m))cf=p[s];js(&a,sn(p+m,c-m));jk(&v,kpn(p+s,e-s));}w=e=g=s=c=0;m=i+1;break;
  case' ':case'\t':case'\r':if(w&&!g)g=i;if(s==(e=i))++s;break;
  case':':if(!c)s=1+(c=i);break;
  case '/':if(!w)w=i+1;case '?':case '&':if(r>=(i+4)&&p[i+1]=='f'&&p[i+2]=='=')o=p[i+3];default: e=0;break;}}if(a)r0(a),r0(v);if(q)r0(q);R b;}

[fiddlerwoaroof]

That's how people with an APL background write C and it is, in fact, readable to those people: to me, however, it's gibberish

[geocar]

It could be shorter if I spent some more time on it.

[irundebian]

LMFAO

[b6]

I think you're missing something if that's what you got out of qmail. The main idea I internalized was, if you find yourself making programming mistakes, take some time to write an API that does not allow you to make that kind of mistake and commit to using it everywhere.

The licensing stuff, I'm not super clear on. If memory serves, DJB did not want to worry about bugs introduced by patches he'd never seen or approved, added by package maintainers for OSes he didn't use.

As for the somewhat weird ecosystem (daemontools), I think it wasn't that it wasn't good enough, it was just that people always find reasons to be dissatisfied. I can't even keep track of the latest reinvention of whatever people are using instead of daemontools, but I bet it's a hundred times as complex, and much less reliable.

[JdeBP]

The licensing stuff was simple: There wasn't a licence. Some people creatively misinterpreted M. Bernstein's page, explaining what one could do under the law in the U.S. as it stood even without a copyright licence, as a licence. But that was a misinterpretation.

* http://jdebp.eu./FGA/law-licence-free-softwares.html

Daemontools ironically wasn't weird at all, as evidenced by the fact that over the past almost two decades the daemontools world got us changes to softwares, all of those do not daemonize options that have appeared in that time as well as things like removing mysql_safe and other Poor Man's Dæmon Supervisors, that made it a lot easier to use those softwares with other service managers.

* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...

Some of the things that people use instead of daemontools are not much less reliable. (-:

* http://jdebp.eu./FGA/daemontools-family.html