RFC: Sendmail deprecation ?

[Rich Kulawiec]

On Thu, Dec 07, 2017 at 02:07:54PM -0800, Xin LI wrote:
> On Thu, Dec 7, 2017 at 8:49 AM, Warner Losh <imp at bsdimp.com> wrote:
> > It's bad that sendmail is such a security nightmare too. We should likely
> 
> I don't think there is fact that backs this claim (I don't personally
> have strong opinion on Sendmail removal though).  Sendmail might well
> be a nightmare a decade ago but not anymore.

I've been running sendmail since it existed, in all kinds of environments.
(And let me note that I've  spent substantial time with the common
open-source alternatives to it as well, so I have a great deal of
direct experience to draw on for comparisons.)

It is most emphatically NOT a security nightmare.  It's had its issues,
but no serious ones in years. [1]  And over the past decade, it's had a number
of features slowly/carefully added that have gradually hardened it against
attacks and abuse.  (greet_pause, for one.)  There have also been
similarly-gradual improvements in its configuration: almost nobody
edits .cf files any more.  (Instead, they build them from .mc files.
A substantial library of these is supplied and many more are just
an Internet search away.)

We are not at the point where it's a trivial install-configure-run
piece of software.  But we are NOT going to be at that point with
sendmail or any other MTA in the forseeable future because not
only are the basic operational requirements of an MTA complex,
the contemporary environment it has to run in is best described
as "constant attacks and abuse interrupted sporadically by actual
real live mail".  Anyone who doesn't have at least a modest working
knowledge of all this shouldn't be running an Internet-facing MTA,
whether it's sendmail or postfix or exim or anything else.  (It's
fine to run simple instances that forward or are internal-only.  That's
a much lower bar to clear in terms of the required knowledge.)

Sendmail is actively supported (by its developers and by the community).
And if you read the release notes that are issued with source updates,
you'll find that they tend to eschew many releases in favor of a few.
That is, they bundle many ports, fixes, updates, features, etc., into
each release.  This works out well for two reasons: first, they're
really good at it. Second, it alleviates the need to upgrade production
systems on a frequent basis.  So don't be misled by the infrequency
of version updates.

One of the other very handy things about sendmail is that it ships
with a sensible default configuration.  This in turn tends to forestall
a lot of bad things that could happen but probably won't.  Note that
this configuration isn't optimized or customized: but that's the point.
(Note also, as I recently pointed out to someone, that when you
attempt to optimize your MTA you need to be careful that you're not
also optimizing it for your adversaries.)

My recommendation is to (1) leave sendmail in place (2) track, as much
as possible, the default configuration published by its authors and
(3) consider making it clear at installation time what a smarthost
is and why someone might want to use it.  (Briefly, a "smarthost"
is one with an MTA that is fully configured, knows how to deliver
amil across the Internet, etc.  Non-smarthosts have a barebones
configuration that renders them unable to do anything other than
(a) accept mail and (b) throw it at the smarthost.  This is the
preferred arranagement for a lot of end-user systems, and for many
server environments: if you have N systems, configure N-1 to throw
all the system-generated mail at the smarthost, and then configure
the smarthost to do something useful with it.)

---rsk

[1] Let me also observe that our collective perception of what a
"serious issue" encompasses has shifted over time.  Some of the
issues that would have caused an entire IT operation to immediately
shut down are now accepted as routine.  And some of the issues that
we once ignored as trivial are now considered show-stoppers.  So it's
useful when, let's say, looking at the sendmail bug exploited by
the Morris worm and assessing its severity, to consider the context.