Los tickets duplicados nacen de un detalle simple: cuando alguien pulsa "Responder a todos" en un hilo de soporte, el recolector de correo de GLPI no reconoce el mensaje como parte de la conversación y abre un ticket nuevo. El módulo Mail Analyzer intercepta ese mensaje antes de crear el ticket y decide, por las cabeceras del propio correo, si es un ticket nuevo o solo un seguimiento del original.
El problema: el recolector nativo pierde el hilo
El recolector de correo de GLPI vincula una respuesta al ticket original leyendo el marcador que él mismo inserta en el asunto de las notificaciones, con el formato [GLPI #0000123]. Mientras ese marcador sobrevive en la respuesta, todo funciona: el mensaje se convierte en seguimiento del ticket correcto. El problema aparece cuando el marcador se pierde.
El escenario clásico es "Responder a todos". Un cliente abre el ticket y pone al gerente en copia. Soporte responde, el gerente decide comentar y pulsa "Responder a todos". Su cliente de correo reescribe el asunto (RE:, RV:), corta el marcador o inicia un mensaje nuevo a partir del historial - y GLPI, al no encontrar el [GLPI #...], abre un segundo ticket para la misma conversación.
El resultado lo conoce quien opera un service desk: dos o más tickets para el mismo asunto, historial fragmentado, riesgo de que dos analistas trabajen en paralelo sin saberlo y un SLA distorsionado, porque cada duplicado cuenta como una solicitud nueva. En entornos corporativos, donde copiar a los gerentes en el hilo es cultura, esto se convierte en decenas de duplicados por semana.
Cómo funciona Mail Analyzer
El módulo actúa mediante hooks en el ciclo de vida del ticket, interceptando el correo ya recolectado antes de que se convierta en ticket. En lugar de depender solo del marcador del asunto, lee las cabeceras estándar de correo (RFC 5322) y aplica una decisión jerárquica en tres estrategias:
- Análisis de References - comprueba si el correo cita un
Message-IDgenerado por el propio GLPI (formatoGLPI_*). Si lo cita, es una respuesta legítima al ticket y se convierte en seguimiento. - Análisis de In-Reply-To - si
In-Reply-Toapunta al correo de un tercero ya registrado por el módulo, y no a unMessage-IDde GLPI, el mensaje se identifica como cadena de copia y se bloquea. - Verificación del primer correo - el respaldo: si el ticket todavía no tiene ningún correo registrado, ese mensaje se trata como el original y se permite.
Sobre esa base, tres ajustes controlan el comportamiento en entornos reales:
- Thread-Index - mejora la detección de cadenas en entornos Microsoft (Outlook/Exchange), que usan esta cabecera propia además de
In-Reply-To. - Block Chain Emails - un modo más agresivo que bloquea activamente las respuestas de terceros en copia. Recomendado para operaciones de alto volumen, con moderación.
- Plantilla de notificación - cuando un correo se bloquea, el remitente recibe un aviso configurable que explica el motivo, manteniendo la transparencia.
Las cabeceras que deciden
En la práctica, la diferencia entre un seguimiento y un duplicado está en dos líneas de la cabecera. El ejemplo siguiente muestra ambos casos lado a lado:
# Respuesta legitima al ticket: la cabecera References cita el Message-ID de GLPI (GLPI_*)
# --> Mail Analyzer lo trata como SEGUIMIENTO del ticket original
Subject: [GLPI #0004521] Impresora de finanzas sin toner
Message-ID: <a1b2c3@mail.cliente.com>
In-Reply-To: <GLPI_7f3a9@soporte.empresa.com>
References: <GLPI_7f3a9@soporte.empresa.com>
# Un tercero en copia hizo clic en "Responder a todos":
# In-Reply-To apunta al correo de OTRO usuario, no a un Message-ID de GLPI
# --> Mail Analyzer BLOQUEA la creacion de un ticket duplicado
Subject: RE: Impresora de finanzas sin toner
Message-ID: <d4e5f6@mail.gerente.com>
In-Reply-To: <a1b2c3@mail.cliente.com>
References: <a1b2c3@mail.cliente.com>Función del módulo frente al comportamiento nativo
| Situación | Recolector nativo de GLPI | Con Mail Analyzer |
|---|---|---|
| La respuesta mantiene el marcador [GLPI #id] en el asunto | Se convierte en seguimiento del ticket | Se convierte en seguimiento del ticket |
| Un tercero en copia responde "a todos" y se reescribe el asunto | Abre un ticket nuevo (duplicado) | Reconoce la cadena por References/In-Reply-To y no duplica |
| Entorno Exchange que agrupa por Thread-Index | Depende solo del asunto y de In-Reply-To | Usa también Thread-Index para casar la conversación |
| Correo bloqueado por ser de cadena de copia | No aplicable | El remitente recibe una notificación configurable |
| Primer correo de un asunto nuevo | Abre ticket | Lo reconoce como original y permite la apertura |
Cómo activarlo
- Instale el plugin NexTool en GLPI y confirme que la recolección de correo (receptores) ya funciona.
- Vaya a Configuración > NexTool > Módulos.
- Active el módulo Mail Analyzer.
- Ajuste Thread-Index y Block Chain Emails según el perfil del entorno.
- Defina la plantilla de notificación para los correos bloqueados.
Lo que aprendimos en la sustentación
En la sustentación de recolectores de correo de clientes, el error que más duplicados genera no es una tecnicidad de GLPI, es de comportamiento: el gerente en copia responde desde el móvil, la app reescribe el asunto y el marcador desaparece. Antes de Mail Analyzer, el "arreglo" era pedir a la gente que no editara el asunto, lo que nunca funciona. Llevamos la solución al origen, leyendo References e In-Reply-To, que el cliente de correo conserva aunque se cambie el asunto. El detalle que solo se ve operando: en entornos Exchange, activar Thread-Index marca una diferencia real, porque Outlook agrupa la conversación por esa cabecera y no siempre mantiene un In-Reply-To limpio. Y una recomendación de campo: active Block Chain Emails de forma gradual y siempre con la plantilla de notificación configurada, porque si no, un correo legítimo de un tercero se bloquea en silencio y nadie lo nota hasta que el cliente reclama.
Para quién es (y cuándo no usarlo)
Mail Analyzer es para cualquier service desk que abre tickets por recolección de correo y opera en un entorno corporativo, en especial:
- Empresas donde gerentes y responsables se copian de forma rutinaria en los hilos de soporte;
- Operaciones con alta rotación de analistas, donde los duplicados pasan desapercibidos;
- MSP que atienden a varios clientes y necesitan un historial organizado por empresa;
- Equipos que dependen de un historial consolidado para auditoría y cumplimiento.
No tiene sentido activarlo si no usa recolección de correo: si los tickets entran solo por el catálogo de servicios o por un formulario, no hay mensaje que interceptar. Y conviene tener cuidado con Block Chain Emails en operaciones pequeñas, donde el duplicado es raro, porque el modo agresivo puede bloquear un correo de un tercero que sí debería convertirse en un ticket nuevo.
Compatibilidad
- GLPI: 10.x y 11.x
- Plan: FREE
- Plugin: NexTool 3.x o superior
- PHP: 8.0+
Mail Analyzer forma parte de NexTool, un plugin modular para GLPI. Para ver el módulo en su escenario de recolección de correo, hable con el equipo.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.
