Checkque reports on the amount of mail waiting in the MMDF distribution queue. It indicates the total number of messages and the size of the queue directory. It then lists the number of messages waiting for each transmission channel.
The -c option allows one or more channel names to be specified. If present, checkque restricts it's report to the named channels.
The -f option causes checkque to print the name of the oldest queued message for each channel. -p causes only channels with "problems" to be listed. Problems are defined as channels which have have mail waiting for over some "problem threshold". The default "problem threshold" is 24 hours. The -t option is used to change the "problem threshold". A number of hours (or minutes, if "m" is appended) should appear without a space after the -t. -s forces an abbreviated summary listing instead of the normal multi-line report. -z causes channels with no messages queued to be skipped in the report. -h causes inclusion of a report detailing waiting mail by host for channels that serve multiple hosts.
Since the mail queue usually is protected from access by any uid, except MMDF's, checkque should be run under root or MMDF's uid. It should not be made setuid() to mmdf unless you want to allow non-staff members to see the queue status.
Most configurations will have only two channels. One is for local delivery and the second is for off-machine relaying, such as by calling out or by being called up, or by attaching to ArpaNet hosts. Local delivery usually happens at the time of submission, so it is rare that any mail is waiting in it. Mail in other outbound queues is processed by deliver according to your site parameters, either by running deliver as a background daemon or by periodically firing it up via cron.
A word about the size of the queue directory (aquedir[] under quedfldir[]): Under versions of Unix before BSD4.2, this only grows in size; there is no retrieval of space as messages are processed out of the queue. Since queues are searched linearly, this can lead to extra processing for deliver. Hence, it can be useful to know the density of the queue (how many messages are actually waiting, compared with the number of slots open in the queuing directory) in order to decide whether to compress the directory. This is a messy process, but can be worthwhile in some cases. For Unix versions after BSD4.2, however, directories are automatically compressed when files are deleted.