John Von Essen
john at essenz.com
Sun Jun 22 18:21:49 PDT 2003
The problem with depending on sendmail -bd -q30m to clean out
/var/spool/mqueue is that it is slow! This is why I want to run a
separate Persistent Queue runner for mqueue.
In my case I have a fallback mx server which gets all the "bad" email
(undeliverable, slow recipient, etc.,.). The problem is sometimes the
fallback is under heavy load, and mail to the fallback gets queued on
my slave nodes. The mail has to get off the slave nodes quickly, this
is why I want a persistent queue runner for mqueue and clientmqueue.
The fallback machine is doing the standard -bd -q1h and -Ac -q1h, which
Obviously this all comes down to preference. In my case I WANT a
listening daemon, mqueue runner, and clientmqueue runner. I am
surprised that rc.sendmail wont grant my request. In the end, I will
simply re-code rc.sendmail to do what I want. But again, I dont
understand the harm of having rc.sendmail behave the way I want it to
behave. If I select sendmail_outbound_enable="YES" - what is the harm
is doing what I ask - why does rc.sendmail have to get in my way.
On Sunday, June 22, 2003, at 04:14 AM, Matthew Seaman wrote:
> 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
>> rc.sendmail and I do understand how everything works. My question is
>> WHY was it designed to behave they way it does?
>> Why isn't rc.sendmail setup such that you can start the listening
>> daemon for inbound, queue runner for outbound, and the msp queue
>> runner. (Currently, you cant start that config with rc.conf and
>> 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.
>> Obviously, you can't run the localhost submission daemon AND the port
>> 25 remote daemon listening for inbound. For that case, it is either
>> or the other - so that part of rc.sendmail makes sense. But if I
>> "YES" to enable both the mqueue runner and the clientmqueue runner in
>> rc.conf, the rc.sendmail script will not perform this. The logic of
>> rc.sendmail will only start mqueue if sendmail and sendmail submit are
>> set to "NO". Likewise, if you select sendmail "YES", then the only
>> other thing you can run is the clientmqueue runner.
>> In my case, I need to run the sendmail daemon, the mqueue runner, and
>> the clientmqueue runner. In other words, I need the following at
>> /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.
>> /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
>> rc.conf and rc.sendmail cannot startup what I want. As a result, I
>> to do sendmail_enable="NONE", and then from rc.local startup what I
>> want manually.
>> Why can't rc.sendmail be designed such that whatever has "YES" in
>> rc.conf will get started?
> If you think you can do it better, please do submit patches.
> 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
More information about the freebsd-questions