Convite de calendário entregue para fora, sumido para dentro
Voltar para blog

Convite de calendário entregue para fora, sumido para dentro

07/06/2026 · 3 min · Infraestrutura

O convite que não chega: diagnóstico CalDAV no cPanel#

Stack: cPanel + Exim (MTA) + Dovecot (IMAP/POP3) + Roundcube ou Horde (Webmail) Cliente de calendário: Thunderbird (com CalDAV configurado) Tipo de servidor: Hospedagem compartilhada ou VPS auto-gerenciado com cPanel/WHM

Fluxo de teste executado:

1. cPanel → criar conta remetente@meudominio.com.br + habilitar agenda CalDAV
2. Thunderbird → configurar conta de e-mail + conectar agenda via CalDAV
3. Thunderbird Calendar → criar evento de teste
4. Adicionar convidados:
   - destinatario@meudominio.com.br   ← INTERNO (mesmo servidor)
   - usuario@outrodominio.com.br      ← EXTERNO
5. Enviar convites

Resultado observado:

DestinatárioRecebeu o e-mail?Recebeu o convite?
user@domain.com✅ Na caixa de entrada, com o .ics anexado✅
user@domain.com❌ Nenhum e-mail na caixa de entrada❓ Desconhecido

Camada 1 - rastreamento de entrega: o Exim sequer registrou?#

Verificando via cPanel track delivery#

A primeira ação forense é verificar se o Exim chegou a gerar uma entrada de entrega para o destinatário interno. No cPanel:

WHM / cPanel → Email → Acompanhar Entrega (Track Delivery)
→ Filtrar por: destinatario@meudominio.com.br
→ Intervalo de tempo: cobrindo o momento do envio do convite

Interpretando os status possíveis:

Status no Track DeliverySignificado
Success → deliveredE-mail chegou à caixa Dovecot - o problema está no cliente não sincronizando
Deferred → timeout/retryExim está tentando entregar mas encontrou atraso (checar fila)
Failed → bounceExim recusou com erro (ver o código de bounce)
Ausente na listaO Exim nunca gerou um envelope para este destinatário - o convite foi interceptado antes do MTA

Verificando o log do Exim diretamente via SSH:

# Buscar o destinatário interno nos logs do mainlog do Exim
grep "destinatario@meudominio.com.br" /var/log/exim_mainlog | tail -30

# Buscar por erros de loop ou unroutable recentes
grep -E "loop detected|unroutable|lost connection" /var/log/exim_mainlog | tail -20

# Ver a fila atual do Exim (mensagens pendentes)
exim -bp | head -30

Saída que indicaria ausência de envelope para o destinatário interno:

# → Nenhuma linha encontrada para destinatario@meudominio.com.br
# Isso confirma: o Exim nunca processou nenhum envelope para este endereço
# O convite foi interceptado ANTES de chegar ao MTA

Camada 2 - a "feature" de interceptação de calendário local#

Este é o comportamento central que causa a confusão. Em servidores cPanel com Roundcube ou Horde, existe um mecanismo de interceptação de convites para destinatários locais:

Thunderbird envia convite via CalDAV → servidor CalDAV do cPanel
    │
    ▼
Servidor recebe o evento com lista de convidados
    │
    ▼
Para cada convidado:
  ├── É conta EXTERNA (outro domínio)?
  │   └── → Gera envelope Exim → envia e-mail com .ics anexado
  │          Destinatário recebe na caixa de entrada ← comportamento esperado
  │
  └── É conta INTERNA (mesmo servidor)?
  └── → INTERCEPTA o convite
         → Injeta o evento diretamente no calendário do destinatário via backend
         → Status do evento: "Provisório" (Tentative) ou "Pendente"
         → Nenhum e-mail é enviado para a caixa de entrada IMAP

Por que isso existe? É uma otimização de performance e anti-spam: para contas no mesmo servidor, não há necessidade de gerar tráfego SMTP interno - o servidor consegue gravar o evento diretamente no armazenamento CalDAV/vCard do destinatário. A intenção é boa; a experiência do usuário é confusa.

Onde encontrar o evento interceptado:

Thunderbird → Aba Calendário
→ Conectar a agenda CalDAV de destinatario@meudominio.com.br
→ Verificar eventos com status "Provisório" ou sem confirmação

Ou diretamente via Roundcube/Horde:

Roundcube → Login como destinatario@meudominio.com.br → Calendário
→ Verificar aba "Pendentes" ou eventos marcados como tentativas

Camada 3 - roteamento de e-mail: local mail exchanger#

Uma variável que pode amplificar o problema ou causar um comportamento diferente é a configuração de roteamento de e-mail do domínio no cPanel. Se o domínio não estiver configurado como Local Mail Exchanger, o Exim pode tentar rotear para um servidor externo (como um antispam gateway) mesmo para contas locais.

Verificando e corrigindo:

cPanel → Email → Roteamento de E-mail (Email Routing)
→ Selecionar o domínio
→ Verificar configuração atual

Estados possíveis:

ConfiguraçãoComportamentoQuando usar
Automatically DetectcPanel decide baseado nos registros MX❌ Problemático se há antispam externo nos MX
Local Mail ExchangerTodo e-mail destino a este domínio é entregue localmente, sem consultar MX✅ Correto para domínios hospedados localmente
Backup Mail ExchangerAceita e-mail mas pode repassar para outro servidorPara backup MX servers
Remote Mail ExchangerRepassa todo e-mail para servidor externoPara domínios com Google Workspace, Microsoft 365, etc.

Corretamente configurado via WHM CLI:

# Verificar a configuração atual de roteamento
whmapi1 get_email_routing | grep -A 5 "meudominio.com.br"

# Forçar Local Mail Exchanger via API
whmapi1 set_email_routing domain=meudominio.com.br mailrouting=local

Verificando os registros MX do domínio (para entender o que o "Automatic" está interpretando):

# Verificar registros MX do domínio
dig MX meudominio.com.br

# Se o MX apontar para um antispam externo (ex: SpamExperts), o cPanel em
# modo Automatic vai acreditar que é "Remote" e rotear externamente
# → Solução: mudar para "Local" explicitamente

Camada 4 - validação de sessões Dovecot: doveadm who#

Para garantir que a comunicação do cliente com o servidor está funcional e que as sessões IMAP do usuário que não recebe o e-mail estão íntegras (descartando problema de conexão como causa colateral), a auditoria é feita via doveadm:

# Listar TODAS as sessões IMAP/POP3 ativas no momento
doveadm who

# Saída esperada (exemplo):
# username           # proto (pids) (ips)
# remetente@meu...   1 imap (12345) (192.168.1.10)
# destinatario@me... 1 imap (12346) (192.168.1.11)

Filtrar especificamente pelo usuário problemático:

doveadm who -u destinatario@meudominio.com.br

# Saída esperada se o usuário está conectado:
# username                            # proto (pids)  (ips)
# destinatario@meudominio.com.br      1 imap  (12346) (192.168.1.11)

# Se não aparecer nenhuma saída → usuário não está conectado via IMAP no momento
# Isso é normal e não indica problema

Visualização detalhada com uma conexão por linha:

doveadm who -1

# Saída formato detalhado:
# destinatario@meudominio.com.br  imap  12346  192.168.1.11

Verificando o mailbox do usuário diretamente:

# Ver as últimas mensagens entregues na caixa (confirmar se algum e-mail chegou)
doveadm mailbox status -u destinatario@meudominio.com.br messages INBOX

# Listar as últimas 10 mensagens da INBOX
doveadm fetch -u destinatario@meudominio.com.br 'date subject from' mailbox INBOX all | tail -30

Camada 5 - validação de conectividade TCP com ss e netstat#

Para ver o tráfego IMAP em nível de socket TCP (útil para confirmar que o cliente está ativamente conectado ao Dovecot):

# Usando o ss (substituto moderno do netstat - preferido no AlmaLinux/CloudLinux 8+)
ss -tnp | grep dovecot

# Saída esperada:
# ESTAB  0      0      192.168.1.11:54321  10.0.0.1:993   users:(("dovecot",pid=12346,...))
# Estado ESTAB = conexão TCP ativa e estabelecida na porta 993 (IMAP over SSL)
# Usando netstat (disponível em sistemas mais antigos)
netstat -anp | grep dovecot | grep ESTABLISHED

# Filtrando por IP do cliente específico
ss -tnp | grep dovecot | grep "192.168.1.11"

Portas de referência do Dovecot:

PortaProtocoloDescrição
143IMAPIMAP sem SSL (STARTTLS disponível)
993IMAPSIMAP com SSL/TLS
110POP3POP3 sem SSL
995POP3SPOP3 com SSL/TLS

Procedimento de diagnóstico diferencial: webmail vs. thunderbird#

O teste definitivo para isolar se o problema é no cliente ou no servidor:

TESTE A: Enviar convite via THUNDERBIRD para destinatario@meudominio.com.br
→ Se convite não aparece no e-mail mas aparece no calendário CalDAV do destinatário
  → Confirma: é interceptação de calendário local (comportamento normal do servidor)

TESTE B: Enviar convite via ROUNDCUBE/HORDE (webmail) para destinatario@meudominio.com.br
→ Se o comportamento é idêntico → confirma que é comportamento do servidor
→ Se no webmail o e-mail chega → problema de identidade/configuração no Thunderbird

TESTE C: Verificar identidade do remetente no Thunderbird
→ Thunderbird → Ferramentas → Configurações da Conta → Identidades
→ Garantir que email = remetente@meudominio.com.br (sem identidade alternativa
  que gere confusão nos cabeçalhos From/Reply-To do convite)

Resumo: árvore de decisão#

Convite interno não chega na caixa de entrada
    │
    ▼
Track Delivery no cPanel → entrada para o destinatário interno existe?
    │
   NÃO ─┼──→ Exim nunca gerou envelope
          → Interceptação de calendário local (comportamento esperado)
          → Verificar calendário CalDAV do destinatário
          → Checar Email Routing = "Local Mail Exchanger"
    │
   SIM ─┼──→ Exim gerou envelope - qual o status?
          ├── Success → E-mail na caixa Dovecot, cliente não está sincronizando
          │   → doveadm fetch + verificar configuração IMAP no Thunderbird
          ├── Deferred → Fila retentando, aguardar ou forçar retry
          │   → exim -M <message-id> para forçar entrega imediata
          └── Failed → Bounce com código de erro
              → Analisar o código SMTP no log do Exim

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.

0 comentários