From owner-cvs-all Wed Jul 29 08:34:06 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14633 for cvs-all-outgoing; Wed, 29 Jul 1998 08:34:06 -0700 (PDT) (envelope-from owner-cvs-all) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14452; Wed, 29 Jul 1998 08:33:50 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id XAA01198; Wed, 29 Jul 1998 23:31:46 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199807291531.XAA01198@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Chris Timmons cc: Peter Hawkins , committers@FreeBSD.ORG Subject: Re: sendmail 8.9.x In-reply-to: Your message of "Thu, 23 Jul 1998 15:59:32 MST." Date: Wed, 29 Jul 1998 23:31:45 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Timmons wrote: > > I think the only issue that would trip people up is needing > > FEATURE(relay_entire_domain) > > if hosts use the machine as an SMTP gateway (we have lots of PCs running > pegasus/eudora/etc that do this.) I think this should be on by default when we ship: FEATURE(relay_based_on_MX) This means, that the current machine gets a message that would be relayed to a host in foo.org, and the current machine is a listed MX handler for foo.org, then it will automatically relay it. This simplifies configuration a fair bit, stops the spammers etc. It doesn't prevent you from being listed as a MX handler without your permission, but I suspect this is the least of everybody's worries at the moment though (you can explicitly block this to prevent abuse from specific sites though). > Also, if your machine is > "freebie.admin.foo.com" and you want to relay for anything in *.foo.com, > you'll need to make sure that you put foo.com in your $=m class, as in: > > Cm foo.com > > Nevertheless I agree with you and Dima that we should upgrade, and accept > the spam inhibiting defaults. > > Peter Wemm has done a great job keeping up bind & sendmail for the FreeBSD > project; let's wait a bit to see how he is doing (Jordan said he had taken > ill.) I'm not having much fun at the moment.. :-( > He may have a direction in mind already... I'm hesitating on what to do, so I'd like some feedback. What I have done is: src/contrib/sendmail (since the license may be significant to some folks) src/usr.sbin/sendmail (builds/installs /usr/sbin/sendmail only) src/usr.sbin/makemap (builds/installs /usr/sbin/makemap only) .. same for praliases, rmail, mail.local, smrsh, but in their dirs .. src/etc/sendmail (for building/installing the sendmail.cf file) This is able to be imported at a moments notice. I'm not very happy about src/etc/sendmail at present. It works just the same as src/usr.sbin/sendmail/cf/cf right now (ie: does nothing by default but can be adjusted from make.conf). I'd like to use src/etc/ mail, but the Makefile there is already taken. Sendmail will move to having it's sendmail.cf file as /etc/mail/sendmail.cf in the next release, and already many of the .m4 files refer to optional files in /etc/mail. Naturally, the src/contrib/sendmail stuff would be imported and local (useful) changes merged in. Are people comfortable about the updated LICENSE? Is it worth doing a repository copy from src/usr/sbin/sendmail to src/contrib/sendmail? This will add around 6MB of bloat to the ncvs files in the repository that wouldn't happen with a clean import (only ~2MB clean, ~8MB with copy first). Considering the cost, is partitioning it off in src/contrib/sendmail an over-reaction? > -Chris > > On Thu, 23 Jul 1998, Peter Hawkins wrote: > > > I would like to put in a bid for having antispam set by default. For one > > thing those who are configured as relays do not just hurt themselves, but > > their existance at all enables spamming to take place, affecting everyone > > and undermining our own anti-spam filters. Further, it's hard to imagine > > a reason for constructing wide open relays so that it's not likely that > > this legacy default is required for backwards compatability. > > [...] more solid points truncated for brevity > Cheers, -Peter