Duplicate tickets are born from a simple detail: when someone clicks "Reply all" on a support thread, the GLPI mail collector does not recognize the message as part of the conversation and opens a brand-new ticket. The Mail Analyzer module intercepts that message before the ticket is created and decides, from the e-mail's own headers, whether it is a new ticket or just a follow-up on the original.
The problem: the native collector loses the thread
The GLPI mail collector links a reply to the original ticket by reading the marker it inserts into notification subjects, in the format [GLPI #0000123]. As long as that marker survives in the reply, everything works: the message becomes a follow-up on the right ticket. The problem appears when the marker is lost.
The classic scenario is "Reply all". A customer opens the ticket and puts their manager in CC. Support replies, the manager decides to comment and clicks "Reply all". Their mail client rewrites the subject (RE:, FW:), strips the marker or starts a fresh message from the history - and GLPI, not finding the [GLPI #...], opens a second ticket for the same conversation.
The result is familiar to anyone running a service desk: two or more tickets for the same subject, a fragmented history, the risk of two analysts working in parallel without knowing, and a distorted SLA, because every duplicate counts as a new request. In corporate environments, where copying managers on the thread is the culture, this becomes dozens of duplicates a week.
How Mail Analyzer works
The module acts through hooks in the ticket lifecycle, intercepting the already-collected e-mail before it becomes a ticket. Instead of relying only on the subject marker, it reads the standard e-mail headers (RFC 5322) and applies a hierarchical decision in three strategies:
- References analysis - checks whether the e-mail cites a
Message-IDgenerated by GLPI itself (formatGLPI_*). If it does, it is a legitimate reply to the ticket and becomes a follow-up. - In-Reply-To analysis - if
In-Reply-Topoints to a third party's e-mail already registered by the module, and not to a GLPIMessage-ID, the message is identified as a copy chain and blocked. - First-e-mail check - the fallback: if the ticket does not yet have any registered e-mail, that message is treated as the original and allowed.
On top of that base, three settings control the behavior in real environments:
- Thread-Index - improves chain detection in Microsoft environments (Outlook/Exchange), which use this dedicated header in addition to
In-Reply-To. - Block Chain Emails - a more aggressive mode that actively blocks third-party replies in CC. Recommended for high-volume operations, used sparingly.
- Notification template - when an e-mail is blocked, the sender receives a configurable notice explaining why, preserving transparency.
The headers that decide
In practice, the difference between a follow-up and a duplicate lives in two header lines. The example below shows both cases side by side:
# Legitimate reply to the ticket: the References header cites the GLPI Message-ID (GLPI_*)
# --> Mail Analyzer treats it as a FOLLOW-UP of the original ticket
Subject: [GLPI #0004521] Finance printer out of toner
Message-ID: <a1b2c3@mail.customer.com>
In-Reply-To: <GLPI_7f3a9@support.company.com>
References: <GLPI_7f3a9@support.company.com>
# A third party in CC clicked "Reply all":
# In-Reply-To points to ANOTHER user's e-mail, not to a GLPI Message-ID
# --> Mail Analyzer BLOCKS the creation of a duplicate ticket
Subject: RE: Finance printer out of toner
Message-ID: <d4e5f6@mail.manager.com>
In-Reply-To: <a1b2c3@mail.customer.com>
References: <a1b2c3@mail.customer.com>Module feature vs native behavior
| Situation | Native GLPI collector | With Mail Analyzer |
|---|---|---|
| Reply keeps the [GLPI #id] marker in the subject | Becomes a follow-up on the ticket | Becomes a follow-up on the ticket |
| Third party in CC replies "all" and the subject is rewritten | Opens a new ticket (duplicate) | Recognizes the chain via References/In-Reply-To and does not duplicate |
| Exchange environment grouping by Thread-Index | Relies only on subject and In-Reply-To | Also uses Thread-Index to match the conversation |
| E-mail blocked as part of a copy chain | Not applicable | Sender receives a configurable notification |
| First e-mail of a brand-new subject | Opens a ticket | Recognizes it as the original and allows the opening |
How to enable it
- Install the NexTool plugin in GLPI and confirm that mail collection (receivers) is already working.
- Go to Setup > NexTool > Modules.
- Enable the Mail Analyzer module.
- Adjust Thread-Index and Block Chain Emails according to the environment profile.
- Define the notification template for blocked e-mails.
What we learned in maintenance
Maintaining mail collectors for clients, the mistake that generates the most duplicates is not a GLPI technicality, it is behavioral: the manager in CC replies from a phone, the app rewrites the subject and the marker disappears. Before Mail Analyzer, the "fix" was asking people not to edit the subject, which never works. We moved the solution to the source, reading References and In-Reply-To, which the mail client preserves even when the subject is changed. The detail you only see in operation: in Exchange environments, turning on Thread-Index makes a real difference, because Outlook groups the conversation by that header and does not always keep a clean In-Reply-To. And a field recommendation: enable Block Chain Emails gradually and always with the notification template configured, otherwise a legitimate third-party e-mail gets blocked silently and nobody notices until the client complains.
Who it is for (and when not to use it)
Mail Analyzer is for any service desk that opens tickets through mail collection and runs in a corporate environment, especially:
- Companies where managers and stakeholders are routinely copied on support threads;
- Operations with high analyst turnover, where duplicates go unnoticed;
- MSPs serving several clients that need a history organized by company;
- Teams that depend on a consolidated history for audit and compliance.
It makes no sense to enable it if you do not use mail collection: if tickets come only from the service catalog or a form, there is no message to intercept. And be careful with Block Chain Emails in small operations, where duplicates are rare, because the aggressive mode can block a third-party e-mail that should indeed become a new ticket.
Compatibility
- GLPI: 10.x and 11.x
- Plan: FREE
- Plugin: NexTool 3.x or higher
- PHP: 8.0+
Mail Analyzer is part of NexTool, a modular plugin for GLPI. To see the module in your mail-collection scenario, talk to the team.
This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.
