这篇文章很清楚的描述了这两个目录的区别，实际上 MSP 是由 submit.cf 文件来控制的，当邮件送到外部邮箱 user@yahoo.com 的时候，我们可以不启动本地的 sendmail 服务，系统会直接和收件人的 MX 服务器的 25 端口协商。但是如果我们发送邮件到本地帐号例如 root 或者 userabc 的时候，如果本地的 sendmail 没有启动的话，邮件就堆积在 clientmqueue 里，一旦启动 sendmail 则会把它们发送到 mqueue 里，然后发送到 local account 的邮件会写入 /var/mail/userabc 的邮件文件里，当 userabc 登录系统的时候，会看到 “You have new mail” 的提示。用户可以自己 touch $HOME/.forward 文件把本地文件转发到自己外部的邮箱，系统管理员也可以通过修改 aliases 文件，来重定向本地用户的邮件。
/var/spool/clientmqueue 爆满问题很早碰到这个问题，SW的同事也来问过我，懒得写了，抄一下放在这里吧。当你使用简单的sendmail发邮件的时候，或者系统默认要发一些邮件（比如cron发的邮件）的时候，首先会把邮件拷贝到这个目录里，然后等待 MTA(mail transfer agent) 来处理，MTA做的事情通常是把这个目录中的邮件弄到/var/spool/mqueue里，然后再发送到真正的目的地。出现/var/spool /clientmqueue/非常大的情况通常因为没有合适的MTA发送邮件，就都积累在这里了，假如这里的邮件并不是你需要的，比如是系统默认发的每分钟跑一次的什么什么cron的信，你可以简单的删掉他们。当然，文件多了一些，直接rm -f *，系统可能会说argument too long什么的，没有关系，find /var/spool/clientmqueue/ -type f Cdelete或者find /var/spool/clientmqueue/ -type f -exec rm {} \+可能对你有帮助，当然这两条命令要求find的版本比较新。如果不幸你的版本比较低，可以尝试find /var/spool/clientmqueue/ -type f -exec rm {} \;
原因分析：系统中有用户开启了cron，而cron中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了这些文件；
解决办法: 1、 将crontab里面的命令后面加上> /dev/null 2>&1
2、知识点：
2>：重定向错误。
2>&1：把错误重定向到输出要送到的地方。即把上述命令的执行结果重定向到/dev/null，即抛弃，同时，把产生的错误也抛弃。
3、具体代码：
（1）、# crontab -u cvsroot -l
01 01 * * * /opt/bak/backup
01 02 * * * /opt/bak/backup2
（2）、# vi /opt/bak/backup
#!/bin/sh
cd /
getfacl -R repository > /opt/bak/backup.acl
（3）、# vi /opt/bak/backup2
#!/bin/sh
week=`date +%w`
tar zcvfp /opt/bak/cvs$week/cvs.tar.gz /repository >/dev/null 2>&1
4、清除/var/spool/clientmqueue/目录下的文件：
# cd /var/spool/clientmqueue
# rm -rf *
如果文件太多，占用空间太大，用上面命令删除慢的话，就执行下面的命令：
# cd /var/spool/clientmqueue
# ls | xargs rm -f