First before I write my scathing review about the future of QMAIL-LDAP let me say that Claudio did a great job with qmail-ldap and was instrumental in helping me get my cluster into production.
In a sentence: I spent about 4 months upgrading/migrating qmail-ldap and my "toaster" IMAP/SquirelMail/LDAP to new hardware/versions. I want to share my experience, and my opinions. Firstly, Daemon tools and the "DJB way" . The forced layout, I did not appreciate it. Daemon tools took extra time because of the way its write data inside its /service/whatever directory my deployment system does not like that. Members of our admin staff have left notes in the /etc/motd "Contact ed@ for more information on restarting". The courier run script that comes with qmail-ldap does not work with recent versions of courier, I gave up and used the courier rc script ( courier suggests this in the documentation). Other run scripts had defaults that were too low for production. I don't dislike daemontools but its just to much work vs a standard init script. The autorestart concept is nice, but we have nagios for auto restarts. Personally, I believe auto-restart scripts are hedging your bets. My old shop made custom software and used to believe in auto-restart scripts. My new shop never does this. We except software not to crash, and if it does we deal with it. IMHO this works much better. So in a nutshell, for the future strip out svc. Next, lack of a standard ./configure, I realized that historically the license prevented lots of stuff. I had to rebuild and deploy qmail-ldap 6 times setting different env variables until I got TLS working, it would have been marvelous if this was somehow auto detected. One more time because I had to enable dirmaker which does not make sense dirmaker is a script, if you don't want it leave it blank Secondly qmails patchyness. All the "toasters" patches, incomplete docs, wrong doc, would lead me down the wrong trail tracking patches I did not need or already built into qmail-ldap. Suddenly you get hit with a term like vpopmail, do i need this? Sounds like it. I know there are probably good docs and bundles out there but they are obfuscated and hidden behind all the bad stuff, and honestly since almost no ones deployment seems to be unpatched, so no one bundle is ever perfect for you. Updates, your average qmail-toaster is tons of software to track and update. This is a snipet from our deployment system: p FreeBSD-7.2/FreeBSD-7.2-amd64-daemontools-0.76.T p FreeBSD-7.2/FreeBSD-7.2-amd64-ucspi-tcp-0.88.T p FreeBSD-7.2/FreeBSD-7.2-amd64-djbdns-1.05.T p FreeBSD-7.2/FreeBSD-7.2-amd64-courier-authlib-0.62.4.T p FreeBSD-7.2/FreeBSD-7.2-amd64-courier-imap-4.5.1.T #p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03.T #p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03-ldap-deprecated.T #p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03-dirmake.T #p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03-tls.T #bad #p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03-tls-2.T #p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03-tls-3.T p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-ldap-1.03-patched.T p FreeBSD-7.2/FreeBSD-7.2-amd64-qmhandle-1.3.2.T p FreeBSD-7.2/FreeBSD-7.2-amd64-qmail-autoresponder-0.96.2_2.T p FreeBSD-7.2/FreeBSD-7.2-amd64-procmail-3.22.T p FreeBSD-7.2/FreeBSD-7.2-pop-before-smtp-1.42.T p FreeBSD-7.2/FreeBSD-7.2-amd64-qmailmrtg7-4.2.T # These are needed for the web stack p FreeBSD-7.2/FreeBSD-7.2-amd64-mhash-0.9.9.9.T p FreeBSD-7.2/FreeBSD-7.2-amd64-libmcrypt-2.5.7.T p FreeBSD-7.2/FreeBSD-7.2-amd64-mcrypt-2.6.4.T p FreeBSD-7.2/FreeBSD-7.2-amd64-imap-2007d.T p FreeBSD-7.2/FreeBSD-7.2-amd64-libxml2.2.7.3.T p FreeBSD-7.2/FreeBSD-7.2-amd64-httpd-2.2.11.T p FreeBSD-7.2/FreeBSD-7.2-amd64-php-5.3.0.T p FreeBSD-7.2/FreeBSD-7.2-amd64-mod_perl-2.0.4.T p FreeBSD-7.2/FreeBSD-7.2-amd64-squirrelmail-1.4.19.T p FreeBSD-7.2/FreeBSD-7.2-amd64-squirrelmail-plugins.T p FreeBSD-7.2/FreeBSD-7.2-amd64-ispell-3.3.02.T #ldap stack p FreeBSD-7.2/FreeBSD-7.2-amd64-db-4.7.25.T p FreeBSD-7.2/FreeBSD-7.2-amd64-openldap-2.4.20.T Not only is keeping this stack up to date hard, configuring is hard too. On one hand its great that components like the IMAP server are swappable, but on the other hand I need to have the LDAP configuration in multiple places squirrelmail, qmail, courier-authlib, moving ldap results in changing three sets of configuration files. Notice this configuration has no-anti-spam, we used an external service, that would likely be more configuration. Logs, logs are all over the place, qmail-logs, apache logs, syslogs. Troubleshooting can be quite a pain. And the deal breaker, front end to LDAP, php-admin? You are probably going to need to spin your own management application for LDAP. command line tools, web interface. Documentation, I had to write pages and pages of my own documentation for deployment specifics, plus all the information that was missing/hard to find on the internet, how to use "openssl -client to test tls smtp for example." All the patches I don't have! There are many cool patches out there like the channel patch etc. Its a big task, but now that qmail is public domain this patch tree can/should centralize. You can't ask a big corporation to use a patch from parts unknown that is not tested with other patches, that you find in someones http://site/~user . I have never used zimbra but I did setup Kerio at my old company, Kerio is not free but I would not consider it expensive. I can not speak for scalability but in terms of setup management and features I find it superior to qmail-ldap. Most of the problems above are NOT a problem. I could not suggest qmail-ldap to anyone who is not a unix+ldap whiz, for the reasons I slated above. We had this quote that people used to throw around "..because exchange requires a full time admin". Well it took me months to migrate our qmail-ldap, and because of some of the complications above only qmail+ldap admins can actually service the system in any way, people always come to me very often. Like I said, the stack has many components, I could not use ports/rpm/etc because they were not "patched right", and even if i could have used such a system, I would probably have to go through MAJOR testing before, I would feel safe with "rpm -u qmail". So in a sense I manage a complete "toaster" now. Id rather have one product and let it be someone else problem. I would say that our deployment is very scalable, front end mail servers, replicated ldap, Isilon clustered NFS mailstore, but the amount of effort it took was almost ludicrous. So what I think qmail-ldap needs nutshell: Utterly complete, clean documentation, from build, deployment, management, troubleshooting init scripts auto-tuning for larger deployments (i had an outage due to default concurrency being two low after upgrade) more ldap documentation and some front end (I know this is not qmail-ldap's place but the two things are married ) community working -together all the patches in one place, trusted tested, unit tests Otherwise qmail-ldap can never stack up to a clean finished product like kerio, or zimbra. Of course qmail-ldap is open source so it is unfair to compare it against commercial products, but I think to have a future it has to be viable against them.
