Do VestaCP ao cPanel: como resolver o erro de corrupção IMAP no Roundcube

Migrar contas entre painéis de hospedagem diferentes quase sempre envolve alguma surpresa no caminho. Quando o assunto é e-mail, copiar os diretórios brutos de mensagens do VestaCP para o cPanel parece simples à primeira vista: ambos utilizam a estrutura padrão Maildir.

No entanto, logo após finalizar a transferência dos arquivos e tentar abrir a caixa de entrada no Roundcube, surge uma mensagem de erro na tela:

Unexpected condition from IMAP server, closed or corrupt connection to IMAP. Possible mailbox corruption.

O susto é imediato. A mensagem sugere que a caixa postal está corrompida e que os e-mails podem ter sido perdidos. Na prática, quase nunca há perda de dados reais. Esse erro ocorre porque o Roundcube tenta abrir uma sessão IMAP, mas o Dovecot encerra a conexão de forma abrupta ao encontrar arquivos de índice com mapeamentos de IDs incompatíveis ou permissões de usuário truncadas.

Abaixo está o roteiro prático para restabelecer a comunicação entre o Roundcube e o Dovecot sem colocar nenhuma mensagem em risco.

Por que a migração quebra a sincronização do IMAP?#

Apesar de VestaCP e cPanel salvarem as mensagens em arquivos individuais nas pastas cur e new, a forma como cada painel gerencia metadados é bem distinta:

1. Dono e grupo de arquivos (UID/GID): No VestaCP, os arquivos frequentemente pertencem ao usuário admin ou ao grupo mail. No cPanel, cada conta precisa que seus e-mails pertençam estritamente ao usuário Linux dono da conta cPanel.
2. Índices de busca do Dovecot: Para acelerar a listagem de milhares de mensagens, o Dovecot mantém arquivos de índice binários (dovecot.index*) e listas de controle (dovecot-uidlist). Quando você copia esses arquivos do servidor antigo, eles trazem registros de UIDs que não batem com o estado atual da nova instalação. Ao ler esses dados incoerentes, o Dovecot derruba a conexão por segurança.

1. Corrigindo permissões e propriedade dos arquivos#

O primeiro passo é garantir que o Dovecot tenha permissão total para ler e gravar na pasta de e-mails.

Acesse o servidor de destino via SSH com privilégios de root:

Realinhar a propriedade dos arquivos recursivamente#

Troque o dono de toda a pasta de e-mails do domínio para o usuário correspondente do cPanel:

chown -R USUARIO:USUARIO /home/USUARIO/mail/DOMINIO/

Substitua USUARIO pelo login da conta cPanel e DOMINIO pelo domínio migrado.

Rodar o reparador nativo de permissões do cPanel#

O cPanel inclui uma ferramenta interna que ajusta automaticamente as permissões de pastas (geralmente 0700) e arquivos (0600) de toda a árvore de e-mails:

/scripts/mailperm --user USUARIO

2. Expurgo dos arquivos de índice antigos do Dovecot#

Essa é a chave para resolver a mensagem "Possible mailbox corruption". Os índices antigos herdados do VestaCP precisam ser descartados.

O Dovecot foi projetado para ser resiliente: se os arquivos de índice forem removidos, o daemon simplesmente faz uma varredura nas pastas físicas (cur/ e new/) e recria todos os índices do zero no próximo login do usuário.

1. Navegue até o diretório da conta de e-mail afetada:

cd /home/USUARIO/mail/DOMINIO/CONTA/

(Por exemplo: /home/minhaconta/mail/meudominio.com.br/contato/)

1. Remova com segurança os arquivos de índice e histórico:

rm -f dovecot.index* dovecot.mailbox.log dovecot-uidlist

Se a conta possuir muitas subpastas e você quiser limpar os índices de todas elas de uma só vez dentro daquela conta:

find /home/USUARIO/mail/DOMINIO/CONTA/ -name "dovecot.index*" -delete
find /home/USUARIO/mail/DOMINIO/CONTA/ -name "dovecot-uidlist" -delete

3. Checagem estrutural da árvore maildir#

No padrão Maildir do Dovecot, as subpastas criadas pelo usuário (como Enviados, Lixeira e Rascunhos) devem ser pastas ocultas, com um ponto no início do nome. Cada uma delas precisa ter suas próprias subpastas internas cur, new e tmp.

Liste o diretório da conta para conferir a estrutura:

ls -la /home/USUARIO/mail/DOMINIO/CONTA/

Você deve ver algo parecido com:

drwx------  cur/
drwx------  new/
drwx------  tmp/
drwx------  .Sent/
drwx------  .Trash/
drwx------  .Drafts/

Se durante a compactação ou transferência do VestaCP o ponto inicial dessas pastas tiver sido removido acidentalmente, o Dovecot não as reconhecerá como caixas IMAP válidas e pode abortar a conexão.

4. Auditoria de logs em tempo real#

Se após limpar permissões e índices o Roundcube ainda exibir a mensagem de erro, abra uma sessão de terminal para acompanhar os registros do Dovecot em tempo real:

tail -f /var/log/maillog

(Em alguns servidores com regras específicas de syslog, os registros de autenticação de e-mail podem estar em /var/log/messages ou /var/log/exim_mainlog).

Com o terminal aberto, tente fazer login novamente no Roundcube. Se houver alguma inconformidade restante, você verá mensagens diretas como:

dovecot: imap(contato@meudominio.com.br): Error: Corrupted index file ...: UIDs not increasing
dovecot: imap(contato@meudominio.com.br): Disconnected: Internal error occurred.

Essa linha aponta com precisão cirúrgica qual subpasta ainda guarda um arquivo de índice corrompido que não foi apagado.

5. Validação de cota de disco da conta#

Um falso-positivo muito comum para esse erro é o limite de espaço. Quando uma conta é criada no cPanel antes da migração, ela pode ter sido configurada com uma cota padrão (por exemplo, 250 MB). Se você copiou 1.5 GB de mensagens do VestaCP, a conta já nasce estourada.

Sem espaço livre para criar arquivos temporários de lock e novos índices durante a inicialização da sessão IMAP, o Dovecot encerra a conexão na hora.

1. Acesse o cPanel > Contas de Email (Email Accounts).
2. Localize o endereço e clique em Gerenciar (Manage).
3. Verifique o limite de armazenamento alocado. Aumente o valor para comportar o volume real com folga ou marque temporariamente como Ilimitado (Unlimited).
4. Salve as alterações e tente abrir o webmail novamente.

6. O teste do cliente externo para isolar a causa#

Se você quer tirar a prova real de onde está o problema (se no Roundcube ou no servidor IMAP em si), faça o teste com um aplicativo desktop como Thunderbird ou Outlook:

Configure a conta via IMAP no cliente do seu computador:

• Funcionou no Thunderbird, mas quebrou no Roundcube: O Dovecot está saudável. O problema é exclusivo do webmail, normalmente relacionado a sessões expiradas do PHP, cookies travados no navegador ou permissões no diretório temporário do Roundcube.
• Falhou tanto no Thunderbird quanto no Roundcube: O Dovecot está rejeitando a conexão na raiz do serviço. O motivo invariavelmente é permissão de sistema (chown) ou restos de arquivos dovecot.index / dovecot-uidlist.

Checklist rápido para migrações de e-mail sem sustos#

Ao transportar contas de e-mail do VestaCP para o cPanel, siga esta sequência prática logo após descompactar os arquivos no destino:

1. Ajuste o dono dos arquivos: chown -R usuario:usuario /home/usuario/mail/dominio/
2. Execute o reparador do cPanel: /scripts/mailperm --user usuario
3. Delete índices herdados: Remova arquivos dovecot.index* e dovecot-uidlist para permitir que o Dovecot regenere metadados limpos.
4. Verifique se a cota no cPanel cobre o volume migrado.
5. Acompanhe o /var/log/maillog no primeiro login.

Adotando esse fluxo, o Roundcube abre as caixas de entrada de primeira, preservando todas as mensagens e pastas organizadas exatamente como o usuário deixou.

Veja também

E-mail cPanel + Dovecot: erro `doveadm exit code 68` - diagnóstico e correção definitiva

Infraestrutura Quando o filesystem e o daemon entram em desincronia

E-mail Anatomia de uma falha em cascata: do bloqueio de IP por spam à depuração do Roundcube no cPanel

Este post está licenciado sob CC BY-NC.