Re: Future of Qmail-LDAP

>> Members of our admin staff have left notes in the /etc/motd "Contact
>> ed@ for more information on restarting".
>
> This is psychology, not technology.
>
Yes, but the fact is your have to train people and document things
like a startup procedure, which are usually simple. That is not
philosophy it is lost time. I think the low adoption of run scripts
speaks to its utility. That is my argument for the the replaced.

>>You could have been the one writing the book.

Maybe I will have to.

> So how would you deal with a crashing Apache, if you don't have daemon

My point, apache does not crash often for me neither does qmail. Thus
the auto-restart feature is not that useful. Couple that with my point
about training people. It is hard to get a package "blessed" by any
distro with svc if it does non standard things. That is going to hurt
the adoption of qmail thus hurting its future.

> Hmmm, rpm on FreeBSD? I hope not!

Obviously I do not do RPM on FreeBSD. My point was that thanks to the
"patchness" factor, I really can not use any package system.

> Then you should purchase a product or hire someone to implement
> something for you.
Regardless of me doing it myself or hiring someone,
time/money/resources is spent. In my opinion the "overhead" to run
this MTA is very high. I used the word ludicrous. I will stand by it.
Take for example SMTP TLS. Ideally during compile/make the mail server
should detect TLS and activate it. Would you agree that most MTA's
would do that? I should not have to pay money or spend more time
configuring a no-brainer feature.

> You're especially comparing qmail-ldap, which is mostly a pure mail
> transport agent, to a groupware package that includes a mail transport
> agent. Your arguments against qmail-ldap, from this perspective, apply
> the same way across all other classic unix mail transport agent
> packages, like Postfix, Sendmail and Exim, to name the biggest ones.
Agreed, that is unfair.

> You're only saying that nobody in your company deigned to learn
> qmail+ldap.

True, but many of the things I mentioned serve as a higher barrier to
entry.   Normaly ./configure && make && install && review mod the
configuration && init script. qmail and qmail-ldap hardly work that
way. The main issue as I mentioned is hunting down patches and through
bad documentation. I can give you a simple example, one searches
"daemontools"

Already I am confronted with:
http://thedjbway.b0llix.net/daemontools/installation.html
http://cr.yp.to/daemontools/install.html

What is this step?
ln -s /usr/local/package /package
Both people are setting up a different way.

This is mostly what i was getting at in terms of time and expense.
This is an issue for all open source projects but I find it
particularly bad for qmail, qmail-ldap has less specific documentation
then qmail.

Comparing qmail as an mta to a groupware app is probably unfair, as
you say. By hooking into ldap qmail-ldap presents itself as an
enterprise solution. After all, who needs LDAP integration except
large enterprises? The small documentation and the decentralized path
management is a detraction in that area IMHO.