Doppelte Tickets entstehen durch ein einfaches Detail: Wenn jemand in einem Support-Thread „allen antwortet“, erkennt der E-Mail-Collector des GLPI die Nachricht nicht als Teil der Konversation und erstellt ein neues Ticket. Das Modul Mail Analyzer fängt diese Nachricht vor der Ticketerstellung ab und entscheidet anhand der Header der E-Mail selbst, ob es sich um ein neues Ticket oder nur um eine Folgeaktion zum ursprünglichen handelt.
Das Problem: Der native Collector verliert den Thread
Der E-Mail-Collector des GLPI ordnet eine Antwort dem ursprünglichen Ticket zu, indem er die Markierung liest, die er selbst in den Betreff der Benachrichtigungen einfügt, im Format [GLPI #0000123]. Solange diese Markierung in der Antwort erhalten bleibt, funktioniert alles: Die Nachricht wird zur Folgeaktion des richtigen Tickets. Das Problem tritt auf, wenn die Markierung verloren geht.
Das klassische Szenario ist „Allen antworten“. Ein Kunde erstellt das Ticket und setzt seinen Vorgesetzten in Kopie. Der Support antwortet, der Vorgesetzte möchte etwas anmerken und klickt auf „Allen antworten“. Sein E-Mail-Programm schreibt den Betreff um (RE:, ENC:, FW:), schneidet die Markierung ab oder beginnt aus dem Verlauf eine neue Nachricht – und das GLPI, das kein [GLPI #...] findet, erstellt ein zweites Ticket für dieselbe Konversation.
Das Ergebnis kennt jeder, der einen Service Desk betreibt: zwei oder mehr Tickets zum selben Thema, zersplitterter Verlauf, das Risiko, dass zwei Analysten unwissentlich parallel arbeiten, und ein verzerrtes SLA, weil jedes Duplikat als neuer Vorgang zählt. In Unternehmensumgebungen, in denen es zur Kultur gehört, Führungskräfte in den Thread zu kopieren, werden daraus Dutzende Duplikate pro Woche.
Wie Mail Analyzer funktioniert
Das Modul arbeitet über Hooks im Lebenszyklus des Tickets und fängt die bereits abgeholte E-Mail ab, bevor sie zum Ticket wird. Statt sich nur auf die Markierung im Betreff zu verlassen, liest es die Standard-Header der E-Mail (RFC 5322) und wendet eine hierarchische Entscheidung in drei Strategien an:
- Analyse von References – prüft, ob die E-Mail eine vom GLPI selbst erzeugte
Message-IDzitiert (FormatGLPI_*). Wenn ja, ist es eine legitime Antwort auf das Ticket und wird zur Folgeaktion. - Analyse von In-Reply-To – wenn
In-Reply-Toauf eine bereits vom Modul erfasste E-Mail eines Dritten verweist und nicht auf eineMessage-IDdes GLPI, wird die Nachricht als Kopie-Kette erkannt und blockiert. - Prüfung auf erste E-Mail – der Fallback: Hat das Ticket noch keine erfasste E-Mail, wird diese Nachricht als Original behandelt und zugelassen.
Auf dieser Grundlage steuern drei Einstellungen das Verhalten in realen Umgebungen:
- Thread-Index – verbessert die Erkennung von Ketten in Microsoft-Umgebungen (Outlook/Exchange), die diesen eigenen Header zusätzlich zu
In-Reply-Toverwenden. - Block Chain Emails – ein aggressiverer Modus, der Antworten von Dritten in Kopie aktiv blockiert. Für Betriebe mit hohem Volumen geeignet, mit Bedacht einzusetzen.
- Benachrichtigungsvorlage – wenn eine E-Mail blockiert wird, erhält der Absender einen konfigurierbaren Hinweis mit dem Grund, damit die Transparenz gewahrt bleibt.
Die entscheidenden Header
In der Praxis liegt der Unterschied zwischen einer Folgeaktion und einem Duplikat in zwei Header-Zeilen. Das folgende Beispiel zeigt beide Fälle nebeneinander:
# 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: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
# 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: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>Funktion des Moduls x natives Verhalten
| Situation | Nativer Collector des GLPI | Mit Mail Analyzer |
|---|---|---|
| Antwort behält die Markierung [GLPI #id] im Betreff | Wird zur Folgeaktion des Tickets | Wird zur Folgeaktion des Tickets |
| Dritter in Kopie antwortet „allen“, und der Betreff wird umgeschrieben | Erstellt ein neues Ticket (Duplikat) | Erkennt die Kette über References/In-Reply-To und dupliziert nicht |
| Exchange-Umgebung, die nach Thread-Index gruppiert | Hängt nur von Betreff und In-Reply-To ab | Nutzt zusätzlich den Thread-Index, um die Konversation zuzuordnen |
| E-Mail blockiert, weil sie aus einer Kopie-Kette stammt | Nicht zutreffend | Absender erhält eine konfigurierbare Benachrichtigung |
| Erste E-Mail zu einem neuen Thema | Erstellt ein Ticket | Erkennt sie als Original und lässt die Erstellung zu |
So aktivieren Sie es
- Installieren Sie das NexTool-Plugin im GLPI und vergewissern Sie sich, dass der E-Mail-Abruf (Empfänger) bereits funktioniert.
- Öffnen Sie Einrichten > NexTool > Module.
- Aktivieren Sie das Modul Mail Analyzer.
- Passen Sie Thread-Index und Block Chain Emails an das Profil der Umgebung an.
- Legen Sie die Benachrichtigungsvorlage für blockierte E-Mails fest.
Was wir im Betriebssupport gelernt haben
Im Betriebssupport von E-Mail-Collectoren bei Kunden ist der Fehler, der die meisten Duplikate erzeugt, kein technisches Problem des GLPI, sondern Verhalten: Die in Kopie gesetzte Führungskraft antwortet vom Smartphone, die App schreibt den Betreff um, und die Markierung verschwindet. Vor Mail Analyzer bestand die „Korrektur“ darin, die Leute zu bitten, den Betreff nicht zu ändern – was nie funktioniert. Wir lösen es inzwischen an der Quelle, indem wir References und In-Reply-To lesen, die das E-Mail-Programm auch dann beibehält, wenn es den Betreff verändert. Das Detail, das sich erst im Betrieb zeigt: In Exchange-Umgebungen macht das Aktivieren von Thread-Index einen echten Unterschied, weil Outlook die Konversation nach diesem Header gruppiert und nicht immer ein sauberes In-Reply-To beibehält. Und eine Empfehlung aus der Praxis: Aktivieren Sie Block Chain Emails schrittweise und immer mit konfigurierter Benachrichtigungsvorlage, sonst wird eine legitime E-Mail eines Dritten still blockiert, und niemand merkt es, bis der Kunde nachfragt.
Für wen es geeignet ist (und wann nicht)
Mail Analyzer eignet sich für jeden Service Desk, der Tickets per E-Mail-Abruf erstellt und in einer Unternehmensumgebung arbeitet, insbesondere für:
- Unternehmen, in denen Führungskräfte und Stakeholder routinemäßig in Support-Threads kopiert werden;
- Betriebe mit hoher Analystenfluktuation, in denen Duplikate unbemerkt bleiben;
- MSPs, die mehrere Kunden betreuen und einen nach Unternehmen geordneten Verlauf benötigen;
- Teams, die für Audit und Compliance auf einen konsolidierten Verlauf angewiesen sind.
Es ergibt keinen Sinn, das Modul zu aktivieren, wenn Sie keinen E-Mail-Abruf nutzen: Kommen die Tickets nur über das Service Desk oder per Formular herein, gibt es keine Nachricht abzufangen. Und bei Block Chain Emails ist in kleinen Betrieben, in denen Duplikate selten sind, Vorsicht geboten, denn der aggressive Modus kann eine E-Mail eines Dritten blockieren, die tatsächlich ein neues Ticket werden sollte.
Kompatibilität
- GLPI: 10.x und 11.x
- Tarif: FREE
- Plugin: NexTool 3.x oder höher
- PHP: 8.0+
Mail Analyzer ist Teil von NexTool, dem modularen Plugin für das GLPI. Um das Modul in Ihrem Szenario mit E-Mail-Abruf zu sehen, sprechen Sie mit dem Team.
Geprüft vom Team der NexTool Solutions.
