>
>I can think of one.  A non-queueing sendmail will attempt delivery
>itself.  This can hang if DNS will hang (for instance you dial up
>part time to the net only, and other times, there is no root DNS 
>server reachable).  This can be bad for something running out of
>uucp.  Also, on larger systems, an rmail to many recipients can take
>time, esp. if the host is forwarding to others, and what if one of 
>those is down, etc, etc.

My point here was, is this is a site specific configuration issue. Leaf
uucp sites only get mail for themselves generally. Queuing in that case
makes no sense. The choice to queue or not queue incoming uucp mail
should be something left up to the machine admin in a configuration
file, not compiled into rmail. If you want outgoing mail to always queue
just set e on the Mailer definitions. However if I don't want it to
queue I have no choice but to go get the rmail source and modify it (once
I figure out why it's happening.)

>
>I ran into this, I just had my cron job run sendmail -q after UUCP
>was finished (I ran uucico in the foreground, then ran sendmail -q).

It's what I was doing, but there's no point in even having to do this if
the option was left up to sendmail.cf like it should be. At the worst case
the rmail man page needs to be updated to note the fact it passes these
options to sendmail.

James