Konnte nicht in Gesendet kopiert werden

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Programm + Version: 31.4.0
    * Betriebssystem + Version: Win7 Pro
    * Kontenart (POP / IMAP): IMAP
    * Postfachanbieter (z.B. GMX): Eigener Postfix Server beim ISP

    Liebe Community,
    wir nutzen im Unternehmen Thunderbird und haben mittlerweile nicht nur mehr sporadisch das folgende Problem, sondern es wird immer häufiger.

    Und zwar äußert sich das Problem so, dass TB eine geschriebene E-Mail wohl verschickt, aber dann beim "In Gesendet kopieren ..." sich aufhängt und es nicht schafft.
    Nach einigen Sekunden dann die Meldung "Konnte nicht in Gesendet kopiert werden, möchten Sie es erneut versuchen?" - Meistens klappt selbst das erneute Versuchen nicht.
    Nun hat TB aber eine doofe Programmierung, denn er sendet die E-Mail jedes Mal erneut zum Empfänger - Und klicke ich auf Abbrechen, dann schließt sich meine E-Mail, was auch sehr ärgerlich ist,
    da ich Sie so nicht einmal mehr sichern konnte. Auch das Zwischenspeichern via "STRG + S" klappt dann nicht, da ich die gleiche Meldung erhalte "Konnte nicht in Entwürfe gespeichert werden".

    Wir haben nun schon diverse Stellen überprüft, konnte aber keine Probleme finden. Der Mailserver langweilt sich den ganzen Tag bei max. 5% CPU-Last und hat auch noch genug Arbeitsspeicher frei.
    Die Platten haben auch noch genug Platz ... Wir haben Dank Multi-Wan insgesamt 3 Internetleitungen... Also selbst wenn eine ausfällt, übernehmen die anderen die Arbeit.
    Aber auch hier konnte ich in Störungsfällen keine Internetausfälle sehen. Auch die Speedtest ergeben keine Schwachstelle ... Das interne Netz weißt auch keine Schwachstellen auf. Das Kopieren von Dateien rennt mit gut 100-90 MB/sec recht zügig im GB-Netzwerk.

    Auf den Computern läuft die Win7-Firewall und auch ein Antivir Program, welches allerdings keinen E-Mail Scanner besitzt und auch das TB-Profil als Ausnahme in der Liste drin stehen hat, damit dies nicht zufällig die mboxen beschädigt beim scannen.

    Das Problem taucht auch nicht immer auf! Das ist ja das merkwürdige, was es mir so schwierig macht. Mir ist nur aufgefallen, dass man TB einmal neustarten muss, nachdem man das Problem hatte, denn TB scheint sich danach irgendwie immer noch im Hintergrund damit zu beschäftigen. Meistens können auch vorhandene E-Mails nicht mehr korrekt geöffnet werden. TB bleibt daher meist auch im Taskmanager hängen, sodass ich ihn erst dort schließen muss. Nachdem TB-Neustart klappt es zu 90% dann auch wieder - Bis er das nächste Mal irgendwann wieder das Problem zeigt.

    Es ist echt zum verzweifeln. Kennt jemand ähnliche Probleme oder hat einen Tipp, woran es evtl. liegen könnte oder was ich noch testen könnte?

    Vielen Dank schonmal im Voraus.

    Liebe Grüße
    Nico

    Hallo Nico,

    ich gehe davon aus, dass Thunderbird dir den Ordner anzeigt, in den die gesendete E-Mail kopiert werden soll (dieser also abonniert ist).

    Ich hatte einmal ein ähnliches Problem und bei mir hat geholfen, den IMAP-Ordner, in den die gesendete E-Mail kopiert werden soll, von Hand in den Thunderbird-Einstellungen auszuwählen:
    Alt => Extras => Konteneinstellungen => entsprechendes Konto => Kopien & Ordner => Beim Senden automatisch eine Kopie speichern unter => Anderer Ordner anklicken und den richtigen Ordner im IMAP-Konto auswählen.

    Was noch sein könnte:
    Irgendwann habe ich irgendwo im Netz gelesen, dass es jemandem geholfen hat, die SMTP-Einstellungen des entsprechenden Kontos von SSL auf STARTTLS umzustellen. Ich verstehe zwar nicht, weshalb das helfen soll (denn der Kopiervorgang hat ja - nach meinem Verständnis - nichts mit dem SMTP-Protokoll, sondern mit dem IMAP-Protokoll zu tun), aber vielleicht ist es einen Versuch wert.

    Mehr Ideen habe ich auch nicht.
    Grüße, Ulrich

    Hallo Nico,

    das von dir gepostete Problem ist eigentlich ein "alter Bekannter". Ich kann mich an gefühlte 50 Forenbeiträge und auch an umfangreiche Testläufe meinerseits erinnern, wo ich versucht habe, per Paketsniffer irgendwelche Timing- und andere Probleme ausfindig zu machen. Fakt ist, bei manchen Providern gab und gibt es keine Probleme, bei anderen keine Erfolge ... .
    Wie Ulrich schon richtig schrieb, hat dieses Problem nichts mit dem Senden, also SMTP zu tun, sondern es ist ein reines IMAP-Problem. Die gesendeten Mails werden per IMAP in den Gesendet-Ordner auf dem IMAP-Server kopiert.
    Meine Vermutung, aber dafür würde ich viel Motivation und auch die ausführlichen Logfiles des IMAP-Servers benötigen, ist, dass die vom Provider festgelegte Zahl der pro Konto aufrecht zu haltenden Verbindungen überschritten wird.

    Meine persönliche Lösung ist, dass ich grundsätzlich die gesendeten Mails in einen lokalen Gesendet-Ordner laufen lasse. Und wenn ich dann täglich als letzte Aktion die im Posteingang meiner Konten gesammelten und gelesenen/bearbeiteten Posteingänge mit einem einzelnen Klick ("Filter ausführen") in meine vielen Ordner und Unterordner einsortieren lasse, schubse ich auch gleich die gesendeten Mails in den Gesendet-Ordner auf dem IMAP-Server. Man kann das natürlich auch öfters machen.
    (Um es ganz genau zu sagen: Ich habe mir angewöhnt, alle Mails auch per BCC an eine eigene "Spezialadresse" die ich nur für diese Funktion angelegt habe, zu versenden. Und die nach ein paar Sekunden wieder ankommende Mail ist für mich die einzig wahre Sendebestätigung. Und diese Mail wird dann als gesendete Mail archiviert. Und ich verwende auch nur sehr selten den Gesendet-Ordner, sondern ich sortiere Vorgangs- oder Personenweise sämtliche empfangenen und gesendeten Mails immer im Zusammenhang in je einen Ordner.)


    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

    Zitat von losgehts

    ich gehe davon aus, dass Thunderbird dir den Ordner anzeigt, in den die gesendete E-Mail kopiert werden soll (dieser also abonniert ist).


    So siehts aus - Der Gesendet Ordner (Auf dem Server ja SENT) ist abonniert, sichtbar und auch nutzbar.

    Zitat von losgehts

    Ich hatte einmal ein ähnliches Problem und bei mir hat geholfen, den IMAP-Ordner, in den die gesendete E-Mail kopiert werden soll, von Hand in den Thunderbird-Einstellungen auszuwählen:


    Das dürfte bei allem der Fall sein, da ich die Thunderbird Einstellungen per zentrale Steuerung (Autoconfig) verteile. Ich überprüfe das aber gerne noch einmal bei denen, wo es derzeit am meisten auftritt.

    Zitat von losgehts

    die SMTP-Einstellungen des entsprechenden Kontos von SSL auf STARTTLS umzustellen.


    Das ist bereits bei uns Standard! Der SMTP-Server steht auf STARTTLS und Port 587 - Der IMAP-Empfang läuft allerdings über SSL/TLS Port 993. Ich kann ja auch gerne hier mal Testweise auf STARTTLS runterschrauben und prüfen, wenn Ihr sagt, dass das kopieren eine IMAP-Aktion ist.

    Peter:
    Vielen Dank für deine ausführliche Antwort. Ich muss grundsätzlich erst einmal erläutern, dass wir einen eigenen Postfix Server bei ISP betreiben und dort bereits alle Limits erhöht haben. Auch die Serverlogs protokollieren keine Fehler mehr,
    wie Anfangs als wir wirklich mal übers Limit kamen mit aktiven IMAP-Sessions uvm. Aber das wurde bereits alles gefixt. Das einzige was auffällt sind die ca. 1200 Threads die parallel laufen. Aber wenn Thunderbird auch pro Konto 5 IMAP-Sessions aufbaut, kommt man bei unserer Mitarbeiterzahl auch schnell auf so eine Anzahl. Aber wie gesagt, die CPU langweilt sich die meiste Zeit und ist auch nicht überlastet. Und ich denke wenn das der Fall wäre, hätten wir viel mehr Probleme am Tag ...

    Deine Idee mit dem lokalen Ordner klingt zwar ganz gut, doch ich weiß jetzt schon, dass viele Mitarbeiter so einen Filter nicht jeden Tag ausführen würden. Lässt sich das automatisieren? Beim Beenden von TB noch schnell die Mails aus dem lokalen gesendeten Ordner dann in den IMAP-Ordner zu kopieren? Dann wäre es sicherlich ein netter Workaround.

    Hallo Nico,

    wie Peter schon schrieb, ist dieses Problem ein alter Bekannter. Es taucht seit einigen Jahren immer mal wieder hier im Forum auf. Meines Wissens ist die Ursache für dieses Verhalten bis heute nicht bekannt. Was wohl auch daran liegt, dass dieses Problem bei den Anwendern nur sporadisch auftritt und bei den meisten offenbar gar nicht.
    Vielleicht bietet sich in Deinem Fall (eigener Server, viele Anwender) die Möglichkeit, anhand der Serverprotokolle einen Schritt weiter zu kommen. Wenn Du nachvollziehen könntest, was genau auf dem IMAP-Server abläuft und welche Aktion dort scheitert, wäre das vielleicht der entscheidende Hinweis für die Entwickler.

    Gruß

    Susanne

    Zitat von losgehts

    anhand der Serverprotokolle einen Schritt weiter zu kommen.


    Das Problem ist ja, dass der Server in so einem Fall nie was in die Logs schreibt :/
    Daher muss das Problem bereits auf dem Weg zum Server entstehen, spricht vielleicht sogar im eigenen Netzwerk oder am Computer ... oder TB selbst ist das Problem?!

    Ich würde ja gerne weiterhelfen und den Entwicklern auch einen Tipp geben, aber wie gesagt, keine Einträge in den Logs und alle Limits sind soweit angehoben und auch die Hardware langweilt sich. Es liegt daher eig. nicht am Mailserver.
    Ich werde auf jedenfall weitere Tests durchführen. Ich werde mal anfangen das SSL auf STARTTLS um zu ändern. Es ist echt wie die Suche nach der Stecknadel im Heuhaufen :(

    Kannst Du den Mailserver nicht so einstellen, dass er seine Aktivitäten protokolliert? Vielleicht mit einem höheren Log-Level? Man müsste doch zumindest sehen, dass (und was) der Client mit dem Server kommuniziert?

    Hallo,

    es könnte evtl. auch ein Thunderbird-Log helfen - gerade weil es eben ein "alter Bekannter" ist und auf Bugzilla schon seit Jahren von ähnlichen Problemen berichtet wird. Allerdings kann ich ein Thunderbird-Logfile nicht lesen/auswerten.
    Hier ist beschrieben, wie man ein solches Logfile erstellt: Generating a Protocol Log
    Das Beispiel ist auch gerade das richtige (IMAP-Log). Bei Bugzilla freut man sich über solche Logfiles.

    Grüße, Ulrich

    Ich habe nach längerer Logdateien Auswertung was gefunden! Es tauchte mehrmals

    Code
    Dovecot: Warning: All login processes are in use. You may need to increase login_max_processes_count


    auf.

    Wir haben nun dementsprechend login_max_processes_count von 512 auf 1024 angepasst. Mal sehen, ob die Meldungen nun ausbleiben und ob unsere Benutzer nun weniger TB-Probleme haben.

    Ich halte euch auf dem Laufenden, sofern ich Neuigkeiten habe. Hilfreiche Tipps nehmen wir aber immer noch gerne an :)

    Hallo,

    ich habe von diesen Verbindungen, die TB aufbaut nicht keine Ahnung, doch scheinen mir deine Aussagen nicht so ganz zusammen zu passen.
    Ist das

    Zitat

    Wir haben nun dementsprechend login_max_processes_count von 512 auf 1024 angepasst. Mal sehen, ob die Meldungen nun ausbleiben und ob unsere Benutzer nun weniger TB-Probleme haben.

    nicht ein wenig unterdimensioniert unter Anbetracht dessen:

    Zitat

    Das einzige was auffällt sind die ca. 1200 Threads die parallel laufen. Aber wenn Thunderbird auch pro Konto 5 IMAP-Sessions aufbaut, kommt man bei unserer Mitarbeiterzahl auch schnell auf so eine Anzahl.

    ?

    Ich finde toll, dass du uns auf dem Laufenden halten möchtest! Vielen Dank!


    Grüße, Ulrich

    Zitat von losgehts

    nicht ein wenig unterdimensioniert unter Anbetracht dessen:


    Hey Ulrich,
    ja das klingt in der Tat merkwürdig, ABER wir wissen leider nicht zu 100% was TB/Dovecot oder Postfix da veranstalten. Die 1200 Threads können ja auch wegen was anderem bestehen. Ich weiß nur, dass TB insgesamt 5 IMAP-Sessions pro Mailkonto aufbaut. Wenn ich jetzt ca. 100 Mitarbeiter habe, die im Schnitt mit 2 E-Mailkonten arbeiten, dann käme ich bereits auf 1000 IMAP-Sessions. Vielleicht sind daher so viele Threads offen. Ich weiß es leider nicht genau, da ich weniger in der Linux Welt arbeite. Auf jedenfall erschien die obrige Fehlermeldung ... Diese haben wir jetzt erst einmal erhöht. Wir möchten ungern zu hohe Grenzen setzen und gehen lieber in kleinen Schritten an das Problem heran. Ich überprüfe jetzt jeden Morgen die Log-Dateien des Vortages und schaue, ob weitere Meldungen aufgetaucht sind.

    Dabei ist uns nun z.B. aufgefallen, dass nachdem wir die obrige Fehlermeldung behoben haben, nun eine weitere erschienen ist.

    Code
    Warning: Inotify instance limit for user exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances

    Das hat unser Serveradmin nun auch behoben. Interessant finde ich allerdings, dass diese Fehlermeldung zu keiner Zeit vorher auftrat, sondern erst nachdem wir "login_max_processes_count" erhöht haben. Ich schätze daher, dass dieser Wert zu erst meckerte und nachdem nun weitere Verbindungen möglich waren der nächste Wert an seine Grenze gestoßen ist.

    Mich würde ja einmal interessieren, wie andere Firmen Ihren Dovecot Mailserver bei einer Mitarbeiteranzahl bis zu 200 Usern oder mehr konfiguriert haben. Nur leider findet man dazu wenig im Netz.
    Dann könnten wir die relevanten Einstellungen vergleichen und ggf. ab ändern.

    Nunja, weiter geht die Fehlersuche :)

    Hallo,

    ich hänge mich mal unverschämterweise mit ran, weil ich das gleiche fast unfindbare Problem habe und heute ein wenig debuggen konnte.
    OS: Debian x64 Wheezy,
    Icedove 31.5.0 (mit Enigmail und so kram)
    Kontoart: IMAP
    Server: dovecot
    Mit dem Hinweis auf

    Code
    # For bash shell (the default shell on most GNU/Linux systems):
export NSPR_LOG_MODULES=imap:5
export NSPR_LOG_FILE=/tmp/imap.log

    und einem loglevel von 7 sieht man zwar eine Menge, aber ausgerechnet zu diesem Problem taucht nichts auf (zumindest nicht in zeitlicher Korrelation zum Fenster).

    • Auf dem Server selber (via roundcube Webmail) lassen sich Entwürfe unfallfrei speichern (und tauchen dann auch in TB in Drafts auf).
    • Auch die Verwendung eines anderen Kontos auf dem selben Server funktioniert, d.h. dass nur ein Konto dieses Problem hat.
    • Es ist das genau das Konto, welches auch einen GnuPG-Schlüssel hat - @s1n88 setzt ihr Enigmail ein?
    • Der Fehler tritt unverändert auf, unabhängig, ob man als Server eine IP oder einen Namen einsetzt (der auf die identische IP auflöst)
    • In einem separaten TB-Profil kann ich mit diesem Konto ohne Probleme Entwürfe speichern

      • sowohl unverschlüsselt
      • als auch mit Enigmail verschlüsselt

    Das Problem lässt sich also ein wenig eingrenzen

    • es liegt an Thunderbird/Icedove
    • aber nur in Verbindung mit einem bestimmten Profil
    • es ist unabhängig von Enigmail-Verschlüsselung

    Updates appreciated... ?(

    Viele Grüße
    Kai

    Hallo Kai,

    Zitat von kakohari

    In einem separaten TB-Profil kann ich mit diesem Konto ohne Probleme Entwürfe speichern

    Wenn es am Profil liegen würde, dann wäre das zumindest keine schlechte Nachricht. Es gäbe dann eine Lösung/Workaround, selbst wenn die eigentliche Ursache nach wie unklar bliebe.
    Wie regelmäßig tritt der Fehler denn in dem anderen Profil auf? Läuft der Test mit dem neuen Profil noch? Ich frage deshalb, weil ich den Fehler schon sehr lange nicht mehr gesehen habe. Er ist bei mir überhaupt nur wenige Male aufgetreten. Die Frage ist daher, ob sich mit hinreichender Sicherheit sagen lässt, dass der Fehler am Profil hängt?

    Zitat von kakohari

    und einem loglevel von 7

    Gibt es diesen Log-Level? Die Dokumentation, die ich dazu kenne, spricht nur von Level 1 - 5. Siehe https://wiki.mozilla.org/MailNews:Logging#smtp

    Konntest Du in den Logs des Dovecot irgendetwas sehen? Vielleicht ähnliche Meldungen, wie oben bei s1n88?

    Gruß

    Susanne

    Zitat von kakohari

    Es ist das genau das Konto, welches auch einen GnuPG-Schlüssel hat - @s1n88 setzt ihr Enigmail ein?


    Nein, setzen wir nicht ein.

    Wir haben zwischenzeitlich eine Systemumstellung im Haus durchgeführt (Neue Samba4 Domain) und im Zuge dessen auch Änderungen an TB vorgenommen. Und zwar haben wir jetzt das Mailcaching abgeschaltet, sodass nun direkt auf dem IMAP-Server gearbeitet wird. Sprich bei jeder E-Mail die angeklickt wird, wird auf dem Server zugegriffen. Es landen nur noch die Kopfzeilen im TB-Profil.
    Wie ich feststellen musste, läuft das leider nicht gerade viel besser - Anfangs gabs starke Probleme mit Anhängen, da dort immer keine Größe angezeigt wurde. Dies hängt wohl mit dem Mailserver und den TB Einstellungen zusammen. Wir haben TB nun gezwungen, selbst die Anhang Größe zu analysieren, sodass nun endlich die Größen angezeigt werden. War das nämlich nicht der Fall, konnte auf eine E-Mail mit Anhängen nicht geantwortet werden - Wieso auch immer ... es wurde keine Signatur mehr angezeigt und das Senden schlug fehl, indem der Sendebalken unendlich lang durchlief ... Aber das konnten wir nun fixen.
    Trotzdem passiert es ab und zu, dass E-Mails nicht richtig geladen werden und man erst wieder eine andere anklicken muss, damit die andere geladen wird. Sehr verwirrend alles.

    Das eigentliche Problem, dass manchmal E-Mails nicht rausgehen (besonders mit Anhängen) haben wir aber immer noch ... Ich finde einfach keine eindeutige Antwort auf das Problem.
    Manchmal habe ich schon unseren Router (Loadbalancer mit 3 Internetleitungen) in Verdacht - Als wenn dieser einfach für diesen Client dann keine Verbindung zum Server aufbauen will oder die Session sich dort aufhängt.

    Achja, bei uns tritt das Problem bei ALLEN Clients auf und nicht nur bei einem Konto ... Allerdings auch nicht ständig ... Manchmal hat ein Kollege ein paar Tage Ruhe und dann hat er mal wieder das Problem - Sehr sehr merkwürdig alles ...

    Hallo s1n88,

    Zitat von s1n88

    Achja, bei uns tritt das Problem bei ALLEN Clients auf ...

    Wäre das vielleicht eine einmalige Chance, den Entwicklern die Möglichkeit zu geben, das Problem näher zu untersuchen? Die Trefferwahrscheinlichkeit ist bei euch sicher höher als bei einzelnen Personen. Falls ihr bei euch testen dürft, ggf. auch mit einem Debug-Build des TB, dann könntest einen bug eröffnen und genau das anbieten.

    Gruß

    Susanne

    Hallo,

    Zitat von SusiTux


    [...]
    Die Frage ist daher, ob sich mit hinreichender Sicherheit sagen lässt, dass der Fehler am Profil hängt?

    In dem anderen Profil habe ich in ca. 20 Versuchen keinen einzigen Fehlversuch gehabt. Aber: aufgrund gewisser Schwächen in Lesekompetenz meinerseits muss ich nochmal richtigstellen: das passiert bei mir reproduzierbar seit dem letzten Update (auf 31.5.0) und *immer* wenn ich in Drafts speichern möchte.

    Zitat von SusiTux

    Gibt es diesen Log-Level? Die Dokumentation, die ich dazu kenne, spricht nur von Level 1 - 5. Siehe https://wiki.mozilla.org/MailNews:Logging#smtp


    Ja, ich bin überrascht. https://wiki.mozilla.org/MailNews:Logging#Logging_level sagt 1-5, aber mit 7 war es deutlich gesprächiger. Ich versuche nochmal, das einzugrenzen. Ist 7 vielleicht 2+5? (mal abgesehen von der dezimal-mathematischen Offensichtlichkeit :D )

    Zitat von SusiTux


    Konntest Du in den Logs des Dovecot irgendetwas sehen? Vielleicht ähnliche Meldungen, wie oben bei s1n88?


    Nein, nicht zeitlich zur Fehlermeldung korrelierbar - dafür die zahlreichen anderen IMAP-Logins und Befehle. Die Fehlermeldung kommt auch verdächtig schnell, wenn ich die Nachricht speichern möchte.
    Hat jemand Erfahrungen mit https://addons.mozilla.org/en-US/thunderbird/addon/tbtracer/ ?

    Zitat von s1n88

    Loadbalancer mit 3 Internetleitungen


    Wenn ich jetzt noch wiederfinden würde, was ich "mal irgendwo im Internet" gelesen habe... Kannst du den Loadbalancer so einstellen, dass der Mailserver fix über eine definierte Leitung (die mit dem dicksten Upstream) erreicht wird? Bzw. ein VPN zum Mailserver drumrumhäkeln? Je nach Loadbalancer "tut es Dinge", die der Mailserver vielleicht nicht verdauen kann?


    Viele Grüße
    Kai

    Zitat von kakohari

    Kannst du den Loadbalancer so einstellen, dass der Mailserver fix über eine definierte Leitung (die mit dem dicksten Upstream) erreicht

    Ja, das können wir und haben wir auch schon eingestellt. Ob ich nun alle Verbindungen zum Mailserver über die dicke Leitung schiebe oder den Loadbalancer sage er soll die Verbindung über die 3 Leitungen teilen bringt leider nichts - Wir konnten keine Verbesserung feststellen. Derzeit ist die Regel allerdings aktiv, sodass Mailserververbindungen über die dicke Leitung gehen.

    Ich konnte allerdings das "Anhänge Problem" wohl lösen. Es wurden bei uns ja nicht immer die Größe der E-Mail Anhänge angezeigt, worauf dann das Antworten nicht richtig funktionierte.
    Dies konnte ich mit zwei Einträge in der Konfiguration beheben, wenn auch eher unschön :D

    Code
    defaultPref("mail.imap.fetch_by_chunks", false);
defaultPref("mail.imap.mime_parts_on_demand_threshold", 50000000);

    So ganz genau steige ich da nicht durch, aber es hat wohl was mit dem E-Mail Abruf zutun bzw. wie Thunderbird die Größe ausliest. Auf jedenfall musste ich den ersten Befehl deaktivieren und mit dem zweiten Befehl definiere ich die Größe. Ich habe sie nun auf knapp 50MB gesetzt, damit auch auf E-Mails mit großen Anhängen (Und ja, einige sind so krass und verschicken sowas mit E-Mails ...) erfolgreich geantwortet werden kann.
    Wenn die Größe z.B. auf 3MB gesetzt habe, so wurde mir die Größe der E-Mail Anhänge bis 3MB erfolgreich angezeigt. Bei größeren E-Mails kam dann wieder "Größe unbekannt".
    Daher hatte ich es jetzt auf 50MB gesetzt, um fast alle E-Mails zu erreichen. Bisher auch keine Beschwerden - Seit 2 Tagen bei uns aktiv.

    Wer eine schönere Lösung kennt, gerne her damit :)
    Mich würde allerdings mal interessieren, wodurch das Problem entsteht - Ich meine gelesen zu haben, dass es ggf. am Mailserver liegt, der TB keine Größe der Anhänge mitteilt?! Weiß da jemand was genaues? wie das alles z.B. abläuft?

    Sei so nett, und beobachte das weiterhin. Da dieser Fehler bei den meisten Benutzern sehr sporadisch auftritt, traue ich diesem Frieden noch nicht. Letztendlich ist icedove ja ein Thunderbird. Trotz der Streitigkeiten, wäre es doch komisch, wenn die Entwickler bei Debian hier einen Fix hätten, der dann nicht in den Thunderbird zurückfliest.

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

    Hat das Thema geschlossen.