mailwrapper (PSARC/2008/759)

[James Carlson]

Ceri Davies writes:
> On Tue, Dec 09, 2008 at 04:27:41PM -0800, Danek Duvall wrote:
> > The whole point is that just about every program which doesn't build in its
> > own mail transmission code calls /usr/lib/sendmail with a standard set of
> > options.  Given that, you can put a glorified commandline processor at
> > /usr/lib/sendmail (or /usr/sbin/sendmail, whatev) which then forks off the
> > appropriate / configured "real" MTA.
> 
> That's exactly what this case proposes.  I've preserved
> /usr/sbin/sendmail because I don't really know what it's doing there.
> I don't want to call the mailwrapper binary /usr/sbin/sendmail because
> it would probably end up being removed by anyone trying to replace
> sendmail.

I don't think we need to try to code around people who deliberately
damage their systems.  Especially so when the attempt here is
unsuccessful -- if someone does munge /usr/lib/sendmail, the new
"mailwrapper" won't be referenced at all because existing programs use
the /usr/lib/sendmail path explicitly, so having the mailwrapper bits
rotating around on the disk unused won't actually fix anything.

A big +1 for delivering a wrapper in place of /usr/lib/sendmail, but
not for the introduction of a new /usr/sbin/mailwrapper binary -- it
seems exceedingly unlikely that anybody would ever use that new
pathname, so it'd serve no purpose.

I _think_ your idea here was to allow for a way to people to "fix"
their systems after having damaged them.  But such a way already
exists -- just reinstall the package.  We even include packaging tools
to detect when packaged bits are damaged in the first place.  We don't
need to squirrel away binaries in unused areas "in case" someone needs
to recover them.

Simplify: just replace the sendmail path.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677