When submitting mail by using sendmail as a mail submission program, sendmail copies all messages to "/var/spool/clientmqueue" first. Sendmail is a setgid smmsp program and thus gives any user the permission to do so (/var/spool/clientmqueue belongs to user and group smmsp). Later, another sendmail process, the sendmail mail transfer agent (MTA) copies the messages from /var/spool/clientmqueue to /var/spool/mqueue and sends them to their destination.
/var/spool/clientmqueue is thus the holding area used by the MSP (Mail Submission Protocol) sendmail instance before it injects the messages into the main MTA (Mail Transport Agent) sendmail instance.
Sendmail will save the message in /var/spool/clientmqueue for safe keeping before trying to connect to the MTA to get the message delivered. Normally there would be a 'queue runner' MSP sendmail instance which every half hour would retry sending any message that couldn't be sent immediately. Each message will generate a 'df' (message routing info) and 'qf' (message headers and body) file. You can list out all of the messages and their status by:
# mailq -v -AcWhen files accumulate in /var/spool/clientmqueue, this is probably due to sendmail localhost MTA not running, and thus the mails don't get send.
- sandip's blog
- Login or register to post comments
Comments
THANKS to all who wrote in this thread. The very last sentence: "Another helpful operation is sendmail -Ac -q -v the verbose comments make a huge difference" was EXTREMELY helpful as it finally revealed to me that sendmail wasn't running as the correct user because the submit.cf file was autogenerated with the wrong filename. I created a symbolic link so there was a /etc/mail/submit.cf from the "hostname.submit.cf" file that got generated when I set up sendmail on this system, and that did the trick. I wouldn't have figured it out without the verbose mode comment in this thread, so thanks!
The files in clientmqueue and mqueue are named thus: first letter for "type and status", second letter is "f", rest is the sendmail queue ID that you see in the logs and mailq output.
The first letter is usually one of :
d: the body of the mail
q: routing information and headers when the message is normal
Q: rename of the "q" file when the message is abandoned for some reason
h: rename of the "q" file when the message is held (quarantined by a milter)
t: temporary file
x: transcript of delivery attempts
Hi there
I had the same issue and sendmail -q did not work.
even sendmail -Ac -q did not work
Check your DNS settings /etc/resolv.conf and make sure your DNS settings are correct.
This fixed it for me.
Another helpful operation is
sendmail -Ac -q -vthe verbose comments make a huge difference.