"Sumiram com minhas pastas!": investigando logs do Dovecot e Exim para provar o que realmente aconteceu

Quem administra servidores de e-mail ou atende chamados de hospedagem já ouviu essa frase pelo menos uma vez: o usuário abre um ticket urgente afirmando com certeza absoluta que o servidor apagou seus e-mails e que pastas inteiras simplesmente evaporaram do Outlook.

Nessas horas, debater na base do achismo não resolve nada. O único caminho seguro e transparente é abrir o terminal, inspecionar os logs do Dovecot (servidor IMAP/LMTP) e do Exim (MTA/SMTP) e reconstruir a linha do tempo exata de cada conexão, comando e entrega.

Abaixo, compartilho a autópsia de um caso real recente, mostrando como interpretar os registros de sessão, os erros repentinos de autenticação, o ciclo de vida das exclusões IMAP e por que o servidor quase sempre é inocente quando pastas somem na tela do cliente de e-mail.

O cenário do chamado e a coleta dos logs#

O usuário de uma conta (user@dominio.com.br) relatou que mensagens e subpastas haviam desaparecido do seu leitor de e-mails. Para reconstituir o que aconteceu, cruzei os dados do /var/log/maillog e do /var/log/exim_mainlog cobrindo o dia anterior e o dia da falha relatada.

1. Linha de base no dia anterior: uso normal do Dovecot#

Comecei filtrando o histórico da conta no dia anterior (Sep 1) para entender o padrão regular de conexões:

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

O retorno revelou uma rotina típica de escritório:

• Logins e logouts via IMAP: Múltiplas sessões curtas abertas pelo IP do usuário (198.51.100.152), com conexões TLS válidas (imap-login: Login: user=<user@dominio.com.br>, method=PLAIN...) e encerramentos normais (Disconnected: Logged out in=11, out=92).
• Entrega local via LMTP: E-mails sendo gravados diretamente na caixa de entrada pelo serviço local (lmtp(user@dominio.com.br): msgid=<...>: saved mail to INBOX).
• Comandos operacionais rotineiros: Execução de instruções como SELECT (o cliente lendo uma pasta específica) e IDLE (o cliente mantendo conexão aberta aguardando novas mensagens).

Nenhuma anomalia, nenhum erro e zero exclusões. Apenas a sincronização padrão de um cliente de e-mail ao longo do dia.

2. O dia do incidente: o que o Dovecot registrou#

No dia seguinte (Sep 2), o comportamento mudou no final da manhã. Analisando as conexões:

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

O ponto de ruptura: falhas contínuas de autenticação#

Até as 11:41, a conta continuava sincronizando normalmente. Às 11:44, os logs registraram uma quebra imediata:

dovecot: auth-worker(2534): Error: conn unix:auth-worker (pid=2339,uid=97): auth-worker<25>: dict(user@dominio.com.br,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@dominio.com.br>, 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@dominio.com.br>, method=PLAIN, rip=198.51.100.152, lip=192.168.0.70, TLS: Connection closed

A partir desse momento, o mesmo IP (198.51.100.152) tentou se autenticar dezenas de vezes seguidas sem sucesso.

O erro Invalid password in passdb: crypt() failed: Invalid argument associado a auth service reported temporary failure aponta que a senha fornecida pelo cliente continha caracteres inválidos ou houve uma tentativa de login com hash incompatível.

Pouco depois, por volta das 13:31, conexões feitas via Webmail local (rip=::1) entraram com sucesso, enquanto o cliente externo no computador do usuário continuava recebendo recusa de autenticação.

3. Cruzando com os logs do Exim (exim_mainlog)#

Para checar se mensagens haviam sido descartadas ou devolvidas pelo servidor de transporte, filtrei o log do Exim:

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

O Exim confirmou que o fluxo de mensagens permaneceu saudável:

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

• Entrada: Mensagens recebidas foram processadas pelo roteador virtual_user, entregues ao transporte dovecot_virtual_delivery e salvas no disco com confirmação 250 2.0.0 ... Saved.
• Saída: O próprio usuário autenticou via SMTP (A=dovecot_login) a partir da sua máquina e disparou e-mails normalmente às 09:29, 09:36 e 10:36.

4. Como o Dovecot registra a exclusão real de e-mails?#

A pergunta central da investigação era: houve alguma ordem de exclusão de mensagens ou pastas enviada para o servidor?

A resposta dos logs é não.

No protocolo IMAP, a exclusão de um e-mail ocorre obrigatoriamente em duas etapas:

1. Sinalização (STORE \Deleted): O cliente marca a mensagem com a flag de deletada. O arquivo físico continua existindo no disco dentro da pasta Maildir.
2. Expurgo (EXPUNGE): Quando o cliente finaliza a pasta ou esvazia a lixeira, ele envia a instrução de expurgo.

Quando o expurgo ocorre, o Dovecot registra explicitamente a ação:

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

Nos registros analisados, só apareceram comandos de leitura (SELECT, UID FETCH) e escrita de novos itens (APPEND). Não existiu nenhum comando EXPUNGE.

Da mesma forma, se pastas tivessem sido apagadas ou desmarcadas, o log registraria comandos DELETE (para remover a mailbox física) ou UNSUBSCRIBE (para desmarcar a pasta da lista de exibição do cliente). Nenhuma dessas diretivas foi enviada.

Por que as pastas "sumiram" no Outlook?#

Com a análise dos logs, o diagnóstico ficou claro:

1. As mensagens continuavam intactas no disco e continuaram sendo entregues pelo LMTP.
2. O servidor nunca recebeu comandos de expurgo ou exclusão de caixas.
3. O cliente local no Windows entrou em loop de falha de autenticação a partir das 11:44.

Quando o Outlook perde a autenticação ou encontra inconsistências no arquivo de cache local (.ost), ele interrompe a sincronização das subpastas IMAP. Se a lista de pastas assinadas (subscribed folders) falhar ao sincronizar, o aplicativo oculta visualmente as pastas ou exibe a estrutura vazia. Para quem está olhando a tela, parece que os dados sumiram do servidor, quando na verdade o cliente local apenas deixou de sincronizar a exibição.

A resolução prática envolveu:

• Atualizar a senha salva nas configurações de conta do aplicativo para estancar as falhas no auth-worker.
• No Outlook, acessar as propriedades da conta IMAP e marcar Consultar Pastas Assinadas para reconstruir a lista de visualização (ou recriar o arquivo de dados .ost).

Logs não mentem. Ter o hábito de auditar o tráfego do Dovecot e do Exim transforma uma reclamação tensa em um diagnóstico técnico simples e fundamentado.

Veja também

Infraestrutura Quando o filesystem e o daemon entram em desincronia

E-mail Anatomia de um e-mail preso em fila: logs de servidores, erros de digitação e a mecânica do Exim com smarthost

E-mail Como resolver o erro 75 not a directory no Dovecot e Sieve

Este post está licenciado sob CC BY-NC.