From owner-freebsd-current Wed Jan 1 21:44:44 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44D9037B401 for ; Wed, 1 Jan 2003 21:44:42 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD51D43ED1 for ; Wed, 1 Jan 2003 21:44:41 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0004.cvx40-bradley.dialup.earthlink.net ([216.244.42.4] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18Ty9g-0004n1-00; Wed, 01 Jan 2003 21:44:33 -0800 Message-ID: <3E13D095.FC52B758@mindspring.com> Date: Wed, 01 Jan 2003 21:39:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Claus Assmann Cc: freebsd-current@FreeBSD.ORG Subject: Re: 5.0-RC2 informal PR: 90 sec sendmail delay References: <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c5446792193d3ed8a28ccda84d973510667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Claus Assmann wrote: > On Wed, Jan 01, 2003, Terry Lambert wrote: > > I'm not too happy about some of the changes to Sendmail recently, > > Which? And why? > > If there are problems, the authors would like to hear > about it directly, instead of reading it in some mailing > list by accident... It's an editorial complaint. I don't like the breaking the program into seperate programs by function. IMO, DJB is wrong, and this does nothing to enhance security. The result of doing this in FreeBSD has been to greatly complicate rc scripts, with the result that sendmail is much less of an unpluggable component that can be replaced with something else, easily, and with little system impact. I understand the "security" reasoning, based on having to compete with qmail and other packages that claim this seperation magically fixes all security issues. But it's just a propaganda move, and it's not technically justified. Similarly, the interior seperation, which is what resulted in the DNS lookup that brought up the link in this current discussion thread, fails via a timeout before the lookup is done, and so the transfer fails. Whistle had to address this problem for Ricoh, with the InterJet, as well, since a linkup could take sufficient time that the timeout would fire, and the mail would never end up getting sent (it would get aged into the queue as "can't lookup destination host"). > > but I understand, from a marketing perspective, why they are > > being made, to compete with DJB's security claims on qmail, and > > Weitse's claims on seperation of operation on performance (both > > claims are bogus, but it's complicated to explain to potential > > customers why that's the case). > > We are not making changes "from a marketing perspective". > > If you are referring to the separation of sendmail into MTA and > MSP: this was necessary to get rid of sendmail being set-user-ID > root, which is a security risk (as you will probably agree, this > isn't marketing, this is real, e.g., sendmail was abused in some > cases to exploit bugs in the OS). Nope. I don't agree. I think the change makes things harder, and I don't see a difference in the volume of security advisories (e.g. not a lot of advisories warning about people being able to obtain the "$MAILUSER" identity through some buffer overflow, rather than "root"). At one point, sendmail was getting a lot of crap in the trade press over running suid root... but, IMO, that's all it was: crap. It was just a hook that people could hang marketing arguments against sendmail on, to FUD people into using a different product. Any reaction to FUD is a marketing reaction, unless there's provable technical merit in the decision. And one result is a FreeBSD where it's harder to pull sendmail out and replace it (also a marketing win, from a sendmail perspective). Personally, I use sendmail, so yanking it out is not high on my list of things to do, but it's now harder to have base mail functionality without parts of sendmail sticking around. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message