Helpdesk-Software in PHP: Auswahl und Betrieb
Ticketsysteme im Selbstbetrieb: Mailanbindung, Rechteverwaltung, Datenschutz und der laufende Aufwand, den ein eigenes System tatsächlich kostet.
Das Wichtigste
- Die Mailanbindung entscheidet über Erfolg oder Scheitern: Ein Ticketsystem, dessen Antworten im Spam landen, wird nicht benutzt.
- Ein-/Ausgang per IMAP abholen ist robuster als eine Pipe im Mailserver – bei einem Fehler bleibt die Mail im Postfach liegen statt verloren zu gehen.
- Selbst gehostet heisst: Updates, Sicherung, Absicherung und Postfachpflege liegen bei dir.
- Ein Ticketsystem verarbeitet personenbezogene Daten. Löschfristen und Auskunftsfähigkeit gehören von Anfang an eingerichtet.
Ein Ticketsystem selbst zu betreiben ist technisch überschaubar und organisatorisch anspruchsvoll. Die Software ist schnell installiert – der Aufwand steckt in Mailzustellung, Datenschutz und Pflege.
Was ein Ticketsystem leisten muss
- Eingehende Mails einer Rollenadresse in Vorgänge umwandeln
- Antworten so versenden, dass die Zuordnung beim Rückweg erhalten bleibt
- Vorgänge zuweisen, priorisieren und einen Status führen
- Vorgangsverlauf vollständig nachvollziehbar halten
- Zugriff auf die Personen begrenzen, die ihn brauchen
- Löschfristen umsetzen können
Der zweite Punkt ist der technisch heikelste: Antwortet ein Kunde auf eine Ticketmail, muss sie beim richtigen Vorgang landen. Systeme lösen das über eine Kennung im Betreff oder – sauberer – über die Header Message-ID, In-Reply-To und References. Die Header-Variante überlebt auch, wenn jemand den Betreff ändert.
Mailanbindung: IMAP schlägt Pipe
Pipe im Mailserver. Der Mailserver übergibt die Nachricht direkt an ein Skript:
support: "|/var/www/helpdesk/bin/mail-import.php"
Schnell und ohne Verzögerung. Der Nachteil ist der Fehlerfall: Bricht das Skript ab, weil die Datenbank gerade nicht erreichbar ist, kann die Mail verlorengehen.
IMAP-Abholung. Das System meldet sich alle paar Minuten an einem Postfach an und verarbeitet neue Nachrichten:
*/3 * * * * www-data php /var/www/helpdesk/bin/fetch-mail.php >/dev/null
Etwas Verzögerung, dafür robust: Scheitert die Verarbeitung, bleibt die Mail ungelesen im Postfach und wird beim nächsten Lauf erneut versucht. Für die meisten Installationen ist das der bessere Weg.
Wichtig in beiden Fällen: Verarbeitete Nachrichten in einen Archivordner verschieben statt löschen. Wenn die Zuordnung einmal schiefgeht, ist das Original noch da.
Zustellbarkeit
Das mit Abstand häufigste Problem im Betrieb. Drei Regeln:
Absender ist eine eigene Adresse. support@example.com, nicht die Adresse des Anfragenden. Wer unter fremder Domain versendet, scheitert an SPF und DMARC.
SPF, DKIM und DMARC für die Versanddomain. Ohne diese Einträge landet ein nennenswerter Teil der Antworten im Spam, und der Kunde denkt, es sei keine Antwort gekommen.
Über authentifiziertes SMTP versenden, nicht über die lokale mail()-Funktion. Nur so bekommt das System Zustellfehler zurück und kann sie anzeigen.
Prüfen lässt sich das mit einer Testmail an ein Postfach bei einem grossen Anbieter und einem Blick in den Quelltext:
Authentication-Results: …
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
Absicherung
Ein Ticketsystem enthält Kundendaten und ist meist von aussen erreichbar. Das Minimum:
- Anmeldung nur über HTTPS, Sitzungscookies mit
Secure,HttpOnlyundSameSite - Zwei-Faktor-Authentifizierung für alle Bearbeiter
- Anmeldeversuche begrenzen
- Der Verwaltungsbereich zusätzlich hinter einer IP-Beschränkung oder einem Verzeichnisschutz
- Datenbanknutzer mit Rechten auf genau diese eine Datenbank
- Anhänge ausserhalb des Dokumentwurzelverzeichnisses ablegen und über ein Skript ausliefern, das die Berechtigung prüft
Der letzte Punkt wird oft übersehen. Liegen Anhänge unter /uploads/ im Webroot, sind sie mit der richtigen URL ohne Anmeldung abrufbar – und Dateinamen sind selten so zufällig, wie ihre Entwickler annehmen.
Datenschutz von Anfang an
Tickets sind personenbezogene Daten, häufig mit mehr Inhalt als nötig – Kunden schreiben in Supportanfragen oft ausführlich über ihre Situation.
Was von Beginn an eingerichtet gehört:
| Anforderung | Umsetzung |
|---|---|
| Löschfristen | automatische Löschung geschlossener Vorgänge nach definierter Frist |
| Auskunft | Export aller Vorgänge zu einer Adresse per Kommando |
| Löschbegehren | Verfahren, das auch Anhänge und Archivkopien erfasst |
| Zugriffsbeschränkung | Rollen statt “alle sehen alles” |
| Verzeichnis der Verarbeitungstätigkeiten | Eintrag mit Zweck, Kategorien, Fristen |
Ein Löschverfahren nachträglich einzubauen ist deutlich aufwändiger, als es von Anfang an vorzusehen – besonders, wenn Sicherungen mit betroffen sind.
Der laufende Aufwand
Ehrlich gerechnet:
- Updates: Sicherheitsaktualisierungen der Anwendung und ihrer Abhängigkeiten. Ein Ticketsystem ist ein attraktives Ziel, weil dort Kundendaten liegen.
- Postfachpflege: Spam im Support-Postfach, Auto-Antworten, Schleifen mit anderen Ticketsystemen.
- Zustellbarkeit überwachen: Reputation der Versand-IP, Blocklisten.
- Sicherung und Restore-Test.
Das ist der Punkt, an dem die Entscheidung zwischen Selbstbetrieb und Dienst fällt. Wer diese Aufgaben ohnehin für andere Systeme erledigt, hat wenig Zusatzaufwand. Wer sie allein für das Ticketsystem aufnehmen müsste, fährt mit einem gehosteten Dienst meist besser – vorausgesetzt, die Datenhaltung passt zu den eigenen Anforderungen.
Häufige Fragen
Lohnt sich ein selbst gehostetes Ticketsystem gegenüber einem Dienst?
Wenn Datenhoheit ein echtes Kriterium ist oder das Volumen die Lizenzkosten eines Dienstes deutlich übersteigt. Sonst rechnet sich der laufende Betriebsaufwand selten – Updates, Sicherung und Zustellbarkeit sind dauerhafte Aufgaben, keine einmaligen.
Wie kommen Mails ins Ticketsystem?
Zwei Wege: Der Mailserver leitet über eine Pipe direkt in ein Skript, oder das System holt regelmässig per IMAP ab. Die IMAP-Variante ist robuster, weil eine fehlgeschlagene Verarbeitung die Mail im Postfach lässt statt sie zu verwerfen.
Warum landen die Antworten meines Ticketsystems im Spam?
Meist weil das System unter der Adresse des Anfragenden versendet oder weil SPF und DKIM für die Absenderdomain fehlen. Der Absender muss eine eigene Adresse deiner Domain sein, und die Domain braucht saubere Authentifizierungseinträge.
Was ist beim Datenschutz zu beachten?
Tickets enthalten personenbezogene Daten, oft auch besondere Kategorien, wenn Kunden ausführlich schreiben. Nötig sind: Löschfristen, ein Verfahren für Auskunfts- und Löschbegehren, Zugriffsbeschränkung auf die Personen, die es brauchen, und ein Eintrag im Verzeichnis der Verarbeitungstätigkeiten.
Weiterlesen
- SPF, DKIM und DMARC einrichten
Die drei Einträge in der richtigen Reihenfolge, typische Syntaxfehler und wie du von p=none auf p=reject kommst, ohne Mails zu verlieren.
- Monitoring und Logauswertung im Alltag
Was überwacht gehört, welche Schwellen sinnvoll alarmieren und wie du aus Logs eine Störungsursache herausliest.
- Linux-Grundlagen für Webserver
Paketverwaltung, Dienste, Rechte, Firewall und die Kommandos, mit denen du eine Störung in Minuten eingrenzt.
- Plesk: Fallstricke bei Installation und Update
Reihenfolge von Betriebssystem und Panel, Konflikte mit vorinstallierten Diensten und was du vor einem Major-Update sicherst.