Quoting Stephen Gran <[EMAIL PROTECTED]>: > 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... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
