Gleich wie schon im Oktober gemeldet:
TB hängt beim Senden:
Inzwischen verwende ich TB 91.3.1
Nach erneutem Versuch kommt ein Pop-up:
Keine Netzwerkprobleme, IMAP-Server ist verfügbar, Webmail funktioniert.
Ordner-Struktur unverändert, Sprache nicht gewechselt.
Das Problem scheint wohl doch tiefer zu liegen...
Beste Grüsse
Überprüfe die Einstellungen des Bitdefender. Schalte dort mal alles ab, das mit E-Mail zu tun hat.
Danke für die Rückmeldung - ganz nach "Compuzius, Buch 5" 
Ich verwende Bitdefender Antivirus Free Edition - da gibt's nichts einzustellen...
Das Problem tritt aber offenbar nur sporadisch auf, zur Zeit läuft wieder alles bestens.
Ja, ich weiss: die wohl blödeste Ausgangslage für eine Problemanalyse 
Kann ich im TB irgendein Logging aktivieren, das weiterhelfen könnte, wenn's wieder hängt?
Grundsätzlich ist das ein sehr altes Thema, sehr schwierig zu debuggen, u.a. weil es so sporadisch auftritt. In einigen Fällen spielt AV eine Rolle, in anderen der Server, die Netzwerkverbindung, etc. . In deinem Fall ist es augenscheinlich nicht die AV. Das spricht wieder mal für den Compuzius.
Ein paar mehr Infos findest du u.a. in diesem Thema: Thunderbird speichert gesendete E-Mails nicht im Gesendet-Ordner
Kann ich im TB irgendein Logging aktivieren, das weiterhelfen könnte, wenn's wieder hängt?
Die Kopie der gesendeten Mail wird in der Regel per IMAP gespeichert. Du müsstest also das IMAP-Log aktivieren:
Protokoll (Log-Datei) der Server-Verbindung mit IMAP, POP und SMTP erstellen - Thunderbird Mail DE
Ein paar mehr Infos findest du u.a. in diesem Thema: Thunderbird speichert gesendete E-Mails nicht im Gesendet-Ordner
Danke, Susi, in dieser Diskussion war ich ja auch dabei 
Die Kopie der gesendeten Mail wird in der Regel per IMAP gespeichert. Du müsstest also das IMAP-Log aktivieren:
Protokoll (Log-Datei) der Server-Verbindung mit IMAP, POP und SMTP erstellen - Thunderbird Mail DE
Danke, Thunder, werde ich mal aktivieren und laufen lassen.
Sobald das wieder auftritt, melde ich mich dann mit IMAP-Log zurück!
Beste Grüsse
Zwischenbericht
Hab den Start mit Log in ein cmd-File verpackt:
@Echo off
rem run Thunderbird in logging mode
rem Protokoll (Log-Datei) der Server-Verbindung mit IMAP, POP und SMTP erstellen
SetLocal
rem Set MOZ_LOG=POP3:4
Set MOZ_LOG=IMAP:4
rem Set MOZ_LOG=SMTP:4
Set MOZ_LOG_FILE=%~dp0Cleanup\Logs\TB-IMAP-%Date%.log
Start "" /D "C:\Program Files\Mozilla Thunderbird" "C:\Program Files\Mozilla Thunderbird\thunderbird.exe"
Endlocal
Exit /b 0
Das kreiert jeweils 5 Logfiles mit eigenen Endungen, wovon 4 leer sind.
Das letzte enthält den IMAP traffic - sehr wortreich - aber kann man ja regelmässig putzen
Bislang keine ungewöhnlichen Einträge
Schöne Grüsse + bis bald
Die leeren Files sind merkwürdig. Das kenne ich so nicht. Vielleicht hängt das mit der UAC zusammen(?). Was du vielleicht noch ergänzen solltest, ist der Timestamp innerhalb der Logs. set MOZ_LOG=IMAP:5,timestamp. Das sollte später die Suche erleichtern.
Die leeren Files sind merkwürdig.
Könnte dies eine Folge der separaten Zeilen im Script sein?
Ich wüsste nicht, weshalb das einen Unterschied ausmachen sollte. Gesetzt werden die Variablen ja offensichtlich.
Ich habe das Logging, soweit ich mich erinnere, bisher stets unter Linux benutzt. Für Windows steht hier:
On versions with User Account Control such as Vista and Windows 7, the batch file must be run with administrator privileges. Right click on the batch file and select "Run as administrator". Otherwise the log file will not be created and no UAC warnings will be generated.
Das passt auch nicht so richtig, aber es lässt sich daraus ableiten, dass administrative Rechte erforderlich sind.
Etwas ungewöhnlich ist, dass der Name der Log-Datei zusammengebaut wird. Das erscheint mir in diesem Fall, wo man länger auf das Auftreten des Fehlers warten muss, durchaus sinnvoll. Vielleicht verschluckt sich Thunderbird daran? Das wäre aber auch komisch, den er spricht die Datei ja über die Variable MOZ_LOG_FILE an und nicht direkt.
Kurzum, ich keine stichfeste Idee, woran das liegt.
set MOZ_LOG=IMAP:5,timestamp
Super - genau das hatte ich vermisst - ist jetzt drin
Admin-rights brauchts nicht - sonst würden ja keine Logs kreiert.
Vom zusammengebauten Filenamen erfährt TB gar nichts - übergeben wird die gesetzte Variable.
Der Fehler ist heute wieder aufgetreten, Das Log war da schon 26 MB gross.
Hab mal auf das letzte MB gekürzt (ca. 14'000 Zeilen), alles anonymisiert (ächz...), und als .txt angehängt
Leider noch ohne Timestamps.
Hoffe, das hilft...
Admin-rights brauchts nicht - sonst würden ja keine Logs kreiert.
Das wäre vermutlich auch kontraproduktiv, falls man das Batch-File mit dem "anderen" Admin-Account aufruft, würde Thunderbird ja komplett im Kontext dieses anderen Users ausgeführt und würde auch die profiles.ini dort suchen und somit potentiell andere Profile verwenden... alles klar? 
falls man das Batch-File mit dem "anderen" Admin-Account aufruft, würde Thunderbird ja komplett im Kontext dieses anderen Users ausgeführt
Stimmt natürlich, ausser man hat eine userID mit admin rights (wie ich).
Um ganz sicherzugehen habe ich TB (via cmd script) mal als admin laufen lassen: verhält sich exakt gleich und kreiert auch die gleichen Logfiles mit den gleichen Namen...
Könnt Ihr bitte mal diesen Abschnitt wegen des Timestamp auf technische Korrektheit wegen des Logging-Levels 4 versus 5 (spielt das für den Timestamp eine Rolle - wohl nicht, denke ich) und wegen der Kombination prüfen:
Protokoll (Log-Datei) der Server-Verbindung mit IMAP, POP und SMTP erstellen - Thunderbird Mail DE
Admin-rights brauchts nicht - sonst würden ja keine Logs kreiert.
Wie gesagt, ich habe das unter Windows nicht ausprobiert. Zitiert habe ich das Mozilla Wiki, davon ausgehend, dass die wissen, was sie schreiben.
Das wäre vermutlich auch kontraproduktiv,
Nicht unbedingt. Man sucht ja nicht an einem Fehler im Profil, sondern nach einem in der Kommunikation mit dem Server.
Das Log war da schon 26 MB gross.
Sorry, aber zumindest ich werde nicht 26 MB, durchsuchen, ohne Timestamps und Angabe der Zeit. Das müsste jemand machen, der weiß, worauf er grepen muss. Der Log-Level scheint mir übrigens nicht zu passen. Die Logs, die ich kenne, enthalten deutlich mehr Informationen.
Nicht unbedingt. Man sucht ja nicht an einem Fehler im Profil, sondern nach einem in der Kommunikation mit dem Server.
Als normaler Anwender wundert man sich dann aber über ein jungfräulich leeres Profil und schiebt Panik - so war das gemeint.
Timestamp auf technische Korrektheit wegen des Logging-Levels 4 versus 5 (spielt das für den Timestamp eine Rolle - wohl nicht, denke ich)
Timestamp geht mit beiden logging levels.
Level 5 ist halt detailierter - müsst ihr Experten entscheiden, welcher Level hier benötigt wird, meine Disk hat für beides Platz
Level 4:
2021-11-22 15:02:14.429000 UTC - [Parent 3288: IMAP]: D/IMAP ReadNextLine [rv=0x0 stream=2944c3a3430 nb=26 needmore=0]
2021-11-22 15:02:14.429000 UTC - [Parent 3288: IMAP]: I/IMAP 2945002e000:imaps.bluewin.ch:NA:CreateNewLineFromSocket: 59 OK capabilities listed
Level 5:
2021-11-22 14:29:37.923000 UTC - [Parent 18932: IMAP]: D/IMAP ReadNextLine [rv=0x0 stream=2557be02ca0 nb=100 needmore=0]
2021-11-22 14:29:37.923000 UTC - [Parent 18932: IMAP]: D/IMAP IMAP auth: server caps 0xc3625, pref 0x1006, failed 0x0, avail caps 0x1004
2021-11-22 14:29:37.923000 UTC - [Parent 18932: IMAP]: I/IMAP 2557f989000:imaps.bluewin.ch:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN AUTH=PLAIN ID SASL-IR
Sorry, aber zumindest ich werde nicht 26 MB, durchsuchen, ohne Timestamps und Angabe der Zeit
Da hab ich volles Verständnis! Hab zwar nur das letzte 1 MB angehängt - grössere Files werden hier ja eh rejected.
Gehe ausserdem davon aus, dass du level 5 vorziehst (meines war level 4). Evtl. in der Anleitung von Thunder anpassen...
Hab das bei mir jetzt so aktiviert und melde mich nach dem nächsten Hänger mit Zeitpunkt und downstripped level 5 log mit timestamps im richtigen Range.
Im Mozilla Wiki steht übrigens auch "Since Thunderbird 70, the .moz_log extension will be added to the file name", von den 4 leeren Files steht allerdings nichts. Die Hinweise auf Win 2000, XP, Vista, Win7 lassen aber auch nicht unbedingt auf Aktualität schliessen.
Das Problem ist wieder aufgetaucht (UTC Zeiten)
2021-11-26 03:10 - mail abgesendet
2021-11-26 03:12 - senden, resp. speichern in gesendete hängt
2021-11-26 03:12 - abgebrochen, erneut versucht, gleiches Resultat
2021-11-26 03:13 - speichern
2021-11-26 03:14 - erneut senden -> okDummerweise bei einem Send mit Video-Attachments von 4.75 und 3.19 MB - mit nun seitenweise "This is a multi-part message in MIME format" im Level-5 IMAP Log.
Die Sequenz im Lvl-5 Log von 03:10 bis 03:12:30 ist 27 MB gross - kann ich nicht hochladen (von wegen downstripped 
)
Interessant is aber, dass zwischen 03:10 und 03:13 im IMAP Log *nichts* passiert:
...
2021-11-26 03:10:31.126000 UTC - [Parent 31480: IMAP]: D/IMAP ReadNextLine [rv=0x0 stream=19c8bc41f70 nb=8 needmore=0]
2021-11-26 03:10:31.126000 UTC - [Parent 31480: IMAP]: I/IMAP 19c873ed000:imaps.bluewin.ch:S-Sent Items:CreateNewLineFromSocket: + Idle
2021-11-26 03:10:31.126000 UTC - [Parent 31480: IMAP]: D/IMAP SetConnectionStatus(0x0)
2021-11-26 03:13:01.436000 UTC - [Parent 31480: Main Thread]: D/IMAP proposed url = Drafts folder for connection Sent Items has To Wait = false can run = false
2021-11-26 03:13:01.436000 UTC - [Parent 31480: Main Thread]: D/IMAP proposed url = Drafts folder for connection Drafts has To Wait = false can run = true
...Irgendwelche Ideen/Vorschläge?
Irgendwelche Ideen/Vorschläge?
Naja, wenn im Log nichts drin ist, kann man als einfacher Supporter schwerlich eine Erkenntnis ziehen. Die Entwickler könnten aber auch aus diesem Umstand vielleicht etwas ableiten. Du kannst dich ja mal mit @jorgk3 in Verbindung setzen oder auch gleich einen Bug aufmachen.
Was war denn kurz vor 3:10 Uhr in den Logs los? Wurde da vielleicht ein Kommando an den IMAP-Server gesendet, das noch nicht fertig war, hing oder einen Fehler warf?
Was mir an dem kurzen Schnipsel noch auffällt, es scheint um zwei Verbindungen zu gehen: zum Draft und zum Sent Items. Was genau die Entwickler mit "has to wait" und "can run" meinen, kann ich nur raten. Ich vermute, das sind Debug-Meldungen zu zwei asynchronen Threads in Richtung IMAP-Server. Jörg kann sicher Genaueres dazu sagen.
