25 years of Postfix
As a few on this list may recall, it is 25 years ago today that the "IBM secure mailer" had its public beta release. This was accompanied by a nice article in the New York Times business section.There is some literature at https://www.postfix.org/press.html that attests how this project accelerated open-source adoption by a very large company.
That release was even noticed by a small publication in its first year of operation.
(Thanks to Kees van Vloten.)
Posted Dec 17, 2023 10:07 UTC (Sun)
by dsommers (subscriber, #55274)
[Link]
> At least one person is raising red flags about IBM's recent open source announcements. Greg Aharonian of the "Internet Patent News Service" points out that, while IBM has made Secure Mailer available, it has made no promises that people actually using Secure Mailer will not be subject to legal action for patent infringement. Software patents in the U.S. are a big problem, and the issue is worth some thought. See Greg's message to see why he thinks we should be concerned.
That illustrates quite well how the whole IT industry has moved to embrace Open Source as a possibility for growth and innovation and not being a threat to your own business.
Those times where different. And IBM was a very different company, especially in regards to open source. So those concerns most likely were quite legit. This shows that IBM also has gone great lengths to embrace Open Source in a good way as well (I'm not claiming all of IBM is perfect now, but some parts of it has pulled the company in the right direction).
Posted Dec 18, 2023 9:04 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (18 responses)
qmail died out after version 1.03, I think, because of
qmail and DJB did make one contribution that has outlasted qmail: the maildir format which is now widely preferred, including by postfix.
Posted Dec 18, 2023 11:05 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (6 responses)
Posted Dec 18, 2023 23:10 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (5 responses)
IIRC, exim appeared a little earlier than Postfix and qmail, as a “better Sendmail” with a less obtuse configuration mechanism.
The main reason exim (rather than Postfix) is the default MTA in Debian GNU/Linux is that when the project was looking for a Sendmail replacement, Postfix wasn't quite ready yet and exim looked like the best option at the time. In the meantime nobody has had the stomach to revisit that decision seriously, especially since exim – certainly as a minimally-configured default setup – is an absolutely reasonable MTA and on Debian, replacing it with Postfix is a fairly trivial exercise for people who are that way inclined.
Posted Dec 19, 2023 7:48 UTC (Tue)
by joib (subscriber, #8541)
[Link] (1 responses)
Posted Dec 19, 2023 10:01 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Traditionally a Linux system would have to have some sort of MTA in order to, e.g., allow the likes of cron to send notifications to local users, even if the machine never received or sent anything from or to other machines. Back in the day, the notion of a “minimal MTA” didn't really exist, so Linux distributions would default to something like a minimally-configured Sendmail.
Presumably Debian could do what FreeBSD is doing, but in the grand scheme of things, exim works, it impacts the typical Debian system a lot less than it used to (relatively speaking), and it is very easy to replace with something else out of the wide selection of minimal and not-so-minimal MTAs that the distribution offers. It comes as no big surprise that nobody really wants to go through the hassle of changing the MTA default, because even in 2023 that would probably spark a huge religious dispute that creates a lot of heat and acrimony and helps nobody.
Posted Dec 19, 2023 10:40 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
Yes, exim is older than postfix and qmail, and friendlier than sendmail, but its security record is not vastly better. It comes from Cambridge University. I think our place uses it because it comes with Debian, and when they first set it up, postfix and qmail were too new. After that it's inertia. A quarter century of config settings that nobody wants to redo.
Posted Dec 20, 2023 17:10 UTC (Wed)
by ewx (subscriber, #103004)
[Link]
Posted Dec 21, 2023 0:49 UTC (Thu)
by epg (guest, #34047)
[Link]
Posted Dec 18, 2023 23:01 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (10 responses)
Unlike Postfix, qmail had a fairly toxic community (certainly here in Germany). Woe betide you if you came on the USENET group and didn't have the documentation and previous traffic memorised (or, even better, the source code). The place was teeming with DJB wannabes. The Postfix people, OTOH, were a lot more accommodating. In general, as is so often the case in open-source software, you were either a dyed-in-the-wool dedicated qmail fan or you detested it with some vigour; there wasn't a lot of middle ground.
The other issue with qmail was that DJB had some fairly idiosyncratic ideas, e.g., about where its configuration files should go, and of course, with DJB being DJB and adamantly insisting on being always right by definition, that created issues with Linux distributions such as Debian which had their own policies for configuration files. Since qmail with its weird approach to licensing couldn't be included in Debian as a policy-compliant binary – you were only allowed to distribute binaries derived from DJB's original sources –, the Debian qmail package essentially worked by downloading the qmail source code and patching, compiling, and installing it locally to get around that restriction and adhere to Debian policy.
In the meantime DJB has contributed qmail to the public domain, which should take care of the licensing issues. Various people have tried to extend it to be able to deal with modern email features but even so it seems to have withered on the vine – there are probably pockets of very dedicated qmail users out there somewhere, but other MTAs, especially Postfix and Exim, seem to be way more popular. Qmail's main selling points used to be security and speed, but over the years it acquired its share of CVEs (certainly so after DJB was done with it) to a point where it now doesn't look a lot better or worse than the competition. Architecturally, like Postfix, qmail consists of a fleet of minimally-privileged processes that distrust one another, and that is part of its appeal vis-à-vis more traditional, all-in-one-process-potentially-running-as-root MTAs such as Sendmail or Exim; it did pioneer some very interesting ideas which have since found their way into the mainstream, but overall I would personally prefer Postfix any day of the week, thank you.
Posted Dec 19, 2023 8:05 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (9 responses)
The toxic community wasn't limited to Germany but also there was really helpful folks and excellent guides out there. Shout out to http://www.lifewithqmail.org/. It's a shame that the restrictive licensing of qmail at that time required this guide in the first place however and it is the only upstream I have seen that recommended a bunch of patches as seen in http://qmail.org/top.html#patches. Running email servers remains a nightmare for other reasons but atleast Postfix and Exim are readily installable in distributions and have sane configuration that doesn't require compiling from source with a cottage industry of patches floating around.
Posted Dec 19, 2023 9:25 UTC (Tue)
by brunowolff (guest, #71160)
[Link] (6 responses)
Posted Dec 19, 2023 10:18 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (5 responses)
Qmail also tended to make itself unpopular by trying to deliver n messages to the same remote MTA in parallel using n SMTP connections, rather than sequentially across the same SMTP connection.
Like maildirs, VERP support and flexible forwarding and aliasing were among the qmail features that the other big MTAs took on board fairly rapidly. (VERP – which may really have been an ezmlm, rather than qmail, thing – is a bit of a two-edged sword; while it is useful for processing bounces, without it, if you have a big mailing list with 100 recipients on the same remote site, you could send 100 RCPT TO commands and then one copy of the body, but with it, you would have to send 100 separate copies of the same message each with a different MAIL FROM. Of course, these days, sending the same message to 100 recipients on the same remote site would probably get you into trouble as a prospective spammer, but that's a different story.)
Qmail did have its share of clever ideas, but it was missing important features – or in any case features that the rest of the MTA community considered important but that DJB didn't agree with, or that only rose to importance after DJB was mostly done with qmail development – and implementations of these for qmail, if they existed, were often a hassle to find and add. In later years there used to be curated collections of patches one would need to apply to make qmail actually usable, and by now there are semi-official beefed-up releases of public-domain qmail, but the MTA caravan has moved on and these are mostly of interest to die-hard qmail devotees.
Posted Dec 19, 2023 10:56 UTC (Tue)
by brunowolff (guest, #71160)
[Link] (4 responses)
VERP is part of qmail proper, and is used by ezmlm.
And yes, VERP has some disadvantages when dealing with large messages. In those days, large messages were rarer. And mailing lists typically didn't get used for large messages either, so it generally worked well.
As someone who has to deal with Microsoft 365 removing attachments, rewriting links in message bodies and auto replies used for out of office messages being sent to the from address instead of the envelope sender address, at work, I think qmail is better than at least some of the popular mail systems today. (Though people would probably insist on having it be modified to corrupt messages as well, in the name of security.)
Posted Dec 19, 2023 11:04 UTC (Tue)
by brunowolff (guest, #71160)
[Link]
Posted Dec 19, 2023 20:22 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
Which program is supposed to send the "out of office"? If it's the mail CLIENT, it doesn't have access to the envelope sender? So it's going to send it to the "From" address, because that's the only address it's got.
While the MTA - which does have access to the envelope address - surely shouldn't be sending an OoO?
Cheers,
Posted Dec 19, 2023 20:33 UTC (Tue)
by fenncruz (subscriber, #81417)
[Link]
Posted Dec 20, 2023 1:22 UTC (Wed)
by brunowolff (guest, #71160)
[Link]
Posted Dec 19, 2023 10:38 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
Just a note that qmail.org isn't the upstream, it is an independent site. The upstream is https://cr.yp.to/qmail.html
There are a couple of forks that continue to be maintained (s/qmail and notqmail, as opposed to netqmail) but probably of interest only to a few die-hards.
Posted Dec 20, 2023 5:26 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Postfix was also very new at the time but has matured and exceeded qmail in every way and is certainly a worthy default with a great track record for performance and security.
25 years of Postfix
I remember two "ultra-secure" mailserver programs that emerged at the same time (late 1990s), postfix and qmail, in answer to the security nightmare that was sendmail. I even set up qmail on some small systems, its configuration was dead simple and it came with some basic but useful mailing list software (ezmlm).
25 years of Postfix
Kudos to Venema for keeping postfix going, and keeping it relevant, all these years. I still use it to forward mail from my desktop to our mail gateway (switched from qmail about 15 years ago). My workplace uses exim.
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
The built in VERP support and flexible forwarding and aliasing was nice. Not being able to reject most invalid recipients before accepting responsibility for delivery turned out to be a problem, once spam took off.
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix
Wol
25 years of Postfix
25 years of Postfix
25 years of Postfix
25 years of Postfix