Letzten Bearbeitungsstand einer Email vor dem Versenden wiederherstellen

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

• Thunderbird-Version: 68.10.0 (64-bit)
• Wurde gerade auf eine neue Versionsreihe aktualisiert (alte und neue Version angeben): Nein
• Betriebssystem + Version: Xubuntu (Ubuntu + Xfce)
• Kontenart (POP / IMAP): Imap
• Postfach-Anbieter (z.B. GMX): Postfix + Dovecot
• Eingesetzte Antiviren-Software: auf Client Seite keine
• Firewall (Betriebssystem-intern/Externe Software): ufw auf client und server
• Router-Modellbezeichnung (bei Sende-Problemen): irrelevant

Ich habe gerade eine Email versendet an deren Bearbeitung ich mehrere Stunden gearbeitet habe. Leider hat Thunderbird diese mit HTML formatierte Nachricht an alle Empfänger als Plaintext versendet und damit nahezu komplett unbrauchbar gemacht. Warum Thunderbird das gemacht hat und ob dies gerechtfertigt war ist mir im Moment erst mal egal. Ich würde mich aber sehr freuen, wenn mir jemand auf die Schnelle mitteilen könnte, ob es eine Möglichkeit gibt, den letzten Bearbeitungsstand vor dem Versenden wieder herzustellen.

Aus meinem Server-Backup kann ich leider nur den Stand von gestern Nacht wieder herstellen und seitdem sind noch mehrere Tabellen dazugekommen.

Gruß

Hallo Micha,

danke für den Hinweis. Das war natürlich das allererste was ich gemacht hatte. Es war vielleicht ein Fehler, das für selbstverständlich zu halten und nicht zu erwähnen. Im Sent Ordner war sie genauso wie bei den Empfängern. Außerdem konnte ich auch nicht länger warten und habe gestern Abend die Nachricht mühevoll aus meinem letzten Server Backup und den unformatierten Texten aus dem Sent Ordner wieder zusammengesetzt.

In den Send Options war immer "Send the message in both plain text and HTML" eingestellt. Allerdings war da noch eine aktivierte Checkbox mit dem Titel "Send messages as plain text if possible", die mir zuvor nicht aufgefallen war oder ich zuvor nicht weiter beachtet hatte. Ich persönlich halte es auch für eine fatale Fehleinschätzung bei einer Nachricht mit HTML-Tabellen aufgrund dieser Einstellung die Entscheidung zu treffen, dass es auch möglich ist, die in Plaintext zu versenden. Das ist aber natürlich eine subjektive Einschätzung. Es wäre aber durchaus interessant zu wissen, nach welchen Kriterien diese Entscheidung getroffen wird und ob man diese Entscheidungsfindung beeinflussen kann.

Nachdem ich die Checkbox "Send messages as plain text if possible" abgewählt hatte funktionierte es zunächst immer noch nicht. Ich hatte Thunderbird daraufhin zunächst neu gestartet und die Option vorübergehend auf "Ask me what to do" gestellt. Letztendlich funktioniert es jetzt aber mit der Kombination aus der gewählten Option "Send the message in both plain text and HTML" und der deaktivierten Checkbox "Send messages as plain text if possible". Ich vermute stark, dass der Neustart ausschlaggebend war. Diese Einstellungen haben jetzt natürlich den Nachteil, dass auch Nachrichten ohne jegliche Formatierung zusätzlich im HTML-Format gesendet werden.

Die Frage, ob es eine Möglichkeit gibt, den letzten Bearbeitungsstand einer Email wieder herzustellen - und zwar nicht aus dem gesendet Ordner - ist immer noch offen. Ich könnte mir vorstellen, dass das für andere Benutzer noch interessant sein könnte. Generell macht es natürlich keinen Sinn, den letzten Bearbeitungsstand einer gesendeten Nachricht zu speichern. In diesem speziellen Fall hat Thunderbird jedoch vor dem Versenden entschieden Änderung an der von mir erstellen Nachricht vorzunehmen die meiner Ansicht nach sehr gravierend waren. Es ist eigentlich eine Art (unverbindliche) Benimm-Etikette in der Software-Entwicklung, dass man in solchen Fällen einen Backup von der Arbeit des Benutzers macht. Außerdem hatte ich gehofft, dass es vielleicht im Dateisystem eine Art Cache Ordner gibt, der den letzten Arbeitsstand enthalten könnte.

Gruß

Allow HTML Temp habe ich nicht installiert. Danke für den Hinweis.

Ich habe eigentlich keine AddOns, die den Inhalt oder den Entwurf von Nachrichten betreffen

• Lightning
• Provider for CalDAV & CardDAV
• Sieve
• TbSync
• FileLink for WeTransfer (?)

Ich halte die Wahrscheinlichkeit das es möglich ist auch für gering. Lasse ich den Thread dann offen oder was ist da wohl die beste Handhabung?

Gruß

Danke Euch allen für die Hinweise

Zitat von MSFreak

Ist vielleicht das Senden von HTML-Mails beim Provider unterbunden ?

Nein, es hat ja auch letztendlich funktioniert

Zitat von Susi to visit

Hast du dir mal den Quelltext der Mail angeschaut?

Ja, war nur Plaintext im Problemfall. In einem der Tests hatte ich auch mal überprüft ob ein Email mit HTML-Tabelle sich sauber mit Tidy parsen lässt. Da war im Draft sauberes HTML und in der gesendeten Version nur Plaintext.

Zitat von Susi to visit

Schau dir mit einem Texteditor die zugehörige mbox "drafts" an.

Das habe ich nur auf dem Server gemacht. Dort war die Email nach dem Senden verschwunden. Auf Client-Seite hatte ich das nicht ausprobiert. Ich habe aber eben gerade mal nachgesehen und im lokalen Dateisystem sind keine Inhalte sondern nur Betreff-Zeilen und Referenzen. Das macht auch Sinn, weil ich die Option "Keep messages in all folders for this account on this computer" unter "Synchronisation & Storage" grundsätzlich deaktiviere.

Zitat von Drachen

Eigentlich nicht. Du hast einen Entwurf erstellt und Thunderbird hat sich an die von dir bestimmten Einstellungen beim Versand gehalten. Dies ist keine (eigenmächtige) Entscheidung, Änderungen vorzunehmen, und so wie ich dich verstehe, wurden auch keine inhaltlichen Änderungen vorgenommen.

Das ist eine absolut berechtigte Meinung die ich aber nicht teile. Die Verbindung zwischen Tabellen-Spalten und Zeilen kann man durchaus als eine inhaltliche Zuordnung werten. Selbst die Hervorhebung von Überschriften oder die Markierung von Textstellen mit Fett oder Kursivschrift, Unterstrichen oder gar der HTML-Anweisung durchgestrichen kann für das Verständnis einer Nachricht wichtig sein und würde ich subjektiv als einen Teil des Inhalts ansehen.

Zitat von Drachen

Die Alternative wären womöglich mehrere Abfragen á la "soll wirklich gemäß Anweisung konvertiert werden" und "soll wirklich eine Verbindung zum SMTP-Server aufgebaut werden" (und sollen wirklich die hinterlegten Zugangsdaten dafür genutzt werden") und "soll wirklich gesendet werden" und "soll wirklich eine Kopie in den Ordner 'Gesendet' abgelegt werden" usw. usw. ....

Mir würde es schon völlig reichen wenn ich wüsste, wie genau die Entscheidung getroffen wird. Optional wäre es wünschenswert wenn man in der erweiterten Konfiguration einstellen könnte bei welchen html-tags automatisch im Multicontent gesendet werden soll. Meine persönliche Meinung ist, dass sobald auch nur eine einzige Formatierung enthalten ist, die sich nicht auch im Plaintext darstellen lässt (also eigentlich alles außer Zeilenumbrüchen und Absätzen) die Möglichkeit im Plaintext zu senden nicht gegeben ist.

Dieses Problem ist bisher eigentlich nicht aufgetreten und ich war vollkommen überrascht von diesem unerwarteten Ergebnis.

Nochmals vielen Dank für all Eure Hinweise und Gruß

Zitat von Susi to visit

waren die Tabellen denn wirklich Tabellen in dem Sinne, dass sie HTML-formatiert werden müssen?

Die Tabellen wurden direkt in Thunderbird erstellt indem ich im Bearbeitungsfenster über das Menu "Insert" > "Table" ausgewählt habe. Während ich nach der Ursache des Problems gesucht habe, habe ich mir eine Test-Email erstellt, deren Inhalt ich dann immer in eine Neue Email kopiert habe. Die Tabellen wurden im Entwurf als vollständige HTML-Tabellen gespeichert (das konnte ich sehen als ich den Inhalt der entsprechenden Datei im Drafts-Ordner auf dem Server angesehen habe). Die größte der Tabellen hatte 8 Spalten und 21 Zeilen.

Zitat von Susi to visit

Mich würde interessieren, welche Einstellung dafür verantwortlich ist. Die oben genannte "wenn möglich ..." ist offensichtlich nicht.

Mittlerweile ist meine Vermutung, dass es im Laufe der Updates zu einer Art Fehlkonfiguration gekommen ist, die das Problem verursacht hat. Es gab schon unzählige Situation in denen ein derartiges Problem hätte auftreten können. Dennoch war es das erste Mal das so etwas passiert ist. Das Update läuft bei mir über die Paketverwaltung des Betriebssystems.

Die Änderungen und Tests die ich vorgenommen habe sind folgende in genau der genannten Reihenfolge:

1. Checkbox "Send messages as plain text if possible" deaktiviert.
2. Mehrere Tests gemacht die alle nicht das gewünschte Ergebnis hatten
3. In den Send Options "Send the message in both plain text and HTML" auf "Ask me what to do" geändert
4. Client neu gestartet
5. Mehrere Tests gemacht die das gewünschte Ergebnis hatten (wobei jedes Mal gefragt wurde)
6. In den Send Options "Ask me what to do" wieder zurück auf "Send the message in both plain text and HTML" gesetzt
7. Mehrere Tests gemacht die das gewünschte Ergebnis hatten (ohne Frage, wobei jetzt alles im Multicontent gesendet wird)

Rückblickend wäre es natürlich für die Auswertung von Vorteil gewesen wenn ich zwischen den Schritten 3 und 4 auch noch einen Test gemacht hätte. Dafür ist es jetzt aber zu spät.

Die vermutlich signifikanteste Information ist folgende:

Wenn ich jetzt die Checkbox "Send messages as plain text if possible" jetzt wieder aktiviere tritt das Problem NICHT mehr auf obwohl alle sichtbaren Einstellungen wieder genau so sind wie sie zum Zeitpunkt waren als das Problem auftrat. Nur um ganz sicher zu gehen habe ich den Client nach dieser Änderung auch noch mal neu gestartet. Das Ergebnis blieb unverändert.

Leider führe ich keine Backups für die Benutzerverzeichnisse auf diesem Computer durch weil dort keine wichtigen Daten gespeichert werden. Ich sehe daher keine Möglichkeit den exakten Zustand von gestern Abend wieder herzustellen um das Problem genauer zu untersuchen.

Zitat von Susi to visit

Größere Tabellen, auch wenn sie gar nicht komplex sind, würde ich immer als Anhang versenden.

Danke für den Hinweis. Rückblickend betrachtet war die Email auch einfach zu groß. Ich hätte ein anderes Dokument daraus machen sollen.

Danke auch noch mal an alle für die rege Beteiligung.

Anscheinend gibt es keine Möglichkeit in einem Fall wie diesem den letzten Bearbeitungsstand vor dem Senden wieder herzustellen (der Zustand nach dem Senden wird natürlich im Sent Ordner abgelegt). Das würde ich auch als absolut akzeptabel bezeichnen. Das Problem das sich gestern Abend zu einem denkbar ungünstigen Zeitpunkt bei mir bemerkbar gemacht hat, scheint ein unvorhersehbares Fehlverhalten gewesen zu sein und nicht die beabsichtigte Umsetzung meiner Konfigurationseinstellungen.

Wie sollte man jetzt mit diesem Thread umgehen, da die Kernfrage des Threads sich in diesem Falle erübrigt hat aber dennoch ungelöst bleibt?