Digging Deeper into QMail

By Blane Warrene
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

I have included QMail in several posts in Open Sourcery over the last year. Frequently the discussion jumps to why QMail, unlike other peers, does not build in refinements and instead leaves the administrator to patch and patch to get to the same level as Postfix, Sendmail and others.

Being a longtime Sendmail user who started into QMail in late 2003 and 2004 for a few clients – I also went through a learning curve adjusting to building and tweaking it to meet requirements (and still am to some extent!).

I have learned to like QMail quite a bit – especially the use of tcpserver to selectively allow, ban with rejection messages or simply drop connections to the server outright. I also like the ease of using POP before SMTP and the ability to control how long IP addresses are cached for SMTP relaying.

A peer of mine, Oban Lambie, president of Brown Rice Internet and a seasoned system administrator who came from a sendmail background, looks at the manual patching differently than I tend to.

“Like most good things in life when the entry level bar is raised it almost always seems that the payoff is well worth it if you take the time to get over the bar,” he wrote to me.

“Qmail is admittedly trickier to install than Sendmail but the flexibility of Qmail always makes my job much easier. Qmail’s large user base, web based email account administration for both clients (Qmailadmin) and administrators (Vqadmin), ease of third party software integration (Spamassassin), and the intelligent layout of the configuration files and directories make it any easy choice for me whenever I configure a mail server.”

Definitely a QMail fan there, and he is one of the primary reasons I use it today. However – being curious as to why QMail did not simplify (at least in the view of some commenters and my own) a build with many of the manual patches built in for ease of deployment and configuration, I went to the source and queried D.J. Bernstein with some of these questions.

I have to assume the lack of response after a month is due to:

  • He thought – “Who the hell is this guy anyway?” ;>),
  • Bernstein appears to be involved in quite a bit of various projects, and probably gets a kabillion emails of this nature and/or,
  • His philosophy simply does not agree with our wishes.

Well – that is perfectly fine – nobody necessarily wants people telling you how to build your applications. However, when you go open source – expect input of both a strong and weak nature. We are looking for some convenience and Bernstein is trying to build robust and secure software. When the two intertwine – it can sometimes cause issues as we have seen in other software large and small.

My questions were fairly simple and non-challenging:

1) Being licensed under a “standards” type license – where the source code can be shared ‘unmodified’ with any improvements supplied as patches (thus our current discussion) – is there any point where those most popular patches might get reviewed and made gold – being included in a future distribution as part of the source?

2) As he ‘appears’ to be the sole proprieter of the QMail code base, is there a succession plan for when he either willingly or unwillingly is no longer managing the source?

3) In 2001, Bernstein claimed more than 700,000 systems worldwide were running QMail. Where do we stand now?

Being a Qmail fan, and obviously there are plenty of other fans, I do hope to get answers on these at some point. Perhaps some readers who have worked closer to QMail development or the project’s developer community will share some insight.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • andre

    qmail being good but owned by just a single person is not a very comforting idea to me. i prefer postfix to it. i’m not very comfortable with patching qmail galore just to get features into it.

    don’t get me wrong — technically qmail is GREAT but i do hope DJB will start to open things up. but that may be just like wishing upon a star.

  • Dave Sill

    Hi, Blane. My qmail Google Alert brought me here. I don’t speak for Dan, but I’ll give it a try anyway.

    Yes, Dan’s a busy fellow. His teaching and cryptography research seem to be getting most of his attention these days and qmail is definitely on the back burner. Also, your questions have all been discussed on the qmail mailing list.

    Since qmail 1.x is “done”, any improvements made to qmail would likely only happen in a 2.x release, on which Dan has done some work, but doesn’t seem to be forthcoming. A group of qmail users, myself included, has assembled a unified patch set called netqmail that includes fixes for all known bugs and portability issues, as well as one minor feature that has Dan’s unofficial blessing (support for the QMAILQUEUE environment variable). This is by no means a “kitchen sink” patch set, though those are available, too.

    Dan hasn’t announced a succession plan, but there’s no reason other would-be maintainers/improvers couldn’t adopt the netqmail model of distributing the qmail 1.03 tarball along with patches and a script that applies the patches automatically.

    Dan hasn’t published an SMTP survey recently so I don’t know where qmail stands in the big popularity contest.

    Hope this helps.


  • Thanks a bunch for sounding in Dave – and hope a roadmap gets a little clearer for QMail going forward. I will asbolutely have to test out netqmail on an upcoming set of server builds I am doing this month.

    I think a new SMTP survey would be valuable – if the numbers continue to grow into the stratosphere – we very well may see some future planning become a reality based on user demand.