Question : I often find many errors DEFERRED

I have many errors in /var/spool/mqueue what can I do?
I use solaris 2.8. There are a lot of messages Deferred what does it means? How can I fix it?
 
1) Is it good idea to do
 # cd /var/spool/mqueue
 # rm *
 or # cp /dev/null /var/spool/mqueue or
 is it the same?

2)I can see running
 ps -ef |grep sendmail
 5 processes sendmail are running. Do I have to kill any of them and let only one running?

3) Is it any way to debug my server if it is ok or is it
a problem of my dialup users.

4) If I kill the unique process of sendmail how can I reread the configuration file maybe
 #pkill -HUP sendmail is it ok?

5) If I decide not to delete the file from mqueue. Is there any command to tell to sendmail to try itself later in order to resend these mails?
Thanks

Answer : I often find many errors DEFERRED

Deferred messages don't necessarily indicate a serious problem. A message will move into a deferred state if sendmail can't deliver it on the first attempt. And that can be because the nameserver responsible for the target domain isn't accessible at the moment, or the remote SMTP server may be down or too busy, or there could be no route to the name server for the domain or the SMTP server, or there could have been errors during the first delivery attempt. Sendmail will keep the message in the delivery queue and periodically retry the delivery for a limited period of time. The intervals between delivery attempts are determined by what queue interval (-q option) was specified when sendmail was started, e.g., "sendmail -bd -q15m" says to run the queue every 15 minutes. If you have problems with a number of messages sitting in the delivery queue (check with "mailq") it is probably best to run the queue less often, perhaps once an hour or two (-q1h or -q2h). One a message enters the delivery queue and can't be delivered on the first attempt sendmail will keep track of how long the messages sits in the queue. After 4 days of delivery attempts (typically) the message will be automatically dropped from the queue and a bounce message set to the message's originator. You should never delete messages from /var/spool/mqueue unless you have certain knowledge that the message can never be delivered.

It is normal to see multiple sendmail processes running. The master sendmail process will fork off a copy of itself for each message that it handles. The children will normally terminate on their own when they have finished processing the message. Occasionally you'll find a sendmail process that's been running for many hours or days. It is possible for a sendmail process to get into a stalled state and never exit, but if you check those processes won't be consuming CPU time.

Under ordinary circumstances the only time that sendmail needs to be told to read it's config files is when local-host-names (aka sendmail.cw) or sendmail.cf has been changed. All of the DB files (aliases, virtusertable, genericstable, etc) are "read on the fly". To get sendmail to re-read local-host-names or sendmail.cf it is necessary to kill sendmail and restart it. A -HUP won't do it.