Hi Ron

Ron Guerin writes:

> There will probably always be gems in the archives that appear nowhere
> else.  But "search the archives" should only be the answer for very
> recent, or very obscure things that have yet to find their way into the
> documentation.  Archives should supplement documentation, not _be_
> documentation.

Again we're in perfect agreement - "search the archives" is good for
something that's come up recently.  The vchkpw uninitialized buffer
causing authentication errors if you use courier-imap with authdaemond
is a very good example (and one that bit me).  I think you're right
about obscure stuff to the extent that an answer of "I think I saw somebody
mention something like that a few years ago" is better than no answer at
all, but I don't think that obscurity or unpopularity are, by themselves,
an excuse not to document something. It is my experience that if somebody 
asks it once then sooner or later somebody will ask it again, unless it's 
about a bug that has since been patched (and even then you may get people 
running old versions who didn't encounter the bug until recently).

I also know that in some quarters pre-canned scripts and good
documentation are frowned upon.  The theory being that mail is such
an important issue that you have to understand the mail system to
postgraduate level before you install it.  I don't think that is
a sensible attitude any more.  Most Linux distros come with sendmail
out of the box, it works and there are even (*spit*) GUI configurators
for those who need them.  Linux is never going to catch on as a desktop
OS without those GUI configurators.  MS Exchange, pile of steaming manure
that it is, is so simple to install that a monkey could do it.  OK, last
I heard, the default Exchange install left it an open relay and you had
to know about undocumented registry keys to prevent your Exchange server
being relay-raped, but everyone wants simplicity of installation.  Every
so often, my boss (who has learned to hate all things from MS through
bitter experience) moans about how long it takes us to figure out how
to get something up and running and maybe we should switch all our
servers to Windows.  For the average company wanting their own mail
server, it's cheaper to pay for Exchange with its bloated price and
bloated per-seat licensing than to pay somebody to figure out how to
install Linux, qmail, sqwebmail, etc.  Total cost of ownership is a
lot higher, but initial expenditure is lower and that's what usually

I see that qmail is falling in popularity simply because it is such
a pain to learn how to install and configure to do what you want.  It
might be the fastest, it might be the most reliable, but the learning
curve is a killer and the documentation is only slightly better than
"read the source and figure it out for yourself".  Add in the learning 
curves for sqwebmail, qmailadmin, vpopmail, etc., and the result is 
depressing.  If you're a big ISP who has hit scaleability problems then
the expenditure of learning qmail et al. is acceptable.  If you're a small 
ISP you're going to stick with sendmail (or Exchange if you're a small ISP 
who has never heard of Linux).

The bottom line is that the documentation MUST improve so that this
stuff remains viable for even large ISPs, let alone small ones.  I
expect that Red Hat would produce nice GUI configurators for qmail,
sqwebmail and the rest (going by Red Hat's recent performance they
would be somewhat broken) if only DJB would be a little more flexible.
I can understand why DJB wants to protect his reputation, especially in
light of Red Hat's most recent cock-ups causing the Gtk team much
undeserved criticism and hassle, but DJB's attitude will be the eventual
death of qmail. :(  What is needed for qmail to be viable in the long
term is for Red Hat to pay DJB to produce RPMs for them that they promise
not to tamper with in any way and to allow them to release RPMs containing
the popular patches after he's vetted them and to have the install
process explain that DJB vouches only for the unpatched version.

> It could be only a few of us will work on it sporadically.  And that's
> ok too.  The important thing is to get started on it.  I was going to
> fix some things for myself, and now I'm going to submit those fixes for
> everyone else's benefit.  It's how much of the code gets written in Free
> and Open software.  Someone who can, scratches an itch and makes it
> available to everyone else.

Hmmm, how about creating a CVS tree for the documentation.  If there's
no way of preventing documentation volunteers messing with the source
tree then it might have to be a separate CVS.  The overhead on the
development team would then only be giving volunteers access to the
documentation CVS and checking that submissions are close enough to
being correct to be accepted.

To kick if off, although it's not a vpopmail issue per se, I can
document how to get sqwebmail and qmailadmin working on a server running 
suexec.  Since Mr Sam has at least once implied that suexec doesn't work
and is unsupported (his reply was along the lines of "who told you that
you could use this with suexec") then this proposed documentation tree may
be the only home it will ever have.  And it does have a bearing on
some vpopmail users.  It certainly affects me because there's no way
my boss is going to allow our servers to run without suexec because
that would allow one of our clients to accidentally or maliciously trash
cgi-created data files of another client.  And yes, I do know most of the
ways suexec can be subverted, particularly the race hazards, but it's
still a lot better than having to leave directories world-writeable so
that the httpd process can create files in them.  A clever malicious user
can do damage if you're running suexec; a stupid user, whether through
malice or accident, can do damage if you're not using suexec.

Paul Allen
Softflare Support

Reply via email to