Tickets duplicados nascem de um detalhe simples: quando alguém responde "a todos" numa thread de suporte, o coletor de e-mail do GLPI não reconhece a mensagem como parte da conversa e abre um chamado novo. O módulo Mail Analyzer intercepta essa mensagem antes da criação do ticket e decide, pelos cabeçalhos do próprio e-mail, se ela é um chamado novo ou apenas um acompanhamento do original.
O problema: o coletor nativo perde a thread
O coletor de e-mail do GLPI associa uma resposta ao chamado original lendo o marcador que ele mesmo insere no assunto das notificações, no formato [GLPI #0000123]. Enquanto esse marcador sobrevive na resposta, tudo funciona: a mensagem vira acompanhamento do ticket certo. O problema aparece quando o marcador se perde.
O cenário clássico é o "Responder a todos". Um cliente abre o chamado e coloca o gerente em cópia. O suporte responde, o gerente decide comentar e clica em "Responder a todos". O cliente de e-mail dele reescreve o assunto (RE:, ENC:, FW:), corta o marcador ou inicia uma mensagem nova a partir do histórico - e o GLPI, sem encontrar o [GLPI #...], abre um segundo ticket para a mesma conversa.
O resultado é conhecido por quem opera service desk: dois ou mais chamados para o mesmo assunto, histórico fragmentado, risco de dois analistas trabalharem em paralelo sem saber e SLA distorcido, porque cada duplicata conta como um novo atendimento. Em ambientes corporativos, onde copiar gestores na thread é cultura, isso vira dezenas de duplicatas por semana.
Como o Mail Analyzer funciona
O módulo atua por hooks no ciclo de vida do ticket, interceptando o e-mail já coletado antes de ele virar chamado. Em vez de depender só do marcador no assunto, ele lê os cabeçalhos padrão de e-mail (RFC 5322) e aplica uma decisão hierárquica em três estratégias:
- Análise de References - verifica se o e-mail cita um
Message-IDgerado pelo próprio GLPI (formatoGLPI_*). Se cita, é uma resposta legítima ao chamado e vira acompanhamento. - Análise de In-Reply-To - se o
In-Reply-Toaponta para um e-mail de terceiro já registrado pelo módulo, e não para umMessage-IDdo GLPI, a mensagem é identificada como cadeia de cópia e bloqueada. - Verificação de primeiro e-mail - o fallback: se o chamado ainda não tem nenhum e-mail registrado, aquela mensagem é tratada como o original e permitida.
Sobre essa base, três ajustes controlam o comportamento em ambientes reais:
- Thread-Index - melhora a detecção de cadeias em ambientes Microsoft (Outlook/Exchange), que usam esse cabeçalho próprio além do
In-Reply-To. - Block Chain Emails - modo mais agressivo, que bloqueia ativamente respostas de terceiros em cópia. Indicado para operações de alto volume, com parcimônia.
- Template de notificação - quando um e-mail é bloqueado, o remetente recebe um aviso configurável explicando o motivo, preservando a transparência.
Os cabeçalhos que decidem
Na prática, a diferença entre um acompanhamento e uma duplicata está em duas linhas do cabeçalho. O exemplo abaixo mostra os dois casos lado a lado:
# Resposta legitima ao chamado: o cabecalho References cita o Message-ID do GLPI (GLPI_*)
# --> Mail Analyzer trata como ACOMPANHAMENTO do ticket original
Subject: [GLPI #0004521] Impressora do fiscal sem toner
Message-ID: <a1b2c3@mail.cliente.com>
In-Reply-To: <GLPI_7f3a9@suporte.empresa.com>
References: <GLPI_7f3a9@suporte.empresa.com>
# Terceiro em copia clicou "Responder a todos":
# In-Reply-To aponta para o e-mail de OUTRO usuario, nao para um Message-ID do GLPI
# --> Mail Analyzer BLOQUEIA a criacao de um ticket duplicado
Subject: RE: Impressora do fiscal sem toner
Message-ID: <d4e5f6@mail.gerente.com>
In-Reply-To: <a1b2c3@mail.cliente.com>
References: <a1b2c3@mail.cliente.com>Recurso do módulo x comportamento nativo
| Situação | Coletor nativo do GLPI | Com o Mail Analyzer |
|---|---|---|
| Resposta mantém o marcador [GLPI #id] no assunto | Vira acompanhamento do chamado | Vira acompanhamento do chamado |
| Terceiro em cópia responde "a todos" e o assunto é reescrito | Abre um chamado novo (duplicata) | Reconhece a cadeia por References/In-Reply-To e não duplica |
| Ambiente Exchange que agrupa por Thread-Index | Depende só do assunto e do In-Reply-To | Usa também o Thread-Index para casar a conversa |
| E-mail bloqueado por ser de cadeia de cópia | Não aplicável | Remetente recebe notificação configurável |
| Primeiro e-mail de um assunto novo | Abre chamado | Reconhece como original e permite a abertura |
Como ativar
- Instale o plugin NexTool no GLPI e confirme que a coleta de e-mail (receptores) já está funcionando.
- Acesse Configuração > NexTool > Módulos.
- Ative o módulo Mail Analyzer.
- Ajuste Thread-Index e Block Chain Emails conforme o perfil do ambiente.
- Defina o template de notificação para e-mails bloqueados.
O que aprendemos na sustentação
Na sustentação de coletores de e-mail em clientes, o erro que mais gera duplicata não é técnico do GLPI, é comportamental: o gestor copiado responde do celular, o app reescreve o assunto e o marcador some. Antes do Mail Analyzer, a "correção" era pedir para as pessoas não editarem o assunto, o que nunca funciona. Passamos a resolver na origem, lendo References e In-Reply-To, que o cliente de e-mail preserva mesmo quando mexe no assunto. O detalhe que só aparece operando: em ambientes Exchange, ligar o Thread-Index faz diferença real, porque o Outlook agrupa a conversa por esse cabeçalho e nem sempre mantém um In-Reply-To limpo. E uma recomendação de campo: ative o Block Chain Emails de forma gradual e sempre com o template de notificação configurado, senão um e-mail legítimo de terceiro é bloqueado em silêncio e ninguém percebe até o cliente cobrar.
Para quem é indicado (e quando não usar)
O Mail Analyzer é indicado para qualquer service desk que abre chamados por coleta de e-mail e opera em ambiente corporativo, especialmente:
- Empresas onde gestores e stakeholders são rotineiramente copiados nas threads de suporte;
- Operações com alta rotatividade de analistas, em que duplicatas passam despercebidas;
- MSPs que atendem vários clientes e precisam de histórico organizado por empresa;
- Times que dependem de histórico consolidado para auditoria e compliance.
Não faz sentido ativar se você não usa coleta de e-mail: se os chamados entram só pela central de serviços ou por formulário, não há mensagem para interceptar. E vale cautela com o Block Chain Emails em operações pequenas, onde duplicata é rara, porque o modo agressivo pode bloquear um e-mail de terceiro que deveria, sim, virar um chamado novo.
Compatibilidade
- GLPI: 10.x e 11.x
- Plano: FREE
- Plugin: NexTool 3.x ou superior
- PHP: 8.0+
O Mail Analyzer faz parte do NexTool, plugin modular para GLPI. Para ver o módulo no seu cenário de coleta de e-mail, fale com a equipe.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
