Exim MTA queue management and cleanup

High Exim queue volume is rarely just a performance issue; it is a critical system signal. In production environments, an inflated queue often indicates a compromised account, a malicious script injecting messages, destination servers rejecting authentication, or a rapid degradation of IP reputation.

This workflow follows an investigation-first, deletion-second philosophy. Rushing to clear the queue without a forensic audit often destroys evidence needed for a permanent fix and can inadvertently delete legitimate business correspondence during a moment of panic.

0) The conceptual mistake that derails troubleshooting#

One of the most common mistakes I see administrators make is attempting to operate the queue by using email addresses directly with management flags.

The INCORRECT command pattern:

exim -Mvh [email protected]

Commands such as -Mvh (view headers), -Mvb (view body), and -Mrm (remove message) do not accept email addresses. They strictly require a Message-ID (e.g., 1tXyZ-0004p-2A).

This is why exiqgrep is the essential bridge between the human-readable email and the system-level ID:

Filter by recipient: exiqgrep -i -r [email protected]
Filter by sender: exiqgrep -i -f [email protected]

The -i flag is mandatory for automation pipelines, as it strips metadata and returns only the raw ID, making it compatible with xargs.

1) Initial queue triage and log auditing#

Initial queue triage allows administrators to obtain a systemic view of the spool pressure on the mail transfer agent.

1.1 volume and general state#

To get an overview of the current pressure on the MTA:

exim -bp        # Browse all messages in the queue
exim -bp | exiqsumm # Generate a summary by domain/host

1.2 message totals#

exim -bpc # Quick count of messages waiting in the spool

1.3 separating frozen messages#

exiqgrep -z -i

A spool filled with frozen status usually indicates a bounce loop, an unreachable destination, or an abusive sender that has been repeatedly blocked by the system's rate limits.

1.4 detailed log verification and analysis#

To perform a deep-dive diagnosis of the mail flow in exim_mainlog:

Messages by status: Count message types in the spool queue:

   exim -bp | awk '{print $1}' | sort | uniq -c | sort -rn

Total frozen messages:

   exiqgrep -z -i | wc -l

Stale/old messages in queue: Identify messages spooled for more than 7 days (604800 seconds):

   exiqgrep -i -o 604800 | wc -l

Spool count by target domain: Group and rank targets to find major anomalies:

   exim -bp | grep -oP '(?<=for )\S+' | sort | uniq -c | sort -rn | head -10

2) Id-level forensic inspection (before removal)#

Once you have identified a suspicious Message-ID, use the following commands to audit the content:

exim -Mvh ID_HERE   # View headers (check Return-Path and From)
exim -Mvb ID_HERE   # View message body (look for spam patterns)
exim -Mvl ID_HERE   # View detailed delivery logs for this specific message

Critical validation points#

Identity: Are Return-Path and From consistent with legitimate use?
Route: Inspect the Received headers to find the host of origin.
Retention Reason: Why is it stuck? Is it timeout, DNS failure, RBL blocking, or quota?
Recurrence: Do multiple IDs share the same pattern or origin?

2.1) DNS and reputation verification#

When messages are retained due to network delivery issues, audit target domain DNS properties to rule out lookup failures:

MX Record Resolution:

   dig MX domain.com +short

SPF Configuration Lookup:

   dig TXT domain.com | grep -i "v=spf1"

DMARC Record Lookup:

   dig TXT _dmarc.domain.com

2.2) RBL (blacklist) auditing#

Verify whether your server's IP address has been listed on major public Real-time Blackhole Lists (RBLs):

Check IP Against RBLs via dig:

   for rbl in zen.spamhaus.org bl.spamcop.net; do
       result=$(dig +short 4.3.2.1.$rbl) # Replace 4.3.2.1 with your reversed host IP
       if [ -n "$result" ]; then
           echo "LISTED in RBL $rbl: $result"
       fi
   done

IP Reputation Queries (MXToolbox API):

   curl -s "https://mxtoolbox.com/api/v1/lookup/blacklists/1.2.3.4" | jq .

3) Selective (surgical) queue cleanup with prior backup#

3.1) Preventive queue and specific data backups#

Before executing any queue pruning commands, it is highly recommended to output the spooled log index to exim-queue-backup.txt and capture spammed message contents to emails-from-spammer.txt:

Full Queue Backup Log:

   exim -bp > /root/exim-queue-backup-$(date +%Y%m%d).txt

Save Spammer Email Logs Separately:

   exiqgrep -i -f '[email protected]' > /root/emails-from-spammer.txt

Audit Spool Summaries Before Cleanup:

   exim -bp | exiqsumm

3.2 removing by sender#

exiqgrep -i -f '[email protected]' | xargs -r exim -Mrm

3.3 removing by recipient#

exiqgrep -i -r '[email protected]' | xargs -r exim -Mrm

3.4 purging frozen messages only#

exiqgrep -z -i | xargs -r exim -Mrm

3.5 cleanup by message age (removing stale traffic)#

To remove messages older than 7 days (604,800 seconds) without touching fresh traffic:

exiqgrep -i -o 604800 | xargs -r exim -Mrm

3.6 emergency full purge#

Only use this if the queue volume poses an immediate operational risk to the server:

exiqgrep -i | xargs -r exim -Mrm

Before execution, always run exim -bp | exiqsumm to confirm which domains are affected. This prevents the "impulse purge" of legitimate traffic.

3.7 reprocessing queue without deletion#

exim -qff

4) Post-cleanup and environment validation#

Once the surgical queue cleaning is finished, validate Exim status boundaries.

4.1) Post-purge verification and immediate monitoring#

Verify that cleanup commands resolved the congestion and spool levels returned to healthy ranges:

Verify Count Post-Pruning:

   exim -bpc

Ensure Remaining Frozen Messages count is low:

   exiqgrep -z -i | wc -l

Query log files at exim_mainlog for recent errors:

   tail -50 /var/log/exim_mainlog | grep -iE "error|fail"

Watch active queue growth:

   watch -n 60 "exim -bpc"

4.2) SMTP authentication and abuse audit#

Inspect logs to rule out authentication bypasses or leaked mail account credentials:

Check for Failed Authentication Patterns:

   grep -iE "auth|login|failed" /var/log/exim_mainlog | tail -n 20

Quantify Authentication Failures (Brute Force Attempts):

   grep -c "auth fail" /var/log/exim_mainlog

Identify Highly Active Authenticators:

   grep "A=dovecot_login" /var/log/exim_mainlog | awk '{print $6}' | sort | uniq -c | sort -rn | head -n 20

4.3) Rate limiting validation#

Validate current rate cap restrictions:

Verify Recipient Limits Settings:

   exim -bP max_rcpt
   exim -bP max_held_timeout

Track Accumulations by Sender:

   exim -bp | grep -oP '(?<=<= )\S+' | sort | uniq -c | sort -rn | head -10

5) Preventing recurrence (whm/cpanel hardening and rate limits)#

5.1) Panel limits setup#

To restrict spamming volumes, enforce strict boundaries on WHM panels or add custom ACL conditions to exim.conf:

WHM Global bounds: WHM > Tweak Settings > Mail > Max hourly emails per domain (recommended default: 200).
WHM Account caps: WHM > Modify an Account > Resource Limits > Maximum Hourly Email by Domain Relayed (recommended default: 100).
Inject Custom ACL Limit Check in exim.conf:

  acl_smtp_rcpt:
    accept
      condition = ${if >{${extract{1}{:}{${readfile{/etc/virtual/domain.com_max}}}}{0}}
      # Custom logic to process limits

5.2) Continuous monitoring implementation#

Create the automated threshold alert script at check-exim-queue.sh:

cat > /usr/local/bin/check-exim-queue.sh << 'EOF'
#!/bin/bash
QUEUE_SIZE=$(exim -bpc)
THRESHOLD=100

if [ "$QUEUE_SIZE" -gt "$THRESHOLD" ]; then
    echo "ALERT: Exim Queue reached $QUEUE_SIZE messages on the server." | \
      mail -s "Exim Queue Alert" [email protected]
fi
EOF

chmod +x /usr/local/bin/check-exim-queue.sh

Add a root cron check to execute every 5 minutes:

echo "*/5 * * * * /usr/local/bin/check-exim-queue.sh" | crontab -

5.3) Script and credential security checks#

To isolate malicious PHP scripts bypassing local SMTP settings to send spam using mail():

Check Queue Senders Count:

   exim -bp | grep -oP '(?<=<= )\S+' | sort | uniq -c | sort -rn | head -10

Find Suspicious PHP Scripts calling mail() functions:

   find /home -name "*.php" -newer /var/log/exim_mainlog -exec grep -l "mail\|smtp" {} \;

6) Queue management checklist and risk matrix#

Operational checklist for queue cleanup#

[ ] Phase 1: Volume Diagnostics
[ ] Audit total queue count with exim -bpc.
[ ] Analyze target distributions with exim -bp | exiqsumm.
[ ] Quantify frozen items.
[ ] Phase 2: Forensic Inspection
[ ] View headers of target IDs with exim -Mvh.
[ ] Trace routing nodes and injection sources.
[ ] Inspect authenticators in exim_mainlog.
[ ] Phase 3: Preventive Backup
[ ] Export spool log index list to exim-queue-backup.txt.
[ ] Save spammer emails content.
[ ] Phase 4: Pruning Spool
[ ] Expurgate message IDs by sender or frozen tags.
[ ] Delete stale spooled entries (> 7 days).
[ ] Phase 5: Post-Cleanup Checks
[ ] Ensure queue size returned to healthy ranges.
[ ] Confirm no new items are freezing.
[ ] Phase 6: Prevention Setup
[ ] Setup hourly caps on WHM settings.
[ ] Configure check-exim-queue.sh cron task.
[ ] Clean compromised PHP scripts and rotate leaked account passwords.

Spool cleanup risk matrix#

Threat / Risk Scenario	Severity	Operational Impact	Mitigation Plan
Pruning Valid Messages	Critical	Deleting legitimate client correspondence.	Log index backups, summaries audit, and exiqsumm query run prior to deletion.
Leaked SMTP Accounts	High	Spam relayed via authenticated users.	Access log inspection, SMTP credentials rotation, and user locking.
Abusive PHP Scripts	High	Local script mail injections.	Scan user document roots using `find` with mail regex lookups.
RBL Listing	High	Blocked outbound server delivery.	RBL test queries using local resolvers (Spamhaus/Spamcop lookup).
Bounce Loop	Medium	Overloaded frozen spool queue.	Pruning frozen mail queue items with `exiqgrep -z` and `exim -Mrm`.

Managing the Exim queue in a production environment is not about executing a single "delete all" command. It is a systematic process of triage, evidence gathering, selective action, and ongoing prevention. By utilizing this surgical approach, you minimize downtime, preserve legitimate business communication, and ensure the long-term deliverability of your infrastructure.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

This post is licensed under CC BY-NC.

Exim MTA queue management and cleanup: a professional forensic approach

0) The conceptual mistake that derails troubleshooting#

1) Initial queue triage and log auditing#

1.1 volume and general state#

1.2 message totals#

1.3 separating frozen messages#

1.4 detailed log verification and analysis#

2) Id-level forensic inspection (before removal)#

Critical validation points#

2.1) DNS and reputation verification#

2.2) RBL (blacklist) auditing#

3) Selective (surgical) queue cleanup with prior backup#

3.1) Preventive queue and specific data backups#

3.2 removing by sender#

3.3 removing by recipient#

3.4 purging frozen messages only#

3.5 cleanup by message age (removing stale traffic)#

3.6 emergency full purge#

3.7 reprocessing queue without deletion#

4) Post-cleanup and environment validation#

4.1) Post-purge verification and immediate monitoring#

4.2) SMTP authentication and abuse audit#

4.3) Rate limiting validation#

5) Preventing recurrence (whm/cpanel hardening and rate limits)#

5.1) Panel limits setup#

5.2) Continuous monitoring implementation#

5.3) Script and credential security checks#

6) Queue management checklist and risk matrix#

Operational checklist for queue cleanup#

Spool cleanup risk matrix#

Was this article helpful?

Comments

0) The conceptual mistake that derails troubleshooting#

1) Initial queue triage and log auditing#

1.1 volume and general state#

1.2 message totals#

1.3 separating frozen messages#

1.4 detailed log verification and analysis#

2) Id-level forensic inspection (before removal)#

Critical validation points#

2.1) DNS and reputation verification#

2.2) RBL (blacklist) auditing#

3) Selective (surgical) queue cleanup with prior backup#

3.1) Preventive queue and specific data backups#

3.2 removing by sender#

3.3 removing by recipient#

3.4 purging frozen messages only#

3.5 cleanup by message age (removing stale traffic)#

3.6 emergency full purge#

3.7 reprocessing queue without deletion#

4) Post-cleanup and environment validation#

4.1) Post-purge verification and immediate monitoring#

4.2) SMTP authentication and abuse audit#

4.3) Rate limiting validation#

5) Preventing recurrence (whm/cpanel hardening and rate limits)#

5.1) Panel limits setup#

5.2) Continuous monitoring implementation#

5.3) Script and credential security checks#

6) Queue management checklist and risk matrix#

Operational checklist for queue cleanup#

Spool cleanup risk matrix#

Was this article helpful?

See also

Comments