Here we provide a particularly useful command-line command that shows you which scripts are responsible for outbound mail. For example, when WordPress themes get exploited, you will see a large number of messages coming out of a long directory inside of the user’s WordPress directory. Very large numbers of messages coming from home directories is generally a source of concern.

# grep cwd=/ /var/log/exim_mainlog | cut -d = -f 2 | cut -d " " -f 1 | sort | uniq -c | sort -n

Using Exiqgrep

Much like the exigrep utility we mentioned previously, exiqgrep is also a powerful tool to help you parse through your queue output and retrieve the specific information you’re looking for.

For example, to search through your queue and output only the messages with a specific sender address, you can use the following syntax:

# exiqgrep -f [user]@domain.tld

Above: An example of using exiqgrep with the -f flag followed by a sender address, to specifically identify messages sent by a particular user.

This is particularly useful to identify the source of local spam or to determine what happened after a user reports that a sent message has not arrived (you would first check to see if they are stuck in the queue, then use the logs to find out why).

By Recipient

Need to track down messages by their recipient instead? You can use the exiqgrep command to do this as well. Here, instead of using the -f flag, we would instead use the -r flag (a bit easier to remember, right?).

# exiqgrep -r [user]@domain.tld

Above: An example of an exiqgrep command with the -r flag followed by the recipient you’d like to search the queue for.

This can be useful to investigate when a user reports that an account is no longer receiving mail. Additionally, you can use this to identify when a user has been mail-bombed, and determine if exim has been set to automatically queue messages when over-quota.

By Age

Another handy feature of the exiqgrep utility is to search the queue for messages based on age criteria. Exiqgrep uses flags based on the younger and older terminology, and appropriately uses -o for older, and -y for younger, followed by a number of total seconds.

Two practical examples of this:

# exiqgrep -o 172800

Above: An example of searching the queue for messages older than one day (172,800 seconds).

# exiqgrep -y 1800

Above: An example of searching the queue for messages younger (newer) than 30 minutes (1,800 seconds) old.

Viewing Headers

It can be extremely useful to analyze a message’s header when attempting to determine what exactly happened to that message, or how it was handled by the server.

After acquiring the message’s Exim ID value, you can then use it to specifically output that message’s header using the following syntax:

# exim -Mvh <exim-id>

Above: Using the exim command-line tool with the -Mvh flags (case-sensitive), followed by a valid Exim ID value (the <> braces are simply for the placeholder; these should not exist in the actual command), will print that message’s header information to STDOUT (read: the terminal).

Viewing the Body

Sometimes the header just isn’t enough, and you need to see what the actual contents of the message’s body look like. You can use a very similar format using the exim command-line tool again, but this time with the -Mvb flag set, followed again by the message’s Exim ID.

# exim -Mvb <exim-id>

Above: Using the exim command line tool again but with the -Mvb flag this time, still followed by the Exim ID, to retrieve the contents of the message’s body and print it to STDOUT (I’ll be using this term ‘STDOUT’ more often as we progress; if you’re not familiar with it, just remember for now that it stands for standard output, and essentially means that it prints the text normally to your terminal).

Using xargs

The xargs utility can be extremely useful for creating quick one-liner command. It’s essentially a for loop packaged up into a single command. It works by taking the output from one command, and turning it into a line-by-line execution of another command.

For example, let’s say I’ve got a text file that has a list of files in it, each on their own line.

I could cat that file, then pipe the output to xargs to perform a different operation on each of the files listed. This can be quite useful for handling Exim queue operations in bulk, which we’ll explain in a moment.

Using Pipes

To use an example, one of the most common uses you might run across is for the purposes of either “grepping” (using the grep tool to search through a file) or paging through the output of a command:

# cat /var/log/exim_mainlog | less

Above: An example command used to allow you to scroll through the contents of a log file page-by-page, rather than printing the entire contents to the screen at one time.

# exim -bp | grep SPAM

Above: An example command using a pipe to search the output of exim -bp (the command used to print a summary of each message in the queue, remember?) for any mention of the word “SPAM”, case-intact (though the -i flag of course can be used with grep to remove case sensitivity).

Resending a Message

At times, you may want to attempt to re-send a message that exists in your queue. Maybe it was delayed for some time, but you’re ready to go ahead and try to resend it now, rather than waiting for the scheduled retry. Who knows? It’s your call.

However, to do this, you can use the exim command once again, but this time by simply providing it with the -M flag alone, followed again by the Exim ID.

What can be useful here, though, is the use of this command within a one-liner, by providing the kind of piped output and xargs command that we described before.

Let’s take a look at one practical example:

# exiqgrep -r user@domain.tld -i | xargs exim -M

Above: In this example command that utilizes piping and the xargs command, we’re instructing Exim to provide us with all messages in the queue (exiqgrep) with the recipient designated as user@domain.tld (-r user@domain.tld), and informing the exiqgrep tool that we ONLY want to output the Exim IDs that match (-i).

This, by itself, gives us a basic, line-by-line output of Exim IDs that match messages with user@domain.tld as the recipient address.

So you can probably guess what we’re doing with that next, right? We’re piping (|) that output as input for xargs to perform the exim -M command on each matching message. We know now that exim -M attempts a resend of messages, so we can discern that this full command will try to resend all messages that have the user@domain.tld address as its recipient. All in one fell swoop. Nice, right?

Deleting a Message

Now for the scarier stuff. Well… not-so-scary as long as you take caution to confirm what it is you’re taking action on.

At some point in time, you’ll almost certainly need to delete messages from your queue. When that time comes, it’s likely that it won’t just be a single message, either. You’ll probably need to clear out a large number of messages that you’ve determined as spam or otherwise “bad” mail.

The basic command syntax you would use to do this involves the exim tool again, but with the -Mrm flags this time, and again – as usual – followed by the Exim ID of the message:

# exim -Mrm <exim-id>

Above: The basic syntax for deletion of a message from the queue, based on its Exim ID. Again, we see the pattern (-M followed by rm; just like you’d rm a file from the file system).

So how about doing this as a bulk operation?

Deleting in bulk should of course always be performed with caution. Once you delete mail from your queue, there’s no guarantee that the sender will ever resend it.

So, if you delete a valid message that was intended for a recipient, you’re creating a chance that your user will never receive that mail or the message within it. So basically… be careful.

Let’s look at an example again using a similar circumstance as before.

We’re going to again utilize the exiqgrep command, but this time we’re going to look for all messages with a particular domain in its sender address, using the -f flag, then finally printing only the Exim ID values by specifying the -i flag, as we did before:

# exiqgrep -i -f  @spammer.tld | xargs exim -Mrm

Above: We’re again using xargs to run exim -Mrm (the command to delete messages by Exim ID) on each Exim ID returned from the exiqgrep command that precedes it, which in our case should match all messages with a sender that uses the domain @spammer.tld (they probably could have been a bit more subtle about it, am I right?).

Note again the pipe (|) being used to pipe the output of exiqgrep into the input for xargs.

When in doubt – see https://bradthemad.org/tech/notes/exim_cheatsheet.php

Finding out the Delivery Path of an Address

exim -bt

Another very important exim command line flag we want to make sure and highlight is the -bt flag, which would be followed by a recipient email address.

Exim -bt works like some of the Email Deliverability tests found within the WHM interface. It effectively shows you where exim thinks a message should be going, and how it should get there.

For instance, messages to this user are destined for a local account:

# exim -bt dogs@animals.test
dogs@animals.test
  router = virtual_user, transport = virtual_userdelivery

While messages to this user will leave the server to a remote destination:

# exim -bt noone@gmail.com
noone@gmail.com
  router = lookuphost, transport = remote_smtp
  host gmail-smtp-in.l.google.com      [64.233.169.26]  MX=5
  host alt1.gmail-smtp-in.l.google.com [173.194.219.26] MX=10
  host alt2.gmail-smtp-in.l.google.com [173.194.204.26] MX=20
  host alt3.gmail-smtp-in.l.google.com [74.125.141.26]  MX=30
  host alt4.gmail-smtp-in.l.google.com [64.233.186.26]  MX=40

Notice that the user doesn’t actually need to exist; exim is only checking on the domain part for remote deliveries.

# service exim restart
Shutting down clamd:                                       [FAILED]
Shutting down exim:                                        [FAILED]
Shutting down spamd:                                       [FAILED]


# service exim status
exim dead but subsys locked

There may be 2 issues to check.

-The presence of /etc/eximdisable, just move this file to eximdisable-bak and restart exim

# mv /etc/eximdisable /etc/eximdisable-bak
# service exim restart
Shutting down clamd:                                       [FAILED]
Shutting down exim:                                        [FAILED]
Shutting down spamd:                                       [  OK  ]
Starting clamd:                                            [  OK  ]
Starting exim:                                             [  OK  ]
0 processes (antirelayd) sent signal 9
/usr/local/cpanel/scripts/update_sa_rules: running in background

-The server being out of disk space and/or inodes, use ‘df -h’ and ‘df -i’ to confirm.

If you want everyone on the server to send out on the same IP, just add the following to


# nano /etc/mailips:
*: xxx.xxx.xxx.xxx

Then add the IP and it’s matching PTR to /etc/mail_reverse_dns:

# nano /etc/mail_reverse_dns
# xxx.xxx.xxx.xxx hostname.tld

This will tell Exim to use that IP for any sender on the server.

Restart exim

# service exim restart

Error:

LOG: MAIN cwd=/usr/local/cpanel/whostmgr/docroot 4 args: /usr/sbin/exim -v -M 1WkPBs-0003X3-Nmdelivering 1WkPBs-0003X3-NmLOG: MAIN PANIC failed to expand condition “${if and{{bool_lax{NULL}}{bool_lax{${perl{should_archive_outgoing_message}}}}}}” for archive_outgoing_email router: Undefined subroutine &main::should_archive_outgoing_message called. inside “and{…}” conditionLOG: MAIN PANIC failed to expand condition “${if and{{bool_lax{NULL}}{bool_lax{${if eq {$authenticated_id}{}{0}{${if eq {$sender_address}{$local_part@$domain}{0}{${if match{$received_protocol}{N^e?smtps?a$N}{${perl{checkbx_autowhitelist}{$authenticated_id}}}{${if eq{$received_protocol}{local}{${perl{checkbx_autowhitelist}{$sender_ident}}}{0}}}}}}}}}}}}” for boxtrapper_autowhitelist router: Undefined subroutine &main::checkbx_autowhitelist called. inside “and{…}” conditionLOG: MAIN PANIC failed to expand condition “${if and{{bool_lax{NULL}}{bool_lax{${perl{check_mail_permissions}}}}}}” for check_mail_permissions router: Undefined subroutine &main::check_mail_permissions called. inside “and{…}” conditionLOG: MAIN PANIC failed to expand condition “${if and{{bool_lax{NULL}}{bool_lax{${perl{enforce_mail_permissions}}}}}}” for enforce_mail_permissions router: Undefined subroutine &main::enforce_mail_permissions called. inside “and{…}” conditionLOG: MAIN PANIC failed to expand condition “${if and{{bool_lax{NULL}}{bool_lax{${perl{increment_max_emails_per_hour_if_needed}}}}}}” for increment_max_emails_per_hour_if_needed router: Undefined subroutine &main::increment_max_emails_per_hour_if_needed called. inside “and{…}” conditionLOG: MAIN == web@cariplex.com R=dkim_lookuphost defer (-1): dkim_lookuphost router failed to expand “${perl{mailtrapheaders}}”: Undefined subroutine &main::mailtrapheaders called.n

Resolution:

You can rebuild the exim configure with


/scripts/buildeximconf

You should also open a ticket using the link in my signature so our techs can determine how your exim.pl.local file became corrupted in order to prevent it from happening again.

Also,
Backup your exim.conf and run the following.


/scripts/eximup --force

How to locate the top scripts on your server that send out email. You can then search the Exim mail log for those scripts to determine if it looks like spam, and even check your Apache access logs in order to find how a spammer might be using your scripts to send out spam. Login to your server via SSH as the root user. Run the following command to pull the most used mailing script’s location from the Exim mail log:

grep cwd /var/log/exim_mainlog | grep -v /var/spool | awk -F"cwd=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n

Code breakdown:

grep cwd /var/log/exim_mainlog 	

Use the grep command to locate mentions of cwd from the Exim mail log. This stands for current working directory.

grep -v /var/spool

Use the grep with the -v flag which is an invert match, so we don’t show any lines that start with /var/spool as these are normal Exim deliveries not sent in from a script.

   
awk -F"cwd=" '{print $2}' | awk '{print $1}' 	

Use the awk command with the -Field seperator set to cwd=, then just print out the $2nd set of data, finally pipe that to the awk command again only printing out the $1st column so that we only get back the script path.

sort | uniq -c | sort -n 	

Sort the script paths by their name, uniquely count them, then sort them again numerically from lowest to highest.

You should see something like this:


    15 /home/username/public_html/about-us
    25 /home/username/public_html
    7866 /home/username/public_html/data

Here we can see that the /home/userna5/public_html/data directory by far has more deliveries coming in than any others.Now we can run the following command to see what scripts are located in that directory:

ls -lahtr /username/public_html/data

In thise case we got back:

    drwxr-xr-x 17 username username 4.0K Jan 20 10:25 ../
    -rw-r--r-- 1 username username 5.6K Jan 20 11:27 mailer.php
    drwxr-xr-x 2 username username 4.0K Jan 20 11:27 ./

So we can see there is a script called mailer.php in this directory. Knowing the mailer.php script was sending mail into Exim, we can now take a look at our Apache access log to see what IP addresses are accessing this script using the following command:

grep "mailer.php" /home/username/access-logs/example.com | awk '{print $1}' | sort -n | uniq -c | sort -n

You should get back something similar to this:


    2 123.123.123.126
    2 123.123.123.125
    2 123.123.123.124
    7860 123.123.123.123

So we can clearly see that the IP address 123.123.123.123 was responsible for using our mailer script in a malicious nature. If you did find a malicious IP address sending out a large volume of messages from a script on your server you’ll probably want to go ahead and block them at your server’s firewall so that they can’t try to connect again.

Remove exim emails:

# exim -bp | exiqgrep -i | xargs exim -Mrm

Here are some useful things to know for managing an Exim 4 server. This assumes a prior working knowledge of SMTP, MTAs, and a UNIX shell prompt.

Message-IDs and spool files

The message-IDs that Exim uses to refer to messages in its queue are mixed-case alpha-numeric, and take the form of: XXXXXX-YYYYYY-ZZ. Most commands related to managing the queue and logging use these message-ids.

There are three — count ’em, THREE — files for each message in the spool directory. If you’re dealing with these files by hand, instead of using the appropriate exim commands as detailed below, make sure you get them all, and don’t leave Exim with remnants of messages in the queue. I used to mess directly with these files when I first started running Exim machines, but thanks to the utilities described below, I haven’t needed to do that in many months.

Files in /var/spool/exim/msglog contain logging information for each message and are named the same as the message-id.

Files in /var/spool/exim/input are named after the message-id, plus a suffix denoting whether it is the envelope header (-H) or message data (-D).

These directories may contain further hashed sub directories to deal with larger mail queues, so don’t expect everything to always appear directly in the top /var/spool/exim/input or /var/spool/exim/msglog directories; any searches or greps will need to be recursive. See if there is a proper way to do what you’re doing before working directly on the spool files.
Basic information

Print a count of the messages in the queue:

root@localhost# exim -bpc

Print a listing of the messages in the queue (time queued, size, message-id, sender, recipient):


root@localhost# exim -bp

Print a summary of messages in the queue (count, volume, oldest, newest, domain, and totals):


root@localhost# exim -bp | exiqsumm

Print what Exim is doing right now:


root@localhost# exiwhat

Test how exim will route a given address:


root@localhost# exim -bt alias@localdomain.com
user@thishost.com
router = localuser, transport = local_delivery
root@localhost# exim -bt user@thishost.com
user@thishost.com
router = localuser, transport = local_delivery
root@localhost# exim -bt user@remotehost.com
router = lookuphost, transport = remote_smtp
host mail.remotehost.com [1.2.3.4] MX=0

Run a pretend SMTP transaction from the command line, as if it were coming from the given IP address. This will display Exim’s checks, ACLs, and filters as they are applied. The message will NOT actually be delivered.


root@localhost# exim -bh 192.168.11.22

Display all of Exim’s configuration settings:


root@localhost# exim -bP

Searching the queue with exiqgrep

Exim includes a utility that is quite nice for grepping through the queue, called exiqgrep. Learn it. Know it. Live it. If you’re not using this, and if you’re not familiar with the various flags it uses, you’re probably doing things the hard way, like piping `exim -bp` into awk, grep, cut, or `wc -l`. Don’t make life harder than it already is.

First, various flags that control what messages are matched. These can be combined to come up with a very particular search.

Use -f to search the queue for messages from a specific sender:


root@localhost# exiqgrep -f [luser]@domain

Use -r to search the queue for messages for a specific recipient/domain:


root@localhost# exiqgrep -r [luser]@domain

Use -o to print messages older than the specified number of seconds. For example, messages older than 1 day:


root@localhost# exiqgrep -o 86400 [...]

Use -y to print messages that are younger than the specified number of seconds. For example, messages less than an hour old:


root@localhost# exiqgrep -y 3600 [...]

Use -s to match the size of a message with a regex. For example, 700-799 bytes:


root@localhost# exiqgrep -s '^7..$' [...]

Use -z to match only frozen messages, or -x to match only unfrozen messages.

There are also a few flags that control the display of the output.

Use -i to print just the message-id as a result of one of the above two searches:


root@localhost# exiqgrep -i [ -r | -f ] ...

Use -c to print a count of messages matching one of the above searches:


root@localhost# exiqgrep -c ...

Print just the message-id of the entire queue:


root@localhost# exiqgrep -i

Managing the queue

The main exim binary (/usr/sbin/exim) is used with various flags to make things happen to messages in the queue. Most of these require one or more message-IDs to be specified in the command line, which is where `exiqgrep -i` as described above really comes in handy.

Start a queue run:


root@localhost# exim -q -v

Start a queue run for just local deliveries:


root@localhost# exim -ql -v

Remove a message from the queue:


root@localhost# exim -Mrm [ ... ]

Freeze a message:


root@localhost# exim -Mf [ ... ]

Thaw a message:


root@localhost# exim -Mt [ ... ]

Deliver a message, whether it’s frozen or not, whether the retry time has been reached or not:


root@localhost# exim -M [ ... ]

Deliver a message, but only if the retry time has been reached:


root@localhost# exim -Mc [ ... ]

Force a message to fail and bounce as “cancelled by administrator”:


root@localhost# exim -Mg [ ... ]

Remove all frozen messages:


root@localhost# exiqgrep -z -i | xargs exim -Mrm

To remove all messages from the queue, enter:


# exim -bp | awk '/^ *[0-9]+[mhd]/{print "exim -Mrm " $3}' | bash

Or


# exim -bp | exiqgrep -i | xargs exim -Mrm

Remove all messages older than five days (86400 * 5 = 432000 seconds):

[/bash]


root@localhost# exiqgrep -o 432000 -i | xargs exim -Mrm

Freeze all queued mail from a given sender:


root@localhost# exiqgrep -i -f luser@example.tld | xargs exim -Mf

View a message’s headers:


root@localhost# exim -Mvh

View a message’s body:


root@localhost# exim -Mvb

View a message’s logs:


root@localhost# exim -Mvl

Add a recipient to a message:


root@localhost# exim -Mar <message-id> <address> [ <address> ... ]

Edit the sender of a message:


root@localhost# exim -Mes <address>

Access control

Exim allows you to apply access control lists at various points of the SMTP transaction by specifying an ACL to use and defining its conditions in exim.conf. You could start with the HELO string.


# Specify the ACL to use after HELO
acl_smtp_helo = check_helo

# Conditions for the check_helo ACL:
check_helo:

deny message = Gave HELO/EHLO as "friend"
log_message = HELO/EHLO friend
condition = ${if eq {$sender_helo_name}{friend} {yes}{no}}

deny message = Gave HELO/EHLO as our IP address
log_message = HELO/EHLO our IP address
condition = ${if eq {$sender_helo_name}{$interface_address} {yes}{no}}

accept

NOTE: Pursue HELO checking at your own peril. The HELO is fairly unimportant in the grand scheme of SMTP these days, so don’t put too much faith in whatever it contains. Some spam might seem to use a telltale HELO string, but you might be surprised at how many legitimate messages start off with a questionable HELO as well. Anyway, it’s just as easy for a spammer to send a proper HELO than it is to send HELO im.a.spammer, so consider yourself lucky if you’re able to stop much spam this way.

Next, you can perform a check on the sender address or remote host. This shows how to do that after the RCPT TO command; if you reject here, as opposed to rejecting after the MAIL FROM, you’ll have better data to log, such as who the message was intended for.

# Specify the ACL to use after RCPT TO
acl_smtp_rcpt = check_recipient

# Conditions for the check_recipient ACL
check_recipient:

# […]

drop hosts = /etc/exim_reject_hosts
drop senders = /etc/exim_reject_senders

# [ Probably a whole lot more… ]

This example uses two plain text files as blacklists. Add appropriate entries to these files – hostnames/IP addresses to /etc/exim_reject_hosts, addresses to /etc/exim_reject_senders, one entry per line.

It is also possible to perform content scanning using a regex against the body of a message, though obviously this can cause Exim to use more CPU than it otherwise would need to, especially on large messages.

# Specify the ACL to use after DATA
acl_smtp_data = check_message

# Conditions for the check_messages ACL
check_message:

deny message = “Sorry, Charlie: $regex_match_string”
regex = ^Subject:: .*Lower your self-esteem by becoming a sysadmin

accept

Fix SMTP-Auth for Pine

If pine can’t use SMTP authentication on an Exim host and just returns an “unable to authenticate” message without even asking for a password, add the following line to exim.conf:

begin authenticators

fixed_plain:
driver = plaintext
public_name = PLAIN
server_condition = “${perl{checkuserpass}{$1}{$2}{$3}}”
server_set_id = $2
> server_prompts = :

This was a problem on CPanel Exim builds awhile ago, but they seem to have added this line to their current stock configuration.
Log the subject line

This is one of the most useful configuration tweaks I’ve ever found for Exim. Add this to exim.conf, and you can log the subject lines of messages that pass through your server. This is great for troubleshooting, and for getting a very rough idea of what messages may be spam.

log_selector = +subject

Reducing or increasing what is logged.
Disable identd lookups

Frankly, I don’t think identd has been useful for a long time, if ever. Identd relies on the connecting host to confirm the identity (system UID) of the remote user who owns the process that is making the network connection. This may be of some use in the world of shell accounts and IRC users, but it really has no place on a high-volume SMTP server, where the UID is often simply “mail” or whatever the remote MTA runs as, which is useless to know. It’s overhead, and results in nothing but delays while the identd query is refused or times out. You can stop your Exim server from making these queries by setting the timeout to zero seconds in exim.conf:

rfc1413_query_timeout = 0s

Disable Attachment Blocking

To disable the executable-attachment blocking that many Cpanel servers do by default but don’t provide any controls for on a per-domain basis, add the following block to the beginning of the /etc/antivirus.exim file:

if $header_to: matches “example.com|example2.com”
then
finish
endif

It is probably possible to use a separate file to list these domains, but I haven’t had to do this enough times to warrant setting such a thing up.
Searching the logs with exigrep

The exigrep utility (not to be confused with exiqgrep) is used to search an exim log for a string or pattern. It will print all log entries with the same internal message-id as those that matched the pattern, which is very handy since any message will take up at least three lines in the log. exigrep will search the entire content of a log entry, not just particular fields.

One can search for messages sent from a particular IP address:

root@localhost# exigrep ‘<= .* [12.34.56.78] ‘ /path/to/exim_log Search for messages sent to a particular IP address: root@localhost# exigrep ‘=> .* [12.34.56.78]’ /path/to/exim_log

This example searches for outgoing messages, which have the “=>” symbol, sent to “user@domain.tld”. The pipe to grep for the “<=” symbol will match only the lines with information on the sender – the From address, the sender’s IP address, the message size, the message ID, and the subject line if you have enabled logging the subject. The purpose of doing such a search is that the desired information is not on the same log line as the string being searched for. root@localhost# exigrep ‘=> .*user@domain.tld’ /path/to/exim_log | fgrep ‘<=’

Generate and display Exim stats from a logfile:

root@localhost# eximstats /path/to/exim_mainlog

Same as above, with less verbose output:

root@localhost# eximstats -ne -nr -nt /path/to/exim_mainlog

Same as above, for one particular day:

root@localhost# fgrep YYYY-MM-DD /path/to/exim_mainlog | eximstats

Bonus!

To delete all queued messages containing a certain string in the body:

root@localhost# grep -lr ‘a certain string’ /var/spool/exim/input/ |
sed -e ‘s/^.*/([a-zA-Z0-9-]*)-[DH]$/1/g’ | xargs exim -Mrm

Note that the above only delves into /var/spool/exim in order to grep for queue files with the given string, and that’s just because exiqgrep doesn’t have a feature to grep the actual bodies of messages. If you are deleting these files directly, YOU ARE DOING IT WRONG! Use the appropriate exim command to properly deal with the queue.

If you have to feed many, many message-ids (such as the output of an `exiqgrep -i` command that returns a lot of matches) to an exim command, you may exhaust the limit of your shell’s command line arguments. In that case, pipe the listing of message-ids into xargs to run only a limited number of them at once. For example, to remove thousands of messages sent from joe@example.com:

root@localhost# exiqgrep -i -f ‘<joe@example.com>’ | xargs exim -Mrm

Speaking of “DOING IT WRONG” — Attention, CPanel forum readers

I get a number of hits to this page from a link in this post at the CPanel forums. The question is:

Due to spamming, spoofing from fields, etc., etc., etc., I am finding it necessary to spend more time to clear the exim queue from time to time. […] what command would I use to delete the queue

The answer is: Just turn exim off, because your customers are better off knowing that email simply isn’t running on your server, than having their queued messages deleted without notice.

Or, figure out what is happening. The examples given in that post pay no regard to the legitimacy of any message, they simply delete everything, making the presumption that if a message is in the queue, it’s junk. That is total fallacy. There are a number of reasons legitimate mail can end up in the queue. Maybe your backups or CPanel’s “upcp” process are running, and your load average is high — exim goes into a queue-only mode at a certain threshold, where it stops trying to deliver messages as they come in and just queues them until the load goes back down. Or, maybe it’s an outgoing message, and the DNS lookup failed, or the connection to the domain’s MX failed, or maybe the remote MX is busy or greylisting you with a 4xx deferral. These are all temporary failures, not permanent ones, and the whole point of having temporary failures in SMTP and a mail queue in your MTA is to be able to try again after awhile.

Exim already purges messages from the queue after the period of time specified in exim.conf. If you have this value set appropriately, there is absolutely no point in removing everything from your queue every day with a cron job. You will lose legitimate mail, and the sender and recipient will never know if or why it happened. Do not do this!

If you regularly have a large number of messages in your queue, find out why they are there. If they are outbound messages, see who is sending them, where they’re addressed to, and why they aren’t getting there. If they are inbound messages, find out why they aren’t getting delivered to your user’s account. If you need to delete some, use exiqgrep to pick out just the ones that should be deleted.
Reload the configuration

After making changes to exim.conf, you need to give the main exim pid a SIGHUP to re-exec it and have the configuration re-read. Sure, you could stop and start the service, but that’s overkill and causes a few seconds of unnecessary downtime. Just do this:

root@localhost# kill -HUP `cat /var/spool/exim/exim-daemon.pid`

You should then see something resembling the following in exim_mainlog:

pid 1079: SIGHUP received: re-exec daemon
exim 4.52 daemon started: pid=1079, -q1h, listening for SMTP on port 25 (IPv4)