Date: Sun, 22 Jun 2003 09:14:59 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: John Von Essen <john@essenz.com> Cc: freebsd-questions@freebsd.org Subject: Re: rc.sendmail Message-ID: <20030622081459.GA12760@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <A5AC358C-A464-11D7-AA6D-0003933DDCFA@essenz.com> References: <20030622115331F.matusita@jp.FreeBSD.org> <A5AC358C-A464-11D7-AA6D-0003933DDCFA@essenz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 21, 2003 at 11:50:21PM -0400, John Von Essen wrote:
> Okay, before people send more responses... Yes, I have looked at man=20
> rc.sendmail and I do understand how everything works. My question is=20
> WHY was it designed to behave they way it does?
>=20
> Why isn't rc.sendmail setup such that you can start the listening=20
> daemon for inbound, queue runner for outbound, and the msp queue=20
> runner. (Currently, you cant start that config with rc.conf and=20
> rc.sendmail due to rc.sendmail's logic)
You seem to be under the misconception that running sendmail with the
'-bd' flag so that it listens on port 25 for incoming messages somehow
negates the '-q15m' flag that tells it to scan and process the mail
queue every fifteen minutes. ie. you don't need separate sm-mta and
sm-queue processes for those functions, as the sm-mta will do both.
If your site handles a sufficient volume of e-mail that running
separate listener and queue flushing daemons would be advantageous,
then I'd recommend looking at an alternative MTA: one of exim, postfix
or qmail should be appropriate -- the FreeBSD.org mail system pumps
out enormous amounts of mailing list traffic using postfix.
=20
> Obviously, you can't run the localhost submission daemon AND the port=20
> 25 remote daemon listening for inbound. For that case, it is either one=
=20
> or the other - so that part of rc.sendmail makes sense. But if I select=
=20
> "YES" to enable both the mqueue runner and the clientmqueue runner in=20
> rc.conf, the rc.sendmail script will not perform this. The logic of=20
> rc.sendmail will only start mqueue if sendmail and sendmail submit are=20
> set to "NO". Likewise, if you select sendmail "YES", then the only=20
> other thing you can run is the clientmqueue runner.
>=20
> In my case, I need to run the sendmail daemon, the mqueue runner, and=20
> the clientmqueue runner. In other words, I need the following at=20
> startup:
>=20
> /usr/sbin/sendmail -L sm-mta -bd -q1h
> /usr/sbin/sendmail -L sm-mqueue -qp5m
Why not just run:
/usr/sbin/sendmail -L sm-mta -bd -q5m ?
The overhead of sendmail forking a child every five minutes is trivial.=20
> /usr/sbin/sendmail -L sm-clientmqueue -Ac -qp5m
I'm not sure either why you want to flush the queue quite so
frequently. Sendmail will attempt to deliver any new message
immediately. It's only if the other side can't receive the message
straight away that the messagegets stuck into the queue. Any message
held in this way should stay queued for a sufficient time to allow the
other end a chance to clear whatever problem it was causing the
hold-up.
> rc.conf and rc.sendmail cannot startup what I want. As a result, I have=
=20
> to do sendmail_enable=3D"NONE", and then from rc.local startup what I=20
> want manually.
>=20
> Why can't rc.sendmail be designed such that whatever has "YES" in=20
> rc.conf will get started?
If you think you can do it better, please do submit patches.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--5vNYLRcllDrimb99
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE+9WWDdtESqEQa7a0RAl3RAJ9cznc3ZnXsDS5xmLBOP1vjiwurRQCdGHj4
v7ryxpe2VXLM8OLrJXQO+5c=
=YdZT
-----END PGP SIGNATURE-----
--5vNYLRcllDrimb99--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030622081459.GA12760>