Beiträge von Hanser

ggbsde

Zitat von ggbsde

Zitat von Hanser

Dann ist das wohl diese Passage in der msf-Datei:

Nicht wirklich. Das sind nur Namen, mit denen TB arbeitet. Die entscheidende Flag ist nur ein gesetztes Bit in einem Wert, der an anderer Stelle steht.

Die .nsf Datei ist eine Datenbank. Nur weil sie aus lesbaren Text besteht heißt das nicht, das man sie 'lesen' kann. Man versucst ja auch nicht, eine sqlite Datenbank ohne spezielle App zu interpretieren.

Danke, also nochmal komplizierter.

OK, wenn man es eh nicht bearbeiten kann/sollte, egal, Löschen der msf-Datei hilft

Zitat von Bastler

Zitat von Hanser

Ich habe z.B. die beiden gleichnamigen Dateien mit und ohne msf-Endung in das Lokale Ordner Verzeichnis kopiert.

Solche Operationen auf Dateiebene immer bei beendetem TB und Dateien mit .msf stets auslassen.
Die werden in neuer Umgebung vom TB selbst erstellt. Die endungslosen mbox-Dateien enthalten die Mails.

Kopiere beispielhaft eine Inbox, INBOX, oder wie auch immer, zu Local Folders und benenne die Alter-Eingang.
(Am besten nur Bindestrich und Unterstrich als optische Trenner verwenden. Leerzeichen Umlaute u.ä. meiden.)

Der Tipp, die msf-Datei einfach zu löschen, ist ein einfacher Weg.
Vielen Dank,

Zitat von ggbsde

Zitat von Hanser

Ind der .msf Datei ist ein Flag 'Posteingang' gesetzt.

Ah, OK, vielen Dank für den Tipp. Dann verstehe ich, wie Thunderbird das macht.
Erstaunlich nur, dass diese Flags erst 2000 Zeilen unterhalb des Dateianfangs in der msf-Datei auftauchen.

Dann ist das wohl diese Passage in der msf-Datei:

<(8F5=8d)(867=12a14d65)(8F7=159240f)(8FD=5923f3dd)(86A=1004)(86B=Inbox)
(86C=Posteingang)(90D=1495542837)(86E=$121)(86F
={"threadCol":{"visible":true,"ordinal":"1"},"flaggedCol":{"visible":true,\
"ordinal":"3"},"attachmentCol":{"visible":true,"ordinal":"5"},"subjectCol":{"v\
isible":true,"ordinal":"7"},"unreadButtonColHeader":{"visible":true,"ordinal":\
"9"},"senderCol":{"visible":false,"ordinal":"11"},"recipientCol":{"visible":fa\
lse,"ordinal":"15"},"correspondentCol":{"visible":true,"ordinal":"13"},"junkSt\
atusCol":{"visible":true,"ordinal":"17"},"receivedCol":{"visible":false,"ordin\
al":"19"},"dateCol":{"visible":true,"ordinal":"39"},"statusCol":{"visible":fal\
se,"ordinal":"21"},"sizeCol":{"visible":false,"ordinal":"23"},"tagsCol":{"visi\
ble":false,"ordinal":"25"},"accountCol":{"visible":false,"ordinal":"27"},"prio\
rityCol":{"visible":false,"ordinal":"29"},"unreadCol":{"visible":false,"ordina\
l":"31"},"totalCol":{"visible":false,"ordinal":"33"},"locationCol":{"visible":\
false,"ordinal":"35"},"idCol":{"visible":false,"ordinal":"37"}})(8C5=202d3)

Sorry, so ganz schlau bin ich noch nicht daraus geworden. Vielleicht habe ich aber auch immer noch zu allgemein gefragt:

Ich habe z.B. die beiden gleichnamigen Dateien mit und ohne msf-Endung in das Lokale Ordner Verzeichnis kopiert. Diese beiden Dateien waren bei einer früheren Installation, als sie in einer POP3 Umgebung angelegt wurden, der Posteingang.
Ich habe dieses Dateienpaar nun, mit von mir substantiell veränderten, als aussagekräftig erachteten, Dateinamen, in das Lokale Ordner Verzeichnis kopiert. Nun zeigt mir Thunderbird diesen Ordner freundlicherweise auch an .... allerdings unter dem Namen Posteingang, und leider nicht mit dem von mir veränderten Namen.

Bei anderen Dateipaaren, die früher nie Posteingang oder Postausgang waren, dagegen, wird der von mir veränderte Dateiname wunschgemäß für das Icon unter Lokale Dateien verwendet.

Ich frage mich, was macht für Thunderbird den Unterschied im Umgang mit diesen beiden Dateitypen, die unter Lokale Ordner angezeigt werden. Bzw. eigentlich ist am Ende die Frage, wie bringe ich Thunderbird dazu, den von mir verwendeten Dateinamen auch für das Icon unter Lokale Ordner zu verwenden.

• Version 128.6.0
• Windows 10
• IMAP und POP
• GMX und Universität
• Windows Defender
• Keine Firewall
• Kein Router

Frage: An welcher Stelle erkennt Thunderbird, dass eine Datei mit emails, die auf der Systemfestplatte unter LocalFolders abgelegt ist, irgendwann einmal ein Posteingang bzw. ein Postausgang war, wenn der Dateiname vollkommen anders ist. Bei anderen Dateien, die nicht Posteingang oder Ausgang waren, wird der Dateiname übernommen im Thunderbird Programm, nur nicht für Dateien, die früher die Funktion Eingang bzw. Ausgang hatten.

VG Hanser

Zitat von Veteran

Zitat von Hanser

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.

Zitat

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:VALARM

mit Thunderbird wird da lediglich diese Sektion ins ics-file geschrieben

BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT5M
DESCRIPTION:TestMitThunderbird
END:VALARM

Die 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?

Susi to visit

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).