From owner-freebsd-current Tue Jan 12 05:54:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA21648 for freebsd-current-outgoing; Tue, 12 Jan 1999 05:54:02 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) 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 FAA21597 for ; Tue, 12 Jan 1999 05:53:58 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (peter@localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Netplex) with ESMTP id VAA66059 for ; Tue, 12 Jan 1999 21:53:22 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901121353.VAA66059@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: current@FreeBSD.ORG Subject: HEADS UP: defaults changed in sendmail.cf Date: Tue, 12 Jan 1999 21:53:21 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While updating the sendmail source from 8.9.1 to 8.9.2, I looked at the default sendmail.cf rules and decided that they were a bit on the light side. I have jumped in and turned on a few more features, including some that I suspect will cause some raised eyebrows. In particular: 1: I turned on the relay_based_on_MX feature. This is intended to ease the transition from the "default relay" to "relay denied" in 8.9.x. Note that this DOES NOT expose anybody to spam risk, although it does mean that sendmail will automatically perform a fallback relay function without explicitly being enabled. For example; if "foo.com" lists "xyz.bar.com" in their fallback MX list, then xyz.bar.com will happily relay mail TO foo.com (and only TO them, not FROM them). If foo.com did this without bar.com's permission and xyz.bar.com relayed spam to foo.com, then foo.com is getting what they deserve and has no right to complain (and they can fix it by repairing their MX configuration). 2: I turned on the Mime header overflow checking. This is a runtime cost since sendmail scans the body when it passes through the system. 3: I turned on a few more (optional) tables. Nothing happens unless the .db files are created, but the rules are present. This means that the default sendmail.cf will be a lot more useful without needing rebuilding in as many cases. I hope this represents a better medium capability sendmail.cf file. Of course it can still be tuned for specific purposes. 4: some default paths are different, in line with Eric's plans to move everthing to /etc/mail for the next release. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message