Auditing Dovecot and Exim logs: investigating disappeared email folders

Anyone managing mail servers or handling hosting support has encountered this scenario: a user submits an urgent ticket claiming that the server deleted their emails and that entire subfolders have vanished from Outlook.

In situations like this, guesswork and endless debates solve nothing. The only reliable approach is to open the terminal, inspect the logs from Dovecot (IMAP/LMTP server) and Exim (MTA/SMTP server), and trace the exact timeline of every connection, delivery, and command.

Here is a breakdown of a real investigation, explaining how to interpret session records, sudden authentication failures, IMAP deletion mechanics, and why the server is almost never the culprit when folders disappear from the desktop client.

Incident background and log collection#

A user account (user@domain.com) reported that several folders and emails had gone missing from their mail client. To reconstruct the events, I correlated entries from /var/log/maillog and /var/log/exim_mainlog across the previous day and the day of the reported incident.

1. Previous day baseline: normal Dovecot activity#

I began by filtering the account's activity on the preceding day (Sep 1) to establish the baseline:

grep user@domain.com /var/log/maillog | grep 'Sep  1'

The output showed a standard office routine:

• IMAP Logins and Logouts: Multiple short sessions originating from the user's IP (198.51.100.152), with successful TLS handshakes (imap-login: Login: user=<user@domain.com>, method=PLAIN...) and clean disconnects (Disconnected: Logged out in=11, out=92).
• Local Delivery via LMTP: Inbound emails delivered cleanly to the mailbox (lmtp(user@domain.com): msgid=<...>: saved mail to INBOX).
• Standard Operational Commands: Expected client instructions such as SELECT (reading a folder) and IDLE (keeping the connection open for instant notifications).

No anomalies, no errors, and zero deletions. Just normal IMAP synchronization throughout the day.

2. The incident day: what Dovecot recorded#

On the following day (Sep 2), the pattern shifted abruptly late in the morning. Inspecting the connections:

grep user@domain.com /var/log/maillog | grep 'Sep  2'

The turning point: continuous authentication failures#

Up until 11:41 AM, the account operated normally. At 11:44 AM, a sudden break occurred:

dovecot: auth-worker(2534): Error: conn unix:auth-worker (pid=2339,uid=97): auth-worker<25>: dict(user@domain.com,198.51.100.152,<session_id>): Invalid password in passdb: crypt() failed: Invalid argument
dovecot: imap-login: Disconnected: Connection closed (auth service reported temporary failure): user=<user@domain.com>, method=PLAIN, rip=198.51.100.152, lip=192.168.0.70, TLS: Connection closed
dovecot: imap-login: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<user@domain.com>, method=PLAIN, rip=198.51.100.152, lip=192.168.0.70, TLS: Connection closed

From that exact minute onward, the client IP (198.51.100.152) generated dozens of failed login attempts in rapid succession.

The error Invalid password in passdb: crypt() failed: Invalid argument accompanied by auth service reported temporary failure indicates that the credentials transmitted by the client were malformed or invalid.

Later, around 1:31 PM, local Webmail sessions (rip=::1) logged in without issues, while the desktop client continued to fail until it gave up.

3. Cross-checking with Exim logs (exim_mainlog)#

To verify whether inbound messages were rejected or dropped, I checked the MTA log:

grep user@domain.com /var/log/exim_mainlog | grep 2025-09-02

Exim confirmed that delivery remained completely healthy:

2025-09-02 02:04:36 [msg_id] <= sender@external.com H=outbound.mail.net [198.51.100.10] P=esmtps ... for user@domain.com
2025-09-02 02:04:36 [msg_id] => user <user@domain.com> R=virtual_user T=dovecot_virtual_delivery C="250 2.0.0 <user@domain.com> [delivery_id] Saved"
2025-09-02 09:29:34 [msg_id] <= user@domain.com H=(DESKTOP-CLIENT) [198.51.100.152] P=esmtpsa ... A=dovecot_login:user@domain.com ... for other@domain.com

• Inbound: Messages were properly handled by virtual_user, handed over to dovecot_virtual_delivery, and stored with confirmation 250 2.0.0 ... Saved.
• Outbound: The user authenticated via SMTP (A=dovecot_login) from their workstation and sent emails normally at 09:29, 09:36, and 10:36 AM.

4. How Dovecot tracks actual email deletions#

The central question in this investigation was: did the server ever receive commands to delete messages or folders?

The logs confirm: no.

In the IMAP protocol, deleting an email is a two-step process:

1. Flagging (STORE \Deleted): The client flags the message as deleted. The physical file remains on the server disk inside the Maildir folder.
2. Purging (EXPUNGE): When the client cleans up the folder or empties the trash, it issues an expunge command.

When an expunge occurs, Dovecot logs it explicitly:

imap(user@domain.com)<pid><session_id>: expunged 1 messages from INBOX

In the analyzed logs, only read instructions (SELECT, UID FETCH) and message writes (APPEND) were recorded. There was not a single EXPUNGE command.

Similarly, if folders had been removed or unsubscribed, commands like DELETE or UNSUBSCRIBE would appear in the logs. None of these were present.

Why did folders disappear in Outlook?#

The log evidence points to a straightforward root cause:

1. All messages remained intact on the server disk and continued to arrive via LMTP.
2. The server never received any delete or expunge instructions.
3. The local Outlook client entered an authentication failure loop starting at 11:44 AM.

When Outlook loses authentication or encounters local .ost data file desynchronization, it stops syncing subscribed IMAP subfolders. If folder subscription checks fail, the application hides the folder tree or renders it empty. To the end user, it looks like data was deleted from the server, when in reality the local client simply stopped displaying it.

The practical fix involved:

• Correcting the saved password in the email client settings to resolve the auth-worker rejection.
• In Outlook, opening IMAP folder settings and querying Subscribed Folders to restore the visible folder hierarchy (or rebuilding the .ost cache file).

Server logs do not lie. Checking Dovecot and Exim logs transforms an emotional complaint into an objective, factual diagnosis.

See also

Infrastructure Anatomy of a phantom email: filesystem and Dovecot IMAP desynchronization

Email Anatomy of an email stuck in queue: mail server logs, domain typos, and Exim smarthost mechanics

Email How to fix error 75 not a directory in Dovecot and Sieve

This post is licensed under CC BY-NC.