clientmqueueディレクトリは、SendmailなどのMTAが正常にメールが送信できなかった場合に一時的に溜め込まれるメールボックスのようなものです。
MTAはこの、clientmqueueディレクトリにメール（ファイル）がある限り再送しようと試みます。
さて、私の管理しているサーバー（RedHatES4）では特にSendmailなどのMTAは動かしていないのですが、このclientmqueueディレクトリ以下に大量のファイルが吐き出されていました。
原因は、cronで動かしていたバッチプログラムにエラーが発生しており、その標準エラー出力がメールとして信されるようになっていたのですが、MTAの設定はしていなかったためメールが送信できずにclientmqueueにメール（ファイル）が保存されたという具合です。
このclientmqueue以下に吐き出された大量のファイルをどうにかしたいと言うのであればメールで吐き出すか、ファイルを全て削除してしまうかのどちらかになります。
そのサーバーにMTAの設定がされており、今回何らかの原因でメールが送信されていないということであれば、その原因を取り除けばメールは送信されるはずです。
MTAの設定がされていないと言う事であれば、その設定をするよりは削除した方が楽です。
※ ただし、ファイルを削除する前に内容を確認しておく事をお勧めします。
大量のファイルへの対処は上記で解決はしますが、根本的にファイルが吐き出された原因への対処を行わないと再びclientmqueue以下にファイルが吐き出されます。
原因は、大量に吐き出されたファイルの中身をエディタかページャを使ってみてみると分かるかもしれません。
また、MTAが正しく設定されいる（はず）のサーバーでは、その原因を調べるにはmaillogを見た方がよい場合もあります。（原因は、もしかしたらメールサーバー側にある場合もあります）
今回、私の環境ではcronで実行した際の標準エラー出力の処理を誤っていたため、その内容がメールとして吐き出されたと言う事だったので、標準エラー出力の処理をどうにかしてやる必要があります。
例えば、PHPでバックアップ用のプログラムをcronで毎日2時に動作させる場合
0 2 * * * /usr/local/bin/php /home/hogehoge/backup.php > /dev/null
と書くと「標準出力」は/dev/nullに消えますが、「標準エラー出力」は/dev/nullには吐き出されません。
標準エラー出力も/dev/nullに吐き出して、消す場合は
0 2 * * * /usr/local/bin/php /home/hogehoge/backup.php > /dev/null 2>&1
とします。
※ cronでの実行シェルがsh・bash系の場合。
cronにおける実行シェルは、/etc/crontabの「SHELL」の記述によって指定可能です。
指定がない場合は、「/bin/sh」
さて、これで一件落着と言いたいところですが、そもそもこの問題になっていた標準エラー出力はエラーの内容そのものであり、プログラムが問題を起こした原因になります。
それを、/dev/nullというブラックホールに放り投げて闇に葬ってしまったら、解決できるものもできなくなってしまいます。
その他で、バッチプログラムの実行が失敗したりその原因がつかめる構造になっているのであれば問題はないかもしれませんがそうではない場合、この標準エラー出力を何らかの形で残しておいた方が運用上よいでしょう。
そのような場合は、この「/dev/null」部分をその他の実在するファイル置き換えてやると解決します。
つまり、
0 2 * * * /usr/local/bin/php /home/hogehoge/backup.php > /var/log/batch.log 2>&1
のような感じになります。
標準出力、標準エラー出力が「/var/log/batch.log」ファイルに吐き出されるので、問題が出た場合にここを参照すれば、原因がわかります。
標準出力と標準エラー出力を分けたい場合は、
0 2 * * * /usr/local/bin/php /home/hogehoge/backup.php 1> /var/log/batch.log 2> /var/log/batch_error.log
とでもしておけばよいでしょう。
エラーを把握すると言う事は、運用上重要な事になります。
それらの原因を特定するために、また問題の解決をスムーズに行うために、何らかの形で記録させるような設定が望ましいです。