[EMAIL PROTECTED] wrote:
>On Mon, 4 Jan 1999, Dave Sill wrote:
>
>> [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."
>
>Not just inertia. Inertia combined with inflexibility and unreasonable
>restrictions on distribution. Inertia enough didn't stop Red Hat from
>making inquiries.
Apprently I need to nail *both* feet to the floor. Okay. Let me know
which of the following statements you disagree with.
1) Red Hat ships sendmail.
2) Red Hat doesn't ship qmail, zmailer, exim, smail, or any other OSS
sendmail equivalent.
3) qmail has more restrictive resdistribution rights than zmailer,
exim, smail, or any other OSS sendmail equivalent.
4) Red Hat refuses to distribute qmail because of its licensing.
5) Licensing doesn't prevent Red Hat from shipping zmailer, exim,
smail, or any other OSS sendmail equivalent.
Question: *Why doesn't* Red Hat ship zmailer, exim, smail, or any
other OSS sendmail equivalent?
My Guess: Inertia: too hard to change, not enough incentive to change,
belief that sendmail is good enough, etc.
>So let's have all OSS authors stop writing code, because they can't ensure
>that all complaints due to broken packaging will go to the responsible
>vendor. Let's recall Apache, sendmail, Inn, and Bind, and withdraw them
>from distribution. Clearly the OSS scheme doesn't work, and generates
>horribly buggy installations.
How about if we just let developers who don't want to make their code
OSS set their own terms based on their beliefs and desires?
Just because OSS works for some developers/projects, doesn't mean it's
the only valid model.
>> "mostly" Maybe you find that acceptable. I postulate that Dan doesn't.
>
>And I postulate that the rest of the world does.
qmail is not a democracy.
>> Oh, right, users installing, say, a broken modified qmail RPM will
>> *know* that the packager broke it, not the author. I forgot that.
>
>Too bad, because they do. You can choose to ignore that fact, but it will
>remain a fact nevertheless.
Riiight. But even if I agreed, it wouldn't matter.
>> Nor should it. The bounce mechanism works.
>
>Which makes any system running Qmail a conduit for a denial-of-service
>attack.
Yawn.
>> Nor should it. There's an add-on to do that.
>
>And since add-ons cannot be redistributed,
Wrong.
>any one of hundreds of ISPs who
>require RBL functionality will not be able to get it from a vendor.
Ever heard of rblsmtp?
>> Nor should it. It's an SMTP server, not a multiprotocol mail gateway.
>
>See above.
What? Where?
>> For those whose inetd's can't be configured to allow higher connection
>> rates, yes, tcpserver is required. Big deal.
>
>No inetd in existance can be configured for higher connections, yet still
>implement load limiting. Nobody running Qmail in any kind of a production
>mode will be able to get it work with inetd.
Fine. Let's just say that qmail requires tcpserver. So what?
>> Wrong. qmail-smtpd's logging is minimal, but qmail's logging, in
>> general, is quite adequate.
>
>Except that qmail-smtpd logging is what most people require.
Says who? "Require" or "desire"?
-Dave
