In this article I’m going to review how you can process a backed up Exim mail queue on your VPS (Virtual Private Server) or dedicated server. We’ll discuss either running the queue in a controlled manor as to not spike the server’s load, or completely clearing out the mail queue so that new deliveries can be processed quickly.
From time to time emails could back up on your server, as every time a message is attempted to be sent from your server the Exim service which is the MTA (Mail Transfer Agent) on the server, places the message into a mail queue.
If that mail queue begins to get backed up due to delivery errors, this can lead to new messages being delayed, and in some cases an elevated server load, leading to further mail delivery issues as well as affecting the performance of your websites.
If you’ve read my previous articles on managing the Exim mail queue in WHM, or how to manage the Exim mail queue via SSH, you should know how to check on the mail queue itself to see if there are failed deliveries. Building upon that knowledge we’re going to review taking mass action on the mail queue when it’s more than just a few messages hanging around in the mail queue.
Please note in order to follow allong with the steps below you’ll need to have root access to either your VPS or dedicated server in order to have access directly to the Exim mail queue.
Safely try to process all messages in the mail queue
Below we’ll cover how you can go ahead and try to deliver out all messages in the Exim mail queue. This is something you might want to do if you were blacklisted by a particular service, and you’ve now verified that you are no longer blacklisted so your messages should go through.
- Login to your server via SSH as the root user.
- Run the following command to saftely process all messages in the mail queue for delivery:
for eximID in `exiqgrep -i`; do /usr/local/cpanel/bin/cpuwatch .50 exim -M
$eximID; sleep 1; done
Code breakdown:for eximID in `exiqgrep -i`; Begin a bash for loop, setting the variable eximID for each loop to the value we get back from the exiqgrep -i command which returns all of the Exim messages IDs currently in the mail queue. do /usr/local/cpanel/bin/cpuwatch .50 exim -M $eximID; Run the cpuwatch command to limit the server’s load to a 0.50 to ensure we’re not spiking the load with our mail queue processing, then run the exim command with the -M flag for sending a message followed by the current $eximID in our loop. You don’t have to run cpuwatch at a load of .50, if you’re on a VPS you can raise this up to 1.00, and on a dedicated server you can raise it to the number of CPU cores you have.
sleep 1; done After sending a message sleep for 1 second to again ensure we aren’t overloading the server processing the mail queue, then end our for loop with the done command. - You won’t see a status of the messages delivering while the loop is running. If it hits the server load limit that you’ve set with the cpuwatch command you will see the following message:
Waiting for load to go down to continueYou can keep an eye on the process of your mail deliveries by noting the current working directory you started the loop in. In this example we’ll say that you are in the directory /home/example:tail -f /var/log/exim_mainlog | grep "/home/example"You should see something similar to:2013-01-21 10:11:26 cwd=/home/example 2 args: /usr/sbin/exim -bpu
2013-01-21 10:11:26 cwd=/home/example 3 args: exim -M 1TvqIn-0002kE-Cy
2013-01-21 10:11:31 cwd=/home/example 3 args: exim -M 1TvqJK-0003Ff-DJ
2013-01-21 10:11:36 cwd=/home/example 3 args: exim -M 1TvqO6-00085E-Vn
2013-01-21 10:11:37 cwd=/home/example 3 args: exim -M 1TvqRC-0003Nq-BP
You can hit Ctrl-C to stop tailing the log at anytime.
- If you were interested in checking on the status of one given delivery attempt that just happened, you can also run the following command on the message ID, in this example we’ll use 1TvqIn-0002kE-Cy from above:
exigrep -I -l 1TvqIn-0002kE-Cy /var/log/exim_mainlogIn this case we saw that it attempted to deliver out, but the delivery failed again, so then a bounce back was issued to the original sender:2013-01-21 10:11:28 1TvqIn-0002kE-Cy == [email protected] host example.com [123.123.123.123]:
450 4.1.1 <[email protected]>: Recipient address rejected: unknown user: "[email protected]"
2013-01-21 10:11:28 1TvqIn-0002kE-Cy ** [email protected]: retry timeout exceeded
2013-01-21 10:11:28 1TvqIn-0002kE-Cy Completed2013-01-21 10:11:28 1TxJ20-0007FI-Hg <= <> R=1TvqIn-0002kE-Cy U=mailnull P=local S=2126
T="Mail delivery failed: returning message to sender" for [email protected]
2013-01-21 10:11:29 1TxJ20-0007FI-Hg => userna5 <[email protected]> R=localuser T=local_delivery
2013-01-21 10:11:29 1TxJ20-0007FI-Hg Completed
Remove all messages in the mail queue
If you’ve tried to process your entire mail queue and things are still backed up due to failed deliveries, for instance if our server was trying to send a bounce back message to [email protected] to let them know their original delivery failed, but if that account didn’t exist either the message could get stuck in the mail queue. You can use the following steps to go ahead and delete all of the messages in the mail queue so that new messages can start getting sent out right away.
- Login to your server via SSH as the root user.
- Run the following queue to remove all messages from the Exim mail queue:
exiqgrep -i | xargs exim -MrmCode breakdown:exiqgrep -i Grab every Exim message ID currently in the mail queue with the exiqgrep -i command. xargs exim -Mrm Run the xargs command which allows you to execute another command on something passed to it, in this case we’re running the command exim -Mrm which is the Exim remove mail command, and xargs is pushing each Exim message ID to it from the previous command.
You should now understand how to effectively clear out your Exim mail queue by either saftely processing the queue, or by clearing the queue. These should hopefully not be things that you have to do often, as if these type of problems are recurring then you probably need to keep closer tabs on what mailing lists your users are sending to that are causing so many delayed or failed deliveries. But at least having this knowledge will help ensure if these events do ocurr that begin to back up your mail queue you’ll have the knowledge to clear it up.
