Date: Sat, 9 Dec 2017 12:35:41 -0500 From: Rich Kulawiec <rsk@gsp.org> To: freebsd-arch@freebsd.org Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171209173541.GA733@gsp.org> In-Reply-To: <CAGMYy3syibGB=NoA41YwwdQR6p=MVrTBY32sckworFR2s4Cn-w@mail.gmail.com> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net> <CANCZdfru0LiT1KbbobCifzF_SjOQ%2B_1HPZ6Q06m_yhsqZDqh1g@mail.gmail.com> <CAGMYy3syibGB=NoA41YwwdQR6p=MVrTBY32sckworFR2s4Cn-w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171209173541.GA733>