I ticket duplicati nascono da un dettaglio semplice: quando qualcuno clicca "Rispondi a tutti" in un thread di supporto, il collettore di posta di GLPI non riconosce il messaggio come parte della conversazione e apre un ticket nuovo. Il modulo Mail Analyzer intercetta quel messaggio prima della creazione del ticket e decide, dalle intestazioni dell'e-mail stessa, se si tratta di un ticket nuovo o solo di un follow-up dell'originale.
Il problema: il collettore nativo perde il thread
Il collettore di posta di GLPI collega una risposta al ticket originale leggendo il marcatore che inserisce lui stesso nell'oggetto delle notifiche, nel formato [GLPI #0000123]. Finché quel marcatore sopravvive nella risposta, tutto funziona: il messaggio diventa un follow-up del ticket giusto. Il problema compare quando il marcatore va perso.
Lo scenario classico è "Rispondi a tutti". Un cliente apre il ticket e mette il responsabile in copia. Il supporto risponde, il responsabile decide di commentare e clicca "Rispondi a tutti". Il suo client di posta riscrive l'oggetto (RE:, I:), taglia il marcatore o avvia un nuovo messaggio a partire dalla cronologia - e GLPI, non trovando il [GLPI #...], apre un secondo ticket per la stessa conversazione.
Il risultato è noto a chi gestisce un service desk: due o più ticket per lo stesso argomento, cronologia frammentata, il rischio che due analisti lavorino in parallelo senza saperlo e uno SLA distorto, perché ogni duplicato conta come una nuova richiesta. Negli ambienti aziendali, dove mettere i responsabili in copia del thread è la cultura, questo diventa decine di duplicati a settimana.
Come funziona Mail Analyzer
Il modulo agisce tramite hook nel ciclo di vita del ticket, intercettando l'e-mail già raccolta prima che diventi un ticket. Invece di dipendere solo dal marcatore dell'oggetto, legge le intestazioni standard della posta (RFC 5322) e applica una decisione gerarchica in tre strategie:
- Analisi di References - verifica se l'e-mail cita un
Message-IDgenerato da GLPI stesso (formatoGLPI_*). Se lo cita, è una risposta legittima al ticket e diventa un follow-up. - Analisi di In-Reply-To - se
In-Reply-Topunta all'e-mail di un terzo già registrato dal modulo, e non a unMessage-IDdi GLPI, il messaggio viene identificato come catena di copia e bloccato. - Verifica della prima e-mail - il ripiego: se il ticket non ha ancora nessuna e-mail registrata, quel messaggio viene trattato come l'originale e consentito.
Su questa base, tre impostazioni controllano il comportamento negli ambienti reali:
- Thread-Index - migliora il rilevamento delle catene negli ambienti Microsoft (Outlook/Exchange), che usano questa intestazione propria oltre a
In-Reply-To. - Block Chain Emails - una modalità più aggressiva che blocca attivamente le risposte di terzi in copia. Consigliata per le operazioni ad alto volume, con parsimonia.
- Modello di notifica - quando un'e-mail viene bloccata, il mittente riceve un avviso configurabile che spiega il motivo, preservando la trasparenza.
Le intestazioni che decidono
In pratica, la differenza tra un follow-up e un duplicato sta in due righe dell'intestazione. L'esempio seguente mostra i due casi affiancati:
# Risposta legittima al ticket: l'intestazione References cita il Message-ID di GLPI (GLPI_*)
# --> Mail Analyzer la tratta come un FOLLOW-UP del ticket originale
Subject: [GLPI #0004521] Stampante finanza senza toner
Message-ID: <a1b2c3@mail.cliente.com>
In-Reply-To: <GLPI_7f3a9@supporto.azienda.com>
References: <GLPI_7f3a9@supporto.azienda.com>
# Un terzo in copia ha cliccato "Rispondi a tutti":
# In-Reply-To punta all'e-mail di UN ALTRO utente, non a un Message-ID di GLPI
# --> Mail Analyzer BLOCCA la creazione di un ticket duplicato
Subject: RE: Stampante finanza senza toner
Message-ID: <d4e5f6@mail.responsabile.com>
In-Reply-To: <a1b2c3@mail.cliente.com>
References: <a1b2c3@mail.cliente.com>Funzione del modulo rispetto al comportamento nativo
| Situazione | Collettore nativo di GLPI | Con Mail Analyzer |
|---|---|---|
| La risposta mantiene il marcatore [GLPI #id] nell'oggetto | Diventa un follow-up del ticket | Diventa un follow-up del ticket |
| Un terzo in copia risponde "a tutti" e l'oggetto viene riscritto | Apre un ticket nuovo (duplicato) | Riconosce la catena tramite References/In-Reply-To e non duplica |
| Ambiente Exchange che raggruppa per Thread-Index | Dipende solo dall'oggetto e da In-Reply-To | Usa anche il Thread-Index per collegare la conversazione |
| E-mail bloccata perché parte di una catena di copia | Non applicabile | Il mittente riceve una notifica configurabile |
| Prima e-mail di un argomento nuovo | Apre un ticket | La riconosce come originale e consente l'apertura |
Come attivarlo
- Installa il plugin NexTool in GLPI e conferma che la raccolta della posta (ricevitori) funzioni già.
- Vai in Configurazione > NexTool > Moduli.
- Attiva il modulo Mail Analyzer.
- Regola Thread-Index e Block Chain Emails in base al profilo dell'ambiente.
- Definisci il modello di notifica per le e-mail bloccate.
Cosa abbiamo imparato nella manutenzione
Nella manutenzione dei collettori di posta dei clienti, l'errore che genera più duplicati non è un tecnicismo di GLPI, è comportamentale: il responsabile in copia risponde dal telefono, l'app riscrive l'oggetto e il marcatore scompare. Prima di Mail Analyzer, la "soluzione" era chiedere alle persone di non modificare l'oggetto, cosa che non funziona mai. Abbiamo spostato la soluzione all'origine, leggendo References e In-Reply-To, che il client di posta conserva anche quando cambia l'oggetto. Il dettaglio che si vede solo operando: negli ambienti Exchange, attivare il Thread-Index fa una differenza reale, perché Outlook raggruppa la conversazione per quell'intestazione e non sempre mantiene un In-Reply-To pulito. E una raccomandazione sul campo: attiva Block Chain Emails in modo graduale e sempre con il modello di notifica configurato, altrimenti un'e-mail legittima di un terzo viene bloccata in silenzio e nessuno se ne accorge finché il cliente non reclama.
A chi è rivolto (e quando non usarlo)
Mail Analyzer è rivolto a qualsiasi service desk che apre ticket tramite raccolta di posta e opera in un ambiente aziendale, in particolare:
- Aziende in cui responsabili e stakeholder vengono messi in copia di routine nei thread di supporto;
- Operazioni con alto turnover di analisti, dove i duplicati passano inosservati;
- MSP che servono più clienti e hanno bisogno di una cronologia organizzata per azienda;
- Team che dipendono da una cronologia consolidata per audit e conformità.
Non ha senso attivarlo se non usi la raccolta di posta: se i ticket arrivano solo dal catalogo servizi o da un modulo, non c'è alcun messaggio da intercettare. E occhio a Block Chain Emails nelle piccole operazioni, dove il duplicato è raro, perché la modalità aggressiva può bloccare un'e-mail di terzi che invece dovrebbe diventare un ticket nuovo.
Compatibilità
- GLPI: 10.x e 11.x
- Piano: FREE
- Plugin: NexTool 3.x o superiore
- PHP: 8.0+
Mail Analyzer fa parte di NexTool, un plugin modulare per GLPI. Per vedere il modulo nel tuo scenario di raccolta della posta, parla con il team.
Revisionato dal team NexTool Solutions.
