Mike Stone wrote...

> > I was quite dismayed to find both sendmail and postfix included in
> > -current.  I can imagine arguments for including one MTA, or none, but
> > two of them?  Can someone please explain the rationale behind this?
> 
> because they're two different tools, intended for very different
> uses.   sendmail is a very general MTA, intended to relay mail between
> systems that use god-knows-what for addressing and delivery
> mechanisms.   it's a glue utility.   postfix is an RFC822-compliant SMTP
> server, and nothing else.

I'm afraid I disagree.  In common use sendmail fulfills the same function
as postfix, making the inclusion of both unjustified redundancy.

> sendmail has been around forever, and most mailserver admins have had to
> become familiar with it at some point or another.   in recent years,
> though, the proliferation of TCP/IP networking and pure-SMTP email
> networks has made the need for a general glue utility less
> important.   sysads run sendmail because they've always run sendmail, even
> though the only part that's being used any more is the bit that does
> simple SMTP-SMTP transfers.

I don't mean to be rude, but we're all well aware of sendmail's place in
history.  Some of us are also aware that more than one alternative exists.

> that leads to some problems, because sendmail has never pretended to be
> RFC822-compliant, and its size and complexity contain some well known
> security holes.   frankly, as pure-SMTP servers go, sendmail isn't all
> that great.

Right - but it does the job for those people who believe that the base
distribution should include a minimally functional MTA.  Many people will
want to replace it with something better - not necessarily postfix.

> postfix was developed by Weitse Venema (as in: "bow down before the great 
> god of unix network security, Weitse Venema") to address the need for a
> simpler, trustworthy, efficient, pure-SMTP MTA that's reasonably
> compatible with the huge number of existing sendmail installations.

Yes - thanks for the sales pitch.  However, that does not make it the
be-all and end-all of future MTAs for everybody who would like to deploy
and support NetBSD.  I happen to like exim - but I wouldn't dare suggest
that it be included in the base distribution because:

a) it's not right for everybody - that's the beauty of choice
b) it's not really required as a part of the basic OS
c) it's easy to download and build for those who want it

Note that all the above apply to sendmail/postfix/qmail/etc too.

> from everything i've seen and heard, postfix is a pretty darned good
> package.   the code is clean and well written, it's easy to install and
> configure, and administration seems to be nice and simple.   it also seems
> to be free of the dubious code issues and personal politics of other
> pure-SMTP development efforts, so endorsing it isn't too much of a
> challenge.. heck, it's from the same guy whose tcp wrappers were
> incorporated into the NetBSD version of inetd.

All irrelevant to the discussion.

> in the long run, it's likely that postfix will take over the niche
> currently filled by sendmail. 

Erm - that contradicts what you've written above about the inclusion of
both being justified because they're totally different tools designed for
entirely different environments.  What's your real reasoning here?  World
domination by postfix or something?  Very strange.

>  right now, though, we're in a state of
> transition.   bundling both sendmail and postfix is a reasonably quiet and
> non-intrusive way to help the migration along.   there'd be cries of
> outrage if sendmail was unbundled, but if postfix was left as a "get it
> yourself" option, most people would never install it. 

They might well install something else which suits them better.  I hadn't
realized that one of the goals of the NetBSD project was to eliminate the
sendmail scourge.  *shrug*

>  the situation
> would be analogous to putting Netscape on a Win95 machine.. you can, but
> why bother?

Another conflict.  You're saying sendmail+postfix is redundant, yet also
trying to justify unnecessary fattening of the base distribution by
claiming they're not the same at all.  Which is it to be?  Your statements
are sounding a lot like those of a postfix fan, and that's not necessarily
in the best interest of the NetBSD project.

> so.. sendmail is there because it's a bit out of date, but nobody wants to
> be assasinated for taking it out.   postfix is there because it's a better
> tool for the current environment, and will spread more quickly if it's
> part of the distro.

Why is it the job of NetBSD to force postfix upon people?

> personally, i'm afraid i find your use of the word 'dismay' puzzling..

That's acceptable of course :)

> the
> purpose of bundling is to give users a reasonable selection of useful
> software 'right out of the box'. 

Okay - let's include every available MTA then eh?  And every available
open source package?  This will quickly make NetBSD fat and ugly.

> if you don't want to use one or the
> other (or either), don't. 

I'll have to download/build/install them anyway I guess.  *sigh*
Furthermore, I'll have to hope that they're maintained and updated and
that the binaries sitting around my systems won't become a security
liability.  This is just not sensible at all.

> they'll be right at home with all the other
> bundled packages that rarely get used.. /usr/sbin/zzz and most of the RPC
> daemons, for instance.

That's the "two wrongs make a right" argument.  While I'm all for making
tools optional and keeping the distribution lean and flexible, the current
topic in that vein is the lack of justification for including two MTAs,
neither of which is desired by many NetBSD users.  If you want to make a
case for taking the APM and RPC daemons out of the base distribution
that's great - I'll probably lend my support, but it's not relevant here.

-- 
Pete Naylor