[EMAIL PROTECTED] wrote:
>On Wed, 30 Dec 1998, Dave Sill wrote:
>
>> Let me try again. Licensing alone could conceivably explain why Red
>> Hat doesn't ship qmail. But it does't explain why they don't ship
>> exim, smail, zmailer, or any other OSS sendmail equivalent.
>
>So, there has to be another reason, that's all. It is probably the same
>reason why these MTAs have virtually no market share of any kind.
Inertia. "Sendmail is good enough."
>No, the question is very specific: if Red Hat botched the sendmail RPM,
>how does that sole event somehow translate into Eric Allman's reputation
>being affected in any way?
>
>The answer, of course, is that it doesn't.
The answer, of course, is that it *does*. First, Allman will be guilty
by association. Lots of people know that he wrote sendmail. If they
hear about a sendmail problem, without complete details, they'll
naturally assume he's responsible. Second, by allowing other people
to modify and repackage sendmail, he's implicitly saying that he
doesn't care what people do to it, even if they break it.
That's one difference between Eric, Wietse, and all the other OSS
authors and Dan: Dan's not willing to let other people diddle with
his code.
>Since I've been reading the mainstream press quite extensively lately, I'm
>comfortable to say that this is not going to be the case.
Doesn't matter. Nothing you think will change Dan's mind.
>You are replying to the assertion that complaining to the author - when a
>vendor's packaging breaks - would be stupid.
Maybe I got confused. Complaining to the vendor/packager would be
smarter than complaining to the author, but there's no mechanism to
ensure that all complaints go to the right place.
>> Of course not. But victims of these third party changes will surely go
>> to him or his lists for help.
>
>No. That's my point. The victims will be going back mostly to the vendor.
>This is not an arbitrary claim, but it's based on experience over the last
>couple of years.
"mostly" Maybe you find that acceptable. I postulate that Dan doesn't.
>> And these victims will also be unaware
>> of the changes their vendor made, so the help they get might be
>> wrong.
>
>Oh yes they will _certainly_ be aware. That's because they installed a
>vendor-specific file in the first place.
Oh, right, users installing, say, a broken modified qmail RPM will
*know* that the packager broke it, not the author. I forgot that.
>> There will be unnecessary confusion in the support community,
>> and this confusion will reflect poorly on Dan and his products to
>> casual observers who don't realize that the confusion is due to third
>> party diddling.
>
>This is plainly FUD. FUD, FUD, FUD...
Huh?
>If that's true, Brister would've never had the time to write inn 2.0,
>because he would've been handling all the mail from Red Hat users. There
>was a whole bunch of people out there who suddenly discovered that they
>can simply load the Red Hat CD, and instantly have a server on their hands
>that can handle a full Usenet feed. Up until that point, you needed to
>have a pretty good INN hacker on staff in order to accomplish that.
You clearly think OSS, Red Hat, and RPM's are the key to mankind's
salvation. Good for you. It's just as clear, however, that Dan doesn't
agree, and repetively claiming that you're right and he's wrong isn't
going to change his mind.
>In some situations Qmail is less efficient than sendmail, and its
>performance is sorely lacking.
Every complex system has weaknesses.
>Qmail does not verify envelope sender addresses, right out of the
>box.
Nor should it. The bounce mechanism works.
>Qmail does not support RBL, right out of the box.
Nor should it. There's an add-on to do that.
>Qmail does not support UUCP, right out of the box.
Nor should it. It's an SMTP server, not a multiprotocol mail gateway.
>Qmail does not rewrite headers on relayed mail, right out of the box.
Nor should it. There's an add-on to do that.
>Qmail can't even handle any kind of a reasonable load, right out of the
>box. You have to go back and install tcpserver for that.
For those whose inetd's can't be configured to allow higher connection
rates, yes, tcpserver is required. Big deal.
>Qmail's logging is virtually nonexistent.
Wrong. qmail-smtpd's logging is minimal, but qmail's logging, in
general, is quite adequate.
>Certain things Qmail can do better than sendmail, but there's still a lot
>of functionality that many people want, and Qmail does not have, unless
>you go out and grab a bunch of other software as well.
Modularity.
>You will not find any single OSS package that comes with any operating
>system in the same original form that the OSS package is distributed by
>the author, period. Besides an MTA, there are other software out there
>that's just as vital to the overall system security. Their respective
>authors do not appear to have any difficulties allowing commercial
>distributors to reconfigure the software for their specific operating
>system. DJB is making demands that nobody else in the entire world is
>making, and, no matter how good Qmail is, I do not see why it is so
>special that it needs it.
Dan doesn't need to justify his actions to you or anyone else
here. The fact is that he owns qmail, and he can redistribute it under
whatever terms he chooses. He's explained his rationale. I've tried to
restate it. If you remain unconvinced, so be it.
-Dave
