Date: Fri, 22 Sep 2000 13:11:51 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: security@FreeBSD.ORG, Peter Wemm <peter@netplex.com.au> Subject: Re: sendmail default run state Message-ID: <200009222012.e8MKCRF12785@cwsys.cwsent.com> In-Reply-To: Your message of "Fri, 22 Sep 2000 21:56:16 %2B0200." <20000922215616.A33103@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000922215616.A33103@mithrandr.moria.org>, Neil
Blakey-Milner writ
es:
> [ moved to security@ ]
>
> > > I've had a few followup comments already. A modification:
> > > sendmail_enable="outbound" # choices: YES, NO, outbound
> > > sendmail_flags="-bd -q30m" # flags for full in/out mode
> > > sendmail_outbound_flags="-q30m" # for when $sendmail_enable="outbound"
> > >
> > > and we set sendamil_enable="outbound" by default. That will break the
> > > least number of people. If people only had sendmail_enable="YES", then m
> y
> > > first proposed change would break them.
> >
> > I think we should keep the "YES"/"NO" nature of *_enable if at all
> > possible, even if it means having to do a bit more work, or to have to
> > mention things in release notes or upgrade guides. From a glance, it
> > seems this would be the first *_enable to take anything but "YES" or
> > "NO".
>
> I've also noticed we'd need to teach sysinstall about it - it has toggle
> stuff for sendmail_enable at the moment.
>
> > sendmail_enable="YES" # run the sendmail MTA
> > sendmail_outboundonly_enable="YES" # don't listen for messages from the net
> work
> > sendmail_queuetime="30" # time in minutes between re-trying queued items
> > sendmail_flags="" # additional sendmail flags
> >
> > Then, when we call sendmail much more complexly:
> >
> > case ${sendmail_enable} in
> > [Yy][Ee][Ss])
> > case ${sendmail_outbound_enable} in
> > [Nn][Oo] | '')
> > ;;
> > *)
> > case ${sendmail_flags} in
> > *-bd*)
> > ;;
> > *)
> > # don't add -bd if we already have it (necessary?)
> > sendmail_flags="${sendmail_flags} -bd"
> > ;;
> > esac
> > ;;
> > esac
> >
> > case ${sendmail_flags} in
> > * -q*)
> > ;;
> > *)
> > # only add -q if we not set in sendmail_flags
> > sendmail_flags="${sendmail_flags} -q${sendmail_queuetime}m"
> > ;;
> > esac
> >
> > if [ -r /etc/mail/sendmail.cf ]; then
> > echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags
> }
> > fi
> > ;;
> > esac
>
> What do others think of this? (orignally Peter's idea)
>
> I personally would really like 'sendmail_outbound_only="YES"' to be the
> default in /etc/defaults/rc.conf, with an option in sysinstall's Network
> Services for turning it on/off.
>
> Reason being the most common situations I see are multi-system networks,
> where you read mail on just one, and not necessarily running sendmail on
> the machine that does receives mail. In the single-user case, also,
> people don't tend to want to allow connections. It's more a special
> case to receive mail, and it's quite simple to flick the switch, since
> you have to set up sendmail to receive mail for your domain anyway.
>
> Obviously this would require a heads-up to current@ when implemented,
> and a heads-up to stable@ when MFC'd, and an entry in the release notes
> and in UPDATING, and finally an entry in rc.conf(5).
>
> Comments eagerly sought,
Good idea. I'm not sure how many FreeBSD users use Sendmail. I use
Obtuse Systems Smtpd (the smtpd port) for inbound and Sendmail for
outbound. One can use Postfix for inbound and Sendmail for outbound as
well. I would guess that most people on this list probably use Qmail,
so this may not even be an issue. I suppose it depends on that the
majority wants.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009222012.e8MKCRF12785>