Protokollieren der Mail-Abholung durch Postmaster-MailAccounts

schnudd31do3 · Post by **schnudd31do3** » 07 Jun 2022, 08:49

Hallo,
ich habe hin und wieder das Problem, dass E-Mails, die nachweislich in den Postfächern der Postmaster-MailAccounts waren, nicht im Ticketsystem ankamen. Das Logfile des MTA zeigt dabei keinen Transport, so dass die Wahrscheinlichkeit groß ist, dass das Ticketsystem die E-Mail im Postfach nur gelöscht statt abzuholen und danach im Postfach zu löschen. Zum Nachweis dieser Annahme fehlt mir aber jeglicher Hinweis in irgendwelchen Logfiles. Gibt es eine Möglichkeit, das Abholen von Emails im Detail zu protokollieren?

Post by **root** » 07 Jun 2022, 09:46

Hi,

ich zweifel ja nicht an der Aussage das die E-Mails im. Postfach waren. Aber definitiv daran das E-Mails ohne Abholen von Ticketsystem gelöscht wurden. Aus wirklich langer Erfahrung kann ich sagen es ist bis jetzt IMMER ein Fehler seitens der Administration gewesen. Dabei waren Dinge wie geclonte Systeme ("ja, garantiert holt der keine E-Mails ab"), andere Systeme die E-Mails abgeholt haben, PostMaster-Filter die E-Mails gelöscht haben (X-OTRS-Ignore: Yes), etc.

Alles was mit dem Abholen der E-Mails zu tun hat findest Du im Kommunikationslog.

- Roy

schnudd31do3 · Post by **schnudd31do3** » 07 Jun 2022, 12:07

Hi Roy,
ich beobachte das seit einiger Zeit. Ich zweifle auch nicht an deiner Darstellung, aber die Fakten kann ich nicht leugnen. Auch andere Nutzer haben mir schon von dem Verhalten berichtet.

Letzte Woche hatte ich eine Testmail aus anderen Gründen an das Ticketsystem gesendet, die nachweislich im Exchange-Postfach ankam und nicht im mail.log auftauchte. Nachdem ich die selbe Mail nochmals gesendet habe, tauchte sie im Ticketsystem und im mail.log auf. In den Communication-Logs habe ich keinen passenden Eintrag zur fehlenden Mail/Ticket finden können.

Wenn es eine falsche Admin-Einstellung wäre, müsste dann das Problem nicht dauerhaft auftreten? Es tritt aber nur sporadisch auf. Kann es ein Timing-Problem sein? Vielleicht kannst du mir eine Stelle in einem .pm nennen, in die ich testhalber code einfügen kann, das mir provisorisch die Aktivitäten protokolliert.

Volker

Post by **root** » 07 Jun 2022, 13:27

Hi,

Erst mal ist zu klären wir die E-Mails in das System kommen: per SMTP (via procmail) oder ob Sie abgeholt werden. Das ist aus Deinen Aussagen "wird gelöscht" (nur bei Abholen) und einem Blick in "mail.log" nicht eindeutig. Wie passiert's denn nun?

- Roy

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 07:34

Postmaster Mail Account:

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 07:35

SendmailModule

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 07:48

Als MTA ist postfix / sendmail aktiv. Kein Procmail installiert.

Post by **root** » 09 Jun 2022, 08:02

Hallo,

wenn also die E-Mails nur per IMAP abgeholt werden, dann steht alles notwendige im Kommunikationslog. Da diese Log auch aufgerämt werden empfehle ich die SysConfigs CommunicationLog::PurgeAfterHours::SuccessfulCommunications und CommunicationLog::PurgeAfterHours::AllCommunications anzupassen.

Sobald als eine E-Mail wieder angeblich abgeholt und gelöscht suche.

Kleiner Tipp am Rande: einfach mal beim Mailserveradmin prüfen lassen welche IP-Adresse auf das Postfach zugreifen.

- Roy

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 08:46

Hi Roy,

die Communocationslogs reichen viel weiter zurück, als die Daten der fehlenden Mails. Daran kann es also nicht liegen. Und es greift genau ein User auf das Postfach zu: Znuny.

Es gibt eigentlich nur zwei Möglichkeiten, warum es sporadisch nicht richtig läuft:
1. Die Mail wird vor dem Abholen aus dem Postfach im Postfach gelöscht
2. Die Mail wird abgeholt, im Postfach gelöscht, aber nicht in ein Ticket umgewandelt

Könnte es einen Zusammenhang mit dem Datenbankserver (postgresql) geben? Evtl. Verbindungsprobleme während der Mail-Abholung?

Volker

Post by **root** » 09 Jun 2022, 09:17

schnudd31do3 wrote: ↑09 Jun 2022, 08:46 Es gibt eigentlich nur zwei Möglichkeiten, warum es sporadisch nicht richtig läuft:
1. Die Mail wird vor dem Abholen aus dem Postfach im Postfach gelöscht
2. Die Mail wird abgeholt, im Postfach gelöscht, aber nicht in ein Ticket umgewandelt

Warum scheint es nicht möglich zu sein, den Vorgang, wie Znuny die Mails abholt und in ein Ticket verwandelt, im Detail zu debuggen und zu loggen? Warum verschiebt Znuny nicht einfach die Mail in den Gelöscht-Ordner des Postfachs (wenigstens zu Debugging-Zwecke)?

Hi,

nur so als Anmerkung am Rande: ich habe nicht gefragt welcher User auf das Postfach zugreift, sondern von welche(n) IP-Adresse(n) der Zugriff erfolgt.

zu 1.) Das Löschen der E-Mail bei IMAP/IMAPS erfolgt nur wenn die E-Mail erfolgreich verarbeitet wurde.
zu 2.) Das ist möglich über die PostMaster-Filter, steht dann aber im Kommunikationsprotokoll.

- Roy

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 09:45

Hi,

der Zugriff auf das Postfach im Exchange erfolgt nur durch den Server, auf dem Znuny läuft.

Am 02.06. und am 08.06. hatten wir wieder fehlende Tickets/Antworten auf Tickets, das Kommunikationsprotokoll zeigt nichts in diesem Zeitraum:

Post by **root** » 09 Jun 2022, 09:56

Hi,

Also ich weiss nicht was Deine Erwartungshaltung ist, ich sehe über 6000 Protokolleinträge. Hast Du jemals auf einen draufgeklickt?

- Roy

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 10:19

Es ist einer sehr ernste Sache, dass wir Anfragen unserer Kunden nicht bearbeiten, weil das Ticketsystem sie nicht erfasst. Uns ist dabei die Außenwirkung wichtig. Meine Erwartung habe ich glaube ich schon mehrmals hier sehr deutlich gemacht: Helfen zu debuggen!

Also ich sehe keine 6000 Einträge, sondern seit dem 30.05. gibt es nur die 36 vom 30.05. Es sind ausschließlich diese Meldungen enthalten:
Open connection to 'xxxx' (xxxx). 05/30/2022 10:25:27
Kernel::System::MailAccount::IMAPS IMAPS: Can't connect to xxxx: Unable to connect to xxxx: IO::Socket::IP configuration failed

Heute um 10:00 hatten wir wieder das Problem. Kannst du in meinem Screenshot irgendwelche Fehler-Einträge vom 09.06. sehen?

Post by **jojo** » 09 Jun 2022, 11:02

Hallo,

wie Roy schon geschrieben hat, werden die Mails nur gelöscht wenn sie abgeholt und verarbeitet wurden. Hast Du denn schon das OTRS Logfile analysiert? Hast Du schon geschaut welche IPs auf das Postfach zugreifen?

Deiner Erwartungshaltung finde ich übrigens eine bodenlose Frechheit. Du nutzt wahrscheinlich kostenfrei eine Software ohne ausreichende Ahnung für den Betrieb zu haben und versuchst nun diese Probleme auf andere (freiwillige) Helfer in einem Forum abzuwälzen.

Dein Unternehmen sollte mal über entsprechenden Wechsel auf einen professionellen Support nachdenken z.B. in Form einer SaaS Lösung.

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 11:37

Bitte sachlich bleiben!

Wie interpretiert ihr meine screenshots?

Habt ihr Vorschläge, was ich noch untersuchen könnte?

Post by **jojo** » 09 Jun 2022, 14:38

Das war sachlich. Beantworte doch einfach mal die Fragen von Roy und mir

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 15:10

1. "Hast Du denn schon das OTRS Logfile analysiert? Hast Du schon geschaut welche IPs auf das Postfach zugreifen?" Das erfolgte schon mehrfach, bitte einfach meine Antworten lesen und nicht wiederholt das bereits Beantwortete nochmals anfragen.
2. "Deiner Erwartungshaltung finde ich übrigens eine bodenlose Frechheit. Du nutzt wahrscheinlich kostenfrei eine Software ohne ausreichende Ahnung für den Betrieb zu haben und versuchst nun diese Probleme auf andere (freiwillige) Helfer in einem Forum abzuwälzen." Ohne Kommentar
3. Meine screenshots wurden immer noch nicht kommentiert.

Meine aktuelle Vermutung ist, dass es nicht innerhalb von Znuny liegt, aber eventuell an der Umgebung, über die Znuny kommuniziert. Dafür spräche, dass es keine Logeinträge im Znuny gibt. Wenn es ein Problem von Znuny wäre, müssten die Probleme im Communication-Log aufgezeichnet sein. Ich habe jetzt die Konfiguration von Postfix geändert und werde es beobachten.

schnudd31do3 · Post by **schnudd31do3** » 09 Jun 2022, 15:25

Welche Schritte durchläuft Znuny, wenn es die Postmaster-Mail-Accounts abfragt? Ich meine damit, welche Module und welche Funktionen nacheinander aufgerufen werden bis hin zum Aufruf des lokalen MTA, d. h. die Kommandozeile mit den Parametern, die dann z. B. Sendmail übergeben werden.

hkais · Post by **hkais** » 09 Jun 2022, 20:33

schnudd31do3 wrote: ↑09 Jun 2022, 15:10 1. "Hast Du denn schon das OTRS Logfile analysiert? Hast Du schon geschaut welche IPs auf das Postfach zugreifen?" Das erfolgte schon mehrfach, bitte einfach meine Antworten lesen und nicht wiederholt das bereits Beantwortete nochmals anfragen.
2. "Deiner Erwartungshaltung finde ich übrigens eine bodenlose Frechheit. Du nutzt wahrscheinlich kostenfrei eine Software ohne ausreichende Ahnung für den Betrieb zu haben und versuchst nun diese Probleme auf andere (freiwillige) Helfer in einem Forum abzuwälzen." Ohne Kommentar
3. Meine screenshots wurden immer noch nicht kommentiert.

Meine aktuelle Vermutung ist, dass es nicht innerhalb von Znuny liegt, aber eventuell an der Umgebung, über die Znuny kommuniziert. Dafür spräche, dass es keine Logeinträge im Znuny gibt. Wenn es ein Problem von Znuny wäre, müssten die Probleme im Communication-Log aufgezeichnet sein. Ich habe jetzt die Konfiguration von Postfix geändert und werde es beobachten.

zwei IT'ler die sich "streiten"

und natürlich sind immer die Anderen schuld

Ernst zurück:

Um auszuschließen, dass es weitere Dienste gibt, die auf das Postfach zugreifen (andere User/andere IPs)
=> einfach das Kennwort ändern UND NUR in Znuny hinterlegen und keinem geben. Dann kann kein Anderer mehr zugreifen und die Mails abrufen. Und der, der Zugreifen will, wird sich bald melden

Bei IMAP auch selber kein IMAP Client auf dem eigenen PC einrichten, hatte schon die dubiosesten Issues damit. D.h. darf wirklich nur Znuny darauf zugreifen!

Dann sind beide IT'ler Seiten/Anforderungen abgedeckt. Und man hat eine Fehlerquelle eliminiert.

Das Logging, kann ich bestätigen, finde ich auch nicht prickelnd. Und zum Glück habe ich es schon lange nicht mehr benötigt (4.x => 5.x Migration)

schulmann · Post by **schulmann** » 09 Jun 2022, 23:30

jojo wrote: ↑09 Jun 2022, 11:02 Deiner Erwartungshaltung finde ich übrigens eine bodenlose Frechheit. Du nutzt wahrscheinlich kostenfrei eine Software ohne ausreichende Ahnung für den Betrieb zu haben und versuchst nun diese Probleme auf andere (freiwillige) Helfer in einem Forum abzuwälzen.

Hallo jojo,

bitte nicht aufregen.

Es war nicht das erste Mal, dass mir diese Person negativ auffällt.
Sonst wäre sie nicht schon länger auf meiner Ignore-Liste.

CD

reneeb · Post by **reneeb** » 10 Jun 2022, 09:00

schnudd31do3 wrote: ↑09 Jun 2022, 10:19 Es ist einer sehr ernste Sache, dass wir Anfragen unserer Kunden nicht bearbeiten, weil das Ticketsystem sie nicht erfasst. Uns ist dabei die Außenwirkung wichtig. Meine Erwartung habe ich glaube ich schon mehrmals hier sehr deutlich gemacht: Helfen zu debuggen!

Also ich sehe keine 6000 Einträge, sondern seit dem 30.05. gibt es nur die 36 vom 30.05. Es sind ausschließlich diese Meldungen enthalten:

Es sind über 6000 Einträge (siehe Tab "All").

schnudd31do3 wrote: ↑09 Jun 2022, 10:19 Open connection to 'xxxx' (xxxx). 05/30/2022 10:25:27
Kernel::System::MailAccount::IMAPS IMAPS: Can't connect to xxxx: Unable to connect to xxxx: IO::Socket::IP configuration failed

Heute um 10:00 hatten wir wieder das Problem. Kannst du in meinem Screenshot irgendwelche Fehler-Einträge vom 09.06. sehen?

Hast Du mal auf die Einträge im Log geklickt? Dann bekommst Du mehr Details. Wenn eine Nachricht abgeholt wurde dann gibt es auf der Unterseite die Einträge für "Connection" und "Message". Wenn Du auf die Message gehst, siehst Du was mit der Mail passiert. Ggf. auch wenn die Mail nicht verarbeitet werden konnte.

Hast Du auch mal in den <ZNUNY_HOME>/var/spool-Ordner geschaut? Wenn eine Mail aus welchen Gründen auch immer nicht verarbeitet werden kann (das muss nicht an einem Postmaster-Filter liegen, sondern evtl auch daran dass die Mail zu groß ist etc.) dann wird sie dort abgelegt...

schnudd31do3 · Post by **schnudd31do3** » 10 Jun 2022, 13:35

Hallo Renee,

danke, dass du zu einer sachlichen und hilfreichen Diskussion zurück führst. Ich beobachte deine Arbeit schon länger und weiß sie sehr zu schätzen!

Ich werde die Hinweise im Detail noch prüfen, möchte die aber einen Zwischenstand geben. Heute hatten wir wieder fehlende Tickes, die nur wenige Zeilen hatten. Ich müsste im 24h-Log etwas dazu finden, aber nichts ist darin:

schnudd31do3 · Post by **schnudd31do3** » 10 Jun 2022, 13:45

Leider sah ich den Wald vor Bäumen nicht. Es stimmt, dass es über 6000 Einträge gibt, aber das Log zeigt nur die fehlerhaften 36 vom 30.05., nicht die fehlerhaften, die z. B. heute hätten eventuell auftauchen müssen.

Dass es sein könnte, dass weitere Personen auf das Postfach zugreifen, ist verständlich, aber in meinem Fall unwahrscheinlich, da die Zugangsdaten nur mir und meinem IT-Kollegen und Znuny bekannt sind. Zusätzlich haben wir einen weiteren Prozess mit Postfach angelegt, der noch nicht veröffentlicht wurde und da hatte ich ebenso Ticketverluste beobachtet.

Es sehen alle heutigen aufgeklappten Logeinträge so aus:

schnudd31do3 · Post by **schnudd31do3** » 10 Jun 2022, 14:01

Heute nichts in den Daemon logs, obwohl es Ticketverlust gab:

schnudd31do3 · Post by **schnudd31do3** » 10 Jun 2022, 14:04

Auch nicht im otrs.log:

schnudd31do3 · Post by **schnudd31do3** » 10 Jun 2022, 14:05

Unbedeutendes im otrs.log.2022-06 am 10.06.:

hkais · Post by **hkais** » 11 Jun 2022, 10:42

leider viele Bilder, die man als Text suchen kann ...
Im Editor gibt es eine Code section.

Zurück zu deinem Thema, kannst Du mir folgendes bitte binär (ja/nein) beantworten:

1) kannst Du ausschließen, dass es keine weitere Person oder Dienst gibt, die auf das Postfach zugreift: AUSSER und ausschließlich Znuny?

2) ist die verlorene Mail laut MTA log eingetroffen?

3) ist die verlorene Mail laut MTA log im Postfach, welches Znuny abruft, eingetroffen?

4) zur Sicherheit: die verlorene Mail, ist diese laut Znuny Log definitiv zu finden?

schnudd31do3 · Post by **schnudd31do3** » 13 Jun 2022, 15:55

1) kannst Du ausschließen, dass es keine weitere Person oder Dienst gibt, die auf das Postfach zugreift: AUSSER und ausschließlich Znuny?
Ja.
2) ist die verlorene Mail laut MTA log eingetroffen?
Nein. Es werden nur ausgehende Email protokolliert.
3) ist die verlorene Mail im Postfach, welches Znuny abruft, eingetroffen?
Ja. Die verlorenen Mails sind definitiv im Postfach vor dem Abholen gewesen und befinden sich auch im Exchange-Mailarchiv
4) zur Sicherheit: die verlorene Mail, ist diese laut Znuny Log definitiv zu finden?
Nein.

Sorry, ganz digital antworten lies sich nicht machen, da eventuell missverständlich

schnudd31do3 · Post by **schnudd31do3** » 13 Jun 2022, 15:59

Kleine Historie vom vergangenen Freitag:
4 Testmails an das System gesendet -> kein Ticket
Reboot der VM
5. Testmail gesendet -> Ticket erstellt

Heute nach dem Wochenende wieder 4 Emails im Exchange-Archiv -kein Ticket erstellt. Bin mir nicht sicher, ob der Reboot am Freitag tatsächlich etwas berichtigt hat, denn heute fehlten wieder Emails.

Wir haben jetzt temporär eine Person als Kopieempfänger eingerichtet, damit keine Support-Anfrage von uns unerkannt bleibt.

schnudd31do3 · Post by **schnudd31do3** » 13 Jun 2022, 16:27

Mir ist heute aufgefallen, dass als ein Testticket nicht in ein Ticket umgewandelt wurde, die SchedulerTaskWorkerOUT-logs nicht geschrieben wurden. Nachdem ich den Server neu gestartet hatte, wurden wieder logfiles in /opt/otrs/var/log/Daemon geschrieben. Danach zeigte SchedulerTaskWorkerOUT.log eine erfolgreiche Email-Abholung:

hkais · Post by **hkais** » 13 Jun 2022, 18:58

wie Groß sind die verlorenen E-Mails?
Haben diese Anhänge?

Mal auf POP3 connector umstellen, ob es damit dann besser wird?

Post by **Johannes** » 14 Jun 2022, 08:58

Ich hab das jetzt hier eine Weile verfolgt und ich bin beim Rest vom Schützenfest.
Da holt wer anders die Nachrichten ab oder hat sein OWA/Outlook offen und schiebt munter durch die Gegend.

Das keine Logs geschrieben werden, wenn keine Mails kommen ist ja normal. Der Reboot hat ggf. nur Einfluss darauf gehabt wann die Mails geholt werden.

Ich kann gern einmal anbieten für 30 Minuten einen Blick auf das Thema zu werfen, nur um hier keine X Akte offen zu lassen.
Das Frage Antwort Spiel scheint mir ausreichend gespielt.

Gruß
Johannes

schnudd31do3 · Post by **schnudd31do3** » 14 Jun 2022, 09:00

Die Mails sind zwischen einigen KBytes und 1-2MBytes groß und haben manchmal Bildanhänge. POP3 geht nicht, da wir dann unser gesamtes Mailsystem umstellen müssten.

Ich habe festgestellt, dass es Logfiles des SchedulerTaskWorkers mit einer Nummer im Dateinamen und welche ohne gibt: SchedulerTaskWorkerOUT-XXXXXXXXX.log und SchedulerTaskWorkerOUT.log. Sind das temporäre Dateien, die manchmal nicht mehr gelöscht werden können?

Gibt es Einstellungen in der sysctl.conf, die eventuell problematisch sind?
Ich habe in der sysctl.conf z. B. diese Timeouts:
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 15
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_keepalive_intvl = 5
net.ipv4.tcp_keepalive_probes = 6

Post by **Johannes** » 14 Jun 2022, 12:30

Die Dateien werden beim Restart des Daemons erzeugt.
Mit Nummer => Alter Daemon Lauf
Ohne Nummer => Aktueller Daemon Lauf

Zu Deinen Settings kann ich nicht viel sagen, außer das ich bezweifle das sie einen direkten Einfluss auf dein IMAP Abruf aus dem Ticket System haben.
Wenn das System per IMAP abruft, steht das im Komm. Log. Wenn es das nicht tut, taucht dort nichts auf. Wenn es bei einem Abruf ein Problem gibt, steht das dann dort. Wie schon vorher geschrieben.

Wenn dort also nichts steht, ist auch nichts passiert.

schnudd31do3 · Post by **schnudd31do3** » 14 Jun 2022, 15:28

Hi Johannes,

gut, dass jetzt klar ist, woher die Nummern stammen. Ich hatte sie für Prozessnummern gehalten, die aufgrund von eventuellen abgebrochenen Kind-Prozessen stehen geblieben sind. Mittlerweile glaube ich auch nicht an einen Einfluss der sysctl-Settings.

Ich gebe dir uneingeschränkt Recht, was die Ablauflogik angeht, das deckt sich exakt mit dem Programmcode z. B. in IMAP.pm. Es scheint das Kuriose zu sein, dass von außen betrachtet sich eine andere Ablauflogik zu ergeben scheint. Um dem auf die Spur zu kommen habe jetzt mal testhalber den Code in IMAP.pm für einen Zeitstempel in SchedulerTaskWorkerOUT.log eingefügt, um einen genauen zeitlichen Zusammenhang mit anderen Logs zu erhalten.

Ich habe mittlerweile auch mal die ulimits auf Standardwerte gesetzt, um danach zu sehen, ob es eventuell an der Begrenzung von Ressourcen liegen könnte.

Post by **Johannes** » 14 Jun 2022, 16:01

Ok, viel Erfolg.
nur so als "Story" am Rande:
Wir hatten es auch schon das andere Nutzer den Account bei sich eingebunden hatten und dann wilde Filder Regeln für Unruhe gesorgt haben. Immer nur wenn die Nutzer Online waren, trat das Phänomen auf.
Um es zu finden blieb nur das Ticket System mal offline zu schalten und zu prüfen ob Mails "verschwinden". Dann war klar das ein Dritter im Spiel ist.

Sonst steht das Angebot: wenn Du es nachstellen kannst, wir helfen im Rahmen von ~30 Minuten auch mal um so ein Problem zu finden. Der Computer/Server/das Programm macht ja nur was man ihm sagt.

Gruß

schnudd31do3 · Post by **schnudd31do3** » 15 Jun 2022, 15:49

Es ist verständlich, dass man zunächst Nutzerfehler etc. vermutet, die sich oftmals auch bestätigen.

Wir haben die Logfiles des Exchange analysiert und belegen können, dass ausschließlich der Server, auf dem Znuny läuft, zugegriffen hat. Durch den Einsatz des Zeitstempels konnte heute zweifelsfrei belegt werden, dass eine Email vom Ticketsystem abgeholt wurde, aber nicht im Ticketsystem registriert wurde. Die Serverzeit (blauer Screenshot) liegt 2 Stunden zurück.

1. Es könnte sich am Ende herausstellen, dass es ein Problem auf der VM ist. Das wäre dann eventuell im Sinne von Znuny, zu wissen, dass es keine diesbezüglichen Fehler hat.
2. Es könnte sich am Ende herausstellen, dass Znuny ein bisher unentdecktes Problem hat. Das wäre dann eventuell im Sinne von Znuny, dadurch das Produkt verbessern zu können.

Deshalb, wer Lust hat, ist gerne eigeladen, mit Tipps und Ideen zu helfen, dem Problem auf die Spur zu kommen. Ich freue mich auf die Hinweise

Post by **Johannes** » 15 Jun 2022, 17:00

Sonst steht das Angebot: wenn Du es nachstellen kannst, wir helfen im Rahmen von ~30 Minuten auch mal um so ein Problem zu finden. Der Computer/Server/das Programm macht ja nur was man ihm sagt.

Du kannst dich gern an uns wenden.
Wir finden kurzfristig einen Termin (Ab Montag)

schnudd31do3 · Post by **schnudd31do3** » 27 Jul 2022, 10:59

Es sind jetzt 5 Wochen seit dem letzten Auftreten von Ticketverlusten vergangen. Es hat schlagartig aufgehört, ohne dass am Znuny-Server oder unserem Exchange-Server oder irgend etwas in der Mailverarbeitungskette geändert wurde. Es ist weiterhin unklar, was zum Auftreten und zum abrupten Aufhören der Störung geführt hat. Es bleibt als Spekulation eventuelle Unverträglichkeiten zwischen Windows-Server-Updates und Linux-Updates.

Um für den nächsten Störfall vorbeugend eine bessere Fehlersuche realisieren zu können, werden wir von IMAP auf procmail+smtp für die Abholung von Emails umsteigen. Der Znuny-Server wird dabei Email-Empfänger.

Allen, die mitgeholfen und mitüberlegt haben, was die Probleme hervorgerufen haben könnten, danke ich sehr. Insbesondere für eure Geduld