How to Read Mail Logs

[KiraX]

Hello everyone!
Could you please tell me if I'm understanding the analysis of mail logs on Exim-based servers correctly?


I use two main log files:

• /var/log/exim_mainlog — incoming and outgoing messages
• /var/log/maillog — IMAP/POP3 mailbox connections (handled by dovecot)

I see that Exim marks log entries with flags (<=, =>, **, ==, etc.) that indicate the delivery status. To view the full trace of a message, I first search for the mailbox I'm interested in, get the message ID (for example, 1kPNom-0007xj-FA), and then search by that ID to see its full path.


I've put together two examples — one successful and one unsuccessful — but I want to make sure I'm interpreting them correctly:

• Successful: the message arrived, was placed in the queue, and saved to the virtual mailbox.
• Unsuccessful: LMTP returns a defer due to quota or limit being exceeded.

Does this logic look correct? Are there any other nuances I should pay attention to when reviewing Exim logs?

 

[Mosab Elhag]

Your reading is right, and the two flags you listed are the easy half. The catch is that Exim logs a delivery attempt, not a verdict, so one message ID can carry several of those lines over hours.

Short version of the symbols: <= is arrival (S= is the size, T= the subject on that line), => a completed delivery that will not be retried, == a defer that is still queued, ** a permanent failure. One trap: T= is the subject on arrival lines but the transport name on delivery lines.

Your mailbox full case is a good example. The first line is correct: 452 4.2.2 from LMTP is a defer and the address stays queued. What follows is what people misread. Every later attempt writes another == line, usually "defer (-52): Retry time not yet reached", which is not a new failure, just the scheduler holding off. The number in parentheses is Exim's own defer reason (-44 from the transport, -52 the scheduler) and it points at the cause faster than the 4xx text. exim -brt on the domain prints the retry schedule behind it.

For the trace, exigrep beats grep: exigrep 1kPNom-0007xj-FA /var/log/exim_mainlog returns arrival, routing and delivery lines together, while plain grep interleaves other messages. If it is still queued, exim -bp lists the queue and exim -Mvl <id> prints that one message's log.