Today is a sad day, and it is sadder still that I feel I should write this article.
Many years ago, when we were all much younger, the skys were cleaner and bluer, kids went outside to play in the street instead of staring at a flickering 14" tv and playstation, you could leave your door unlatched and we all used Sendmail as our MTAs. Life was good.
Then Bad Stuff[tm] started happening, we started getting spams, and sendmail was found wanting in the security dept many times. There were alternatives popping up, but when you are hooked into also providing UUCP feeds, your options are extremely limited.
Then in 1997 I discovered Qmail, with the promise of security, modularisation and simpler administration. So I launched headlong into replacing our sendmail install with Qmail. I ended up with a functional hybrid of installing Sendmail for UUCP and overlaying Qmail to do the SMTP/POP3. All in all this worked well for many years while we weaned everyone off UUCP.
So, why am I saying Qmail is dying, and who am I to make such an assertion? Perhaps a few credentials are in order. I was a reasonably early adopter of Qmail back in 1997 and when I started there were no documents or howtos on setting it up in an ISP type environment. All you had was DJB's INSTALL file, which was a pretty basic set-up for system account users. The man pages were pretty poor and involved a spot of trial and error to work out many things. To this end, I wrote the first published document on setting up Qmail, called the Qmail Single UID Howto which has been used by thousands (if emails are anything to go by) of sysadmins around the world.
Up until a couple of weeks ago, I continued in my die-hard attitude of Qmail can do anything, but increasingly of late, I have found it harder and harder to do what I need it to do. Yes, we can all hook in spamassassin and antivirus scanners, but other more fringe issues just aren't there yet. Specifically a test install of greylisting using greylisting-spp and qmail-spp (which incidentally looks like a great system that needs greater buy in from the Qmail community) refused to let qmail processes exit and sucked cpu - solidly killing my colo server. I had to drop the qmail-spp and greylisting idea.
Next up is SpamCop. Now I'm no great fan of SpamCop's arbitrary "we say it is bad so you must obey" style, but Qmail's architecture falls fowl of one of SpamCop's rules that says you should not accept email for a user that doesn't exist. With the deluge of spam (with forged smtp envelope sender addresses) the net result is Qmail will say 'Sure send me the email' but reject it at the local delivery stage causing a bounce to be sent back to the envelope sender address. SpamCop deems this as "spamming" the poor unfortunate schmuck who's email address was Joe-Jobbed to send you the spam. Worse, Spamcop has several "traps" set up that will cause your mail server to be automatically placed onto their blacklist if a trap receives any such bounces. Qmail simply doesn't do recipient verification in qmail-smtpd (which is why qmail never supported VRFY, ever).
Added to this, again in my opinion, Qmail's author Daniel J Bernstein has effectively signed Qmail's own death warrant by (1) Not supporting qmail in the past several years, and (2) Refusing to donate the code out to the community under say a GPL or Apache style license. I am not disputing his right to do so. Dan is perfectly within his rights to retain his code. I am simply stating that the current position means anyone with plans on using Qmail will find themselves less and less supported to the point that maintaining Qmail systems (evolving with the times, e.g. adding IMAP, or the next big thing) becomes an untenable proposition. That said, I have a lot of respect for Dan and his achievements and the quality of his work.
I also do not want to use this article to promote any alternatives to Qmail. Not out of fear of being called a fan-boy (I believe, if anything I have proven I was big proponent of Qmail), I am simply mourning the passing of, what was, a great MTA. Suffice to say, there are now much better supported systems out there.
Qmail, R.I.P. I shall miss you.
Edit: If you came here from the qmail at eight criticism of this article, please read my response.
Many years ago, when we were all much younger, the skys were cleaner and bluer, kids went outside to play in the street instead of staring at a flickering 14" tv and playstation, you could leave your door unlatched and we all used Sendmail as our MTAs. Life was good.
Then Bad Stuff[tm] started happening, we started getting spams, and sendmail was found wanting in the security dept many times. There were alternatives popping up, but when you are hooked into also providing UUCP feeds, your options are extremely limited.
Then in 1997 I discovered Qmail, with the promise of security, modularisation and simpler administration. So I launched headlong into replacing our sendmail install with Qmail. I ended up with a functional hybrid of installing Sendmail for UUCP and overlaying Qmail to do the SMTP/POP3. All in all this worked well for many years while we weaned everyone off UUCP.
So, why am I saying Qmail is dying, and who am I to make such an assertion? Perhaps a few credentials are in order. I was a reasonably early adopter of Qmail back in 1997 and when I started there were no documents or howtos on setting it up in an ISP type environment. All you had was DJB's INSTALL file, which was a pretty basic set-up for system account users. The man pages were pretty poor and involved a spot of trial and error to work out many things. To this end, I wrote the first published document on setting up Qmail, called the Qmail Single UID Howto which has been used by thousands (if emails are anything to go by) of sysadmins around the world.
Up until a couple of weeks ago, I continued in my die-hard attitude of Qmail can do anything, but increasingly of late, I have found it harder and harder to do what I need it to do. Yes, we can all hook in spamassassin and antivirus scanners, but other more fringe issues just aren't there yet. Specifically a test install of greylisting using greylisting-spp and qmail-spp (which incidentally looks like a great system that needs greater buy in from the Qmail community) refused to let qmail processes exit and sucked cpu - solidly killing my colo server. I had to drop the qmail-spp and greylisting idea.
Next up is SpamCop. Now I'm no great fan of SpamCop's arbitrary "we say it is bad so you must obey" style, but Qmail's architecture falls fowl of one of SpamCop's rules that says you should not accept email for a user that doesn't exist. With the deluge of spam (with forged smtp envelope sender addresses) the net result is Qmail will say 'Sure send me the email' but reject it at the local delivery stage causing a bounce to be sent back to the envelope sender address. SpamCop deems this as "spamming" the poor unfortunate schmuck who's email address was Joe-Jobbed to send you the spam. Worse, Spamcop has several "traps" set up that will cause your mail server to be automatically placed onto their blacklist if a trap receives any such bounces. Qmail simply doesn't do recipient verification in qmail-smtpd (which is why qmail never supported VRFY, ever).
Added to this, again in my opinion, Qmail's author Daniel J Bernstein has effectively signed Qmail's own death warrant by (1) Not supporting qmail in the past several years, and (2) Refusing to donate the code out to the community under say a GPL or Apache style license. I am not disputing his right to do so. Dan is perfectly within his rights to retain his code. I am simply stating that the current position means anyone with plans on using Qmail will find themselves less and less supported to the point that maintaining Qmail systems (evolving with the times, e.g. adding IMAP, or the next big thing) becomes an untenable proposition. That said, I have a lot of respect for Dan and his achievements and the quality of his work.
I also do not want to use this article to promote any alternatives to Qmail. Not out of fear of being called a fan-boy (I believe, if anything I have proven I was big proponent of Qmail), I am simply mourning the passing of, what was, a great MTA. Suffice to say, there are now much better supported systems out there.
Qmail, R.I.P. I shall miss you.
Edit: If you came here from the qmail at eight criticism of this article, please read my response.
![General [rss]](http://pgregg.com/mt-static//images/status_icons/feed.gif){kind=icon}
I have to say that qmail is dead. When you haven't released any updates, patches, or new files in say a year and 1/2 in the computer world (2005-10-26 is the date on the djbware.csi.hu/SOURCES ftp server), then you're not looking to improve your product, nor for that matter support it. Postfix has come very far in that time. It's what I've migrated to from qmail.
Hi Paul,
Well, DJB's licencing terms are certaintly holding back the qmail MTA these days. This is unfortunate, because as you say, this is DJB's right. qmail is(was?) actually quite a good product at it's core.
The Licence has fractured development efforts, and so additional software & patches aren't as well developed & tested as they should be. In fact, there's every chance that qmail patches don't necessarily live up to the security aims of qmail-proper.
Regarding greylisting, if qmail-spp is buggy or not well enough developed, there is only one other option that I am aware of. This is a perl-based replacement for qmail-smtpd, qpsmtpd, which is extendible through plugins, one of which handles greylisting. My main concern here is performance/scalability - I've not tested qpsmtpd, however perl rings a few alarm bells on this score.
Anyways, qmail's not dead *yet*. To survive, it badly needs a changed software licence, and a centralised support/development effort.
XW
Hi,
my humble opinion is that there is only one solution. Rewrite qmail and give it mainstream license. I myself prefer BSD license, if you ask me, but GPL will be fine as well. I am working with qmail several years now and I really think this is the only solution. If it's not going to happend soon, I'll have to switch to postfix on servers, which require complex configuration. PITA.
Yours,
r.
Paul,
I have about 6 new machines to set up for a new web-hosting client. I have always set up Qmail, but havent done it in several years, since I sold my ISP in 2000.
Im thinking this is the time to make a break from Qmail, since its a fresh start and new install. Learning curve vs a re-learning curve. What SMTP and MTAs should I be looking at? postfix has been suggested, but I remember its early days, and frankly it sucked.
Any opinion?
Hi,
I am new to qmail, basically I am trying to setup email on a remote access fedora server that I did not install or originally configure. This has been a nightmare. Qmail has very little documentation and when having to add hundreds of users at a time it has proven to be less than capable. For instance there is no command that I can just pass off to my programmer to write a script to automatically add users I instead have to modify 3 files, and if there is a command no one seems to know it. Frustrations aside, there has to be a better way of administering qmail, and without a little more open minded thinking that may never happen.
I'm using qmail (netqmail-1.05) with vpopmail right now and exploring ways to benefit from my current setup while being able to use new technologies via plugins.
Specifically, I'm looking at qmail-smtp replacements that can leverage all my current settings.
Qpsmtpd looks very good but I was worried about performance. But two solutions exist to prevent the need for perl interpreter startup cost:
1. use pperl (persistent perl which turns normal perl scripts into daemons)
2. use Apache's mod_perl
I'm going to try using pperl since that only involves changing 1 line at the top of the qpsmtpd perl script. This allows me to continue using djb's tcpserver.
There's even a plugin for qpsmtpd that allows the use of sendmail plugins (milter)--which means there will be well-tested and high-quality greylisting plugins for example.
Another possibility is magic-smtpd which I haven't explored yet. The pre-1.0 version number is kinda scary unless I find a decent number of deployments.
Hi!
Its very unfortunate that Qmail is loosing grounds
though its quite modular and scalable vertically and
horizontally.
DJB could have allowed to use his code in BSD style
or GPL style license. He did a great job of creating every
single peice of tools by himself and can work in "all" Unix like
boxes.
There is one way to save Qmail. User communities can re-write
Qmail like and makes that a GPL or BSD.
I'm skecptical that IBM is claiming Postfix is almost their product
and it has IBM "wrapper" sometimes.
I request through this forum that DJB can do something for making
Qmail evergreen.
Thanks,
S.Gopinath
<sgopi@bluebottle.com>
I have been using qmail for several years now and I have to say qmail is anything but dead.
1. Daniel Bernstein has released the source as public domain - literally you can do as you please with the source now.
2. As to the problems listed by Paul Gregg,
a) It has been updated as patches by several people, John Simpson's patch being the biggest and best out there.
b) Documentation is not too bad if you look at sites like Qmailrocks and Life with Qmail
c) As to spam and virus filtering filtering - qmail has one of the best filters - when coupled with the IP checking patch.
d) I have to agree with Paul though, it is not for the faint of heart. It has a steep learning curve.
Gurjar
I cannot say it is dead. According to the requests at http://rapid4me.com/ , people didn't stop looking for updates, patches etc... They continue using it!