[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

Quoting Stephen Gran <sgran@debian.org>:

> qmail is one of the few pieces
> of software I've ever seen that is so poorly written that it's author
> recommends running it under a supervisor because it can't stay running
> on it's own.

I wasn't planning on actually replying to this bag of complete rubbish,
but I just couldn't stay away...

You should really get your facts straigt before feeding the FUD!

Qmail is the most secure MTA out there. It's slick, and quite well
written (a little unorthodox, granted) and designed for security!
And noone have still been able to claim the $5k (think it was 5k
anyway) bounty for a security hole (yes, I know there are claims
that there are at least one hole, but I buy Bernsteins 'excuse'
for not paying - if configured correctly, the hole don't exist).

And the supervisor isn't because it can't stay running on it's own,
it's a extra security measure - IF something goes wrong, it won't
affect mail delivery. The key word here is _if_.

In Swedish, there is an old proverb saying "using both suspenders
and belt". Guess the closest English saying would be "better safe
than sorry"...

> It also doesn't support most useful features any reasonable
> MTA can be expected to support without fairly extensive patching.

Can be argued as well, but I'm not completely dismissing this claim -
Qmail work a lot better with a little patching (I do). But all in all,
I actually agree on Bernstein here to. An MTA shouldn't try to be 'smart'
- all that send receipt on acceptance/delivery, reject at SMTP etc (and
claims that this makes Qmail wide open for spams is rubish - it's only
if/when configured incorrectly that this becomes a problem) shouldn't
be done by an MTA (it isn't in the SMTP RFC that I know of).

> So, right, the argument we're left with is, it's quick and it doesn't
> have many apparent security flaws.

It have NO security flaws (especially not if patching it with the most
obvious patches).

> The fact that it's a poor netizen and is also unstable

Now, come on!! Get a f****ng reality check! Have you ever even USED
Qmail?! And actually READ it's code!?

I have Postfix crash more often on my home machine (~ 10 mails / 24h -
using an smarthost) than Qmail do on my main mailservers (~ 10k mails / 24h).

> featureless, and trivially replaced with things
> that do respect the FHS are IMHO more important.

Qmail [can] respect[s] the FHS just perfectly! Especially now when it's
public domain (if the modifications is ok that is - then we're back to
my original point - ARE we allowed to distribute modified versions!?).

> If someone actually cares, I suppose I'll say go ahead, but what a
> waste of time and energy.

I rather waste it on something good like Qmail than crap like Postfix
and Sendmail.

Now, THAT'S a complete waste of time and energy! Slow, complicated (to
configure correctly) and way to bulky.

And then I haven't even started on the code itself... It's the biggest
mishmash of cooks I have seen in a long time (for a project this important).

> The world has moved on and qmail has been made irrelevant because of
> it's original licensing decisions.  I think that at this point, qmail
> serves better as an object lesson in license idiocy than as a serious
> candidate for the archive.

Here we actually agree (on the licencing stuff any way). It's easy to
say "if only", but if the licencing is still bad, then it shouldn't go
into Debian GNU/Linux...

Reply to: