Beiträge von cschla

  • Dateiendung verliert einen Buchstaben beim Speichern der Anlage

    Zitat von Veteran

    Bliebe noch zu klären, ob das auch unter Linux/Mac passiert, oder ob nicht doch Windows seine Finger im Spiel hat. Für TB 78.14.0 unter Linux kann ich sagen, daß hier nichts automatisch verändert oder angefügt wird – egal welchen Namen ich dem Anhang beim Speichern gebe.

    Hi,

    kleiner Nachtrag: Linux verhält sich insofern anders als dass dieses bei beiden Speichervarianten welche ich benannt habe immer die Endung verwirft wenn man den Dateinamen ohne Endung eingibt. Gibt man als Dateiname "bild" ein, so wird auch nur eine Datei "bild" erstellt.

    Da Linux nicht so mit den Dateiendungen arbeitet wie Windows könnte entweder TB in Windows ein anderes Verhalten haben (tippe fast darauf) oder wirklich Windows irgendwo beteiligt sein. So ein Verhalten (erster Buchstabe der Endung wird entfernt) habe ich aber noch nie gesehen, daher tippe ich fast auf irgendeine String Bereinigung welche fälschlicherweise anstatt des letzten Punkts ein Zeichen zu viel schluckt wenn die Dateiendung im Code festgestellt werden soll.

    Grüße

    cschla

  • Dateiendung verliert einen Buchstaben beim Speichern der Anlage

    Hallo,

    ich arbeite mit Thunderbird 91.10.0 und seit einigen Minor Versions ist mir auf mehreren Windows 10 Geräten folgendes Verhalten aufgefallen:

    Voraussetzung ist, dass in den TB Einstellungen gewählt wurde, dass man immer gefragt werden möchte was bei einem Doppelklick auf eine Anlage passieren soll (Öffnen oder Speichern).

    Wenn man eine Mail erhält welche einen Dateianhang besitzt so kann man auf zwei wegen die Datei speichern - entweder per rechter Maustaste auf den Dateieintrag bei den Anhängen -> "Speichern..." oder per Doppelklick und dann Auswahl "Datei speichern".

    Seit einigen Versionen unterscheiden sich die daraufhin gezeigten Dialoge danach. Bei rechter Maustaste -> Speichern... wird z.B. als "Dateityp" "jpg-Datei (*.jpg)" angezeigt. Hingegen bei Doppelklick und Auswahl "Datei speichern" "JPEG Image (*jpg)".

    Die Problematik tritt auf, wenn der Benutzer den kompletten Dateinamen samt Dateiendung im Feld "Dateiname" überschreibt und keine Dateiendung mehr angibt (z.B. aus dem automatisch eingetragenen Dateinamen "logo.jpg" macht der Benutzer "bild" und verlässt sich darauf, dass Windows die korrekte Dateiendung anhängt). Tatsächlich wird auch eine Dateiendung angehängt, die gespeicherte Datei heißt jedoch "bild.pg" und nicht "bild.jpg".

    Das Verhalten tritt nicht auf, wenn man eine Anlage per rechter Maustaste speichert und es wird immer der erste Buchstabe der Dateierweiterung entfernt, egal ob .jpg, .pdf, .txt usw.

    Ich habe zuerst auf einen Fehler in der Windows Registry getippt, aber da immer der erste Buchstabe gelöscht wird und auch die Schreibweise unter "Dateityp" etwas komisch ist ("*jpg" statt "*.jpg") habe ich irgendwie den Verdacht, dass dies nichts mit Windows selbst zu tun hat...

    Hätte vielleicht jemand die Möglichkeit dieses Szenario bei sich nachzustellen damit ich ausschließen kann, dass es sich nur um ein Problem auf meinen Geräten handelt?

    Gruß

    cschla

  • Wieder mal doppelte Nachrichten

    Hallo,

    wir hatten ein ähnliches Problem bei uns, wobei ich aus der Beschreibung nicht ganz direkt ableiten kann ob es das selbe Problem ist:

    Hatte man bei uns z.B. eine ungelesene Mail in einem Postfach und wechselte man dann schnell zwischen Ordnern hin und her, so wurde plötzlich diese ungelesene Mail in einem Ordner angezeigt wo sie nicht hingehörte.

    Die Mail selbst konnte man nicht öffnen, nur der Eintrag in der Liste der Mails war sichtbar.

    Nach langer Suche kam ich darauf, dass in einer alten TB Version zur Behebung eines anderen Problems der Parameter

    Code
    max_cached_connections = 1

    gesetzt wurde.

    Das hat zur Folge, dass TB nicht parallel Verbindungen zum Server aufbauen kann und daher so ein komisches Verhalten erzwungen wird (prinzipiell müsste man das vielleicht im Code abfangen, aber es ist einfach eine unwahrscheinliche Konfiguration - Default ist glaube ich 10).

    Wäre zwar ein Zufall wenn du die selbe Konfiguration vorfindest, aber wer weiß :).

  • Probleme beim Öffnen von angehängten eml Dateien mit Base64 Kodierung

    Hallo Feuerdrache,

    vielen Dank, aber leider handelt es sich nicht um die winmail.dat, es geht tatsächlich nur um eml Dateien. Dabei ist es auch so, dass ich diese eml Dateien selbst erstellen kann und sie mir per Thunderbird mailen kann - dann funktioniert alles korrekt. Wenn ich dann aber einen Webmailer verwende, dann bekomme ich eine base64 kodierte Datei...

    Sieht natürlich tatsächlich so aus wie mrb es beschrieben hat (alte Webmailer usw.) aber eben frage ich mich ob das nicht eventuell durch Thunderbird "toleriert" werden könnte und die base64 kodierte eml einfach dekodiert werden könnte... :)

    bg cschla

  • Probleme beim Öffnen von angehängten eml Dateien mit Base64 Kodierung

    Hallo,

    vielen Dank für die Rückmeldung!

    Demnach ist diese Form der Deklarierung tatsächlich komplett falsch oder gibt es da verschiedene RFCs die es vielleicht auch mal erlauben?

    Ich frage da bei einer Online Recherche dieses Problem auch von Benutzern beschrieben wurde, welche Mails von Outlook bekommen haben. Ich weiß, dass Outlook sich (speziell früher) nicht unbedingt um Standards geschert hat, aber vielleicht tritt dieses Problem doch öfter auf?

    Genau deinen Ansatz habe ich auch so versucht und bin eben dadurch zum Ergebnis gekommen, dass base64 nicht korrekt sein kann. Stutzig machte mich nur dann die Möglichkeit die Mail "als neu bearbeiten" zu können, wo sich das angehängte eml dann öffnen lässt. Prinzipiell scheint Thunderbird also in gewissen Momenten die dekodierung selbst vorzunehmen - oder?

    bg cschla

  • Fehlermeldung bei Anhängen

    Hallo,

    vielen Dank für eure Antworten.

    Zumindest im meinem Fall kann ich das dazwischenfunken von einer Antivirensoftware definitiv ausschließen (vorhanden, aber durch mich administriert).

    Die Sache mit dem Junkprotokoll und der Zuordnung der Dateiendungen / mimetypes.rdf sind gute Ansätze, treffen aber zumindest in meinem Fall auch nicht zu...

    Hingegen ist die Sache mit der Deklarierung für mich eher der Übeltäter, aber hierzu gibt es einen eigenen Thread hier von mir, daher möchte ich Doppelgleisigkeiten vermeiden und zumindest mein Problem hier nicht weiter ausführen - dies wäre eben mein Ansatz für miri89 gewesen welchen ich ansehen wollte.

    Vielleicht warten wir auf die Antwort von miri89 um ihr Problem anzusehen - eventuell ergibt sich dann auch eine Parallele zu meinem.

    bg cschla

  • Fehlermeldung bei Anhängen

    Hallo ThunderSparrow,

    zu 1: Zumindest bei meinem Problem sind die Dateigrößen korrekt, nicht nur das, ich weiß sogar dass der Inhalt darin steht (siehe auch den Thread Hier von mir.

    zu 2: in meinem konkreten Fall geht es nicht um Bilddateien, das kann vielleicht mir89 beantworten.

    zu 3: bei mir nicht so konfiguriert (guter Ansatz aber)

    zu 5: hab bereits die neuste Version im Einsatz.

    Das was ich unter Verdacht hätte und mir im Quellcode ansehen wollte ist das Verhalten von Thunderbird wenn Dateien mit einer bestimmten Kodierung und einem (bei miri89 eventuell nicht passenden Content-Type) übermittelt werden... Kann aber auch daneben liegen ;).

    bg cschla

  • Probleme beim Öffnen von angehängten eml Dateien mit Base64 Kodierung

    • Programm + Version: Thunderbird 52.3.0
    • Betriebssystem + Version: alle
    • Kontenart (POP / IMAP): IMAP
    • Postfachanbieter (z.B. GMX): eigener Server

    Hallo,

    ich bin aktuell einem Problem auf der Spur, welches ich auf allen TB Installationen bei uns und auch z.B. auf Linux Maschinen reproduzieren kann. Die Situation wurde bereits öfters im Forum beschrieben, eine konkrete Lösung habe ich aber noch nicht gefunden. Würde euch bitten mir bei der Ermittlung des Fehlers unter die Arme zu greifen, damit man dann vielleicht einen Bug Report öffnen könnte welcher genügend Infos bereithält.

    Problem:

    In gewissen Situationen (z.B. von gewissen E-Mail Clients und Webclients) erhalte ich E-Mails, welche als Dateianhang eine .eml Datei besitzen. Diese Dateien lassen sich normalerweise per Klick auf den Anhang ohne Probleme öffnen und werden durch Thunderbird auch vorzeitig "entpackt" wenn "Ansicht -> Anhänge eingebunden anzeigen" aktiviert ist. In gewissen Situationen lassen sich die Dateien aber nicht öffnen, es wird die Meldung

    "Dieser Anhang scheint keinen Inhalt zu haben.

    Bitte klären Sie dies mit dem Absender.

    Firewall- oder Antivirenprogramme in Firmen sind häufig der Grund für gelöschte Anhänge."

    angezeigt, obwohl die Anlage sicher nicht leer ist und auch eine Dateigröße neben dem Dateinamen bei den Anhängen stehen hat.

    Habe diese Fälle genauer angesehen und bemerkt, dass in diesem Moment im Mail Quelltext die angehängte .eml Datei mit diesem Header in die empfangene Mail eingebunden ist:

    Code
    Content-Type: message/rfc822
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="modifiziert.EML"

    Danach folgt dann ein Base64 kodierter Block.

    Nun habe ich versucht in den RFCs nachzusehen und zumindest laut RFC 2046 ist für angehängte Mails zwar der Content-Type message/RFC822 vorgesehen, aber als Encoding darf nicht base64 angewendet werden. Ändere ich den Header der angehängten Datei um indem ich Content-Transfer-Encoding auf 8bit stelle und dann noch den Inhalt der .eml in Klartext einbaue, öffnet Thunderbird die angehängte .eml ohne Problem.

    Auch lässt sich die eml Datei öffnen indem man über das Menü "Nachricht -> Als neu bearbeiten" auswählt - dort kann man dann per Doppelklick auf die angehängte eml Datei zugreifen und sie öffnen.

    Nun möchte ich mich aber nicht einfach auf das RFC berufen und behaupten TB macht alles richtig - immerhin ist dies eher ein Problem welches Thunderbird der Kompatibilität wegen vielleicht anzugehen ist (Aussagen wie "bei meinem Outlook klappt das aber").

    Details:

    Ich habe daher über die Debugfunktion von TB die zuständige Funktion in der Datei msgHdrViewOverlay.js ausfindig gemacht (denke ich) und habe den Ablauf verfolgt. Es scheint so als würde Thunderbird nicht mit dieser Situation umgehen können (schon die Bytelänge des Attachments wird dort in Zeile 1944 als 0 erkannt statt die richtige Länge zurück zu geben...

    Ist das nun tatsächlich eine Sache die Thunderbird nicht zu verarbeiten schafft (mangelns Dekodierung von base64 Inhalten) oder kommt das aus einem anderen Grund?

    Vielleicht könntet ihr versuchen diesen Fall nachzuvollziehen? Ich hänge auch ein Beispiel an, welches bei mir das Problem aufweist.

    bg cschla

  • CalDAV Kalender verschwunden (weg) - Ursachenforschung

    Hallo,

    ok, TB legt jedes mal beim Erstellen eines Kalenders (oder beim wieder Eintragen des Kalenders nachdem er verloren ging) einen neuen Eintrag an. Demnach funktioniert das scheinbar zumindest...

    Hast du eventuell irgendwelche Addons installiert, welche mit dem Kalender zu tun haben?

    Check vielleicht auch mal den Eintrag calendar.list.sortOrder - ich weiß nicht ob der damit zu tun haben könnte, aber dort müssten alle IDs (also jene welche nach "calendar.registry." und vor ".uri" stehen aufgelistet sein. Ansonsten mal probehalber dort eine der IDs eintragen und TB neu starten.

    Schon komisch die Sache, am ehesten wäre vielleicht noch in der Fehlerkonsole (STRG+Umschalt+J) nachzusehen ob dort vielleicht was drinnen steht - bringt aber nur was, wenn der Kalender wieder verschwindet und man vielleicht in etwa weiß wann es passiert ist.

    Sollte Lightning beim laden (also z.B. beim starten von TB) Probleme haben die Kalender aus der Konfiguration zu lesen, sieht man vielleicht auch in der Fehlerkonsole bei jedem Programmstart etwas dazu...

    Gruß

    cschla

  • CalDAV Kalender verschwunden (weg) - Ursachenforschung

    Hallo Terminus,

    hmm, also du meinst, dass du zwar in Lightning normal keinen GMX Eintrag mehr siehst, aber unter calendar.registry siehst du den selben Kalender 4 mal?

    Such mal bitte nach "calendar.registry.*.uri" - kommt da dann 4 mal exakt die selbe Url raus, aber mit verschiedenen "Einstellungsnamen" vorne?

    Vielleicht machst du einen Screenshot von den uri's und postest diesen mit? Streich eventuell die persönlichen Infos - sollte was darin sichtbar sein?

    Gruß

    cschla

  • Lightning & Nextcloud: bei jeder Kalender Synchronisation wird Erinnerungsfenster angezeigt

    Hallo Heyfisch,

    danke für deine Antwort - habe inzwischen etwas zum Thema gefunden, auch wenn die definitive Lösung noch aussteht:

    Die Situation scheint jene zu sein (zumindest bei meiner Installation von NC), dass es zwei CalDAV Adressen gibt - jene mit /caldav/ darin (so wie es bei OwnCloud üblich ist) und jene mit /dav/ (was Nextcloud zu verwenden scheint). Es scheint so, als greift die /caldav/ Adresse auf ein anderes Sabre Backend zu als die /dav/ Adresse (so mutmaße ich jetzt mal). Verwende ich die /caldav/ Url, dann verhält sich Thunderbird wieder so wie früher (oder fast, aber das kann mich auch nur täuschen).

    Habe ein wenig im Source nachgesehen (Opensource sei dank) und glaube erkannt zu haben, dass bei Verwendung von der Adresse mit /dav/ das SabreDAV Backend Thunderbird mitteilt, dass der Server Webdav Sync unterstützt. Das veranlasst Thunderbird zu einem anderen vorgehen beim Synchronisieren - was auch gut wäre. Aber eben in dieser Situation scheint TB jedes mal zu vergessen, dass das Erinnerungsfenster bereits für die Termine gezeigt wurde...

    Vorerst wäre somit eher - wenn das bei dir klappt - auf die alte URL zurückzugreifen, dann syncht TB aber anhand des CalDAV ctag, was mehr Traffic zur Folge hat.

    Gruß cschla

  • CalDAV Kalender verschwunden (weg) - Ursachenforschung

    Hallo,

    edvoldi Sorry, aber ich erkenne die Beta Version nicht - ich arbeite mit exakt der selben Konstellation und habe ja bekanntlich auch Probleme mit dem Kalender. Aber die Lightning Version 4.7.8 sollte doch eigentlich die aktuellste sein, oder? Zumindest habe ich das immer so auf dieser Seite https://developer.mozilla.org/en-US/docs/Moz…lendar_Versions interpretiert.

    Terminus Nur nochmal fürs Verständnis - eigentlich hat dein Problem nichts mit dem Kennwortspeicher zu tun, oder? Immerhin siehst du ja dort den Eintrag noch, aber die Kalender selbst nicht mehr, korrekt?

    Hast du mal versucht unter about:config nach zu sehen ob dort die Einträge auch nicht mehr vorhanden sind? Praktisch unter Einstellungen -> Erweitert -> Allgemein -> Konfiguration bearbeiten und dann nach calendar.registry suchen.

    bg cschla

  • Lightning & Nextcloud: bei jeder Kalender Synchronisation wird Erinnerungsfenster angezeigt

    • Thunderbird-Version: 45.8.0
    • Lightning-Version: 4.7.8
    • Betriebssystem + Version: Windows 7

    Hallo,

    wir nutzen bereits seit längerer Zeit Thunderbird / Lightning um unsere Termine zu verwalten. Als Kalender Backend kam bis jetzt immer OwnCloud zum Einsatz, was gut funktionierte. Aus diversen Gründen sind wir nun auf Nextcloud in Version 10 umgestiegen (konnten aus einem anderen Grund noch nicht auf 11 wechseln) und haben die gesamte CalDAV Kalender dorthin migriert.

    Prinzipiell sind alle Kalender erreichbar und funktionieren, aber es kommt zu einem Problem, welches ich auch bereits bei OwnCloud mal beobachtet habe und welches nun aber immer auftritt:

    Die Kalender lassen wir nicht Cachen (also nicht Offline verfügbar gemacht) und bei jedem Sync mit dem Server (unabhängig ob automatisch oder manuell) wird, sofern im Erinnerungsfenster von Thunderbird noch offene Termine stehen, dieses Fenster immer wieder in den Vordergrund gebracht. Dieses Verhalten ist seit der Verwendung von Nextcloud neu - bei OwnCloud trat dies nur dann auf, wenn wir die Kalender offline verfügbar machten.

    Das Problem ist daher sehr nervend, da bei sehr kurzen Aktualisierungsraten der Kalender das Fenster sehr oft in den Vordergrund gebracht wird, bis man endlich alle offenen Termine im Reminder Fenster geschlossen hat (aber manchmal dauert das halt ein wenig).

    Ich wollte nachfragen ob vielleicht auch sonst noch jemand dieses Phänomen kennt bzw. vielleicht sogar eine Lösung parat hätte? Ich habe bereits mit den Debug Optionen in der Fehlerkonsole nach einem neuen Verhalten gesucht - das einzige was mir aufgefallen ist, ist dass nun bei jeder Synchronisierung diese Einträge aufscheinen, welche mir früher nicht aufgefallen sind:

    CalDAV: webdav-sync Token: http://sabre.io/ns/sync/25

    CalDAV: webdav-sync Token: http://sabre.io/ns/sync/2098

    CalDAV: New webdav-sync Token: http://sabre.io/ns/sync/2098

    aChangeLogListener=null calendarURI=https://adresse/sub/remote.php/dav/calendars/user/kalender/ iscached=false this.mQueuedQueries.length=

    CalDAV: New webdav-sync Token: http://sabre.io/ns/sync/25

    aChangeLogListener=null

    calendarURI=https://adresse/sub/remote.php/dav/calendars/user/kalender2/iscached=falsethis.mQueuedQueries.length=0

    Habe mich zwar auf der Sabre Seite in die Thematik dieser neuen Tokens (webdav-sync) etwas eingelesen, aber ich bin mir gar nicht sicher ob dies auch wirklich das Problem ist. Irgendwie scheint mir Lightning einfach zu vergessen, dass die Erinnerung des Termins bereits einmal angezeigt wurde - vielleicht weil Nextcloud irgend einen Zeitstempel o.Ä. ändert?

    Wäre sehr froh wenn mir jemand weiterhelfen könnte!

    bg cschla