Kürzlich hatte ich auf der Arbeit das Problem, dass ein neu eingeführtes Ticketing-System sich automatisch aller auf die Support-Adresse eingehenden Mails annehmen hätte sollen – es aber nicht tat.
Auf dem Server läuft Debian, als MTA ist exim4 installiert.
In /etc/aliases stand nach der erfolgreichen Installation von Request Tracker (RT) bereits alles zum Besten …
rt3: "|/home/rt3/bin/rt-mailgate --queue incoming --action correspond --url http://rt3.domain.tld"
… sogar die Weiterleitung war aktiv …
pc-support: rt3
… doch irgendwie wollte die Zustellung der Mails nach RT einfach nicht klappen! In /var/log/exim4/mainlog war nach erfolglosen Mail-Versuchen (vorerst vom localhost aus, später auch aus dem LAN) zu lesen:
2007-10-09 05:23:42 1Ieqtj-0000u4-40 == |/home/rt3/bin/rt-mailgate --queue incoming --action correspond --url http://rt3.domain.tldR=system_aliases defer (-30): pipe_transport unset in system_aliases router
Nach einer etwas längeren Google-Suche war das Problem eingegrenzt: exim4 pipet Mails in der Standardkonfiguration nicht. Die Entwickler raten in der Doku zwar vom Pipen nach herkömmlicher Art ab – aber wenn niemand ein anständiges Beispiel beilegt und die Dokumentation im Kreis herumführt (In Z steht: „Schaue in XY nach“ und in XY steht „Schaue in Z nach“), biegt man die Konfiguration halt so um, dass zumindest die „mittelalterliche“ und gewohnte Vorgehensweise klappt.
Hierzu mussten in der Datei /etc/exim4/exim4.conf.template (falls eine monolithische Konfigurationsdatei verwendet wird) folgende Zeilen eingetragen werden:
... # for explanation and some workarounds. SYSTEM_ALIASES_USER = rt3 SYSTEM_ALIASES_GROUP = rt3 SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe system_aliases: ...
Seither gelangen neu eintreffende Mails direkt in das Ticketing-System und warten nun darauf, freiwillig von einem der Supporter übernommen zu werden. Dies scheint ein deutlich grösseres Problem zu sein *zwinker*