On Mon, Aug 14, 2000 at 05:31:59PM -0700, Pete Naylor wrote:
> David Maxwell wrote...
> > Mature is a strawman argument here,
> 
> You misunderstand me.  That was not an argument, I was trying to be nice -
> making excuses for the relative paucity of features in postfix and the
> relatively recent fixes for simple things like not being an open relay
> (27th of December 1999).

Ok. Certainly sendmail has been around long enough to have people 
figure out how to do wierd and wonderful things with it, probably many
that haven't been done with Postfix yet. The open relay issue didn't
affect me - it had a pretty specific issue, backup MXs running postfix,
and specific configs on the primary MX.

> It's not as old as qmail, zmailer, exim or smail either.  I'd never try to
> make a case for always using the oldest piece of software.  Having
> experience in production environments though, I know the value of mature
> and well-tested code. 

Not that this is a great resort to authority - considering ownership,
but just an example of people using Postfix in a high-volume, (and
no doubt high abuse-target), production environment.

% telnet mailsorter-102.bryant.webtv.net 25
Trying 209.240.198.91...
Connected to mailsorter-102.bryant.webtv.net.
Escape character is '^]'.
220 mailsorter-102-1.bryant.webtv.net ESMTP WebTV_Postfix (Postfix-19990906-pl02/ms-o.gso.05Nov99) ready to rumble

> postfix might well work fine - but there's no
> reason for it to replace the familar old tool that many folks depend on.

Absolutely. With all else being equal, there would be no reason to
even _Evaluate_ changing.

But I don't think all else is equal here. Postfix (Or, the "IBM 
Secure Mailer") was designed, written, disseminated, and debugged, in
that order. I would suggest that was not the case with the default
mailer shipped with NetBSD - sendmail.

Postfix was designed with performance, and security in mind. Certainly,
for many NetBSD users, the performance aspect is largely a non-issue -
many people are running personal or small mail servers, and if running
a large mail server, they can evaluate and install an MTA of their
choice anyway. Security on the other hand is a different matter. Sendmail's
structure makes any new flaws likely to put a system at risk. Postfix's
design makes that much less likely. Put simply:
% ls -l /usr/libexec/sendmail/sendmail
-r-sr-xr-x  1 root wheel ....

For an overview in more detail, about the things that were considered
while writing Postfix, look at http://www.postfix.org/security.html

> use.  From other messages in this discussion, I understand that the NetBSD
> distribution currently doesn't even include an official beta release, it
> is an "experimental" release.  Gee - I can't wait to become a postfix beta

The version sup gave me is 19911231-pl08. Not a beta.

> > Maybe UVM should be ripped out too because it's not as
> No - that's a perfect example of what the NetBSD project is all about.
> That's an OS improvement, as opposed to an attempt to push someone's MTA
> preference upon everybody without so much as a reason as to why the
> existing and familar tool should be replaced.

I'm sure you noticed the tone in my last message - and thanks for
not taking it as flamage, but I emphasized two major issues for myself,
the configuration, and the secure design. Thor brought up licensing
shenanigans, which always draw attention in NetBSD, due to the
goals of the project. Is your comment here about why the mailer would
be evaluated without explaining this first, or do you feel you haven't
had a sufficient explanation since asking on the list?

> Okay - I'll rephrase that.  Anything represented by a jumble of a dozen
> daemons is likely to be more daunting to a newbie than a single binary and
> single process which does a fairly predictable job.  When something goes
> wrong with one of the postfix daemons, the newbie will likely struggle to
> work out what's missing.

Postfix does have 2 daemons that run all the time - master and qmgr.
Other processes are spawned on demand, as required, and exit shortly
afterwards. The phrase "a jumble of a dozen deamons" doesn't do justice
to what you will actually see on a system running Postfix. I would
contrast your viewpoint, with that of a newbie attempting to fathom
a dozen sendmail.cf macro rules.

> > I think the level of verbosity speaks for itself. Someone will be
> > able to learn postfix much faster than sendmail.
> Yeah - same is true of qmail, zmailer, exim, smail, etc.  This is
> certainly not reason enough to conclude that postfix is the best MTA for
> all sites whether they want something different from sendmail or not.

No, perhaps not. My personal comments on the above -
qmail: wierd. Abritrary changes to the way things are done, file
	formats, directories, aliases files... Different, fine, but
	far from a 'typical' mailer.
zmailer: esoteric, beyond that I seem to remember some wierd licensing.
exim: Haven't tried it in a long time.
smail: Great mailer, but with very limited ongoing development resources.

None hold great appeal for me, in comparison to the support behind
Postfix.

> > Right, but that's not a good way to look at things
> Depends if you're an idealist or a realist.  In the real world, people
> running Unix systems are quite busy with current concerns, and if a tool
> is working fine as it stands, they don't want to have to mess with it and
> they shouldn't have to.

If these people aren't going to change things on their system, then
it seems to me best to deliver a system with a better inherent security
design, so that the busy admin is less likely to find his box compromised
by the mailer he never bothered to update.
(Anyone done a count on wizard mode capable sendmails recently?)

> > - new sysadmins will learn postfix more easily,
> Possibly.  And they might learn qmail, exim, zmailer etc with even more
> ease.  Unfortunately, nobody did any sort of detailed evaluation of those
> mailers, and giving users a choice is apparently out of the question.  A

That doesn't follow to me. The mailerwrapper setup makes it easier to
try different mailers, and easier for pkgsrc to do a full setup so
that someone can try them. 

Perhaps no individual did an eval of all those mailers and posted the
results, but no one has made an argument that one of those other mailers
should be in the system, and until someone proposes a better solution
than evaluating Postfix, I don't expect to see a change in that.

> few developers decided that they like postfix, and concluded that all
> NetBSD users will have to like it too.  That sucks, and it's unnecessary.

But the many remaining developers haven't dissented, which they're 
welcome to do, if Postfix is such an awful thing.

> If you're aware of current bugs in sendmail which are the cause of
> security breaches, you should perhaps report them to the developers.  I'm
> not going to automatically assume that postfix is the most secure MTA

Nor will I, but I'll easily assume that a monolithic setuid root daemon
(sendmail)... that has never had a rewrite AFAIK, and I'd guess never
will, due to the .cf state machine... is likely to be the least secure.

> available or that security it held above all other requirements at all
> NetBSD sites

No, NetBSD wants to compete with ____x for the title of most security
issues. ;-)  Sysadmins don't have time to learn everything about
securing a box, so let the people who have made the effort make some
suggestions about how to make the default install more secure.

> There's no reason why sendmail shouldn't continue to be the basic mailer
> included with NetBSD.

Yes, there are, but since I repeated myself three times in the last
message, and you aren't even acknowledging the arguments, I won't
bother to say them again.

> > Of course the postfix install will work out of the box, just like sendmail
> > did.
> It doesn't right now.

Great, please report the issue so it can be fixed.

> Right now it's just a pointless waste of download
> and build time for most.  The long term goal seems to be to only include
> one MTA, the one that nobody is familiar with and few are interested in.

I've only seen two people complain about this.

How many people have SMP capable systems? Probably a pretty small percentage
of NetBSD users. Does that make it not worth the effort? I think the
design benefits make it beneficial even for those who aren't 'interested'.

> > Security.
> You keep claiming this as though all the other options are blatantly full
> of security bugs which can be exploited at this time.  I'm not convinced.

They don't have to be blatantly full, they have to have better odds of
having one security bug.

> > Configurability. 
> sendmail, exim, zmailer, qmail etc are all configurable.  Most are more
> flexible and powerful than postfix.  They're being ignored though because

They're being ignored because no one has made an argument _for_ any of
those.

> > NetBSD users deserve to get a default install that is as resonably
> > secure as possible.
> Again, the "security is everything, other mailers will never be secure
> because postfix was written by Wietse Venema" argument.  That argument is
> very weak, and is quickly getting old.

I'm afraid I don't think it's weak, but you seem to want to avoid it.
And I've not once mentioned WV, but you did twice in your message.

A program isn't secure because of who wrote it, it's secure because 
of design, implementation, and review.

> It is the current defacto standard upon which much familiarity has been
> built.  Unless there is good reason for inducing discomfort in the
> userbase by replacing it with something sparkly and new (but "weird"), it
> should be left as it is because it has value to many that way.

>  Nobody has presented good reason.

You seem unwilling to actually address the reasons, simply returning
to "It has always been sendmail". I'm happy to discuss the secure
design of Postfix, or any of the other advantages mentioned, but I 
don't see benefit in continuing to to play 

Q. "Show me a reason"
A. "reason. reason. reason."
R. "I don't believe those, show me a reason."

> > Security. Configurability.  I said it clearly last time, here it is
> > again.
> Yeah.  It's very easy to spout those words again and again.  They're
> meaningless though, because you have not proven that the current tool is
> insecure or inconfigurable.

I don't have to prove it, I have to suspect it. You have to prove that
Postfix isn't likely to be much much much safer, due to it's design,
since that's what I'm suggesting.

>  The very fact that so many people use the
> sendmail that's supplied in the distribution suggests that it's adequate
> for many, and that many people are comfortable with the way it is
> configured, operates, etc.

That suggests to me many people don't change what the system ships with,
and so it should ship with the best tool possible, that works as shipped,
for the common config.

> > > sendmail works just fine for me for that purpose, and I have.. 
> > > no desire to learn about the dozen+ daemons in postfix or the postfix
> > I'm only aware of two, qmgr, and postfix.
> 
> There are many more.  Perhaps you should read some of the documentation
> and try to understand the software before you make claims about why it
> should replace sendmail on all NetBSD systems.

The other apps are called daemons because they run in the background,
but they aren't daemons in the traditional Unix sense of being 'always on'.

> What happens when I want to test mail processing via "sendmail -v" ? 

Sorry, the design of Postfix is too secure to support that. ;-)

> What about when I try to set a different queue run frequency using the
> -q<interval> command line option that I'm accustomed to?

Then you read the helpful text in the config file, preceeding
the various xx_queue_xx = options.

> > Security. Configurability.
> A predictably lame response.

Well, same lame question, same lame answer. In case you don't know which
one that was, the next line repeats it again anyway.

> > > there is just absolutely no justification at all.  Why fix something
> > > that's not broken? 

> Let me get this straight... having a thick O'Reilly book documenting a
> software package makes that package broken and is conclusive proof that
> said package should be replaced by a few people who fanatically support
> some other software to the detriment of the majority?  Nonsense.

Nope, having such a large complex document to express the configuration
options for an MTA does.

But continuing to express the same issues when no one else feels
the need to make a significant comment would be nonsense.

							David