[hippiefahrzeug]

I've followed a policy of using djb's software whenever possible over the years. Unfortunately qmail shows its age and may no longer be a good choice these days, but then again, who runs their own email server? :)

daemontools and ucspi-tcp are still some of the best tools to dig into. I love multilog (part of daemontools) which solves problems I didn't even know exist. e.g. I had a pool of servers and wanted to collect all the logs in one place... the way multilog names files makes this a simple rsync task, and you can just concatenate and sort, it even works for multi-lined output.

Since I started using docker, djb's tools got a new life for me. I manage all services within docker containers with daemontools.

[vidarh]

Qmail may show its age, but the overall structure is sound, and one the beautiful parts of qmail was/is how it isolated everything in their own processes intercommunicating via very simple protocols over file descriptors. So you could build far more complicated mail systems by starting with qmail and replacing parts as you went.

A company I co-founded used qmail for delivery for a webmail service for ~2m users, and while we used the original qmail less and less, it was because we were able to use qmail as scaffolding as described above.

And we ran lots of services under daemontools.

Later we used qmail as a generic message queueing system for a turnkey registrar platform for .name...

[voltagex_]

Are you able to expand on how qmail was used / not used? I didn't think it was something that could be easily modified like that

[vidarh]

In which context?

For the webmail provider, Qmail was used for all inbound/outgoing e-mail. Some modifications we made was to replace the delivery process with one that looked up the mail storage backend a given user was on and passed on the mail to qmails normal delivery process.

We also modified the delivery process to embed additional information in the message file names so that we could get away with just reading the directory to get file size (instead of additional stat() calls for each file), flag status etc.

Eventually we added quota checking and a cache of parsed header information (coupled with a custom command added to the POP server to list that info).

Qmail was ideal for that given that it consists of a bunch of small, easily understood components that all are documented extremely well and can be tested on the command line.

For the queueing system, any mail system works fine if your requirements does not include absolute ordering. All we needed to do was poll a Maildir (or POP server) to handle incoming messages, or inject outbound e-mail for outbound messages. It was fast and simple at a time when there was a distinct lack of open source dedicated queueing implementations.

[davvid]

Unfortunately qmail shows its age and may no longer be a good choice these days

Last I checked, Yahoo (Mail) uses qmail. Can anyone verify whether that is still true today?

[Arnt]

Yahoo advertises TLS support, so the bulk of the code Yahoo uses will be third-party extensions, perhaps openssl.

[blueskin_]

>who runs their own email server? :)

Anyone who cares about privacy? :)

Qmail is too old to be usable these days, but Postfix does at least use its security model. It isn't perfect, but arguably the best mail server around for that reason.

[nodata]

> who runs their own email server? :)

Hilary Clinton

[101914]

"Qmail is too old to be useable..."

With regard to age, both qmail and Postfix were written around 1998.

For my purposes, qmail works just fine. I use it; therefore it is "useable".

For me, Postfix is overkill. Not fact, just my opinion. Personal preference.

In the event I want to change something, I find it easier to modify and recompile qmail than I do to modify and recompile Postfix.

[ForHackernews]

> With regard to age, both qmail and Postfix were written around 1998.

Postfix has been updated (latest stable release February 8, 2015). Qmail doesn't get updated because DJB considers it complete (last [official] stable release June 15, 1998). There are custom third-party patches you can compile into qmail, so I guess those could be considered updates.

[blueskin_]

>Is this your opinion, or fact?

Well, it depends on the feature set you need, but to a level that most people might consider fact.

From memory, no support for TLS connections, SMTP AUTH, or SPF/DKIM on mail. That, plus it has very limited support in general and needs an arcane collection of patches to remain workable.

Other mail servers can work around its restrictions, yes, but that doesn't make it fit for purpose.