From owner-freebsd-security  Sun Jan  5 16:49:23 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id QAA25993
          for security-outgoing; Sun, 5 Jan 1997 16:49:23 -0800 (PST)
Received: from fools.ecpnet.com (moke@fools.ecpnet.com [204.246.64.101])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA25986
          for <freebsd-security@freebsd.org>; Sun, 5 Jan 1997 16:49:20 -0800 (PST)
Received: from localhost (moke@localhost)
          by fools.ecpnet.com (8.8.4/8.8.4) with SMTP
	  id SAA19982 for <freebsd-security@freebsd.org>; Sun, 5 Jan 1997 18:47:31 -0600 (CST)
Date: Sun, 5 Jan 1997 18:47:29 -0600 (CST)
From: Jimbo Bahooli <moke@fools.ecpnet.com>
To: freebsd-security@freebsd.org
Subject: sendmail....tricks...
Message-ID: <Pine.BSF.3.95.970105182549.18011A-100000@fools.ecpnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


	Well in watching this mailing list and many others, the solution
to the sendmail problem seems to be not run it as root. Yet, because of
the performance hit many do not wish to start it from inetd. I have found
somewhat of hack solution with a few downfalls, but seems to work.

The first idea, which i have successfully accomplished, is logging and
access control via tcp wrappers.

This idea uses netcat, /usr/ports/net/netcat, and some configuration.

First, I setup sendmail to bind to a different port by changing this line
in sendmail.cf to:
O DaemonPortOptions=Port=26
This could easily be a port above 1024 allowing it to bind to its port as
a non-root user.

Second, I linked /usr/local/bin/nc (netcat) to /usr/local/bin/recvmail to
make logs more readable when tcp wrappers style logging is used.

Third, I added a line to /etc/inetd.conf,
smtp     stream tcp     nowait  nobody  /usr/libexec/tcpd    
/usr/local/bin/recvmail  -w 3 127.0.0.1 26

(all on one line of course)

Restarted everything, and now I get nice log entries of each mail connect,
with the increased overhead of running a netcat, which compared to a new
sendmail from inetd is very small.

Any comments on this? Time permitting I am going to explore running
sendmail on a non-root port and having netcat forward connections to it
from inetd.

-moke@fools.ecpnet.com