Re: [SLE] MTA Selection

• Previous message: David Barnes: "Re: [SLE] OK, so how do I publish this key thing?"
• In reply to: Gary: "Re: [SLE] MTA Selection"
• Next in thread: Paul W. Abrahams: "Re: [SLE] MTA Selection"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 21 Feb 2004 14:35:47 +0100
To: suse-linux-e@suse.com

Fri, 20 Feb 2004, by gv-dated-7213432.fknap@mygirlfriday.info:

> On Fri, Feb 20, 2004 at 11:49:48PM +0100 or thereabouts, Theo v. Werkhoven wrote:
> > Thu, 19 Feb 2004, by gv-dated-7098286.cckeb@mygirlfriday.info:
> > > The ease of configuration and use of the above MTAs are based on your
> > > needs. Of course security is a main issue... qmail is the most secure,
> > > postfix second, sendmail last..
> >
> > You're obviously (conveniently?) forgetting a couple of minor points.
>
> Theo, I'm not going to get into a p-- contest here, I don't have the time,
> but ..
> well, lets see.... I don't think so.. you seem to be adding some
> distortion here..
>
> > - It's the admin's work that's the main issue wrt security, not what
> > software he/she runs.
>
> security is an absolute requirement. Quality software helps.. or maybe he
> should just use an older version of Sendmail ... or formmail?

What I mean is, that a good admin, confronted with bad software, will
do everything he can to make sure that either the bad software can't
do any harm, by putting other security measures in place, or he/she
will upgrade/discard the bad software.
A bad admin just doesn't care, or doesn't have the skills to
recognize a bad piece of s/w, so with him it's "luck" when his
host(s) happen to run a secure setup.
A bad admin can make a Qmail or Postfix server go open relay in
no-time, secure by design or not.

> > - Qmail hasn't been updated in 10 years or so, the basic package is
> > secure, yes, but all the patches you need to use it in the 21st
> > century are *not* proven to be just as secure (and djb won't vouch
> > for those either).
>
> I believe the first beta was in 1996, version 1.3 in 1998, and it has not
> been upgraded because it never has had to. The author's cash reward for
> security guarentee is still in effect.
>
> http://cr.yp.to/qmail/guarantee.html
>
> patches? qmail works right out of the box.. I have several servers out
> there running v1.03 right out of the box.. nothing added. qmail
> quarentees that once mail is accepted, it will never be lost. It is also
> code-wise, a lot smaller than Sendmail or Postfix.

Both Sendmail and Postfix have a /lot/ more functionality per
default than Qmail, like all the anti-UCE filtering (RBL lookups,
header/body pcre/regexp filtering), sasl/ssl authorization +
authentication, LDAP/SQL/SDBM lookups for virtual domains/mailboxes,
content-filtering etc.
Qmail v1.03 offers only the most basic MTA functionality.
Wietse is at least as concerned, about guaranteeing that mail that's
been accepted is really written onto disc, as djb is.

[..]
> Postfix does not have security partitions between individual, mutually
> distrustful, elements of the mail system as qmail does. Most

Postfix trusts it's own sub-system, and why not? If a box is rooted
and subsystems replaced all bets are off anyway.

> daemons run under the same, single, global UID (specified by the
> mail_owner keyword in main.cf). A compromise of one of those daemons
> immediately compromises all of the others, .

With the effect *at most* that Postfix's internal mailqueue's could
be compromized. No OS files are in danger. All the parts of Postfix
can be run chrooted seperately, thus adding an even deeper layer of
security to the total.

> http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.html

That's just a Postfix bash. I'm not a programmer, so I can't comment
on the system architecture philosophies, but just listening to
Wietse on the mailinglist makes me trust his s/w a lot more, than
reading a rant against it does for Qmail.
The rant isn't even correct.

"It uses two large monolithic configuration files, master.cf and
main.cf, rather than multiple simple small task-oriented
configuration files. Like with all applications that choose this
route, configuring Postfix thus requires that one learn a set of
configuration file keywords, and automated configuration cannot be
easily done under script control with echo and cat."

Postfix provides 'postconf -e <keyword = value>', thus a
configuration /can/ be changed in a script quit easily.

Also the "learning" keywords is bogus, Postfix comes with a
complete, and comprehensive set of readme's, manpages, Howto's and
examples.

The author rants agains a history of local vulnerabilities, but what I
would like to know is what a local user is doing on any serious
mailserver anyway, or does he use his company's mailserver as
workstation?

Then the author goes on about Postfix not complying to all the
broken mailsystems out there, and says that thus Postfix should let
it's RFC-compliancy go, and follow suit of the broken systems,
because they represent the majority on the Internet.
Right, so all the MTA's should behave like Exchange, and stop
following the most basic RFC-2821 MUSTs and SHOULDs because hé, when
you're the greatest you don't have to comply to RFCs anymore of
course..

I could go on about this aswell, but let's just say that I think the
author listened to djb's rants about other people's inadequecies
once or twice too often..

> takes about 15 minutes. It uses it's own system library replacements to
> avoid buffer overflow exploits.

Ok, there was no such thing when I used it back in 98/99.

> > - Postfix is simple to grok, but it can also be used in complex
> > situations.
>
> Yes, like reg-exing all the headers and body of each email to block
> worms/viruses.. ?

That's an option, not something it does by default. And unless a
clueless admin uses header/body check files 100s of lines long,
using pcre makes it quite effortless (but very effective) to run the
mail through these checks.

> > - Postfix's licence permits it to be distributed in either binary or
> > source form. No need to go hunting for the correct patches,
> > tricks&tips etc., it runs out-the-box on a x86 Linux box (and even
> > under Cygwin/Windows I heard), but also on a 64 CPU Sun box or a PPC
> > Mac under OS-X (they use it as default MTA aswell).
>
> once again, qmail runs out of the box on any *nux or OS-X system,, no
> patches are needed, no hunting. If you want "extras" they are available
> all in one place. No big hunting here...

You still have to know that the extra's are available, and what you
need to get for a specific purpose right? I'd rather have it ready
to use when I'm done installing the mailsystem.
 
> You can use qmail for any purpose, you can redistribute unmodified qmail
> source distributions and qualifying var-qmail binary distributions, and
> you can distribute patches to qmail if you wish. You can't distribute
> modified qmail source code or non-var-qmail binary distributions.

Many people's thing against Qmail is caused by the way in which
Qmail doesn't comply to LSB, e.g. /var/qmail as base for the mail
system breaks systems where /var is mounted noexec,nosuid etc.

Linux distributors want to keep everything tidy and in expected
places, to make it easy both for themself and for their users. Qmail
makes this nearly impossible.

Theo

-- 
Theo v. Werkhoven    Registered Linux user# 99872 http://counter.li.org
ICBM 52 13 27N , 4 29 45E.     +      ICQ: 277217131
SUSE 8.2                       +   Jabber: gurp@jabber.org
Kernel k_athlon-2.4.20         +      MSN: twe-msn@ferrets4me.xs4all.nl
See headers for PGP/GPG info.  +

• application/pgp-signature attachment: stored

• Previous message: David Barnes: "Re: [SLE] OK, so how do I publish this key thing?"
• In reply to: Gary: "Re: [SLE] MTA Selection"
• Next in thread: Paul W. Abrahams: "Re: [SLE] MTA Selection"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]