[Exim] cheatsheet

This post is a partial copy of this article.


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 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.

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 subdirectories to deal with larger mail queues.

Basic information

Print a count of the messages in the queue:

# exim -bpc

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

# exim -bp

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

# exim -bp | exiqsumm

Print what Exim is doing right now:

# exiwhat

Test how exim will route a given address:

# exim -bt alias@localdomain.com

Run a pretend SMTP transaction for a given IP:

# exim -bh

This will display Exim’s checks, ACLs, and filters as they are applied. The message will NOT actually be delivered.

Display all of Exim’s configuration settings:

# exim -bP

Searching the queue with exiqgrep

For messages from a specific sender:

# exiqgrep -f [luser]@domain

For messages for a specific recipient/domain:

# exiqgrep -r [luser]@domain

Print messages older than than 1 day:

# exiqgrep -o 86400 [...]

For messages less than an hour old:

# exiqgrep -y 3600 [...]

There are also a few flags that control the display of the output. Use -i to print just the message-id. Use -c to print a count of messages matching the condition.

Managing the queue

Remove a message from the queue:

# exim -Mrm <message-id>

Freeze a message:

# exim -Mf <message-id>

Thaw a message:

# exim -Mt <message-id>

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

# exim -M <message-id>

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

# exim -Mc <message-id>

Remove all frozen messages:

# exiqgrep -z -i | xargs exim -Mrm

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

# exiqgrep -o 432000 -i | xargs exim -Mrm

Freeze all queued mail from a given sender:

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

View a message’s headers:

# exim -Mvh <message-id>

View a message’s body:

# exim -Mvb <message-id>

View a message’s logs:

# exim -Mvl <message-id>

SSH through HTTPS proxy

connect-proxy is a simple relaying command to make tunnel TCP connection via SOCKS4/5 or HTTPS proxies. It is mainly intended to be used as proxy command for OpenSSH. To use it first install the appropriate package, connect-proxy on GNU/Debian.

Then adjust your ssh configuration:

# vi ~/.ssh/config 
Host 10.10.1?.* 10.10.2?.* 10.10.3?.* *.foobar.fr
   User root
   ProxyCommand connect-proxy -H %h %p

Here in order to reach these specific hosts we connect through an HTTPS proxy on the port 3128 of the machine Note that you can also use other program, like corkscrew instead of connect-proxy.

[Debian] Disable a service

In the Debian world, the usual method to remove a service from startup without uninstalling the package, is to delete the init’s script symlinks like this:

update-rc.d -f remove foobar

Problem: at the next package upgrade, the post-install script will recreate the symlinks. Fortunately update-rc.d has a lesser-know disable option for this precise use case:

update-rc.d -f disable foobar

[OpenVZ] iptables: Memory allocation problem

Let say you add a new iptable rule inside an container, but this time this happen:

# iptables -I INPUT -s -j DROP
iptables: Memory allocation problem

Where does it come from ?

You probably hit the limit of the numiptent parameter. Check its failcounts:

# egrep "failcnt|numiptent" /proc/user_beancounters

If it’s greater than zero, you have your answer.

Increase the limit

On the host you can redefine the limit (soft and hard) for a container like this:

# vzctl set VPS_ID --save --numiptent 800:1000

Here i double default values.