From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
Subject: Re: OK, so how do we slam shut this sendmail problem once and for all? 
Date: Thu, 31 Aug 1995 00:06:30 -0400

> > Can folks live without .forward files piping mail to
> > an agent and/or other random-execution paths?
> 
> Uh, you mean, like 'slocal'?  or 'vacation'?
> 
> "BAD idea."
> 
> 
> There are a lot of problems with making sendmail nonpriveleged.
> For example, getting the contents of .forward files.  (one could make
> sendmail invoke the local delivery program, which could then re-invoke
> sendmail, but...)

Chris (and others) --
	A few years ago, it became very clear to me that sendmail was
the wrong answer, based on engineering grounds.  Anyone who trusts a
100 - 400 KB setuid root program, with a Turing-equivalent
configuration language, is, IMHO, out of touch, to be kind.  Sendmail
is too big, and too complicated, to trust.  It does too much:  there's
no reason inbound and outbound mail need to be handled by the same
program.  (Yes, headers may need rewriting, but that's a job for a
common library, reading the same rewrite specification.  There's no
need for the same program to do it.)
	Making a mailer run without root priviliges is possible, but
decidely non-trivial -- but it would be much better if the process
that was connected to port 25 wasn't root -- then the syslog(3) bug
wouldn't have been quite so nasty, although given the low assurance of
Unices, getting a non-root shell is most of the battle.
	Anyways, you have to decide exactly how many feature you want
your mail transport agent to have, and how much risk you're willing to
tolerate -- security, like everything, has a price.
	I haven't written an MTA (but I don't run sendmail on my
personal machine, either), so I won't claim to be an expert.  But, if
you think hard about the problems and tradeoffs (send email if you'd
like an incomplete list), you can make a more secure MTA than
sendmail, and "BAD idea" doesn't do justice to the problem.  Given the
Unix protection model, running arbitrary programs when mail arrives is
inherently a very risky proposition.

Drew Dean