24.07.2023, aktualisiert um 18:32:29 Uhr

6221

Unerklärbares Verhalten beim SMTP-E-Mail-Versand

Hallo!

Wir haben eine in C# selbst entwickelte Software, die unter anderem E-Mails über SMTP verschickt. Diese Software ist bei vielen Kunden seit Jahren im Einsatz – sie ist jeden Arbeitstag im Dauerbetrieb, und es werden damit täglich Hunderte von E-Mails verschickt. Nur bei einem Kunden haben wir eine Merkwürdigkeit, und wir kommen nicht darauf, was es sein könnte.

Es handelt sich dabei um ein kleines Netzwerk mit einem Windows-Server 2022 Standard und fünf Arbeitsstationen. Der Server sieht im Groben so aus:

ASUS SERVER P12R-E/10G-2T S1200 C256/VGA/2xGBL/ATX
ASUS SERVER ASMB10-iKVM Modul für P12R
CPU Intel Xeon E-2356G/3.2 GHz/12MB/UP/LGA1200/Tray
64 GB RAM PC3200, ECC/UB, Samsung (2Rx8)
5 SSD 2.5" 1.92TB Samsung PM1643a SAS3 (RAID10 3.49TB + Hotspare)
BC MegaRAID 9560-8i PCIe x8 SAS/NVMe

Als Switch verwendet der Kunde folgendes Modell:

NETGEAR JGS524 Switch 24 Port Gigabit Ethernet LAN Switch

Die Arbeitsstationen:

Micro-PC
CPU Core i7-1165G7
16 GB SO DDR4-RAM,
SSD 500GB M.2 NVMe SSD
WLAN, 1x LAN 10/100/1000 (Netz läuft über Kabel mit 1 GBit/s)
Windows 11 Pro

Nun ist es so, dass nur in diesem Netzwerk der SMTP-Versand des Öfteren in ein Timeout läuft. Versucht es der Anwender ein zweites Mal, dann geht es fast immer.

Das Timeout ist auf Standard 100 Sekunden eingestellt, sodass man genug Zeit hat, E-Mails zu versenden. Diese sind auch samt Anlagen in der Regel um die 120 KB klein.

Wir haben bis zur Stelle gedebuggt, bis die E-Mail verschickt wird:

SmtpClient.Send()

Hierbei handelt es sich um den SMTP-Client von .NET.

Die Anwendung verharrt bei Fehlern auf der Methode "SmtpClient.Send()" und gibt erst nach 100 Sekunden mit einer Ausnahme auf, welche nur sagt, dass das Timeout erreicht wurde:

"System.Net.Mail.SmtpException: Timeout für den Vorgang wurde überschritten."

Nun gehen mir die Ideen aus. Ich glaube auch nicht, dass das Programm einen Fehler hat – dann müsste dieser bei irgendeinem anderen Kunden aufgetreten sein, was aber nicht der Fall ist. Daher tippe ich auf die Netzwerk-/Sicherheitskonfiguration des Kunden.

Nun wollte ich fragen, ob jemand Ähnliches erlebt hat und eventuell auch Lösungsansätze hat, die mir vielleicht auf die richtige Spur bringen.

Danke im Voraus und liebe Grüße

René

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7940237821

Url: https://administrator.de/forum/unerklaerbares-verhalten-beim-smtp-e-mail-versand-7940237821.html

Ausgedruckt am: 26.12.2024 um 01:12 Uhr

45 Kommentare

Neuester Kommentar

Moin,

Hast Du mal parallel mitgesnifft, was sich auf der Leitung tut, wenn diese verhalten auftritt?

Oder einfach mal einen smarthost (raspi oder kleine linux-VM) dazwischengeschaltet, um zu schauen, ob sich das Verhalten dann ändert?

Als Entwickler solltet ihr schon wissen, wie man debugged und nicht einfach nur "Bauklötze zusammensteckt".

lks

Zitat von @Lochkartenstanzer:

Hast Du mal parallel mitgesnifft, was sich auf der Leitung tut, wenn diese verhalten auftritt?
Oder einfach mal einen smarthost (raspi oder kleine linux-VM) dazwischengeschaltet, um zu schauen, ob sich das Verhalten dann ändert?

Einen Smarthost könnte man versuchen. Einen Sniffer wäre aber die letzte Möglichkeit, allerdings nur, wenn das auch honoriert wird, denn es sonst läuft seit 13 Jahren bei allen anderen fehlerfrei.

Als Entwickler solltet ihr schon wissen, wie man debugged und nicht einfach nur "Bauklötze zusammensteckt".

Danke, ich glaube, das zu können

Hallo

Ist denn von da aus wo eure Software läuft überhaupt eine SMTP-Verbindung zum Zielserver möglich? Du schreibst leider nicht genau, wo eure Software läuft und wo der SMTP-Server. Oder ich hab's überlesen.

Manuel

Zitat von @temuco:

Einen Smarthost könnte man versuchen. Einen Sniffer wäre aber die letzte Möglichkeit, allerdings nur, wenn das auch honoriert wird, denn es sonst läuft seit 13 Jahren bei allen anderen fehlerfrei.

Moin,

Auch wenn es die letzten 13 Jahre funktioniert hat, heißt das nicht, daß da keine Bugs drin sind. Und einen wireshark anwerfen kostet nur ein paar Minuten. Wenn das nachweist, daß der Fehler nicht bei euch liegt, ist das mehr wert als eine nicht berechnete halbe Stunde. Denn dann könnt ihr begründen, warum ihr den den Aufwand abrechnen wollt.

lks

Hallo

viele Mailserver akzeptieren nun noch TLS Empfang und das scheint mir hier nicht gegeben

so long

Yumper

Zitat von @manuel-r:

Hallo

Ist denn von da aus wo eure Software läuft überhaupt eine SMTP-Verbindung zum Zielserver möglich? Du schreibst leider nicht genau, wo eure Software läuft und wo der SMTP-Server. Oder ich hab's überlesen.

Das habe ich verschlampt, sorry! Ja, die SMTP-Server sind immer erreichbar. In der Regel (auch in diesem Fall) handelt es sich um Exchange-Online von einem Microsoft-365-Plan. Ein paar wenige schicken über deren Internet-Provider. Nur bei diesem Kunden könnte ich vor dem Versand die Erreichbarkeit seines Exchange-Online prüfen.

Ich habe den Kunden gefragt, wie er ins Internet geht: Er nutzt als Router eine Digitalisierungsbox von der Telekom, mit der ich bisher kaum Berührung hatte. Ich wollte mir die Protokolle anschauen, aber wie es aussieht, taugen diese nur für eine Live-Vorschau, denn es werden nur 50 letzten Einträge gespeichert.

Zitat von @yumper:

Hallo

viele Mailserver akzeptieren nun noch TLS Empfang und das scheint mir hier nicht gegeben

Doch, ausschließlich TLS/587 – sonst würde das nie funktionieren. Wie gesagt, der Fehler taucht nicht immer auf (ca. 10%). Versucht es der Anwender darauf wieder, dann geht es.

Zitat von @temuco:

Eigentlich zielte die Frage darauf ab, ob der Rechner auf dem eure Software läuft per SMTP zum Mailserver kommt. Bei uns bspw. dürfen nur bestimmte Server per SMTP nach außen und Clients gar nicht.

Manuel

Zitat von @manuel-r:
Eigentlich zielte die Frage darauf ab, ob der Rechner auf dem eure Software läuft per SMTP zum Mailserver kommt. Bei uns bspw. dürfen nur bestimmte Server per SMTP nach außen und Clients gar nicht.

Ach so! Ja, der Rechner darf es. Wie schon auch beschrieben: Normalerweise funktioniert es auch, ab und an aber doch nicht. Wenn nicht, dann versucht es der Anwender wieder und dann geht es.

Ich überlege, bei diesem Kunden die SMTP-Mail vom IIS zu installieren. Dann kann er seine E-Mails lokal sofort abliefern und der IIS kümmert sich als Smarthost um den weiteren Versand. Wahrscheinlich ist das am schmerzlosten...

Zitat von @temuco:
Ich überlege, bei diesem Kunden die SMTP-Mail vom IIS zu installieren (...)

Toll

Ich habe testhalber den IIS inkl. SMTP-Server auf einem Server 2022 installiert und erfahre – sofern ich das richtig verstand –, dass diese Konfiguration von Microsoft quasi als obsolet betrachtet wird und dass man sie nur mit Tricks einigermaßen zum Laufen bringen soll. Richtig Lust darauf habe ich aber nicht.

Was bleibt noch übrig? Postfix? Da müsste ich aber einen virtuellen Linux aufsetzen. hMailServer? Ok, das könnte eine passende Alternative sein.

Hallo,

Zitat von @temuco:
Was bleibt noch übrig?

Wie schon gesagt wurde. Mit einen Kabelhai nachsehen warum das Passiert. https://www.wireshark.org/download.html
Oder dem SMTP Server betreiber (Microsoft) bitten das die dir ihre SMTP Logs geben wo deine Software versuht sich zu Verbinden.

Gruß,
Peter

P.S. Wireshark ist schneller, ergiebiger. Aber kläre auf jeden Fall ob das dein Kunde dir Bezahlt.

Moin...

P.S. Wireshark ist schneller, ergiebiger. Aber kläre auf jeden Fall ob das dein Kunde dir Bezahlt.

also wenn er schon den IIS als smarthost installiert hat, und über postfix nachdenkt kommt es auf die 10 Minuten mit dem Kabelhai auch nicht mehr an!
da fehlt mir persönlich beim entwickler die ernsthaftigkeit, oder wissen!

Frank

Moin,

es könnte auch entscheidend sein, welche Digitalisierungsbox genau zum Einsatz kommt (Standard, Premium 1/2, Basic, Smart usw.), die haben alle so ihre Eigenheiten und der (Hardware-)Unterbau kommt von unterschiedlichen Herstellern (Zyxel, bintec ...).

Macht eure Software SMTP-Auth? Ist das bei dem Kunden freigeschaltet auf O365 Seite und hat der verwendete Benutzer mindestens eine Exchange Online Lizenz zugewiesen?
Als Referenz kannst Du bspw. dies nehmen: https://learn.microsoft.com/de-de/exchange/mail-flow-best-practices/how- ...

Dann wäre auch noch wichtig, dass mindestens TLS 1.2 unterstützt und verwendet wird - vielleicht versucht er es beim ersten Mal mit 1.0/1.1 und das muss fehlschlagen.

Gruß

cykes

Zitat von @temuco:

Was bleibt noch übrig? Postfix? Da müsste ich aber einen virtuellen Linux aufsetzen. hMailServer? Ok, das könnte eine passende Alternative sein.

Moin,

Wie ich gleich zu Anfang sagte: 15 -30 Minuten in das sniffen mit Wireshark Inverstieren, egal ob Kunde das bezahlt oder nicht und dann weißt Du, an welcher Stelle das hängt. Danach kann man entweder seinen eigenen Fehler beheben oder dem Kunden darlegen, daß die Fehlersuche Geld kostet.

lks

PS: warum macht eure Software keinen Retry, wenn der erste Versuch schiefgeht?

PPS: ein kleiner smarthost mit raspi oder ähnlichem ist für unter 100€ ist deutlich billiger und zeitsparender als stundenlanges herumexperimentieren.

P3S: und wenn Du weder eine VM noch einen Raspi aufsetzen willst, kannst Du immer noch das Windows Subsystem für Linux nutzen: https://www.leibling.de/office-365-mit-postfix-unter-windows-mit-linux/

Zitat von @temuco:

Was bleibt noch übrig? Postfix? Da müsste ich aber einen virtuellen Linux aufsetzen. hMailServer? Ok, das könnte eine passende Alternative sein.

Moin,

Wie ich gleich zu Anfang sagte: 15 -30 Minuten in das sniffen mit Wireshark Inverstieren, egal ob Kunde das bezahlt oder nicht und dann weißt Du, an welcher Stelle das hängt. Danach kann man entweder seinen eigenen Fehler beheben oder dem Kunden darlegen, daß die Fehlersuche Geld kostet.

lks

PS: warum macht eure Software keinen Retry, wenn der erste Versuch schiefgeht?

PPS: ein kleiner smarthost mit raspi oder ähnlichem ist für unter 100€ ist deutlich billiger und zeitsparender als stundenlanges herumexperimentieren.

P3S: und wenn Du weder eine VM noch einen Raspi aufsetzen willst, kannst Du immer noch das Windows Subsystem für Linux nutzen: https://www.leibling.de/office-365-mit-postfix-unter-windows-mit-linux/

Dauert auch nur Minuten - da längste dürfte der reboot der Windows-Küste sein - und sollte dein Problem auch umgehen.

Zitat von @Pjordorf:
Wie schon gesagt wurde. Mit einen Kabelhai nachsehen warum das Passiert. https://www.wireshark.org/download.html

Danke Peter. Eigentlich wollte ich mich nicht wieder einmal mit einem weiteren Tool befassen, welches ich noch nie benutzt hatte. Auf der anderen Seite muss ich dir Recht geben, dass man wahrscheinlich nur so der Ursache auf die Spur kommt. Ein Arbeitskollege hat mich dann gerade eben motiviert, die Untersuchungen mit Wireshark zu machen. Wir legen heute Abend los.

LG

René

Zitat von @Vision2015:
da fehlt mir persönlich beim entwickler die ernsthaftigkeit, oder wissen!

Deine persönliche Meinung. Diese muss ich aber nicht teilen. Damit ist dieses "Unterthema" erledigt.

Zitat von @cykes:
es könnte auch entscheidend sein, welche Digitalisierungsbox genau zum Einsatz kommt (Standard, Premium 1/2, Basic, Smart usw.), die haben alle so ihre Eigenheiten und der (Hardware-)Unterbau kommt von unterschiedlichen Herstellern (Zyxel, bintec ...).

Digitalisierungsbox Smart von bintec elmeg

Damit hatte ich bisher keine Berührungen. Ich versuchte gestern, Protokolle zu untersuchen, fand ich aber nur eine Stelle mit max. den letzten 50... Also gerade genug für eine Live-Schau.

Macht eure Software SMTP-Auth? Ist das bei dem Kunden freigeschaltet auf O365 Seite und hat der verwendete Benutzer mindestens eine Exchange Online Lizenz zugewiesen?

Ja, trifft alles zu. Es läuft auch zu 90%.

Dann wäre auch noch wichtig, dass mindestens TLS 1.2 unterstützt und verwendet wird - vielleicht versucht er es beim ersten Mal mit 1.0/1.1 und das muss fehlschlagen.

Nein, das ist definitiv nicht der Fall. Dann müsste es auch immer beim ersten Mal fehlschlagen und das bei allen Kunden, die Microsoft 365 nutzen.

Danke und lG

René

Zitat von @Lochkartenstanzer:
Wie ich gleich zu Anfang sagte: 15 -30 Minuten in das sniffen mit Wireshark Inverstieren, egal ob Kunde das bezahlt oder nicht und dann weißt Du, an welcher Stelle das hängt. Danach kann man entweder seinen eigenen Fehler beheben oder dem Kunden darlegen, daß die Fehlersuche Geld kostet.

Wie in einem anderen Beitrag bereits erwähnt: Ja, das werden wir.

PS: warum macht eure Software keinen Retry, wenn der erste Versuch schiefgeht?

Ganz einfach: Das Timeout ist aus gutem Grunde beim Standard von 100 Sekunden belassen worden. Erst nach dem Timeout könnte man ein Retry machen – das warten die Anwender aber nicht ab, sondern sie killen die Anwendung und starten sie neu. Werden wir dennoch zukünftig implementieren. Aber genau deswegen hat die Lösung mit einem Smarthost ziemlich Scharm: E-Mail wird lokal im LAN an den Smarthost übergeben und dieser kümmert sich um den Rest.

Danke und Grüße

René

Hallo,

Zitat von @temuco:
Werden wir dennoch zukünftig implementieren. Aber genau deswegen hat die Lösung mit einem Smarthost ziemlich Scharm: E-Mail wird lokal im LAN an den Smarthost übergeben und dieser kümmert sich um den Rest.

Nur das dann der Smarthost keine Mails senden kann. Wo Ist das eine Lösung ohne die Ursache zu kennen? Aber wenn deine Kunden schon die Anwendung killen obwohl die noch versucht E-Mails zu versenden, legt das nahe das deine Kunden unfähig sind oder E-Mails extremst wichtig sind das dem nicht Versenden einen Weltuntergang gleichkommt.

Gruß,
Peter

Zitat von @Pjordorf:

Hallo,

Nur das dann der Smarthost keine Mails senden kann.

Wenn es nach einem retry geht, schafft der smarthost das. denn dem kann man sagen, wie oft und wie lange er es probieren soll. Insbesondere wenn es beim zwiten Versuch immer geht, kann man mit einem smarthost den gfehler umgehen. (lösen ist allerdings etwas anderes).

Wo Ist das eine Lösung ohne die Ursache zu kennen?

Ja, das ist ja nur ein workaround. Aber das ist heutztage die Arbeitsweise bei den meisten Firmen.

Hängt aber auch damit zusammen, daß 10 Manntage Fehlersuche und -behebung mehr kosten als ein RasPi und 1/2h Arbeitszeit.

lks

Firmen müssen Geld verdienen und daher immer wieder abwägen, wie man mit solchen Sachen vorgeht. Und nein, es sind kein 10 Manntage.

Darüber hinaus hat mich die Diskussion auf die Idee des Smarthosts gebracht: Unabhängig von der Fehlerursache, nach der wir heute Abend fahnden werden, ist der Smarthost eine gute Sache. Der Anwender wird in Windeseile seine Mail los und alles andere regelt der Smarthost. Kann er die E-Mail doch nicht versenden (z. B. falsche E-Mail-Adresse o. ä.) kann er den Anwender darüber benachrichtigen. Er kann auf jeden Fall für einen geschmeidigeren Arbeitsfluss und weniger Fehler sorgen.

Nun schauen wir einmal, ob wir die Ursache finden.

Zitat von @temuco:

Firmen müssen Geld verdienen und daher immer wieder abwägen, wie man mit solchen Sachen vorgeht.

Klar. Aber trotzdem sollte man Qualitätssicherung betreiben.

Und nein, es sind kein 10 Manntage.

Das war ironisch gemeint. Soltle nur übertrieben darstellen, daß der Aufwand zwischen Workaround und chter fehlerbehebung nicht unerheblich ist. (weißt schon "unsichbare Ironitags").

lks

Bei Timingfehler ist natürlich ein Paketsniffer wie Wireshark optimal.

Aber um auch noch eine Idee aus der Glaskugel einzubringen: Ev. ein DNS Problem? Der Mailserver hat IPv4 und IPv6 Adressen hinterlegt, aber nur IPv4 funktioniert? Oder mehrere MX Records, aber nicht alle gehen? So was in der Art?

Zitat von @HansFenner:

Bei Timingfehler ist natürlich ein Paketsniffer wie Wireshark optimal.

Natürlich. Man sieht dann, welcher Protokollteilnehmer schleudert.

lks

Gibt es evtl Gemeinsamkeiten bei den Mail Adressen, bei denen der Timeout kommt?
Bzw gibt es Adressen bei denen nie ein Timeout kommt?
Das könnte auch auf ein DNS Problem hinweisen und das macht vermutlich die Digitalisierungsbox (Smart von bintec elmeg).

Habt ihr gestern was rausgefunden mit Wireshark?

Zitat von @franc:

Gibt es evtl Gemeinsamkeiten bei den Mail Adressen, bei denen der Timeout kommt?

Überhaupt keine. Wenn es nicht geht und man es gleich wieder versucht, dann läuft es wieder problemlos. Es ist zufällig und nicht reproduzierbar.

Bzw gibt es Adressen bei denen nie ein Timeout kommt?

s. o.

Das könnte auch auf ein DNS Problem hinweisen und das macht vermutlich die Digitalisierungsbox (Smart von bintec elmeg).

Mit ihr kenne ich mich nicht aus. Ich kenne ihre Eigenheiten nicht.

Habt ihr gestern was rausgefunden mit Wireshark?

Noch nicht. Wir haben gestern Abend alles eingerichtet und gestartet und dem Kunden mitgeteilt, sobald der Fehler wieder auftritt, uns zu benachrichtigen. Wir nehmen alles im Ring auf – maximal 80 Dateien à 250 MB. In Moment sind wir schon bei 74 Logdateien und 17,2 GB.

Sehr merkwürdig: Seitdem wir darum gebeten haben, uns sofort alle Fehler mitzuteilen, hören wir vom Kunden nichts mehr...

Zitat von @temuco:.

Sehr merkwürdig: Seitdem wir darum gebeten haben, uns sofort alle Fehler mitzuteilen, hören wir vom Kunden nichts mehr...

Vielleicht ist es ja auch nur ein 'PEBKAC' gewesen der es jetzt richtig macht.

lks

PEBKAC

Sorry, muss passen! Ich komme nicht drauf...

OK, Google ist dein Freund:

PEBKAC (Englisch)
Bedeutungen: [1] Netzjargon: Abkürzung für "Problem Exists Between Keyboard And Chair". Auf Deutsch: Das Problem befindet sich zwischen Tastatur und Stuhl. Wird gelegentlich verwendet um auszudrücken, dass der Benutzer, und nicht der Computer, die Ursache des Problems ist.

Falls es interessiert:

Ich habe den Fehler noch nicht gefunden, denn er taucht plötzlich beim Kunden nicht mehr auf. Allerdings habe ich eine Vermutung:

Der SMTP-Server ist so konfiguriert, dass er Kontakt mit outlook.office365.com aufnimmt. Wenn ich jetzt diese Adresse mehrmals anpinge, sehe ich, dass die IP-Adresse immer wieder wechselt:

PS C:\Users\rkk> ping outlook.office365.com -n 1

Ping wird ausgeführt für FRA-efz.ms-acdc.office.com [40.99.155.226] mit 32 Bytes Daten:
Antwort von 40.99.155.226: Bytes=32 Zeit=33ms TTL=242

Ping-Statistik für 40.99.155.226:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 33ms, Maximum = 33ms, Mittelwert = 33ms

PS C:\Users\rkk> ping outlook.office365.com -n 1

Ping wird ausgeführt für HHN-efz.ms-acdc.office.com [52.98.241.194] mit 32 Bytes Daten:
Antwort von 52.98.241.194: Bytes=32 Zeit=21ms TTL=242

Ping-Statistik für 52.98.241.194:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 21ms, Maximum = 21ms, Mittelwert = 21ms

PS C:\Users\rkk> ping outlook.office365.com -n 1

Ping wird ausgeführt für HHN-efz.ms-acdc.office.com [40.99.150.98] mit 32 Bytes Daten:
Antwort von 40.99.150.98: Bytes=32 Zeit=33ms TTL=241

Ping-Statistik für 40.99.150.98:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 33ms, Maximum = 33ms, Mittelwert = 33ms

Was ist, wenn durch eine zwischengespeicherte IP-Adresse die falsche genutzt wird?

Bemerkenswert ist der kurze TTL von den A-Records:

PS C:\WINDOWS\system32> Resolve-DnsName outlook.office365.com | ft name,querytype,ttl

Name                       QueryType TTL
----                       --------- ---
outlook.office365.com          CNAME  37
ooc-g2.tm-4.office.com         CNAME  37
outlook.ms-acdc.office.com     CNAME  37
HHN-efz.ms-acdc.office.com      AAAA   2
HHN-efz.ms-acdc.office.com      AAAA   2
HHN-efz.ms-acdc.office.com      AAAA   2
HHN-efz.ms-acdc.office.com      AAAA   2
HHN-efz.ms-acdc.office.com         A   2
HHN-efz.ms-acdc.office.com         A   2
HHN-efz.ms-acdc.office.com         A   2
HHN-efz.ms-acdc.office.com         A   2

Das bestätigt meine Beobachtung – gerade einmal 2 Sekunden.

Hallo,

Zitat von @temuco:
Ich habe den Fehler noch nicht gefunden, denn er taucht plötzlich beim Kunden nicht mehr auf. Allerdings habe ich eine Vermutung:

Falsche Vermutung.

Adresse mehrmals anpinge, sehe ich, dass die IP-Adresse immer wieder wechselt:

Ja, wie soll es auch mit nur einer IP denn füt Millionen Teilnehmern sonst funktionieren?

Was ist, wenn durch eine zwischengespeicherte IP-Adresse die falsche genutzt wird?

Dann wird die falsche halt verwendet...

Hättet ihr damals beim Programmieren nicht nur Bauklötzchen zusammengesteckt sondern auch ein Logging eingebaut wüsstet ihr schon lange was dort als Antwort zurückkommt und du müsstest heute nicht über Geldausgaben dir deinen Kopf zerbrechen.

Und dein Wireshark nur auf SMTP und DNS ansetzen. Nicht das ganze Internet mitschneiden, nicht das wir kein Internet mehr haben

Gruß,
Peter

Peter, hast du ein Problem? Du schreibst:

Hättet ihr damals beim Programmieren nicht nur Bauklötzchen zusammengesteckt sondern auch ein Logging eingebaut wüsstet ihr schon lange was dort als Antwort zurückkommt und du müsstest heute nicht über Geldausgaben dir deinen Kopf zerbrechen.

Du hast entweder keine Ahnung oder die beste Glaskugel. Entweder hilfst du oder sparst du dir die Belehrungen. Der Ton macht die Musik und ich bin bisher sicher weder laut, noch singe ich schief.

Ich danke dir, dass du das verstehst und zurück zu einem für ein Hilfe- und Austauschsforum angenehmen Miteinander kehrst.

Liebe Grüße

René

Moin...

Zitat von @temuco:

Peter, hast du ein Problem? Du schreibst:

neeee, hat er nicht!

hm... da ist aber auch etwas dran....

Du hast entweder keine Ahnung oder die beste Glaskugel. Entweder hilfst du oder sparst du dir die Belehrungen. Der Ton macht die Musik und ich bin bisher sicher weder laut, noch singe ich schief.

oha... dann schreibe uns doch mal bitte was dein Programm im SMTP log ausgiebt!
du hast doch ein SMTP log oder?

Ich danke dir, dass du das verstehst und zurück zu einem für ein Hilfe- und Austauschsforum angenehmen Miteinander kehrst.

oha...

Wir nehmen alles im Ring auf – maximal 80 Dateien à 250 MB. In Moment sind wir schon bei 74 Logdateien und 17,2 GB.

Alter, was Feiert ihr da?
du sollst nur SMTP mitschneiden nix mehr... DNS wäre auch noch sinvoll, mehr aber nicht!

Liebe Grüße

von mir auch...

René

Frank

Hallo,

Zitat von @Vision2015:
Alter, was Feiert ihr da?

Ne ausgelassene Kabelhai Excess (Division durch 0) Party.

Weil für vernünftige Fehlersuche kein Budget existiert, und vor 13 Jahren keiner daran dachte das mal in Zukunft was an Protokollen geändert werden könnte. Wer Logs einbaut ist halt Feige und verbrennt nur Kohle

Gruß,
Peter

Zitat von @Pjordorf:

Wer Logs einbaut ist halt Feige und verbrennt nur Kohle

Oder einfach nur einen debug-switch, der bei Bedarf statusinformationen ausgibt.

lks

Zitat von @temuco:

Falls es interessiert:

Ich habe den Fehler noch nicht gefunden, denn er taucht plötzlich beim Kunden nicht mehr auf.

Rene, ist der Fehler jetzt bisher nie mehr gemeldet worden?
Würde mich schon interessieren wie das ausgegangen ist...

In der Tat nicht mehr. Wir protokollieren aber weiter und sobald wir mehr wissen, gebe ich hier Bescheid. Dabei hoffe ich sehr, dass die Kristallkugelbesitzer ihre Visionen für sich behalten – spart Zeit und Nerven. 😎

Moin...

wurde den zufällig beim Kunden etwas geändert?
evtl. updates Installiert, switch oder router etc...
war das Problem eigentlich nur auf einem PC, oder Server, oder auf jedem PC?

Frank

Laut Kunden auf jedem PC. Es wurde absolut nichts geändert bis auf die Windows-Updates. Aber der Fehler hat laut Kunden mehrere Windows-Updates überlebt – er soll seit Monaten auftreten.

Auf dem Server wird nicht gearbeitet und daher kann er auch da nicht auftreten.

Ich habe dem Kunden schon letzte Woche mitgeteilt, er und seine Mitarbeiter sollen jeden Fehler manuell protokollieren und uns sofort kontaktieren. Seitdem ist es Ruhe...

Zitat von @temuco:

Ich habe dem Kunden schon letzte Woche mitgeteilt, er und seine Mitarbeiter sollen jeden Fehler manuell protokollieren und uns sofort kontaktieren. Seitdem ist es Ruhe...

Wie meine Kristallkugel schon sagte, vermutlich ein PEBKAC, der jetzt durch die erhöhte Aufmerksamkeit den Fehler, den er sonst immer macht, vermeidet.

lks

Hallo,

Zitat von @temuco:
Auf dem Server wird nicht gearbeitet und daher kann er auch da nicht auftreten.

?!?

Seitdem ist es Ruhe...

Könnte auch ruhig sein weil der Kunde nicht mehr dein Kunde ist und nichts mehr (nach all den schönen Jahren) mit euch zu tun haben will

Gruß,
Peter

Er hat einen gewissen Hang zur Übertreibung, aber der Fehler taucht in der Tat auf. Der E-Mail-Versand wird in der Datenbank protokolliert. Dazu erstellt der Versand einen Eintrag in der Datenbank, der vom E-Mai-Modul vervollständigt und beim wiederholten Versand ergänzt wird. Nun ergab unsere Auswertung, dass ca. 9% der Einträge nicht vervollständigt wurden. Das kann nur dann vorkommen, wenn das E-Mail-Modul in ein Timeout läuft (100 Sekunden) und der Anwender es nicht abwartet, sondern das Modul über den Taskmanager killt. Das hat auch der Kunde so bestätigt.

Also wir haben bei ihm ein Problem. Nun müssen wir uns in Geduld üben und warten, bis Fehler wieder auftreten.

Seitdem wir mit Wireshark protokollieren, taucht der Fehler nicht mehr auf. Der Kunde hat sich sogar bedankt, dass der Fehler nicht mehr auftritt und dass alles richtig flott läuft. Wir konnten auch keinen technischen Fehler festmachen. Selbstheilung durch Erkenntnis der Überwachung?

Danke an alle! Für mich ist das Thema damit erledigt.

gelöst Frage Internet Netzwerke E-Mail Telekommunikation

Mehr von temuco

Autodiscover in Outlook schlägt fehl - Microsoft 365 korrekt eingestellttemuco - 13 Kommentare

Langsamer VPN-Zugriff nur bei einem virtuellen Servertemuco - 8 Kommentare

Lets Encrypt und DNS-Verwaltung in Plesk auf Strato VPS - Brauche Hilfe!temuco - 8 Kommentare

Windows 11 - hohe Systembelastungtemuco - 12 Kommentare

Heiß diskutiert