Posts by MysticJay

Das Problem erneut berichtet als: https://bugzilla.mozilla.org/show_bug.cgi?id=1886044

Moin,

ich habe das Thema mit WTNET in den letzten beiden Wochen intensiv diskutiert und ausgetestet. Es wurde sogar in-House reproduziert mit einer ganz frischen TB-Installation.

Zwar liegen mir die Protokolle und die Config (Postfix?) von WTNET nicht vor, aber es sieht nach wie vor danach aus, als ob der "Schwarze Peter" bei TB liegt.

Bei mir funktioniert der Versand nur wie folgt:
Mit TB Offline gehen, Mail dann mit "später senden" in den Ausgangskorb legen, wieder online gehen. Nach ein oder ein paar mehr Versuchen geht die Mail dann raus.

Mit Verweis auf diesen Beitrag: https://bugzilla.mozilla.org/show_bug.cgi?id=1870909

vermute ich ein Timing Issue im TLS Handling, was erklärt, warum es mal geht und mal nicht.

M.

dies ist mein Code, der mit V 91.7.0 arbeitet. das deckt sich schon ziemlich mit dem was Calendar Tweaks erzeugte...
der rechte Balken entspricht der Kalender-Farbe. Beim Fr. 15:00 Termin ist z.B. keine Kategorie hinterlegt (vergleiche Do. 15:00, gleicher Kalender)

.calendar-category-box{
    margin:0 0 0 -200px!important;
    min-width: 188px !important;
}
.alarm-icons-box,.reminder-icon{
    margin:0 -40px 0 0!important;
}
.event-name-label,.item-time-label,.alarm-icons-box{
    z-index:100000!important;
}
.calendar-item-flex{
    padding:0!important;
}
.calendar-month-day-box-list-item{
    margin:0!important;
}
.calendar-color-box{
    border:none!important;
}

The content cannot be displayed because it is no longer available.

Dass CT nicht mehr weiterentwickelt wird ist schade, aber wohl nicht zu ändern.

Gibt es über StyleSheets eine Möglichkeit die Farbe von Kalender und Kategorie zu vertauschen?

M.

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

• Thunderbird-Version (konkrete Versionsnummer 78.10.0
• Wurde gerade auf eine neue Versionsreihe aktualisiert (alte und neue Version angeben): nein
• Betriebssystem + Version: Win10.20H2
• Kontenart (POP / IMAP): pop
• Postfach-Anbieter (z.B. GMX): postfix
• Eingesetzte Antiviren-Software:
• Firewall (Betriebssystem-intern/Externe Software):
• Router-Modellbezeichnung (bei Sende-Problemen):

Moin,

in meinem Posteingang befinden sich mehere 100 Mails. Markiere ich eine über das Flammensymbol in der Liste, wird die Mail korrekt als JUNK markiert und nach JUNK verschoben. Danach springt der Marker auf eine beliebige andere Mail in Folder.
Bisher habe ich kein Muster erkennen können. Ändern kann man das nur, wenn man als erstes eine Mail auswält (aktiviert), die man nicht als JUNK markieren will.

Bug, Feature oder fehlende Einstellung?

M.

Quote from Onuseit

Ich frage mich allerdings immer noch, warum die .ics-Dateien nicht angenommen wurden.

Ich hab schon häufiger Kalender zwischen Systemen hin und her geschoben. Zu Problemen kommt es häufig!

In der Regel geht es dann aber nicht um einen defekten Datensatz sondern um falsche Kodierungen.
Viele Kalendereinträge haben z.b. Zeilenumbrüche, die dann falsch interpretiert werden.
Auch das Datum von Einträgen ist häufig nicht korrekt dargestellt.

Aber wenn es dich interessiert, kannst Du die Daten auch in einen neuen Kalender importieren.
Die ICS ist nur eine Textdatei Nimm dabei nur die Hälfte der Datei oder einzelne Jahrgänge.
Geht dabei wieder was schief, kannst Du noch kleinere Teile diees Jahrgangs verwenden.
Normalerweise hast Du den fraglichen Eintrag in wenigen Minuten identifiziert.

Good Luck!

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

• Thunderbird-Version (konkrete Versionsnummer 68.12.0 (32-Bit)
• Lightning-Version: n/a
• Betriebssystem + Version: W10.2004
• Google-Kalender mit "Provider for Google-Calendar" (ja/nein): nein
• Google- oder sonstiger Kalender mit WebDAV / CalDAV (ja/nein/was genau): ja, NextCloud
• Eingesetzte Antivirensoftware: F-Secure
• Firewall (Betriebssystem-intern/Externe Software): Windows Defender

Ist der NAS-Server, auf dem NextCloud installiert ist, erreichbar (über LAN oder VPN) ist alles OK.
Bei Nichterreichbarkeit sollte dann doch die Offline Unterstützung greifen.

Tatsächlich wird der Kalender aber nach wenigen Sekunden deaktiviert.
Reaktiviert man ihn manuell, sind die Termine kurz sichtbar, dann wird wieder deaktiviert.
In dieser Situation ist der Server nicht anpingbar (erwartungsgemäß).

Ich hab den Server jetzt in der No-Proxy-Liste eingetragen. Erst jetzt geht die Offline-Unterstützung.

Die Routinen sollten dahingehend nachgebessert werden, dass eine Abweisung durch einen Proxy den Kalender als offline betrachtet und nicht deaktiviert!

M.

Moin,

schön, das auch in diesem Forum vor der noch immer aktiven Plage der Krypto-Trojaner gewarnt wird. Aber diese Aussage

Quote from Peter_Lehmann

Und bitte jetzt nicht mit dem aktiven "on-access-Scanner" ("Virenwächter", "Hintergrundwächter") kommen! Dessen Erkennungsrate ist niemals so gut, wie die eines bewusst durchgeführten "on demand"-Scans!

kann ich nicht einfach im Raum stehen lassen, weil sie so nicht richtig ist.

Korrekt ist: Die Erkennungsrate eines On-Demand-Scans liegt seit einigen Jahren deutlich unter denen eines "Hintergrundwächters". Manuelle Scans können Malware frühzeitig auch in Dateien, die nicht angefaßt werden, dadurch kommt es zu "Erkennungen" die sonst zufällig oder nie erfolgen, eben weil die Datei nicht genutzt wird. Es ergibt sich eine "gefühlte" bessere Erkennungsrate.

Der Grund ist einfach: ein manueller Scan durchsucht die Datei auf Grund von Signaturen. Moderne Hintergrundwächter arbeiten aber zusätzlich mit "Verhaltensüberwachung" und blockieren die Anwendung bei "auffälligem Verhalten". Genau das kann aber der manuelle Scan nicht.

Der Unterschied wird deutlich, wenn man sich die Testergebnisse von AV-Test ansieht. Microsoft arbeitet (bisher) ohne Verhaltensüberwachung und endet irgendwo bei 85%.

Aber: bei Locky versagt auch die Verhaltenserkennung, denn "eine Datei lesen, modifizieren und zurückschreiben" ist ein Grundprinzip der EDV und die Scripte die Locky und Co. verwenden sind so einfach gestrickt, das kaum ein zusätzliches auffälliges Verhalten erkennbar war.

Inzwischen haben aber alle AV-Hersteller nachgerüstet und die Erkennung wird besser.

Signaturbasierte Erkennung hinkt meist mehrere Stunden hinterher, Server-gestützte Erkennung ist recht schnell verfügbar. Hängt aber stark vom Einzelfall ab.

Also bitte auf keinen Fall auf einen "Echtzeitschutz", Verhaltensüberwachung" oder Servergestützte Verfahren verzichten! Nur in der Summe und bei aktuellen Systemen können sich die Schutzmechanismen ergänzen.

(Um diesen Thread nicht zu hijacken bitte Rückfragen per PM)

* Thunderbird-Version: 45.2.0
* Betriebssystem + Version: W7 / W10
* Kontenart (POP / IMAP): IMAP

Hi,

Beobachteter Effekt: nach der Re-Archivierung von Mails in den neuen Server verschwinden diese aus den Archiv Verzeichnissen, sind aber auf dem Server physisch weiter vorhanden.

Historie:
es wird eine einzige Adresse "info@..." auf dem Server der Providers verwendet, auf die mehrere Mitarbeiter per IMAP zugreifen. Nach der Bearbeitung wird die Mail archiviert. Dafür wurde ein "Exch2003-öffentlicher Ordner" per IMAP allen Mitarbeitern als zweites Konto in jedem TB eingerichtet, in das archiviert wird.
Über mehrere Jahre ist ein inziwischen ziemlich umfangreiches Mail-Archiv mit mehreren 10.000 Mails entstanden, das nun aber abgelöst werden muss.

Als Hardware ist eine QNAP-TS453pro angeschafft worden, aber bisher scheitere ich damit die Mails dorthin zu verschieben oder zu kopieren. Weder mit dem Mailserver-APPs Xeams noch mit XMail komme ich zu einem befriedigenden Ergebnis. Die Versuche wurde mit sehr wenigen Mails (<2000) durchgeführt und sind weitestgehend reproduzierbar.

Ich glaube aber nicht, dass es an dem neuen Mailserver liegt, eher vermute ich dass TB etwas mis-interpretiert, was der Exchange mit in die Mails eingebaut hat. Beim Eerstellen des Indexes verschwinden die Mails, ganz so als ob sie als gelöscht gekennzeichnet sind.

Fragen:
Mache ich einen grundsätzlichen Denkfehler?
Sind die Mails irgendwie falsch gekennzeichnet, dass sie aus den Verzeichnissen verschwinden?
Was könnte die Ursache sein?
Wie beginne ich ein Debugging.

Hat jemand einen ganz anderen Ansatz?

M.

(Neuauflage des Beitrages: Archivierung mit IMAP - Mails verschwinden)

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
* Thunderbird-Version: 31.4.0
* Betriebssystem + Version: W7-32
* Kontenart (POP / IMAP): IMAP
* Postfachanbieter (z.B. GMX): QNAP452pro mit Xeams

Hi,
ein alter Exch2003 soll durch Xeams abgelöst werden.
auf beiden Systemen existieren Konten auf die über IMAP zu gegriffen wird.
Das normale Arbeiten mit den Konten klappt problemlos.
Das Archivieren einzelner neuer Mails klappt, auch in monatliche Archive.

Im Exchange liegen Mails von 2009 ebenfalls schon in "öffentlichen" Monats-Ordnern.

zuerst werden alle Mails eines Ordners in einen Ordner auf dem XEAMS kopiert, dann
alle Mails des Ordners mit Strg-A markiert und das Archivieren gestartet.
Der Transfer beginnt und läuft durch wie erwartet. (Archiv/2009/2009-04) zeigt die entsprechende Anzahl Mails an.

Wechselt man dann in in andere Ordner und kommt wieder auf den 2009-04 zurück werden dort alle Mails bis auf eine gelöscht.

Springe ich zwischen verschiedenen Ordnern hin und her tauchen einzelne Mails wieder auf, verschwinden aber auch wieder.

Im Aktivitäten-Fenster dokumentiert TB das Löschen von Mails.

Alle Einstellungen wurden mehrfach geprüft, Junkfilterung komplett deaktiviert.

Wie kann ich debuggen/loggen welches Signal TB dazu veranlaßt Mails zu löschen?

Danke
M.