You can select one of three delivery modes by setting the delivery_mode attribute in the config file to either of foreground, background, or queued. These select delivery in the foreground (immediate processing of incoming messages), in the background, (message is delivered by a child of the receiving process, with the parent process exiting immediately after forking), and queued. Incoming mail will always be queued regardless of this option if the boolean variable queue_only is set in the config file.
If you turn on queuing, you have to make sure the queues are checked regularly; probably every 10 or 15 minutes. If you run smail in daemon mode, you have to add the option -q10m on the command line to process the queue every 10-minutes. Alternatively, you can invoke runq from cron at these intervals. runq should be a link to smail.
You can display the current mail queue by invoking smail with the -bp option. Equivalently, you can make mailq a link to smail, and invoke mailq:
$ mailq -v
m0pvB1r-00023UB From: root (in /var/spool/smail/input)
Date: Sun, 24 Apr 94 07:12 MET DST
Args: -oem -oMP sendmail [email protected]
Log of transactions:
Xdefer: reason: (ERR 148) transport smtp:
connect: Connection refused
This shows a single message sitting in the message queue. The transaction log (which is only displayed if you give mailq the -v option) may give an additional reason why it is still waiting for delivery. If no attempt has been made yet to deliver the message, no transaction log will be displayed.
Even when you don't use queuing, smail will occasionally put messages into the queue when it finds immediate delivery fails for a transient reason. For SMTP connections, this may be an unreachable host; but messages may also be deferred when the file system is found to be full. You should therefore put in a queue run every hour or so (using runq), else any deferred message will stick around the queue forever.