Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jan 1999 15:37:05 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        "Joseph M. Scott" <jmscott@ainet.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: HEADS UP: defaults changed in sendmail.cf 
Message-ID:  <199901130737.PAA69828@spinner.netplex.com.au>
In-Reply-To: Your message of "Tue, 12 Jan 1999 19:32:47 PST." <Pine.GSU.4.05.9901121928230.16124-100000@www.ainet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
"Joseph M. Scott" wrote:

> > 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).
> 
> 	I'll have to go back and check, but I this type setting can still
> allow anyone with control of their dns to relay mail through a system.  If
> spam.com adds norelay.com to their mx list then spam.com can relay off of
> norelay.com.  This is just quickly off of what I remember when reading
> about these options when they first came out.  If I'm totally wrong (
> which is not totally out of the question by any means :-) please let me
> know.  Also, even if what I just stated is true, I do think, like you
> said, it is a good transition step.

If spam.com adds norelay.com to their MX list, then *everybody else* can
relay *to* spam.com via norelay.com.  spam.com cannot *send* via
norelay.com!

> > 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.
> 
> 	Which ones where turned on?

You could look at the source..  :-)
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/sendmail/freebsd.mc

> > 4: some default paths are different, in line with Eric's plans to move 
> > everthing to /etc/mail for the next release.
> 
> 	I take it that the previous items in /etc/mail have been removed
> then?  ( I thought I'd read something about them at least been renamed or
> something )

No, "move *to* /etc/mail" was what I wrote.  Most stuff that used to default
to cluttering /etc is moving to /etc/mail.

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901130737.PAA69828>