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.
Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.
