IMAP Timeouts beim Versand mit Anhängen [erl.]

    Nächster Zwischenstand:
    Avira Free deinstalliert - IMAP-Timeout beim weiterleiten
    gmail Konto angelegt - SMTP-timeout Problem beim Senden

    Jetzt bleibt nicht mehr viel nach was sein kann, ich werde jetzt mal schauen ob ich einen Linux-Rechner habe, danach kann es eigentlich nur noch mein ISP-Provider sein.

    Nächster Zwischenstand (es geht mir inzwischen ziemlich auf den ....)

    Es funktioniert an der gleichen Netzwerkdose ohne Probleme ein MacbookPro.
    Ebenfalls kein Problem beim Senden haben zwei WindowsXp Rechner mit einer alten 24.x.6? Version, hier hakt es allerdings beim Kopieren in den Sent-Ordner.

    Dann habe ich mir den aktuellen Ubuntu Stand auf DVD gebrannt. Dort ist TB 31.0 drauf, auf zwei verschiedenen Rechnern keine Chance in endlicher Zeit auf eine Mail mit größeren Anhängen zu zugreifen. Den Timeout habe ich nicht mehr abgewartet, es waren mehr als 5 Minuten.

    Rückantwort von meinem ISP, sie haben die Benutzung des Dualstack freigeschaltet IP4/6. Hat aber keine Änderung gebracht.
    Ich habe einen Wireshark-Trace gemacht und als Antwort geschickt. Natürlich mit dem Macbook, mit den anderen Rechner gehts ja nicht.

    Eine Eigenanalyse vom Trace ist von mir nur beschränkt möglich, es gab jede Menge Fehler bezüglich Malformed TCP-Pakete.

    Einen Versuch mit einer anderen Linux-Distribution werde ich noch versuchen, dann bin ich mit meinem Latein am Ende.

    Vom Strato wurde mir empfohlen die Timeoutzeit hoch zu setzen, bei dem Versuch habe ich festgestellt, das zwei Einträge vom Benutzer auf den Wert 29 gesetzt wurden (mail.server.server1.timeout und server6).

    Verändere ich diese, stehen diese nach einem Neustart wieder auf dem alten Wert (29). Dieser Zeitraum wird aber ebensowenig wie der Wert für mailnews.tcptimeout erreicht. Die Fehlermeldung kommt bereits spätestens 20s nach dem Drücken des Senden-Buttons.

    Am 10.9 kommt ein Techniker die Leitung zu testen, ich habe Spannung.

    Hallo kuschelhuhn,

    ein ganz schön hartnäckiges Problem hast Du Dir da ausgesucht. :mrgreen:
    Die bisherigen Ergebnisse lassen auch für mich keinen eindeutigen Schluss zu - alles recht verwirrend.

    Ich würde Dir folgende zwei Tests vorschlagen:

    1. Nimm einen der Rechner, auf dem das Problem auftritt, und ziehe damit mal zu einem Nachbarn/Freund/Bekannten um.
    2. Sollte auch dort der Fehler auftreten, dann gehe testweise auf eine TB-Version zurück, mit der es früher noch funktionierte. Du hast ja einleitend geschrieben, dass das Problem scheinbar erst seit der Version 24 auftritt.

    Um Nebeneffekte auszuschließen, würde ich alle Tests mit einem frischen Profil, ohne Erweiterungen und bei deinstalliertem AV-Schutz durchführen.
    Beachte, dass das Kopieren in den IMAP-Sent-Folder bekanntermaßen hin und wieder Probleme macht. Bleibe also dabei und kopiere die gesendeten Nachrichten nur in einen lokalen Ordner.

    Zitat von "kuschelhuhn"

    Ich habe einen Wireshark-Trace gemacht und als Antwort geschickt. Natürlich mit dem Macbook, mit den anderen Rechner gehts ja nicht.

    Das verstehe ich nicht. Wenn der Fehler auf dem MacBook nicht auftritt, was erwartest Du Dir dann von den Traces? Die malformed TCP-Pakete mögen eine Rolle spielen oder gar die Ursache sein. Gut möglich, dass der Mac da etwas toleranter ist. Nur, zweifelsfrei feststellen lässt sich das damit nicht.
    Meiner Meinung nach wären deshalb Traces beim Auftreten des Fehlers besser geeignet.

    Verhält sich Dein Netzwerk ansonsten ganz normal? Siehst Du diese malformed Packets auch bei anderen Aktionen, z.B. beim Kopieren größerer Dateien innerhalb des lokalen Netzwerks oder beim Upload größerer Dateien in die Cloud?
    Hast Du für den Test mit Ubuntu einen Rechner benutzt, der das Problem zuvor schon unter Windows zeigte?

    Zitat von "kuschelhuhn"

    ... habe ich festgestellt, das zwei Einträge vom Benutzer auf den Wert 29 gesetzt wurden (mail.server.server1.timeout und server6).

    Diese Werte stehen bei mir ebenfalls auf 29, benutzerdefiniert. Das ist merkwürdig, weil sie gewiss nicht von mir so gewählt wurden. Könnte das bitte jemand der anderen Helfer ebenfalls einmal kontrollieren?

    Gruß

    Susanne

    Nachtrag: Ich weiß, Du hast auch schon mit einem frischen Profil getestet. Schau bitte dennoch auch noch mal bei den Proxy-Einstellungen nach und wähle dort "Kein Proxy".

    Hallo Susanne,

    Zitat von "SusiTux"

    Diese Werte stehen bei mir ebenfalls auf 29, benutzerdefiniert. Das ist merkwürdig, weil sie gewiss nicht von mir so gewählt wurden. Könnte das bitte jemand der anderen Helfer ebenfalls einmal kontrollieren?


    Die Werte für mail.server.serverX.timeout sind bei mir ebenfalls geänderte 29.
    Ich denke jedenfalls nicht, dass dieser Wert die Ursache für das Problem von kuschelhuhn ist. Bevor jemand fragt: Ich weiß nicht, wo die Ursache liegen könnte...

    Viele Grüße,
    tempuser

    Entwickler des Add-ons Mail Merge für Thunderbird

    Hallo tempuser,

    vielen Dank für das Überprüfen.

    Zitat von "tempuser"

    Ich denke jedenfalls nicht, dass dieser Wert die Ursache für das Problem von kuschelhuhn ist.

    Ja, da bin ich ganz Deiner Meinung. Mich "stört" lediglich, dass ich nicht weiß, warum dieser Wert auf benutzerdefiniert steht. Da er bei Dir ebenfalls auf 29 steht, liegt der Verdacht nahe, dass dieser Wert nicht benutzerdefiniert sondern vom TB vorgegeben ist.
    Die Einstellung könnte auch von eine Erweiterung stammen. Doch da ich lediglich Enigmail und AllowHTMLTemp verwende, halte ich das nicht für sehr wahrscheinlich.

    Gruß

    Susanne

    Unsere Nachbarn sind auch alle bei willytel. Ich werde am WE mal ein paar Kilometer umziehen und woanders probieren. Wenn da klappt werde ich mal das Routing vergleichen.

    Die verschickten Mails werden immer lokal kopiert.

    Den Trace habe ich natürlich im Fehlerzeitraum beschränkt auf dem betroffenen Rechner gezogen, ich hab ihn nur mit dem Macbook verschickt. Eine Analyse bedarf da leider viel Detailwissen. Ein Trace mit dem Macbook würde eine Vergleichsmöglichkeit bieten.

    Eine Verlängerung des "benutzerdefinierten" Wertes ist zur Laufzeit möglich, ändert aber nicht wirklich etwas ausser der Wartezeit bis zum Abbruch.

    Ein weiteres Problem hat seit ein paar Wochen das Windows Update, eine Aktualisierung ist nicht mehr möglich und bricht jedesfall mit einer Fehlermeldung ab, welche auf ein Netzproblem hinweist. Das kann aber auch etwas anderes sein, kann ich auf einem anderen Windows 7 Rechner noch mal testen.

    Ein Test der Up/Downloadraten sieht gut aus.

    Aus meiner Sicht verhält sich irgendeine Komponente auf dem Weg von meinem Rechner zum Mailserver nicht korrekt. Ich habe inzwischen ein paar Foreneinträge im Netz gefunden mit einem ähnlichen Problem, leider ohne konkrete Auflösung.

    So, jetzt ist die Sache klar, ich bin Opfer einer Verschwörung geworden.
    Da die Abhörungsversuche kurz vor der Aufdeckung standen, haben sich die Agenten zurückgezogen und alle Spuren verwischt.

    Gestern abend lief das Windows Update automatisch durch und fröhliches Versenden von größeren Mails war problemlos möglich. Wo war jetzt das Problem, ääähh die Lösung, es hat natürlich wieder keiner etwas gemacht. :wall:, wie in og. anderen Foreneinträgen.

    Ich werde das Beobachten, erstmal vielen Dank an alle Miträtseler.

    Zitat von "kuschelhuhn"

    Da die Abhörungsversuche kurz vor der Aufdeckung standen, haben sich die Agenten zurückgezogen und alle Spuren verwischt.

    Ja, machmal hilft es schon, in öffentlichen Foren zu berichten, dass man sich die Sache genauer anschaut. Hättest Du gleich in Englisch geschrieben, wäre das Problem wahrscheinlich schon früher verschwunden ;-)

    Spaß beiseite, vielleicht hat Dein Provider ja doch noch mal genauer nachgeforscht und einen Fehler behoben.

  • Community-Bot 3. September 2024 um 20:20

    Hat das Thema geschlossen.