Reading an Exim queue like a support engineer

Most delivery tickets sound different but come down to the same handful of causes. The queue is where they all leave fingerprints.

The first command

exim -bp shows what's waiting. I read it from right to left:

1h   45K  1a2b3c-0004dE-9X  <sender@example.com>
                              recipient@example.org

Age first, then size, then the message ID, then the route. Old + tiny often means a bounce loop; huge + fresh often means an attachment that will never fit a quota.

The four patterns

1. Frozen with "retry timeout exceeded" — the remote side was unreachable long enough that Exim gave up. Usually DNS, firewall, or a dead MX.
2. Deferred with "remote host address is the local host" — a domain whose MX points back at the same server. Classic broken config.
3. Rejected at SMTP time — the remote accepted the connection but refused the message. Read the exact 5xx code; it tells you why.
4. Delivered but the user "didn't get it" — it's in spam, or a filter filed it. The queue won't show this, so check the delivery log instead.

Headers are the story

exim -Mvh <message-id> dumps the message headers. I look at the Received: chain from bottom to top — that's the path in real chronological order. When a client says "we sent it at 3pm," the topmost Received: timestamp usually tells a different story.

Once you can read the queue, most of the job is just confirming which of the four patterns you're looking at.