Subject: Re: Microsoft: Closed source is more secure
From: Lynn Winebarger <>
Date: Thu, 3 May 2001 08:47:20 -0500

On Thursday 03 May 2001 02:23, Norbert Bollow wrote:
> Lynn Winebarger <> responded:
> > (a) personality of the author as seen in Internet postings (usenet/web
> > pages) (b) poor documentation, if qmail is any indicator
> > (c) odd way of writing source code, if qmail is any indicator
> > (d) odd build process, if qmail is any indicator
> > (e) odd license and infrequent updates to official source (if qmail
> > ....), which exacerbate the effects of b,c, and d.
> All of these are valid points even though they don't say
> anything against djbdns being a secure, very usable and
> RFC-conforming alternative to BIND.
    They don't say anything against djbdns being RFC-conforming, and
nothing either for or against its security.
    However, when they are combined, they do say something very negative
about its usability.  (b) alone is enough to make usability a problem. However, 
neither it nor (c) and (d) would prevent me from using djbdns (or qmail)
without the presence of (e).  I can only tell of my experience looking at qmail to
justify this.  Qmail lacks a features that are necessary for running
an effective and secure mail exchange/relay operation "out of the box".  By secure,
I particularly mean supporting authorization and starttls.  By effective, I mean configuration
by means other than file editing (such as LDAP).  Because of the license, remedying
requires sifting though a multitude of patches, which may or may not be well-documented,
and for which there are no well-established trust relationships.   Furthermore, the
factors (c) and (d) start taking a larger role here, because now I personally have to
take an
interest in the source code.  Not only that, I have to look at a wide variety of feature
because the author, because of some political game he wants to play (it's in his docs,
add this feature because it would expose me to this security-related criticism"), won't.

Furthermore, the license is imposed (as far as I can tell) to maintain the specious
for finding a security hole" "guarantee".  Bah!
    Now, you may say this is how it should be.  I should be familiar with every line
of source code
for every package I run on the systems I maintain.  I should put security absolutely
above features.
The reality is, it's not a real option.  I would be proud to be at the point to tell
you that I know
all the build-time options of every piece of software run on the machines I maintain.
 But I don't
(though I almost do).  That in itself requires a hefty investment of time that some
would tell
me I shouldn't have made in a pragmatic world. And they may be right.  But I certainly
don't have
the time to delve through a mound of source code to add features and documentation I
(and possibly
others) need in order to effectively use it.   If I could redistribute the whole package,
or if I could
rely on the author to take an interest in these features, I might consider it a worthwhile
of my time.  But he's made it clear he's not.  He's made it quite clear he's more interested
winning a technical victory (and I mean one on technicalities, not on technical virtues),
rather than
one on being both featureful and secure.   And this makes me say, why am I wasting my
     Now, I know, qmail has its adherents, and Russ Nelson, notably, provides support
for it.
Presumably they have found its virtues worth investing their time on.  Of course, Russ
on qmail, so one can guess that his time investment gaining expertise in the details
of qmail is
well-spent.  I, and I assume many (but not all) sysadmins out there, do not have that
I'm not saying other free mail server implementations (or BIND) are really easy to use
troubleshoot, or add features to.  But at least I'm pretty sure that if it came to that,
either the maintainers
of the software would have some interest in incorporating my work (depending on quality)
I would have the option of forking if I disagreed with their evaluation or if there
were some 
political game being played.  Either way, my attempt to contribute and my needs (or
the needs
of my employer) get a fair shake.
     Here ends my rant on why "oddness" matters, particularly when the software isn't
Maybe I'm just not diligent enough, but I doubt it.  Or maybe I'm an odd sysadmin. 
Hard for me to