wir hatten zuletzt ein etwa 1-stündiges Problem mit unserem internen Mailserver, so dass OTRS seine inwischen erzeugten Mails nicht loswerden konnte. Nachdem das Problem behoben war hatte OTRS aber schon die Zustellversuche abgebrochen und hat mir dann anschließend entsprechende Mitteilungen zugestellt, Ausschnitt:
Message: CommunicationLog(ID:1914187,AccountType:-,AccountID:-,Direction:Outgoing,Transport:Email,ObjectLogType:Message,ObjectLogID:1988678)::Kernel::System::MailQueue => Temporary problem returned from server, requeuing message for sending. Message: SMTPCode: 451, ErrorMessage: Could not send message to server: 451, 4.7.0 Temporary server error. Please try again later. PRX5
!
Error:
Could not send message with ID '9296'! Please refer to the log.
Error: Failed.
Die Mailqueue war anschließend leer, wie kommt man in einer solchen Situation einfach an die entsprechenden Tickets, damit man einen neuen Sendeversuch starten kann?
Ok, das scheint also nicht möglich zu sein, oder? Aber was nützt mir die Info, dass OTRS x eMails nicht versenden konnte, wenn ich die entspechenden Tickets nicht wiederfinde?
der Sendemechanismus ist nicht für eine, nicht falsch verstehen, "wacklige" Infrastruktur gedacht. Immer wenn so etwas auftritt sollte die erste Massnahem sein den Daemon anzuhalten damit er nicht mehr weiterversendet.
Im Default werden drei Zustellversuche unternommen, das kann man in der System-Konfiguration einstellen: https://yourhost.example.com/otrs/index ... =MailQueue
Hier den Interval erhöhen und ggf. auch die Anzahl der Versuche.
Der Agent der die E-Mail gesendet hat, erhält auch eine Benachrichtigung: per E-Mail
Mit einer SQL-Query kann man zumindest die TicketIDs identifizieren und erhält damit einer Liste. Ich muss mal schauen ob ich die noch finde.
- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO
der Sendemechanismus ist nicht für eine, nicht falsch verstehen, "wacklige" Infrastruktur gedacht. Immer wenn so etwas auftritt sollte die erste Massnahem sein den Daemon anzuhalten damit er nicht mehr weiterversendet.
Im Default werden drei Zustellversuche unternommen, das kann man in der System-Konfiguration einstellen: https://yourhost.example.com/otrs/index ... =MailQueue
Hier den Interval erhöhen und ggf. auch die Anzahl der Versuche.
Der Agent der die E-Mail gesendet hat, erhält auch eine Benachrichtigung: per E-Mail
Mit einer SQL-Query kann man zumindest die TicketIDs identifizieren und erhält damit einer Liste. Ich muss mal schauen ob ich die noch finde.
- Roy
- Dämon anhalten ist zumindest in der Nacht oder bei den Gelegenheiten schlecht, wenn der Kollege mal wieder ohne Rücksprache den Exchangeserver neustartet
- Den Link schaue ich mir heute Abend mal an, der lässt sich hier auf der Arbeit nicht öffnen
- Betrifft das auch automatisch versendete Mails, z.B. beim Schließen von Tickets oder Erinnerungsmails an Agenten?
root wrote: ↑04 Aug 2021, 14:44Immer wenn so etwas auftritt sollte die erste Massnahem sein den Daemon anzuhalten damit er nicht mehr weiterversendet.
Das ist nicht wirklich praktikabel.
Warum der Daemon nicht einfach den einschlägigen Standard (RFC 5321) beachtet verstehe ich nicht.
Dort steht: Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.
Wir umgehen das indem wir die Mails mit dem SendmailModule Kernel::System::Email::Sendmail versenden.
Dann übernimmt der lokale Postfix die Mail und hält sich an RFC 5321.
Mit einer SQL-Query kann man zumindest die TicketIDs identifizieren und erhält damit einer Liste.
Im Communication Log wird das Subject der Mail und damit auch die Ticketnummer angezeigt.
jojo wrote: ↑07 Aug 2021, 11:02
OTRS ist kein MTA, deswegen sehe ich keinen Grund hier den genannten RFC zu beachten. Eher agiert OTRS hier als Client (MUA).
Optimalerweise wird die Mail über das lokale sendmail binary versendet. Die MTA auf dem Server ist schließlich dafür gemacht.
Hallo Jojo,
weil der Daemon auch für das Verschicken von Agenten-Benachrichtungen, Erinnerungen und Eskalationen genutzt wird hat er nach meiner Meinung nur teilweise die Rolle eines MUA.
Das Quintessenz aus solchen Diskussionen ist für mich aber erneut: In einer professionellen Installation ist für OTRS sowohl für ein- als auch für ausgehende Mails ein lokaler Postfix (oder ein anderer lokaler MTA) notwendig.
Ich stehe da auch eher auf der Seite von schulmann.
Das System sollte mMn hinsichtlich Mailversand und Empfang von sich aus fehlerresistent sein und solche Fälle auch ohne MTA abdecken können.
Ich packe das mal auf meine (Wunsch-/Entwicklungs-)Liste.
Octane wrote: ↑09 Aug 2021, 11:27
Ich habe jetzt diese Einstellungen angepasst, das betrifft aber nur den Mailversand im Fehlerfall und nicht den normalen Versand von Mails, oder?
Ich denke im Fehlerfall werden keine E-Mails versendet?
Mit er Einstellung legst Du fest wieviele Versuche maximal unternommen werden und der Abstand dazwischen. "Normal" ist ja Erfolg beim ersten Versuch.
- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO
Octane wrote: ↑09 Aug 2021, 11:27
Ich habe jetzt diese Einstellungen angepasst, das betrifft aber nur den Mailversand im Fehlerfall und nicht den normalen Versand von Mails, oder?
Ich denke im Fehlerfall werden keine E-Mails versendet?
Mit er Einstellung legst Du fest wieviele Versuche maximal unternommen werden und der Abstand dazwischen. "Normal" ist ja Erfolg beim ersten Versuch.
- Roy
Das meinte ich doch damit. OTRS versucht dann häufiger und länger eMails im Fehlerfalle doch noch zu versenden.
Ich wollte halt nur sicherstellen, dass dadurch nicht der normale Mailversand beeinträchtigt wird . Mich hat der Eintrag "IncrementAttemptDelayMinutes" verunsichert