Neue Mails nicht ladbar

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Thunderbird-Version: 38.5.1 oder 38.6.0
    * Betriebssystem + Version: Win 8.1 64-Bit
    * Kontenart (POP / IMAP): IMAP
    * Postfach-Anbieter (z.B. GMX): Lokaler Mailserver (Cyrus)
    * Eingesetzte Antiviren-Software: Avira
    * Firewall (Betriebssystem-intern/Externe Software): BS-System in privatem Netz
    * Router-Modellbezeichnung (bei Sende-Problemen): -

    Liebes Forum,

    sporadisch haben wir Probleme beim Laden neuer Mails mit Thuderbird 35.1 oder 36.0 auf einem Windows 8.1 Client (32 GB RAM).

    Der Server identifiziert sich mit "* OK mail Cyrus IMAP4 v2.2.13-Debian-2.2.13-19+squeeze3 server ready"
    In Protokollmitschnitten (per Wiresharf) finden wir häufiger folgenden Ablauf:
    7 UID fetch 1:* (FLAGS)
    Der Stream endet dann wie folgt:

    Code
    83952 1876.335372 172.25.3.230 172.25.10.16 IMAP 1264 Response: (FLAGS (\Seen NonJunk) UID 2165418)
83953 1876.374273 172.25.10.16 172.25.3.230 TCP 54 63692 → 143 [FIN, ACK] Seq=165 Ack=73611 Win=64256 Len=0
83954 1876.374292 172.25.10.16 172.25.3.230 TCP 54 [TCP ACKed unseen segment] 63692 → 143 [ACK] Seq=166 Ack=73612 Win=64256 Len=0
83955 1876.374863 172.25.3.230 172.25.10.16 TCP 60 143 → 63692 [FIN, ACK] Seq=73611 Ack=166 Win=5888 Len=0
83956 1876.586168 172.25.3.230 172.25.10.16 TCP 60 [TCP SpuriousRetransmission] 143 → 63692 [FIN, ACK] Seq=73611 Ack=166 Win=5888 Len=0
83957 1876.586219 172.25.10.16 172.25.3.230 TCP 54 [TCP ZeroWindow] 63692 → 143 [ACK] Seq=166 Ack=73612 Win=0 Len=0


    Alle in der Response auf FETCH enthaltenen Mails werden in der Übersichtsliste des Postfachs angezeigt,
    nur sind bisweilen insbesondere die neueren nicht anzeigbar.
    An der Taskbar erscheint ein Hinweisfenster mit dem Inhalt, dass der Server die Verbindung beendet hätte.

    Eine Reparatur des lokalen Liste (.msf Datei) bringt keine Besserung.
    Auch wurde das Phänomen bereits in früheren Thunderbird Versionen beobachtet.

    In Unterpostfächern des Mailaccounts sind bisweilen einige (bis zu 100.000) Nachrichten enthalten, die
    Postfachstruktur ist im Laufe der Zeit recht umfangreich geworden.

    Der Nachrichtenaustausch (auch das Lesen neuer Nachrichten) funktioniert mit anderen Mailclients
    (iPhone, MAC, ...) auch zur selben Zeit einwandfrei.

    Ist dieses Phänomen und vielleicht auch ein Lösungsansatz bekannt?

    Besten Dank im Voraus
    -- Chris

    Edited once, last by graba: Code-Tags gesetzt (February 19, 2016 at 1:18 PM).

    Hallo,

    wie so oft gleich wieder die üblichen Fragen:

    2 bzw. 4 GByte-Dateigröße der einzelnen [lexicon='Mbox-Dateien',''][/lexicon] überschritten? Werden die Ordner in Thunderbird mit dessen "[lexicon='Ordner komprimieren',''][/lexicon]"-Funktion regelmäßig wieder verkleinert?

    Darf Avira aktuell noch den [lexicon='Profilordner',''][/lexicon] scannen? Das sollte man vermeiden, um Datenverlust vorzubeugen. Darf Avira zur Zeit den Datenstrom beim Senden und Empfangen noch scannen? Das sollte zumindest bei SSL/TLS gesicherten Verbindungen ausgeschaltet werden (empfiehlt sogar Avira selbst).

    2 GB werden bei keiner der in den Profilordnern vorhandenen Dateien erreicht.
    Die Funktion "Ordner komprimieren" wird unregelmäßig, etwa 14-tägig ausgeführt.

    Das Scannen der Profilordner war aktiv, ist jetzt per Ausnahmeliste abgestellt.
    Die Datenübertragung erfolgt derzeit im Klartext.

    Gruß
    -- Chris

    Es gibt ein paar Auffälligkeiten im Wireshark Trace:

    [tmdebutton]TCP SpuriousRetransmission[/tmdebutton]

    zeigt an, dass ein Paket nochmals empfangen wurde, obwohl dessen Empfang bereits per ACK bestätigt wurde. Der Sender hatte also das ACK noch nicht bekommen.

    Schlimmer ist dies:

    [tmdebutton]TCP ZeroWindow[/tmdebutton]

    Es besagt, das der TCP-Puffer aufgebraucht ist. Das sieht man auch sehr schön daran, dass der Wert Win von 64256 stetig abnimmt, bis eben zu Win=0.
    In dieser Situation signalisiert die eine Partei der anderen, dass der Puffer aufgebraucht ist und deshalb keine weiteren Pakete mehr empfangen werden können. Folglich werden auch keine mehr gesendet, bis der Empfänger wieder bereit ist und Puffer zur Verfügung steht.

    Beides deutet also auf ein in diesem Moment langsames Netzwerk hin. Es gab es eine Komponente im Netzwerk, welche die Pakete in diesem Moment nicht so schnell verarbeiten konnte, wie sie angekommen sind.
    Das kann ein Fehler im Netzwerk sein oder auch ein sog. Slow Drain Device. Auch ein Virenscanner, der den Datenstrom untersucht, könnte dazu führen, dass der Puffer aufgrund der Verzögerung volläuft und er Rechner somit zum Slow Drainer wird.

    -> Zeig die Logs mal dem Netzwerkadmin.

    Nachtrag: 172.25.10.16 ist der Rechner, richtig? Hier ist der Puffer leer. Das spricht dafür, dass er das Bottleneck, der Slow Drainer ist.

    Edited once, last by SusiTux (February 19, 2016 at 3:08 PM).

    Nach Eintragung der Ausnahmeregel für den Profilordner in der Avira Konfig ist das beschriebene Problem nicht mehr aufgetreten. Auch auf Netzwerkebene habe ich den oben beschriebenen Abbruch der Streams nicht mehr beobachten können.

    Stattdessen (selten):

    Code
    ...
29817	564.840662	172.25.10.16	172.25.3.230	TCP	54	49952 → 143 [ACK] Seq=205 Ack=11941 Win=65536 Len=0
29818	564.855894	172.25.10.16	172.25.3.230	TCP	54	[TCP ACKed unseen segment] 49952 → 143 [FIN, ACK] Seq=205 Ack=11942 Win=65536 Len=0
29819	564.858482	172.25.10.16	172.25.3.230	TCP	54	[TCP ACKed unseen segment] 49952 → 143 [RST, ACK] Seq=206 Ack=11942 Win=0 Len=0

    Augenscheinlich klinkt sich Avira auch als LSP in die Kommunikation zwischen Client (IP: 172.20.10.16) und Server (IP: 172.25.3.230) ein. Eine Wechselwirkung zwischen dem Online-Scan des Profilordners und dem Datenaustausch erschließt sich mir zunächst nicht. Das Scannen des (plain) IMAP Datenaustauschs ist nach wie vor aktiv.

    TB scheint zunächst sachgerecht zu funktionieren, der Datenaustausch mit dem Server findet unterbrechungsfrei und zügig statt.

    Ich werde die Situation weiter beobachten und mich hierzu gegen Ende der Woche nochmals melden.

    Bis dahin bereits jetzt vielen Dank für die Antworten.
    -- Chris

    Fangen wir mal mit dem Trace an ...

    Vorab: Ich weiß, wie TCP-Verbindungen auf- und abgebait werden, aber das Lesen solcher Traces ist nicht mein täglich Brot. Außerdem ist der Trace ein wenig kurz und enthält Acknowledments zu Paketen, die der Wireshark nicht "gecaptured" hat (unseen).

    Zwei Dinge fallen mir auf:

    - Der Client sendet dem Server ein FIN/ACK, ohne dass vorher ein FIN vom Server zu sehen ist. Das kann normal sein, weil entweder das vorherige FIN vom Server in dem kurzen Ausschnitt nicht zu sehen ist, oder weil es in einem der Pakete enthalten war, die der Wireshark nicht gesehen hat.
    (Das Beenden einer TCP-Verbindung ist nicht trivial, weil ja noch Pakete unterwegs sein können, und erfordert normalerweise ein FIN/ACK/FIN/ACK.)

    - Der Client sendet dem Server einen Reset ([RST]). So ein RST wird normalerweise nur dann gesendet, wenn etwas unerwartetes passiert ist. Ich habe aber schon gelesen, dass MS-Clients so einen Reset auch dann senden, wenn sie eine SSL-Verbindung beenden wollen. Die haben wohl keine Lust, den kompletten Handshake abzuwarten. Das ist meines Wissens nicht regelkonform, aber das wäre im Falle MS nichts neues.

    Das kann also ebenfalls normales MS-Verhalten sein. Wenn Du sicher gehen willst, beherzige meinen Hinweis von oben. Der Netzwerkadmin sollte diese Traces lesen können.

    Quote from Bubu_S24

    Augenscheinlich klinkt sich Avira auch als LSP in die Kommunikation zwischen Client (IP: 172.20.10.16) und Server (IP: 172.25.3.230) ein.

    Ja, das machen diese Produkte und erzeugen damit oft genug Probleme. Wie bereits oben erwähnt:

    Quote from SusiTux

    Auch ein Virenscanner, der den Datenstrom untersucht, könnte dazu führen, dass der Puffer aufgrund der Verzögerung volläuft ...


    Kommen wir zum nächsten Punkt ...

    Quote from Bubu_S24

    Eine Wechselwirkung zwischen dem Online-Scan des Profilordners und dem Datenaustausch erschließt sich mir zunächst nicht.

    Ein Erklärungsversuch: Wenn der AV-Scanner eine Datei untersucht, dann kann in dieser Zeit nicht in diese Datei geschrieben werden. Wenn in dieser Zeit aber weitere Pakete für diese Datei eintreffen, müssen sie irgendwo gepuffert werden. Das kann in einer temporären Datei erfolgen, im RAM oder eben im Netzwerkpuffer. Letzterer war laut den Traces oben in Deinem Fall augenscheinlich vollgelaufen.

    Ein solcher Scan kann Dir u.U. auch den Profilordner gründlich zerlegen, bis hin zum Verlust der lokal gespeicherten E-Mails. Deshalb lautet der dringende Rat, den Profilordner nicht scannen zu lassen.
    Schau Dich dazu am besten ein wenig im Forum um. Dort findest Du ausreichend "tragische" Beispiele.