On the systems I used to be responsible for (apple.com, and some others
there), I ran sendmail -q out of cron, moderated by a script that set up
locks to limit the number of queue runners to some (low) number. The
trouble with the '-q30m' argument to the daemon process is that if your
queue gets large, you can have a potentially unlimited number of queue
runner processes, and that's not good for overall system throughput. As
someone else pointed out, "cron" is intended for invoking things that need
to run periodically.

You still have that danger with sendmail -bd (unlimited children), but
there's no way to fix that without hacking on the sendmail sources. Well,
you could, I suppose, write an inetd equivalent that listened on the SMTP
port, and only allowed some N children to be running at a time (sendmail
-bs), and withdrew the SMTP listener socket when that limit was hit or
exceeded (resulting in ICMP port unreachables to peers, i.e. "connection
refused").

The program that did the locks is called "shlock" (shell script locks), and
was once included in the NNTP software distribution for B news (I wrote it
for the NNTP news transmit scripts); it is a general purpose lock file
manipulation program for UNIX, best used by scripts & such. I can make it
available to the NetBSD distribution if you all think it would be handy to
have around.

I think it would be a good idea for the default NetBSD distribution to have
sendmail -q in a crontab entry for some id (e.g. "daemon"). This way, even
if the SMTP daemon is shut off in the rc script, mail in the queue (from
random programs, etc) will be dealt with eventually.

Erik Fair