I think you're confused about some aspect of the functionality of
sendmail; at MIT, client machines run sendmail -q every half hour and
don't run a sendmail daemon, and they handle local mail delivery and
the like without trouble.  (The delayed message problem occurs because
many of our NetBSD clients are lacking such a cron job, due to a bug
in our local setup procedures.)  Bounces are routed appropriately
since envelope from addresses get rewritten.

The point is that, right now, if you install a NetBSD system out of
the box and configure its network, mail to outgoing sites will work
most of the time, but queued mail will sit around in the sendmail
queue essentially forever without any retransmission attempts.

> If you spool incoming AND outgoing mail to the mail hubs directly,
> then that makes sense, but even if you're going to be sending mail
> from a machine, you should start sendmail on it.

Even if you normally spool outgoing mail to the mail hub (which most
clients do), the mail hub may be down from time to time, so you need
something to clean out the queue.  But why should one start a sendmail
daemon on a machine just to send mail from it?

> It's kind of a pity you can't just do a 'sendmail -send-only' and
> have it just sit there processing the queue as needed, and have it
> refuse in- coming connections

All such a sendmail process would do is sit there and try to delivery
the queue every N minutes.  cron is perfectly good at initiating tasks
every N minutes; there's no reason to have a sendmail process doing
it.

> I can't see a single valid reason not to run sendmail at all.

1. It's a big security hole.

> Even if you're the only user on a standalone machine, some processes
> want to send you mail if they blow up.

sendmail is quite capable of delivering mail locally without a daemon
running.

> Didn't you just say the same thing twice here?

Um, no, not unless I'm confused.