Diagnose Exim queued and frozen messages

Treat the spool as outstanding delivery work, not disposable cache. A queue growing after an application deployment may reflect recipient policy, DNS, routing, remote throttling, or a local transport failure.

Start with read-only evidence

The Exim command reference describes queue listing and message-log inspection:

exim -bp

Use the documented per-message log inspection for the selected queue ID when permissions allow. Do not publish message headers/bodies merely to show that a message exists.

1. Record the message ID, age, unresolved recipients, and whether the message is frozen.
2. Correlate main/reject/panic logs with the failing router or transport.
3. Separate transient destination failures from permanent invalid recipients and local configuration errors.
4. Verify disk space, spool ownership, and the active retry policy before deciding on recovery.

Retry only after understanding the cause

A blanket forced queue run does not fix bad DNS or an unauthorized smarthost login. A thaw/retry can deliver real mail; deletion loses it. Require an operator to approve the specific action and preserve enough evidence for reconciliation.

After repairing the cause, follow a controlled message through the intended transport and verify the final outcome. Keep application resend logic separate: replaying the original send may create another queued copy while the first remains deliverable. Back up configuration and spool consistently before disruptive upgrades or host replacement.