From owner-cvs-all  Wed Jul 29 16:34:18 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA00836
          for cvs-all-outgoing; Wed, 29 Jul 1998 16:34:18 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00795
          for <committers@FreeBSD.ORG>; Wed, 29 Jul 1998 16:34:07 -0700 (PDT)
          (envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA01854;
	Wed, 29 Jul 1998 17:33:34 -0600 (MDT)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id RAA00686; Wed, 29 Jul 1998 17:33:32 -0600
Date: Wed, 29 Jul 1998 17:33:32 -0600
Message-Id: <199807292333.RAA00686@mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Sean Eric Fagan <sef@kithrup.com>
Cc: committers@FreeBSD.ORG
Subject: Re: sendmail 8.9.x 
In-Reply-To: <199807292227.PAA02559@kithrup.com>
References: <199807291531.XAA01198@spinner.netplex.com.au>
	<Pine.BSF.4.00.9807291506420.24795-100000.kithrup.freebsd.cvs-all@resnet.uoregon.edu>
	<199807292227.PAA02559@kithrup.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >> > 	FEATURE(relay_entire_domain)
> 
> As I understand this feature, if this is enabled, the site can still
> be put on the RBL for relaying.  (Much to nobody's surprise, thieves
> often lie about who they are when they are committing their acts of
> theft.)

Probably, but it's better than the stock setup.

> >> I think this should be on by default when we ship:
> >> 
> >>    FEATURE(relay_based_on_MX)
> >
> >Can we do both?  Both are perfectly reasonable options that stops the
> >grand majority of relay abuse.  
> 
> The first does not stop the grand majority of relay abuse.  I can speak as an
> expert here.
> 
> The second is less so, but still abusable, and will still likely result in
> blackholing.

Both are abusable.

> Why don't we also stop providing security fixes in new releases, and
> provide versions of, say, qpopper, that are still susceptible to
> widely-known exploits?

Poor example.  Why don't we provide the system with IPFW enabled by
default, thus making them totally secure from network problems?  In
essence, not allowing most 'networks' to get email.

If you don't want a chance to get spammed or be a spammer, disable
sendmail completely.  But, if we want people to get email at all, then
set it up *better* than the current default, but not so secure as to be
unusable.



Nate