From owner-freebsd-hackers Mon Nov 25 11:12:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01834 for hackers-outgoing; Mon, 25 Nov 1996 11:12:52 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA01815 for ; Mon, 25 Nov 1996 11:12:41 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA15280; Mon, 25 Nov 1996 13:09:37 -0600 From: Joe Greco Message-Id: <199611251909.NAA15280@brasil.moneng.mei.com> Subject: Re: Replacing sendmail (Re: non-root users binding to ports < 1024 (was: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2 To: twpierce@bio-3.bsd.uchicago.edu (Tim Pierce) Date: Mon, 25 Nov 1996 13:09:37 -0600 (CST) Cc: nate@mt.sri.com, peter@taronga.com, hackers@FreeBSD.org In-Reply-To: <9611251742.AA10825@bio-5.bsd.uchicago.edu> from "Tim Pierce" at Nov 25, 96 11:42:18 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Nate Williams said: > > > I'm with Michael. I trust sendmail much more than something I know > > nothing about. > > This amounts to defending the devil you know over the devil you > don't. While that's a sound principle, it's also something of a > last line of defense: i.e., there's no reason you can't get to > know the other devil a little better. Very true. But forcing everyone to become familiar with the other (unknown) devil by default may be a Bad Idea. > Most of the defenses of sendmail I've seen thus far can be summed > up: it's the industry standard, everyone else in the world runs > it, any administrator will be instantly at home with it. Hmm -- > and I thought that I *wasn't* running Windows! If you're running Sendmail, the chances are pretty slim that you are running Windows. > For the record, I currently run neither sendmail nor qmail (not > having a net-connected machine). I am not intimately familiar > with qmail and am not really in a position to defend it. What I > know is that I spend a lot of time with security weenies, and have > heard more about qmail in the last several months than about > perhaps any other package I'm not personally working on. I'm > inclined to believe that it deserves a closer look than the folks > here have been willing to give it. I don't think that's the issue at all. I will certainly agree that Qmail _may_ be more secure than Sendmail. This may be due to: 1) A more recent design, designed explicitly with security in mind. 2) Less people scrutinizing Qmail for security related bugs. 3) Other reasons. (On the other hand, because of #2, Sendmail will tend to have more true bugs shaken out of it. That is not necessarily a defense of Sendmail, it is more like a double-edged sword.) Peter da Silva and I have been having a running argument all morning about this very subject. :-) Here's the deal. 1) If you can make a totally transparent change to something, generally there is no reason not to. 2) If you can make a mostly transparent change to something, you need to document what the difference is, and be ready to deal with the occasional question from the people who have not read the document. 3) If you make a mildly transparent change to something, you still need to document what the difference is, but the set of differences is going to be reasonably large. You will also need to be ready to deal with a steady stream of questions from people who have not read the document. 4) If you make a moderately intrusive change to something, you probably need to start fresh with documentation. Since the delta between old and new is pretty large, there will also be a large stream of questions from people who have not read your document and/or noticed the change. 5) If you make a totally intrusive change, and decide to totally change how something works, you also need new documentation. Since many people will not read your document and/or notice the change, you will have PLENTY of questions, plus a fair number of people who wish for the old behaviour. Version to version changes in Sendmail are usually Class 1 or 2 changes. Switching from Sendmail to Qmail is a Class 4 or Class 5 change, depending on just how compatible Qmail strives to be. If you will notice, there is a penalty associated with a Class 4 or 5 change, in that you will get LOTS of questions flowing in, questions that you would not otherwise have to field. As a largely volunteer operation, I doubt the FreeBSD team has the desire or wish to increase the burden. As someone who spends a fair amount of time trying to assist others, I know that I personally would not wish to have to support a bunch of additional questions that were brought about by some change that ALSO made FreeBSD less of a standard UNIX operating system (standard as compared to what the commercial vendors typically ship). I think it is more than reasonable to offer it as an option: anyone who chooses to install it as an option is aware that their system is nonstandard, hopefully knows where to go for support, and hopefully will not be too upset if the FreeBSD team refers package specific problems to Qmail's support structure. I _personally_ will probably not choose to run a relatively unknown quantity such as Qmail as my MTA. That is a personal choice, separate from the support issues, since I try to do all my own support ;-) ... JG