Date: Wed, 29 Jul 1998 15:27:49 -0700 (PDT) From: Sean Eric Fagan <sef@kithrup.com> To: committers@freebsd.org Subject: Re: sendmail 8.9.x Message-ID: <199807292227.PAA02559@kithrup.com> In-Reply-To: <Pine.BSF.4.00.9807291506420.24795-100000.kithrup.freebsd.cvs-all@resnet.uoregon.edu> References: <199807291531.XAA01198@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.BSF.4.00.9807291506420.24795-100000.kithrup.freebsd.cvs-all@resnet.uoregon.edu> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807292227.PAA02559>