16 ms·

This. Qmail was the lighter option in between, along with some strong security guarantees, and for a while was used by some of the biggest mtas in the world. T

This. Qmail was the lighter option in between, along with some strong security guarantees, and for a while was used by some of the biggest mtas in the world. Then it failed to keep up in the war against spam and it became completely irrelevant and postfix took its place as the sendmail alternative/replacement.

habibur 4y ago
This. Qmail was lightweight. Postfix was considered robust but reliable without security holes. And then at some point postfix took over qmail as the default.
- vbernat 4y ago
  Qmail was undistributable and there were several set of patches to choose from as it was not accepting any contribution.
vidarh 4y ago
I ran "qmail" for ~2 million mailboxes, and the greatest appeal with qmail was that the design made it trivial to replace anything. Hence the quotes. We started out with near-pure qmail, and ended up replacing or modifying component by component because there was a well-defined API between each piece. Spam was never the issue for us - tieing things in with filtering was not a problem. I think the bigger problem for qmail was that because of the licensing, you pretty much had to patch qmail, which meant you needed developers happy to effectively maintain your own version or at least patch sets. If you were building your own mail infrastructure (we were - we ran a webmail provider until we sold of that bit), that was fine and it was a good scaffold while you customised what you needed, but if you just wanted to run a mail server and it wasn't your core business it very quickly stopped making sense to deal with that hassle. It's a real shame, but a good example of how license choice can affect things...
- stormbrew 4y ago
  > I think the bigger problem for qmail was that because of the licensing, you pretty much had to patch qmail This is - indirectly - exactly what I was referring to. Most of the patches people had to apply to qmail, in order to be a good netizen, had to do with spam either directly or indirectly. First because the design of qmail made it very difficult to stop backscatter by immediately failing undeliverable mail - out of the box it wanted to send a bounce for even the most obvious of errors. None of the patches for this were great. This made even running qmail as an incoming mail server only difficult and risky. And then of course the various anti-spam tech came along like rbl and the now-static qmail source had no support for it, and it was another place where you had to reject early. And this would all probably have been fine if the licensing hadn't let it sit for so long without a real fix to the fundamental architecture, with competing patches and so on. Since the licensing issue was resolved a long long time ago (more or less) a string of maintainers have popped up to keep it alive with another name for a year or two at a time but I can't imagine standing it up fresh now. Absolutely agree on the strengths though, it's almost certainly why it was so successful at scale for a while. Postfix feels clunky to me by comparison.

habibur 4y ago

This. Qmail was lightweight. Postfix was considered robust but reliable without security holes. And then at some point postfix took over qmail as the default.

vbernat 4y ago
Qmail was undistributable and there were several set of patches to choose from as it was not accepting any contribution.

vidarh 4y ago

I ran "qmail" for ~2 million mailboxes, and the greatest appeal with qmail was that the design made it trivial to replace anything. Hence the quotes. We started out with near-pure qmail, and ended up replacing or modifying component by component because there was a well-defined API between each piece. Spam was never the issue for us - tieing things in with filtering was not a problem. I think the bigger problem for qmail was that because of the licensing, you pretty much had to patch qmail, which meant you needed developers happy to effectively maintain your own version or at least patch sets. If you were building your own mail infrastructure (we were - we ran a webmail provider until we sold of that bit), that was fine and it was a good scaffold while you customised what you needed, but if you just wanted to run a mail server and it wasn't your core business it very quickly stopped making sense to deal with that hassle. It's a real shame, but a good example of how license choice can affect things...

stormbrew 4y ago
> I think the bigger problem for qmail was that because of the licensing, you pretty much had to patch qmail This is - indirectly - exactly what I was referring to. Most of the patches people had to apply to qmail, in order to be a good netizen, had to do with spam either directly or indirectly. First because the design of qmail made it very difficult to stop backscatter by immediately failing undeliverable mail - out of the box it wanted to send a bounce for even the most obvious of errors. None of the patches for this were great. This made even running qmail as an incoming mail server only difficult and risky. And then of course the various anti-spam tech came along like rbl and the now-static qmail source had no support for it, and it was another place where you had to reject early. And this would all probably have been fine if the licensing hadn't let it sit for so long without a real fix to the fundamental architecture, with competing patches and so on. Since the licensing issue was resolved a long long time ago (more or less) a string of maintainers have popped up to keep it alive with another name for a year or two at a time but I can't imagine standing it up fresh now. Absolutely agree on the strengths though, it's almost certainly why it was so successful at scale for a while. Postfix feels clunky to me by comparison.