Qmail [was Re: [Israel.pm] Detecting Random characters]
yuval at windax.com
Mon Oct 4 05:25:22 PDT 2004
I snipped some:
Shlomi Fish said:
>> Obviously, anything's better than BIND.
> I don't know - I haven't seriously worked with bind. But there are many
> DNS server alternatives.
BIND is hell. That's all I have to say.
>> Qmail is written very well, and thus had very few (if any?) security
> True, but what if a security hole is discovered in it? That would
> require peple to write patches, to patch the source distribution, and
> to re-install qmail in a gazillion different places with a gazillion
> configurations. Not exactly a straightforward "apt-get update all"
> process, and something that will give Internet low-life plenty of time
> to write a nice qmail worm or scanner or whatever.
I'm almost sure you can apt qmail.
Not a Debian user.
You can emerge it, for sure.
>> Sendmail needs to be patched twice a week.
> That used to be the case in the past. It may still be the case or not.
> In any case, I specifically mentioned that there are also postfix
> (http://www.postfix.org/), exim (http://www.exim.org/), Courier
> (http://www.courier-mta.org/) and possibly other alternatives. These are
> fully open-source.
I used Courier and Postfix.
1. They aren't that much easier to install
2. They aren't that much easier to configure
3. They need more maintainance than qmail
4. They aren't as secure/stable/fast as qmail
>> DJB is entitled for his own opinions about anything, and I don't care
>> if he thinks he's superior.
>> I really don't think we should think of the authors of the software we
>> use. Especially not to decide which mail-server to install.
> His sense of superiority is the least of my problems. The problem is he
> thinks he knows better than anyone else, and has a very bad attitude.
> Projects used to fork because of the bad attitude of their developers,
> or their inability to manage it properly. And DJB has the worst
> possible attitude.
>> Would you use Windows just because Alan Cox or Linus Torvalds think
>> they are superior?
>> I assume you'd rather be tortured to death :)
> Let's skip this superiority argument.
The point is, don't judge the software by the people who wrote it.
Now THAT'S bad attitude :)
Seriously, I don't care about DJB, but he has one fine piece of mail
>> I do not want a piece of software that updates every month, as long as
>> it stays "secure" (please don't fight about the definition of the word
> It's hard for me to understand this sentence.
I don't want to recompile or patch any software, unless there's a good
reason to (security or amazing new features).
As for security, I don't want to recompile twice a month because of
Qmail didn't have security holes for years, hence I had no need to recompile.
>> Do you know how many times I re-compiled Apache???
>> I compiled qmail once (per server, that is).
> Right, you need to compile it once. But according to the qmail handbook,
> if you want to add some more features, you need to apply some
> third-party patches, in which case you need to compile it again. (and
If you can't patch, you're in deep problems.
Patching takes a few seconds.
You can use it without patches.
I only use vpopmail which was VERY easy to install.
>> Qmail installs on Linux very well.
> With the help of a patch perhaps. But not the vanilla distro from
I installed the vanilla distro.
I now install vanilla distro + vpopmail.
RTFM, and you're set.
>> I really don't understand why you'd want to distribute your binaries
>> or modified code, and not patches, anyway.
> 1. I'd like a qmail-1.03-6mdk rpm file that I can install using rpm or
> urpmi or whatever. A full-fledged binary package, that everyone can
> pass around and not everyone has to compile and install from source
I think there are packages, but I'm not sure.
Why would you install qmail on mandrake?!? Nevermind :)
> 2. I want a source distribution that compiles out of the box, not a
> random collection of tarballs and patches that require a script.
Well, that's true in a lot of other cases, even large open-source projects.
My latest Apache install was a collection of tarballs and 1 patch.
(OpenSSL, mod_ssl, mm, mod_perl, Apache)
>> Hey, is Apache with a few modules ./configure && make && make install?
> Apache itself is ./configure; make and make install. Each one of the
> modules is also usually ./configure ; make and make install. You can
> write a script to automate everything, and since everything is
> open-source there are also RPMs, DEBs, urpmi sources, apt sources,
> emerge sources, or your favourite package manager. None of this exists
> for qmail.
The packages aren't worth the download bandwidth, honestly.
I think Reuven Lerner once wrote that even though he's a huge RH fan,
there are a few things he always compiles from source, Apache being one of
And as for the (not so standard but not so complicated) installation I
did, it was a lot more complicated than ./configure && make && make
>> I don't use a mailing-list manager, so I don't know.
> Heh. Well, a mailing list service is considered quite an important thing
> for a public mail server to have. Of course, one can use mailman or
> Siesta or whatever with qmail, so it's not such an issue.
"Public". Mine isn't.
>> I agree on some issues about Qmail, but I just don't think you could
>> find anything better.
> I think I could: postfix, exim and Courier. All of them open-source and
> all of them much better than sendmail. I don't know how they compare
> against Qmail (never used them) but they also have their following.
Please try to use them. Even on a small mail server.
I've been using Qmail for 2 years now, and I really haven't touched it
except for compiling once.
Postfix had a lot of security issues, and I personally didn't like it.
I don't see how Postfix or Courier are any better.
>> And hey, no one stops you from writing patches :)
> With the other three, I don't need to write any patches.
But you do need to recompile every other day.
>> What are good alternatives anyway?
> See above.
They are good, just not "better" except for MAYBE licensing.
I wouldn't use a package anyway, so I really don't care.
More information about the Perl