Scott Barman writes:
>The recent CERT advisory regarding sendmail has gotten me thinking...
>This program is such a problem, is there a way of replacing it?
[Questions about upas, etc, deleted]
MMDF is considered by many to have more desireable design,
from a security (and performance) perspective. It's used by a lot
of heavy-load mail servers. Last time I talked w/someone about upas
I got the impression it had fallen somewhat into disfavor and was
suffering from some code rot.
The problem isn't really sendmail. The problem is that we
have mailers that we expect to execute programs on behalf of the
user, via .forward files, etc, etc. From a security perspective,
this is simply a bad idea.
I believe sendmail can be made quite trustworthy, if you
run it as a non-privileged user process, and disable the prog mailer.
There may be some other way to invoke programs through it, other
than via prog, but I don't think it's an unmanageable problem.
Every time I've come along and rigged sendmail to run unpriv'd,
and zapped out the prog mailer, someone comes along and wants to
know why they can't forward their mail to some goofy process or
other.
Mailers don't need to be complex. For example, you can do
away with a lot of grossness if you are willing to make one simplifying
assumption: all addresses are in the form of user @
host .
If you make
that assumption, then your mailer just has to check the right side and
see if it's for itself (where "itself" is defined in some file someplace)
or whether there's a known re-route for the right hand side, and if
not, it just sends it off. Queuing, retry, bouncing, etc, are a fairly
complicated part, but not unworkable. The original goal of "smap" was
to evolve into a minimalist mailer. My experience with mailers, though,
indicates that they are prone to feature-creep almost as much as
web browsers and perl. It may be impossible to actually have a minimalist
mailer. Human nature may forbid it.
mjr.
References:
|
|
