[[ I'll reply one more time to the list....  ]]

[ On Tuesday, August 15, 2000 at 01:36:40 (-0700), Pete Naylor wrote: ]
> Subject: Re: Postfix
>
> Now I understand your point - thanks.  Not sure that I really agree
> though, given the number of different components of postfix (as you can
> tell, I'm not of the opinion that more daemons equates to more security).

You'd do well to understand the design of postfix a bit better I think.

Contrary to what you say Postfix's collection of multiple daemons and
other programs does make it much more secure.  Postfix compartmentalises
the risks presented by each type of activity that it must perform and
thus greately improves the overall security of the entire mailer by
building on the very strengths of the Unix security model; monolithic
mailers must fight the Unix security model, kicking and screaming, all
the way from beginnging to end.  Postfix's author has a very deep
understanding of this model and knows full well that putting all your
eggs in one gigantic process that runs as root for much of its life is
very risky indeed (as has been proven over the years by all the faults
found in monolithic mailers like sendmail, and including, despite their
attemtps to write safer code from the start, smail and exim).

> But why
> confuse the situation and make people uncomfortable by pulling the
> sendmail rug out from under them?

Speaking for myself alone I can only say "because it keeps them on their
toes!"  :-)

Change is good.  Especially so when it is for the better (greater good!).

> How would someone who is familiar with sendmail and has no requirement for
> anything different/better know that without spending time learning about
> postfix?  And all those people should allocate that time why?  A few
> NetBSD developers who happen to like postfix decided that they're right
> and everybody else is wrong - that's why.

On the contrary -- it would be best to say that Postfix is a better
*default* choice of MTA for everyone.  There's still nothing in the
system that prevents any given NetBSD vendor or user from making a
different choice.

> You may be talking about exim.  If the object of this postfix "evaluation"
> is to come up with a small and simple mailer to replace sendmail in the
> NetBSD distribution, why aren't you suggesting that Exim should be used
> instead of postfix?

Actually, no.  I don't believe the out-of-the-box configuration of exim
is any more suitable for a true leaf node than is that of NetBSD's
sendmail.  :-)

> The right answer is to make postfix, exim, etc available as packages, and
> keep the base distribution basic and familiar to users by leaving sendmail
> alone (though making it easily replaced such as Sun have done with recent
> Solaris releases is a bonus).

And so they are.  The issue is that there's a need for a *default*
mailer and so someone's got to make a value judgment on which default
MTA is best for NetBSD (i.e. which best matches the overall system
design goals).

> That is my point exactly.  Nobody's going to agree to one single mailer
> being "best" for NetBSD, 

I'm not so sure.  It's also not really everybody's business either.
Even our discussion of the subject borders on pointless off-topic
rambling because neither of us are in a position to make the decision or
even particularly to influcence the decision makers!

>  so please, leave sendmail in its defacto
> position, and let people choose for themselves.

As an independent developer who uses NetBSD a lot, I don't agree....  :-)

> I think that including two MTAs represents bloat and wasted resources.

I don't disagree with that -- however given the obvious religious nature
of choosing an MTA for someone else, perhaps it's a necessary waste of
resources.

However I'm going to point out that I'm thinking of a specific sub-set
of "resources" here, i.e. that the only resources wasted are those of
the NetBSD developers which would be available for other tasks if there
were only one MTA to integrate.  Even then this subset of resources
isn't necessarily wasted if a significant number of users find the
availability of a choice to be of some advantage.

As for bloat, well, since every "user" of NetBSD is free to make their
own final choice in which MTA they will compile and install, the only
bloat is in the download.  Perhaps if all MTA stuff were split from the
"base" system set, and if there were separate MTA sets created, then
users could even avoid this "bloat" if they wished.  Note though that
this requires more "resources" to be "wasted" too!  ;-)

> Since I now understand that the goal is to replace sendmail with postfix,
> I anticipate confusion on the part of those people who like sendmail and
> expect to find it in the NetBSD distribution, just as it has been for a
> long time.

Don't take anything I say as NetBSD gospel on this subject!  I cannot
speak for TNF.

I do build my own private release of NetBSD though, and just as I have
permanently removed all csh-related stuff from my source tree, so will I
remove all sendmail stuff too.

> > many people, even some of its fans I think, consider sendmail "broken by
> > design"
> 
> What a strange statement.  sendmail has active development and a lot of
> happy users - no doubt they think there's improvements to be made,
> otherwise they'd stop working on it right?  Same is true of postfix,
> qmail, exim, etc.  sendmail shouldn't be singled out as "broken" at all.

No, it's not strange at all, at least not from the point of view of
someone considering its security model, or indeed of someone viewing the
evidence of the failings of its security model!

> This only lends strength to my suspicion that the proponents of postfix
> replacing sendmail in NetBSD are just fans blinded by their liking for
> postfix and who refuse to believe that any NetBSD could want something
> else.

I happen to be the maintainer of yet another monolithic mailer, and
though I believe "my" mailer is somewhat better implemented and can
withstand various threats in a more robust manner than sendmail can, I'm
very well aware of the risks in its fundamental design and I will in
fact probably attempt to permanently deprecate "my" mailer and strongly
encourage everyone using it for any purpose to choose another
non-monolithic mailer to replace it with.  While one might contend that
these choices are already available (in postfix and qmail, for example),
I'm personally going to wait until Postfix has a few new features before
I take this action (and make Postfix my choice for all of my mailer
installations).

> Eh?!  You really believe that there should be "one true" MTA?  That there
> should be no choice and that all alternatives should be stamped out in
> favour of postfix?  *sheesh* Anything that isn't in line with the one true
> way is "broken" I suppose.

Oh, no!  Quite the contrary -- I believe fundamentally in the
availablity fo multiple choices of mailers, MTAs, programming languages,
etc., etc.  In fact I'm very much aligned in thought with Rob Pike,
i.e. in what he says in:

	http://freshmeat.net/news/2000/08/05/965534399.html

> Pretty much, yes.  Do not mess with the sacred cow, and allow folks to
> choose their own replacement MTA if they wish - as that's a deeply
> religious decision.  There are heaps of other tools distributed with
> NetBSD which should be considered part of the sacred herd, because a _lot_
> of users depend on them being in the distribution and working in the
> familiar manner.

I'm not sure what you mean here....   While I'm sure everyone would be
royally peeved if any true Standard tools (or any of their standardised
features), or any system or device support features, were removed, I
doubt anyone's really all that worried if, for example, one
implementation of awk were replaced by another.....  (I've already
replaced gawk with "The One True AWK" in my source tree and I'm well on
my way to deciding to replace GNU Grep and friends with alternate
implementations.)

> postfix does not cleanly or adequately replace sendmail
> for all user requirements

Well, since sendmail definitely doesn't met all user requirements
either....   :-) 

>, and there is no justification for trying.

Hopefully I've given some more such justifications....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>