Test-System parallel zu E-Mails aufsetzen

[Ebebalf]

Hallo erstmal;
ich bin recht neu im Umgang mit OTRS; zur Zeit arbeite ich mich durch das Administrations-Handbuch um zu lernen und habe mir ein kleines System zum Testen aufgesetzt.

Ich würde gerne in einer kleinen Firma ein System aufsetzen, um die Mitarbeiter (und natürlich den Chef) von dem System zu überzeugen. Im Moment läuft es da so, dass alle Mitarbeiter auf die gleichen Mailaccounts (plural) Zugriff haben und sich Antworten auf E-Mails per CC ebenfalls zuschicken. Ich vermute mal die Ausgangslage ist nicht all zu ungewöhnlich.
Angedacht ist es so, dass ich ein kleines OTRS-System mal für ein paar Tage nebenher laufen lasse, damit sich alle das ganze mal ansehen und ein bisschen daran rumexperimentieren können. Die bisherigen Prozesse mit den E-Mails sollen da vorerst mal nicht beeinträchtigt werden.
Nun habe ich gelesen, dass es im OTRS nicht vorgesehen ist, dass abgeholte Mails auf dem Server belassen werden; das ist im Grunde auch kein sonderliches Problem, ich kann die Mails ja per getmail abholen und dann mit otrs.PostMaster.pl manuell an das System übergeben.
Mails von den Mitarbeitern, die CC an sich selbst geschickt wurden kann ich durch hinzufügen des Headers "X-OTRS-SenderType: agent" auch direkt entsprechend markieren und wenn die Mails auch an interne Ziele gehen zusätzlich noch "X-OTRS-ArticleType: email-internal" setzen.
Soweit ist das alles ja kein Ding.

Es gibt dennoch ein paar kleinere Aspekte, die mich stören, bzw. für die ich gerne Abhilfe hätte, wenn möglich:

• Jede Mail, die ins System kommt erzeugt ein neues Ticket. Selbst wenn es Antwort-Mails auf vorhergegangene Mails sind, was über In-Reply-To:- und References:-Header ersichtlich wäre. Doch die Header werden offenbar nicht ausgewertet. Die Tickets mühsam per Hand verschmelzen zu müssen ist nicht unbedingt zielführend. Gibt es da einen Weg?
• Der Date:-Header der Mails, also der Zeitpunkt, zu dem die jeweiligen Mails ursprünglich geschrieben wurden, scheint bei der Einspeisung ins System komplett verworfen zu werden; ist das so gewollt? Besteht da keine Möglichkeit wieder an den Inhalt dieser Information zu kommen? Gerade für den Anfang, wo ich die Mails der vergangenen Woche(n) importiere ist es doch etwas irritierend, wenn die nun alle ohne Zeitangabe sind, bzw. die einzig verfügbare Zeitangabe (Ticketerstellung) identisch ist.

Ansonsten ist mir in meinem Test-System noch aufgefallen, dass das System Benachrichtigungen per Mail Verschickt hat (Ticket-Besitzer geändert o.ä.), obwohl in den persönlichen Einstellungen sämtliche Benachrichtigungen auf „Nein“ bzw. „Keine Benachrichtigung” standen; gibt es da noch irgendwo einen globalen Parameter, der die Benutzereinstellungen überschreibt, oder wie kommt das?

[schulmann]

Selbst wenn es Antwort-Mails auf vorhergegangene Mails sind, was über In-Reply-To:- und References:-Header ersichtlich wäre. Doch die Header werden offenbar nicht ausgewertet.

SMTP-References haben bei uns immer einwandfrei funktioniert. Da dürfte irgendetwas anderes schieflaufen.

Der Date:-Header der Mails, also der Zeitpunkt, zu dem die jeweiligen Mails ursprünglich geschrieben wurden, scheint bei der Einspeisung ins System komplett verworfen zu werden; ist das so gewollt?

Vermutlich ja, da dürfte das Stichwort Revisionssicherheit zum Tragen kommen.

Besteht da keine Möglichkeit wieder an den Inhalt dieser Information zu kommen?

Wenn die Sysconfig-Variable "Ticket::Frontend::PlainView" den Wert "Yes" hat kann der Agent in der Ticketansicht die Artikel unformatiert ansehen.

Ansonsten ist mir in meinem Test-System noch aufgefallen, dass das System Benachrichtigungen per Mail Verschickt hat (Ticket-Besitzer geändert o.ä.), obwohl in den persönlichen Einstellungen sämtliche Benachrichtigungen auf „Nein“ bzw. „Keine Benachrichtigung” standen

Was steht in den Logs und in der Tickethistorie?

[Ebebalf]

SMTP-References haben bei uns immer einwandfrei funktioniert. Da dürfte irgendetwas anderes schieflaufen.

Das war offenbar ein Konfigurationsproblem. Core::PostMaster::PostmasterFollowUpSearchInReferences stand auf default false. Nachdem ich das geändert habe klappt es offenbar.

Der Date:-Header der Mails, also der Zeitpunkt, zu dem die jeweiligen Mails ursprünglich geschrieben wurden, scheint bei der Einspeisung ins System komplett verworfen zu werden; ist das so gewollt?

Vermutlich ja, da dürfte das Stichwort Revisionssicherheit zum Tragen kommen.

Hm, mir ist zwar schon klar, dass auf den Date:-Header nicht wirklich Verlass ist; da kann der Absender schließlich rein schreiben was er möchte, aber ausschließlich die Zeit zu verwenden, zu der die Mail ins System gelangt ist scheint mir auch etwas unglücklich zu sein.
Man stelle sich mal ein produktives System vor, bei dem aus irgendeinem Grund für längere Zeit (ein bis ein paar Tage) das Abholen der Mail fehlschlägt. Der Kunde weiß ja nichts von den Problemen und für ihn beginnt die Wartezeit ja eigentlich in dem Moment, wo er seine Mail wegschickt.

Wenn die Sysconfig-Variable "Ticket::Frontend::PlainView" den Wert "Yes" hat kann der Agent in der Ticketansicht die Artikel unformatiert ansehen.

Danke, das ist schonmal ein guter Anfang.
(Die Zahl der Konfigurationsoptionen ist ja geradezu erdrückend)

Ansonsten ist mir in meinem Test-System noch aufgefallen, dass das System Benachrichtigungen per Mail Verschickt hat (Ticket-Besitzer geändert o.ä.), obwohl in den persönlichen Einstellungen sämtliche Benachrichtigungen auf „Nein“ bzw. „Keine Benachrichtigung” standen

Was steht in den Logs und in der Tickethistorie?

Was sollte denn da stehen?
In der Tickethistorie steht:

Code: Select all

SendAgentNotification 	"OwnerUpdate"-Benachrichtigung versandt an "****". 

Im Systemlog steht im Grunde genau das gleiche:

Code: Select all

Sent agent 'OwnerUpdate' notification to '****'.

Wie gesagt hat der entsprechende Agent in den persönlichen Einstellungen (also das Zahnrädchen ganz oben links) sämtliche Benachrichtigungen auf „Nein” bzw. „keine Benachrichtigung” stehen.


BTW, welche Art von RegExp werden eigentlich bei den E-Mail-Filtern verwendet, oder gibt es ggf. eine Möglichkeit Filter anhand von Beispielen zu testen?

[schulmann]

Hm, mir ist zwar schon klar, dass auf den Date:-Header nicht wirklich Verlass ist; da kann der Absender schließlich rein schreiben was er möchte, aber ausschließlich die Zeit zu verwenden, zu der die Mail ins System gelangt ist scheint mir auch etwas unglücklich zu sein.

Dein Vorschlag wäre?

Man stelle sich mal ein produktives System vor, bei dem aus irgendeinem Grund für längere Zeit (ein bis ein paar Tage) das Abholen der Mail fehlschlägt. Der Kunde weiß ja nichts von den Problemen und für ihn beginnt die Wartezeit ja eigentlich in dem Moment, wo er seine Mail wegschickt.

Und wenn die Mail beim Kunden zwei Tage hängenbleibt weil einer seiner MTAs versagt gehen dessen Probleme zu Deinen Lasten obwohl Du vielleicht nur seine SAP-System betreust. Da ist mir die jetzige Einstellung deutlich lieber.

Was steht in den Logs und in der Tickethistorie?

Was sollte denn da stehen?

Da könnten z. B. mehrere Einträge in der gleichen Sekunde stehen.
Dann wäre die Wahrscheinlichkeit groß, dass ein anderer Agent die Benachrichtigung ausgelöst hat, z. B. durch eine Agentenbenachrichtigung.
Soweit ich weiß kann ein Agent die explizite Benachrichtigung durch einen anderen Agenten nicht verhindern.

BTW, welche Art von RegExp werden eigentlich bei den E-Mail-Filtern verwendet, oder gibt es ggf. eine Möglichkeit Filter anhand von Beispielen zu testen?

Du kannst mit einem beliebigen Editor eine Mail erstellen und diese dem Programm ~otrs/bin/otrs.PostMaster.pl auf stdin anbieten.
Damit sollten Tests recht schnell von der Hand gehen. Als Vorlage kannst Du eine Mail aus der unformatierten Ansicht herunterladen.

Alternativ kannst Du die regulären Ausdrücke auch dem Programm "egrep" übergeben. Das dürfte für die meisten Fälle ausreichend sein.

[Ebebalf]

Dein Vorschlag wäre?

Eine wirklich gute Lösung fällt mir dazu nicht wirklich ein, da jede Variante irgendwelche Haken hat.
Was ich mir allerdings vorstellen könnte wäre, dass man die Zeit verwendet, zu der die E-Mail im Postfach angekommen ist. (Ermittelbar anhand des dazugehörigen Recieved:-Headers). Wenn ich davon ausgehe, dass der Server mit den Postfächern (mehr oder weniger) im eigenen Einflussbereich liegt, sollte man dessen Systemuhr zumindest soweit trauen können, dass die Angaben stimmen.

Da könnten z. B. mehrere Einträge in der gleichen Sekunde stehen.
Dann wäre die Wahrscheinlichkeit groß, dass ein anderer Agent die Benachrichtigung ausgelöst hat, z. B. durch eine Agentenbenachrichtigung.
Soweit ich weiß kann ein Agent die explizite Benachrichtigung durch einen anderen Agenten nicht verhindern.

Ach, das heißt wenn jemand die Tickets manuell den Besitzern zuweist, dann führt das immer zu einer Benachrichtungsemail?
Gut zu wissen.

Alternativ kannst Du die regulären Ausdrücke auch dem Programm "egrep" übergeben. Das dürfte für die meisten Fälle ausreichend sein.

Okay. Das beantwortet meine Frage weitestgehend.
Gibt ja verschiedene „Dialekte” von RegExp und da wollte ich halt hauptsächlich wissen um welchen es sich hier handelt.

[schulmann]

Was ich mir allerdings vorstellen könnte wäre, dass man die Zeit verwendet, zu der die E-Mail im Postfach angekommen ist. (Ermittelbar anhand des dazugehörigen Recieved:-Headers).

Die Idee ist nicht schlecht.
Die Received-Zeile wann es im OTRS-Postfach angekommen ist ist bei professionellen Installationen aber nicht zielführend weil dort die Mails sowieso sofort an OTRS übergeben werden und sich dadurch die Zeit nicht ändern würde.
Wenn man sowas macht, dann sollte man die Received-Zeile des ersten Mailservers nehmen, der im eigenen Einflussbereich liegt.
Aber auch da gibt es Unzulänglichkeiten: Was ist wenn mein erster Mailserver oder meine Internetverbindung ausfällt?

Ach, das heißt wenn jemand die Tickets manuell den Besitzern zuweist, dann führt das immer zu einer Benachrichtungsemail?

Das hatte ich zwar nicht geschrieben weil ich es nicht sicher verifizieren kann, es scheint aber so zu sein.
Relevant sind da auch die Sysconfig-Variablen Ticket::Frontend::AgentTicketOwner###InvolvedAgent und Ticket::Frontend::AgentTicketOwner###InformAgent.

Eine ganz andere Geschichte ist aber: Warum macht man einen Besitzerwechsel? Der Grund dafür könnte ein suboptimales Queue-Design sein. Deshalb würde ich mir die Aufteilung der Queues kritisch ansehen.

Gibt ja verschiedene „Dialekte” von RegExp und da wollte ich halt hauptsächlich wissen um welchen es sich hier handelt.

Es dürfte sich um Perl regular expressions handeln (Vermutung meinerseits).
Vor dem produktiven Einsatz empfiehlt sich deshalb immer der Test mit einer passend präparierten Mail.