From owner-cvs-all Wed Jul 29 15:28:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14597 for cvs-all-outgoing; Wed, 29 Jul 1998 15:28:22 -0700 (PDT) (envelope-from owner-cvs-all) Received: from kithrup.com (kithrup.com [207.126.97.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14592 for ; Wed, 29 Jul 1998 15:28:21 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id PAA02559; Wed, 29 Jul 1998 15:27:49 -0700 (PDT) (envelope-from sef) Date: Wed, 29 Jul 1998 15:27:49 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199807292227.PAA02559@kithrup.com> To: committers@freebsd.org Subject: Re: sendmail 8.9.x In-Reply-To: References: <199807291531.XAA01198@spinner.netplex.com.au> Organization: Kithrup Enterprises, Ltd. Sender: owner-cvs-all@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you write: >> > 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.) Enveleop information is untrustworthy. >> 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. >For the record, I had a brainstorm: > > Provide some stock .cf's for common situations, kind of like how we > provide some stock firewall configurations: 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? At this point, any spam I get that is relayed through someone is placed on the RBL immediately. Keep that in mind.