Wie kann ich die email wieder formatiert anzeigen und den Anhang als Anhang öffnen?
Hast du den Ordner schon mal 'Reparieren' lassen? (Rechtsklick → Eigenschaften)
@Veteran
Nein, das hatte ich nicht und kannte es auch nicht.
Es hat geholfen. Nun ist es wieder in Ordnung.
Vielen Dank
mfg Hans
PS: Bastler Keine Ahnung, woher die Angabe kam. Das habe ich bei der Versionsabfrage bekommen. Nun aber erhalte ich die Angabe Ver: 102.7.0
Version 2.5.0 (1.2.27)
Windows 10 Pro 22H2 Buid 19045.2486
IMAP
GMX
kein Speicherdienst
nur Windows-intern
keine Firewall
Hallo
Ich habe plötzlich den Effekt, dass einige emails, die vorher mit diesem Thunderbird abgeschickt wurden, plötzlich, im Ausgangsordner geöffnet, plötzlich Quellcode statt formatiertem Text anzeigen und eine ursprünglich angehängte pdf-Datei auch als Quelletext eingebunden angezeigt wird.
Es ändert nichts, ob ich im Menü bei Ansicht/Anhänge eingebunden darstellen ein Häkchen habe oder nicht.
Es ändert nichts, ob ich im Menü bei Ansicht/Nachrichteninhalt OriginalHTML oder irgendetwas anderes auswähle.
Wie kann ich die email wieder formatiert anzeigen und den Anhang als Anhang öffnen?
Viele Grüße
Hans
This is a multi-part message in MIME format.
--------------THqFNU43RkqQOLYVYk0gREzx
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html> <head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> <p>Guten Tag,Susi to visit Ich kann verstehen, dass "X-MOZ-..." sich irgendwie nach Mozilla anhört. Und vielleicht wurde es auch von Mozilla ins Leben gerufen und eM-Client verwendet es für die Kompatibilität ... ??? Aber Du kannst sicher sein, eM-Client schreibt das selbst rein, gleich bei der Terminerstellung, sogar, wenn er ganz offline die Termine einträgt. Ich hab's ausprobiert. Aber Thunderbird trägt X-MOZ-LASTACK: auch ein, allerdings erst später, mit der Erinnerungsbestätigung.
Die Systematik der Erinnerungsverwaltung beim Thunderbird-Kalender liegt nicht in der VALARM-Sektion der ICS-Datei. Diese sieht bleibt dauerhaft unverändert immer gleich, auch nach Erinnerung und Bestätigung:
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT5M
DESCRIPTION:Mozilla Standardbeschreibung
END:VALARM
Die Erinnerungs-Verwaltung hierfür wird bei Thunderbird also offenbar eine Ebene höher in der VEVENT-Sektion, außerhalb von VALARM-Sektion, dokumentiert.
Die Zeitpunkte der schreibenden Zugriffe, also Erstellung und Erinnerungsbestätigung (nicht aber Erinnerung) werden indentisch in den Tags LAST-MODIFIED: und DTSTAMP: dokumentiert. Erst mit der Erinnerungsbestätigung wird hier der Tag X-MOZ-LASTACK: eingeführt, der dann den Zeitpunkt der Bestätigung identisch mit LAST-MODIFIED: und mit DTSTAMP: notiert.
LAST-MODIFIED:20220425T151636Z
DTSTAMP:20220425T151636Z
UID:787a80a1-57ad-4a85-8f81-1a747105bd20
SUMMARY:TestTermin mit Thunderbird
X-MOZ-LASTACK:20220425T151636Z
Ein Eintrag mit dem X-MOZ-SNOOZE-TIME: Tag wird geschrieben, wenn man Zurückstellen für statt Schließen wählt.
Wird das Erinnerungsfenster einfach mit dem X oben rechts im Fenster geschlossen (statt zu bestätigen oder eine Zurückstellung zu vereinbaren), wird in die Datei automatisch ein Eintrag mit dem X-MOZ-SNOOZE-TIME: Tag mit der neuen ErinnerungsZeit gemacht in meinem Fall automatisch 4 Minuten später, oder sonst wie
Die Systematik der Erinnerungsverwaltung bei eM-Client ist halbwegs gut in den gespeicherten ics-Dateien erkennbar.
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Alarm
X-MOZ-LASTACK:20220425T145400Z
ACKNOWLEDGED:20220425T145400Z
TRIGGER;RELATED=START:-PT5M
X-WR-ALARMUID:b86f7d76-f933-486e-a378-22ac0a3097fd
END:VALARM
Die Einträge X-MOZ-LASTACK und ACKNOWLEDGED: dokumentieren zunächst beide synchron den Zeitpunkt der Erstellung des Eintrages (nach UTC-Zeit), auch noch nach der Erinnerung. Sie werden nach der Terminbestätigung beide identisch auf einen Wert gesetzt, der mit 9999 anfängt. Diese könnte das Signal für eM-Client sein, dass die Erinnerung erledigt ist.
Der Eintrag X-WR-ALARMUID: wird sowohl bei der Erinnerung, als auch bei der Bestätigung immer neu anders gesetzt.
X-MOZ stammt gewiss nicht vom eM-Client. Der stammt vom Thunderbird.
Doch, der stammt vom eM-Client!
Probiere es einfach mal aus: Schaffe einen Termin mit Erinnerung in eM-Client und gucke Dir vor jeder Synchronisation die VALARM Sektion an. Du findest dann immer die 6 Tags
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:test
TRIGGER;RELATED=START:-PT5M
X-MOZ-LASTACK:20220422T130900Z
ACKNOWLEDGED:20220422T130900Z
X-WR-ALARMUID:b1576569-914a-405c-be19-04c6ef772b24
END:VALARMmit Thunderbird wird da lediglich diese Sektion ins ics-file geschrieben
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT5M
DESCRIPTION:TestMitThunderbird
END:VALARMDie RFC kenne ich, der Syntax ist auch denkbar einfach. Nur mir hilft sie erst einmal nicht:
Fakt scheint zu sein, dass Thunderbird genau wie der Server in der Sektion VALARM nur die Tags
ACTION:DISPLAY
DESCRIPTION: .....
TRIGGER;RELATED=START:-PT12H
setzt,
während eM-Client zusätzlich die Tags
X-MOZ-LASTACK:20220421T192900Z
ACKNOWLEDGED:20220421T192900Z
X-WR-ALARMUID:a9742507-091d-401b-8c50-af9b1e.....
führt, die aber nur lokal sind und nicht beim Server landen.
Vermutlich sind diese korrekt gesetzten zusätzlichen Tags der Grund, warum em-Client Alarm-technisch sauber arbeitet.
Wie allerdings Thunderbird die Bestätigungen der Alarme handhabt bleibt mir im Dunklen. Es scheint ein interner Algorithmus zu sein, der die Tags in der Hauptsektion VEVENT
LAST-MODIFIED:20220421T160945Z
DTSTAMP:20220421T161027Z
UID:0c47a6fa-f241-4a90-92d7-2e4d8....
DTSTART;TZID=Europe/Berlin:20220422T093000
DTEND;TZID=Europe/Berlin:20220422T100000
nach individueller Logik auswertet und danach entscheidet, ob ein Alarm ausgelöst wird.
Nur das kann ich nicht aus der RFC ableiten, sondern das ist wohl ein Java-Script innerhalb von Thunderbird, das zu analysieren, wohl meine Fähigkeiten+Zeit überfordert.
Etwas verwirrend ist, dass Em-Client dieselbe ICS-Datei des Servers das Ereignis mit geringfügig anderen Parametern listet, als Thunderbird.
So hat Em-Client in der VALARM Sektion der ics-Datei einen Parameter gesetzt Acknowledged:Zeitstempel , der in Thunderbird gar nicht auftaucht.
Aber auch weniger verdächtige Parameter sind unterschiedlich:
Bei Thunderbird für den Erinnerungszeitpunkt 7 Tage vor dem Ereignis TRIGGER;VALUE=DURATION:-PT10080M also (-10080Minuten =7 Tage) per Dauer relativ zu default, da keine REPEAT Wiederholung gesetzt wird also einmalig zwischen 7 Tage vorher und Termin die Erinnerung scharf geschaltet .... und sollte eigentlich danach inaktiv sein.
Bei Em-Client für den Erinnerungszeitpunkt TRIGGER;RELATED=START:-P7D also ohne Umschweife -7 Tage zum Termin
Hier wirkt Em-Client deutlich klarer, als Thunderbird.
Offenbar setzen die Clients die vom Server übertragenen Werte in einen Client-intern veränderteten Syntax um, der im lokalen ICS-File je nach Client gegenüber dem Original etwas verändert ist.
Also ... bei mir kommen die Erinnerungen immer wieder trotz deaktivierter Offline-Unterstützung.
Manchmal kann ich die dann einfach auf's Neue bestätigen und dann ist für eine Weile Ruhe, manchmal kommt ein Warnfenster
"Dieser Eintrag wurde kürzlich auf dem Server geändert. Das Übertragen der Änderungen wird die Änderungen, die auf dem Server gemacht wurden überschreiben" dazu die Buttons "Änderungen trotzdem übertragen" und "Änderungen verwerfen und neu laden"
D.h. die Bestätigung eines Termins wird als eine Änderung des Termins betrachtet.
Dies wird durch aktualisierte Zeitstempel hinter den Tags LAST-MODIFIED, X-MOZ-LASTACK, DTSTAMP und einer Eintragung einer User-Id UID: in der ics-Datei in Thunderbird definiert.
Diese wird dann per Push-Synchron in der Tat als Änderung an den Server übertragen und wird dort in der ics-Datei ebenfalls hinter den Tags LAST-MODIFIED und UID (also mit einer User-Id) hinterlegt.
Quintessenz: Thunderbird betrachtet Terminbestätigungen als normale Terminänderungen ....
Also:
Auch das Deaktivieren der Offline-Unterstützung plus beendet die Endloserinnerungsschleife bei mir nicht dauerhaft.
Mit dem eM-Client konfiguriert mit dem gleichen Kalenderserver klappt das Bestätigen der Termine sofort problemlos.
==> Daraus leite ich ab, dass offenbar der Server nur die Termine zur Verfügung stellt, dass für die Terminbestätigung jeder (Thunderbird)Client seine eigene, nur lokal gültige Buchführung hat, die auch nicht mit dem Server kommuniziert wird. Das hat ja auch eine Logik, wenn mehrere verschiedene Leute auf die gleiche Kalenderdatei zugreifen, soll ja auch jeder für sich erinnert werden und das Erinnern nicht aufhören, nur weil der Erste es zur Kenntnis genommen hat.
Teilt ihr diese Einschätzung der Abläufe?
Das bedeutet aber, dass die Endlos-Erinnerungsschleife rein gar nichts mit dem Server zu tun hat, sondern ganz lokales ein individuelles Problem ist.
Andererseits ist es merkwürdig, dass scheinbar nicht jeder Anwender das Problem hat. Schließlich gibt es wohl schon lange Beschwerden, aber scheinbar sind die nicht so zahlreich, dass ein Bug daraus abgeleitet würde.
Vielleicht ist es ein Problem, das nur mit eigenen persönlichen Kalendern, die man in der Cloud liegen hat, auftritt und das nur wenige das nutzen?
Ich habe lokale Kalender auf dem PC nicht ausprobiert.
• Thunderbird-Version (konkrete Versionsnummer) = Thunderbird 91.6.1
• Betriebssystem + Version = Windows 10 21H2
• Kontenart (POP / IMAP) = IMAP
• Postfachanbieter (z.B. GMX) = Universität
• Google-Kalender mit "Provider for Google-Calendar" (ja/nein) = Nein
• Google- oder sonstiger Kalender mit WebDAV / CalDAV (ja/nein/was genau) = sonstiger CalDAV Kalender auf Server Universität mit Horde-ServerSoftware
• Eingesetzte Antivirensoftware = nur Microsoft Defender, keine weiteren Antivirus
• Firewall (Betriebssystem-intern/Externe Software) =keine Firewall
Ich habe nach wie vor das Problem der Erinnerungen in Dauerschleife, die sich auch nach vielen Bestätigungen nicht befrieden lassen
Recht willkürlich poppen in unregelmäßigen Abständen immer wieder Erinnerungen längst bestätigter Termine auf, auch durchaus 2,3 auf einmal.
Ich habe zwei WindowsRechner gleicher Konfiguration mit Thunderbird, die beide auf die gleichen Kalender zugreifen, den einen verwende ich tagsüber, den anderen abends. Thunderbird läuft nicht gleichzeitig mit Zugriff auf die Kalender
Abhilfe schafft zur Zeit, wenn ich
==> die Offline-Unterstützung der Kalender deaktiviere, sprich an jedem einzelnen Kalender bei Eigenschaften das Häkchen deaktiviere.
==> beim gleichen Server die Verwendung eines anderen Clients (statt Lightning/Thunderbird in meinem Fall die Software em-Client.)
Offenbar liegt das Problem in Konflikten zwischen den Erinnerungsstatuseinträgen im Client-Lightning-Cache (Offline-Unterstützung) und den Serverdaten.
Hallo
Es gibt immer wieder Probleme mit den Kalender-Erinnerungen, die sich nicht befrieden lassen.
Kann man den Kalender zwingen, seine intern gespeicherten Erinnerungsstatus mit dem des Servers zu überschreiben, egal, ob er nun gerade meint, selbst aktueller zu sein (was nicht stimmt) ?
Es scheint auch etwas erratisch, welche längst vergangenen Termine er meint erinnern zu müssen.
Und .... falls es wie es scheint, kaum Möglichkeiten zu geben, dieses Verhalten zu stoppen, gibt es eine Empfehlung für ein alternatives Kalenderprogramm, das gut mit ICal arbeitet?
Thunderbird 91.6.1
Windows 10 21H2
IMAP
Universität Postfach
Kein Google Kalender
sonstiger CalDAV Kalender auf Server Universität Web-Horde-Server
nur Microsoft Defender, keine weiteren Antivirus
keine Firewall
Ja, das habe ich verstanden, und oben #3 steht ja das gewünschte schon länger.
Beta+Daily probiere ich nicht. es gibt ja schon das Problem mit der offiziellen Version
War ein Versehen, ich bitte um Entschuldigung
Sie haben das ja netterweise auch schon von dem Verzeichnis weg verlagert.
Nein, ich arbeite mit der aktuellesten Version, auf die Thunderbird automatisch aktualisiert.
Das Problem besteht schon länger.
Hat sich das Verfahren im Verlauf der Versionen denn geändert, wie man den Kalender zwingen kann, den Erinnerungsstatus vom Server zu akzeptieren, statt der eigenen Meinung?
Windows 10 21H2
Thunderbird 91.6.1
Firefox 97.0.1 64bit
nur Microsoft Defender, keine weiteren Antivirus
Windows 10 Pro, aktuellste Versionen von Windows, Thunderbird, Kalender per ICAL und Firefox
Hallo
Es gibt immer wieder Probleme mit den Kalender-Erinnerungen, die sich nicht befrieden lassen.
Kann man den Kalender zwingen, seine intern gespeicherten Erinnerungsstatus mit dem des Servers zu überschreiben, egal, ob er nun gerade meint, selbst aktueller zu sein (was nicht stimmt) ?
Es scheint auch etwas erratisch, welche längst vergangenen Termine er meint erinnern zu müssen.
Und .... falls es wie es scheint, kaum Möglichkeiten zu geben, dieses Verhalten zu stoppen, gibt es eine Empfehlung für ein alternatives Kalenderprogramm, das gut mit ICal arbeitet?
Hilfreich für mich (um Deinen Post zu verstehen) wäre, zu wissen, was dieser "X-lic" Fehler eigentlich aussagt und was ihn erzeugt.
Diese Frage wurde hier im Forum auch schon gestellt, aber in den Fällen, die ich gefunden habe, blieb sie unbeantwortet. Vom Text in X-Lic Fehlermeldung her könnte man meinen, es wurde ein nicht verstandener Wert für einen der Parameter übertragen ... warum überhaupt auch immer eine Änderung übertragen wurde.
Aber das ändert ja nichts an der vorhergehenden Frage:
> Wird eine Terminbestätigung als Änderung mit einem Zeitstempel gehandhabt?
> Warum tritt dieser X-Lic Fehler nicht auf, wenn ich tatsächlich eine Änderung durchführe, nur wenn ich eine Erinnerung bestätige
Darum meine Interpretation: Eine Terminbestätigung korrekt wird auf dem Server eingetragen. Diese Eintragung wird auch vom Server akzeptiert und offenbar mit Zeitstempel gespeichert. Die Thunderbird-Kalender-App scheint aber ein Problem zu haben, diese Änderung als eine bereits erfolgte Bestätigung eines Termins zu akzeptieren und keine erneute Bestätigung des Termins entgegen zu nehmen.
Von daher folge ich dem ersten Teil Deiner Aussage: Ich denk auch, das Problem liegt bei der Thunderbird-App und nicht beim Server (zumal ich mit dem Kalender und einem Android Smartphone dazwischen völlig problemlos interagiere).
Meine fachlich inkompetente Theorie wäre, dass das Auslösen der Erinnerung-Nachricht, dass diese Aktion auf dem Server eingetragen wird ..... und damit einen Zeitstempel hinterlegt und damit eine Änderung stattgefunden hat.
Ich vermute einmal, dass
1==> "Änderungen trotzdem übertragen"
2==> "Änderungen verwerfen und neu laden"
die Bedeutung sein könnte:
1==> "Auftrag an fernen ServerSoftware: Mit meiner aktuellen Bestätigung die alte Bestätigung überschreiben"
2==> "Auftrag an lokalen ThunderbirdKalender: Einträge vom Server übernehmen und meine gerade erfolgte Bestätigung löschen"
Im Fall ==>2 bleibt mir dann allerdings unklar, warum meine lokale Thunderbird-Kalender-App dann nicht lokal umsetzt, dass der Termin schon bestätigt ist. Denn die Meldung zeigt ja, dass die App ganz offenbar wahrgenommen hat, dass da eine ältere Bestätigung des Termins auf dem Server bereitsteht.
Was besagt eigentlich genau die Warnung: "Dieser Eintrag wurde kürzlich auf dem Server geändert. Das Übertragen der Änderungen wird die Änderungen, die auf dem Server gemacht wurden überschreiben."
Und was täten die beiden Optionen:
==> "Änderungen trotzdem übertragen" oder
==> "Änderungen verwerfen und neu laden"
Was sind " ... die Änderungen, die auf dem Server gemacht wurden ... " ? Wenn ich auf PC1 arbeite, dann vermutlich ja die Bestätigungen von dem anderen (PC2) vom Vorabend.
Wenn ich jetzt "Änderungen trotzdem übertragen" wähle, dann wird vermutlich die identische Bestätigung mit neuem Zeitstempel zum Server übertragen. Der neue Zeitstempel irritiert dann wieder den anderen PC2.
Wenn ich jetzt "Änderungen verwerfen und neu laden" wähle, dann müßte doch eigentlich die Bestätigung vom Vorabend vom anderen PC2 geladen werden und Ruhe sein mit den Erinnerungen, Oder? Aber da ist keine Ruhe !
Thunderbird 91.5.1
Windows 10 Professional 21H1
IMAP
Uni mit Server Webhorde-Software-Paket
kein Google Kalender
Uni mit Server Webhorde-Software-Paket : CalDAV
Windows Virenschutz
Keine Firewall
Keine Plugins
Ich habe ein Problem mit immer wiederkehrenden Erinnerungen an Termine, die ich längst bestätigt hatte.
Ich nutze einen zentralen CalDAV Kalenderserver WebHorde, der von der Universität betrieben wird.
Ich nutze diese Kalender mit 2 PCs (identische Versionen von Windows und von Thunderbird).
Wenn ich eine Terminerinnerung mit einem PC bestätigt hatte und abends Thunderbird auf dem anderen PC nutze, werde ich erneut an die Termine erinnert, die ich auf dem ersten PC morgens schon bestätigt hatte.
Wenn ich dann am nächsten Tag morgends wieder am ersten PC sitze, erinnert Thunderbird erneut an diese Termine, die ich den morgen vorher mit diesem ersten PC und danach am abend auch mit dem zweiten PC bestätigt hatte.
Gelegentlich, aber nur in Einzelfällen bekomme ich dann von Thunderbird diese Warnmeldung: "Dieser Eintrag wurde kürzlich auf dem Server geändert. Das Übertragen der Änderungen wird die Änderungen, die auf dem Server gemacht wurden überschreiben."
Dann werden mir zwei Optionen zur Wahl gestellt: "Änderungen trotzdem übertragen" oder "Änderungen verwerfen und neu laden"
Die einzige "Änderung" die ich vorgenommen hatte, war die Terminerinnerung zu bestätigen.
Was ist da zu tun? Das Verhalten ist nicht neu, sondern begleitet mich schon lange. Solange ich nur einen PC mit Thunderbird nutze, läuft alles wunderbar, wenn ein zweiter PC ins Spiel kommt, entsteht diese Endlosschleife von Erinnerungen.
So, nun 18h später mit noch geöffnetem Thunderbird ... sind die Ordner in Thunderbird allesamt aufgetaucht. Ich habe in der Zwischenzeit NICHTS gemacht, der Rechner war in Energiesparstellung. Während der ersten Stunde hatte ich ja noch in den Einstellungen gesucht, ob ich irgendetwas aktivieren müßte oder ähnliches. Während der Zeit wurden die Ordner nicht erstellt, waren nur in der Liste der abonnierten Ordner aufgeführt, aber nicht in der Struktur angezeigter Ordner.
Zum Volumen: Dieser Test erfolgte mit 583 emails in einem Ordner mit 13 Unterordnern, die allesamt in der Abbonniert-Liste mit einem Häkchen versehen waren. Der Netz-Anschluß sind etwas mehr als reale 50Mbit/s. Das sollte also kein Flaschenhals sein.
Ich frage mich, was für Timing diese Prozesse haben.