David Maxwell wrote...

> > > [ On Sunday, August 13, 2000 at 19:06:16 (-0700), Pete Naylor wrote: ]
> > > > Uh - if I were only looking at functionality, postfix would probably be my
> > > > last choice of MTA.  It's not mature, and lacks a lot of configurability
> 
> 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).

> no it's not as old as sendmail,
> not much is.

old != mature

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

Personally, I consider the "beta" nomenclature to be a pretty good
indication that a piece of software is probably not ready for production
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
tester at the whim of a few postfix fans who've decided to push it upon
all NetBSD users.

> Maybe UVM should be ripped out too because it's not as
> mature as the old VM system?

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.

> > > simpler,
> > 
> > No, it's not.  Anything represented by a jumble of a dozen daemons is
> > likely to be daunting to a newbie 
> 
> No, ANYTHING is going to be daunting to a newbie. A newbie doesn't know
> what a process is, so (s)he won't know if there's 1 or 20.

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.

> What a newbie will find out is this:
> 
> (First lines from sendmail.cf - aside from copyright and RCS tags)
> 
> Cwlocalhost
> # my official domain name
> # ... define this only if sendmail cannot automatically determine your domain
> #Dj$w.Foo.COM
> CP.
> # "Smart" relay host (may be null)
> DS
> # place to which unknown users should be forwarded
> #Kuser user -m -a<>
> #DLname_of_luser_relay
> # operators that cannot be in local usernames (i.e., network indicators)
> CO @ % !

Why would a newbie care about that?  A simple null client configuration
will work just fine out of the box.  Anything more involved than that will
teach them about sendmail, or they'll take the opportunity to learn about
the alternatives and choose the one that suits them best.

> (First lines from postfix's main.cf - aside from copyright and RCS tags)
> 
> # Global Postfix configuration file. This file lists only a subset
> # of all 100+ parameters. See the sample-xxx.cf files for a full list.
> #
> # The general format is lines with parameter = value pairs. Lines
> # that begin with whitespace continue the previous line. A value can
> # contain references to other $names or ${name}s.
> # LOCAL PATHNAME INFORMATION
> #
> # The queue_directory specifies the location of the Postfix queue.
> # This is also the root directory of Postfix daemons that run chrooted.
> # See the files in examples/chroot-setup for setting up Postfix chroot
> # environments on different UNIX systems.
> #
> queue_directory = /var/spool/postfix
> # The command_directory parameter specifies the location of all
> # postXXX commands.  The default value is $program_directory.
> #
> command_directory = /usr/sbin
> 
> 
> 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.

> > Of course, most system administrators
> > can accomplish the basics with sendmail because they're familiar with it.
> 
> 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.

> - 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
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.

> and established sysadmins should get their
> head out of the sand and use a secure mailer.

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
available or that security it held above all other requirements at all
NetBSD sites just because Wietse Venema has a reputation for developing
secure tools or because the MTA's function is split among an astounding
number of separately fallible binaries.  If someone likes postfix, that's
great - let them get it, build it and maintain it.  There's no reason why
sendmail shouldn't continue to be the basic mailer included with NetBSD.

> > > and easier to configure. 
> > 
> > Most people don't need to do much sendmail configuration.  For a simple
> > node, it doesn't need much help - and a sendmail.cf as distributed would
> > work pretty much out of the box. 
> 
> Yeah, and I'm sure NetBSD will go from distributing a sendmail that
> runs out of the box on a standard install to a postfix where you have
> to key in the source code by hand.

Possibly.  We've gone from having no unusual features with respect to the
mailer, to having a configurable interface to it via mailer.conf.  We've
also gone from distributing one MTA to distributing two, and there are a
number of issues relating to this that need to be sorted out according to
my reading of the questions about it on the list of late.

> Of course the postfix install will work out of the box, just like sendmail
> did.

It doesn't right now.  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.

> > Or even postfix - people are free to get it and install if they so desire.
> > Replacing sendmail with postfix in the base distribution is senseless.  
> 
> 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.

> Configurability. 

sendmail, exim, zmailer, qmail etc are all configurable.  Most are more
flexible and powerful than postfix.  They're being ignored though because
a few people have decided to take away a tool that many people are very
happy with, and shove their own personal preference down their throats
instead.

> - Hardly 'senseless'.

Sounds like you're a postfix fan too.

> > It provides no advantage at all, and it confuses a lot of people without
> > justification.  Exim would probably be a better choice, actually, but I
> > still wouldn't want to see it replace sendmail in the base distribution.
> 
> Here's a pop quiz, what piece of software is well known to be the
> buggiest of all time? (Single piece, OSs don't count)

Well known or often claimed?  What does a history of active development
and willingness to address bugs have to do with ripping a familiar and
useful tool out of NetBSD to be replaced with someone's favourite new toy?

> 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.

> > No, it's absolutely not.  sendmail as included in Unix OS distributions
> > for many a year has fulfilled the purpose required of it just fine, and
> 
> Bzzt. Did you read my last message? "It always worked that way." 
> isn't sufficient by itself.

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.  All I'm getting is "I like postfix - everybody
else will too - it's secure because I think it's secure (thereby making
all other MTAs an instant exploit) - it's easy to configure because I'm
familiar with it - and it's sparkly and new".  While that might be
convincing to you, it is not reason to mess with the distribution that a
_lot_ of other people depend on as stable and predictable - not at all
known for frivolous changes that produce incompatibilities of function of
or administration.

> > nobody has presented any justification for replacing it with postfix
> > beyond "but I like postfix and I think it's better than sendmail".  Geez,
> 
> 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.  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.

> > In many systems I prefer not to install my preferred MTA, because I can
> > use the included MTA for the basic functionality which is required.
> 
> You'll still be able to do that.

After I learn how to administer yet another MTA for no apparent reason.

> > sendmail works just fine for me for that purpose, and I have absolutely 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.

> I'll give you a quick tutorial...
> 
> postfix start  (starts the daemons)
> postfix stop   (stops the daemons)
> postfix reload (reloads config files)

Thanks.  When one daemon dies or fails to operate properly for whatever
reason, the above is all I'll need to know?  When the daemon is
chronically overwhelmed and the queue is filled by some foolish spammer or
a dim-witted loop caused by MS-Exchange, the above is all I'll need to
know?  When I want to remove a queued message, the procedure is exactly
the same as for sendmail?  What happens when I want to test mail
processing via "sendmail -v" ?  What happens when users start complaining
because postfix doesn't do duplicate removal like sendmail does?  What
about when I try to set a different queue run frequency using the
-q<interval> command line option that I'm accustomed to?

All of this stuff will be different, as will the presence of so many odd
process names in the process table and the format of the logging.  There's
absolutely no reason to change any of this for the large number of people
who are happy with the familiar sendmail which they've come to depend on.

> > configuration, or postfix queue management etc.  If there was a compelling
> > reason for replacing sendmail with postfix I wouldn't be complaining, but
> 
> Security. Configurability.

A predictably lame response.

> > there is just absolutely no justification at all.  Why fix something
> > that's not broken?  Seems like it's just a personal crusade by a few
> > postfix fans :(
> 
> sendmail _is_ broken. Go buy the thickest book O'Reilly prints if you don't
> believe me.

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.

-- 
Pete Naylor