> But I've never seen any OSS that I'd put in the same class as
> djbware.
I have.
> >> Just because OSS works for some developers/projects, doesn't mean it's
> >> the only valid model.
> >
> >Well, then, please explain what is so special about Qmail that requires
> >something different. The answer is: nothing.
>
> I believe its extraordinary quality and security sensitive nature
> justify its restricted distribution.
Its security sensitive nature is no different than the same security
sensitive nature that other MTAs have to deal with, and there does not
appear to be any problems with their distribution method. As far as
quality goes, I've seen better, and I've seen worse.
> >You may acknowledge it as
> >simply a privilege reserved by the author; but you will not be able to
> >claim that there is any good and sound technical reason for it. Any time
> >this question is put to you, you keep repeating the same mantra about
> >diddling with the code.
>
> Code quality control is a good, sound technical reason.
Code quality has nothing to do with the distribution method. You have a
lot of secure, quality, software out there being distributed as OSS.
> >Well, diddling with the code doesn't bother those
> >who maintain the infrastructure that the Internet runs on.
>
> Maybe it should. Maybe it would if their code was as tight as
> qmail's.
Again, please substantiate your implicit assumption that it isn't. You are
making a straw argument.
> Just because OSS is good enough to run the Internet doesn't
> mean it's appropriate for everything. Next time you have a CAT scan,
> ask yourself if you'd like the software running the scanner to be Open
> Source, running under Red Hat Linux, installed from some RPM that the
> technician found on the net, or tightly controlled, tested, audited
> code provided by the manufacturer, running on tested, approved, h/w
> and OS.
I'd feel more comfortable with a product that has undergone an extensive
peer review and anal exam, as compared to some closed box that only the
manufacturer knows how it works.
> >Once again, you're changing the topic. Noone said that it has to be a
> >democracy. Try arguing the topic, for a change.
>
> My point is that 5,000 people screaming at Dan for relaxed qmail
> redistribution rights won't mean squat. Dan has already considered
> relaxed licensing, already heard and considered all of your arguments,
> and decided against it. Deal with it.
Feel free to point out any time in the past where I have actually argued
that. I have not. I don't care. I'm simply debunking the baseless claim
that there is any sound reason behind the restrictions on the distribution.
There aren't any. It's simply personal privilege, nothing else. Why don't
*you* deal with the fact that there's no valid reason for a restrictive
distribution license, except personal privilege.
> >> >> 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.
> >
> >Well, facts matter to me.
>
> Then you should realize that your "fact" isn't one: it's an assertion.
Of course, you've written OSS that vendors have packaged for distribution,
and you have first-hand experience in making that conclusion.
> >> >And since add-ons cannot be redistributed,
> >>
> >> Wrong.
> >
> >You cannot redistribute Qmail with add-ons, silly.
>
> You can't distribute modified qmail source or binaries, but you can
Right.
> distribute virgin qmail + add-ons like rblsmtp and you can distribute
> virgin qmail source + source patches for add-ons.
Which is what - 5-10% of all the add-ons?
> >> Ever heard of rblsmtp?
> >
> >Which is badly broken,
>
> That's news to me, but I don't use it.
Neither do most of the people who have implemented RBL checking (by other
means).
> >and places unnecessary load on the server, and
>
> In your opinion.
Is how the actual code works just my opinion? Is it only my opinion that
rblsmtpd returns a temporary error code, for no good reason, so that the
blacklisted relay keeps banging at your server for two weeks, until the
mail bounces? As opposed to every other RBL implementation out there,
which immediately rejects all mail?
> >does not permit selective RBLing based upon the recipient.
>
> procmail. Modularity. Sure, it's less efficient, in some
> ways.
It would also be broken. We are not talking about user-level filtering,
but system-level filtering.
Furthermore, post-receipt filtering opens up your server as a conduit for
certain denial-of-service attacks. Anyone who actually done any kind of
work or research in that area knows it.
> "Premature optimization is the root of all evil."
So is a broken spam filter.
> >So what is the fact that Qmail is not the ultimate MTA, therefore, if you
> >choose to argue that a vendor must bend through hoops in order to
> >distribute it, just because it's so great, you will be mistaken.
>
> I'm not a vendor, but if I was, I *would* jump through hoops to
> distribute qmail. It's not "ultimate", as if that's possible, but it's
> the best there is for the types of applications I have.
And, that's why you're not a vendor. No vendor will have its hands tied
this way.
> >> >Except that qmail-smtpd logging is what most people require.
> >>
> >> Says who?
> >
> >Says those who administer mail servers for user bases that are at least
> >five digits long.
>
> I must have missed the reference to the peer-reviewed study that
> reached this conclusion. What's that URL, again?
<news:news.admin.net-abuse.email>
>
> >> "Require" or "desire"?
> >
> >Require.
>
> And this is documented there, too, right?
In every line of code that's used to implement it.
