On Mon, Aug 14, 2000 at 10:37:52AM -0700, Pete Naylor wrote:
> 
> Greg A. Woods 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, no it's not as old as sendmail,
not much is. Maybe UVM should be ripped out too because it's not as
mature as the old VM system?

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

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 @ % !

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

> 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 - new sysadmins will
learn postfix more easily, and established sysadmins should get their
head out of the sand and use a secure mailer.

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

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

> 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. Configurability.  - Hardly 'senseless'.

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

NetBSD users deserve to get a default install that is as resonably
secure as possible.

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

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

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

> 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. I'll give you a quick tutorial...

postfix start  (starts the daemons)
postfix stop   (stops the daemons)
postfix reload (reloads config files)

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

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

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
					      - Jamie Woods