Zudem würde, wenn denn angefordert, lediglich der empfangende Mailserver diese Bestätigung senden und nicht dein Mailclient.
Kann es sein, dass Du hier "DSN" mit dem vom Autor gemeinten "MDN" (Message Disposition Notification) durcheinander wirfst? Die "normale" altbekannte Empfangsbestätigung (MDN) kommt vom Mail-Client. Der Text dazu ist ja auch in Thunderbirds Code enthalten.
Hast Du das Verhalten auch bei anderen IMAP-Konten, oder nur bei denen von Alfahosting? Ich würde sowas immer zum Vergleich mit einem Konto bei einem anderen Anbieter gegentesten.
So sieht das jetzt bei mir (Thunderbird 60 Beta 6) im Filter-Dialog des Thunderbird aus, wenn ich einen neuen Filter anlegen will:
Dort könntest Du für die alten Mails als Aktion "Verschlüsseln (Enigmail)" wählen und an Dich selbst verschlüsseln, denke ich.
Wenn Du nach dem doppelten Herunterladen Thunderbird schließt und wieder öffnest, bleiben die Duplikate dann vorhanden oder sind die Duplikate dann automatisch weg?
Für mich sieht das nach einem Fehlverhalten im Zusammenspiel mit dem IMAP-Server aus, wovon man bei manchen Hostern hört, da die teilweise eigene Implementationen verwenden. Das kann sein, muss aber nicht sein.
Was passiert, wenn Du den Ausgangsordner über Datei > Diesen Ordner komprimieren komprimierst?
Ich habe gerade diese Seite mal wieder ausgebuddelt:
Du musst einen Filter in Thunderbird erstellen, denke ich. Allerdings finde ich zwar momentan die Bedingung "OpenPGP-verschlüsselt", aber eben nicht die notwendige Filter-Aktion.
Muss ich mir später mal in Ruhe anschauen.
Könnte es sein, dass die Mails am Ausgangsort (des Verschiebens) nur als gelöscht markiert werden (ein IMAP-Feature) und dann erst beim Beenden des Programms tatsächlich auch "remote" auf dem IMAP-Server gelöscht werden?
Kontrolliere mal die Konten-Einstellungen > Server-Eintellungen des IMAP-Kontos in Thunderbird.
Wie entschlüssele ich diese nun mit enigmail 2.0.6?
Ich habe eine Weile gesucht und die Antwort nun gefunden:
In addition, this version allows to re-encrypt messages without MDC protection using the message filter action "Encrypt to Key".
Hallo!
Im Grunde kann es sich nur um Windows handeln, da bei Linux + macOS ja die 64-Bit-Versionen schon lange Standard sind.
Ich halte es für keine gute Idee jemand anderem ausgerechnet eine Daily-Installation zu machen. Wenn möglich, dann Versuche Dein Glück wenigstens mit der aktuellen Version 60 Beta 6 (oder neuer) statt einer 64-Bit-Daily.
Update im Add-on-Manager müsste bereits möglich sein, denke ich.
Enigmail 2.0.6 wurde auf AMO veröffentlicht. Im Changelog steht unter Anderem:
Furthermore, this version allows to re-encrypt messages without MDC protection.
Zugehöriger Checkin im Code:
Außerdem zeigt das Programm noch an "Benutzername oder Paßwort ungültig" obwohl das definitv richtig eingegeben ist.
Diese Meldung kommt leider (in Abhängigkeit von der Rückmeldung des antwortenden Servers) auch bei allen möglichen Ursachen. Es kann also teilweise sein, dass die Angaben korrekt sind und eine andere Ursache schuld ist.
Bezüglich des Zertifikats kann es helfen, wenn man in GData den Mailschutz mal eine Zeit lang deaktiviert und später wider neu aktiviert. Ich hasse diese Teile, die da rein grätschen und Probleme verursachen, die man dann überhaupt nicht mehr überblicken kann.
Ein wichtiger Punkt (einfach es zu wissen) ist, dass die Mails selbst unbeschadet den Anhang weiterhin besitzen. Das sieht man beim Betrachten des Quellcodes der Mails. "Kaputt" ist nur die Indexdatei, welche mit "Reparieren" neu angelegt wird. Vielleicht gibt es immer nur Konstellationen, die dazu führen. Eigentlich sollte es aber mit 52.8.0 behoben sein. Bei mir waren ausschließlich Maildir-Konten betroffen, prinzipiell konnte das aber wohl auch bei denen im Mbox-Format passieren.
Die Einstellung verwendet er doch vermutlich.
Mehrere Mails markieren und dann mit einem Klick für die gewählten die komplette Mail laden geht glaube ich nicht.
Letztlich ist das immer von beiden Seiten abhängig. Der Sender muss eine gängige Kodierung verwenden und die korrekte Kodierung auch im Header angeben. Das macht Thunderbird eigentlich. Der Empfänger muss die Kodierung im Idealfall aus dem Header auslesen und dann auch noch berücksichtigen. Wenn der Empfänger eventuell eine Einstellung hat, womit er die Angabe im Header ignoriert, dann kann es beispielsweise Probleme geben.
Der Fehler trat auch unter Windows in bestimmten Konstellationen bis inkl 52.7.0 auf.
57.* war ein Tippfehler.
Mit 52.8.0 ist die Ursache behoben.
War bei T-Online nicht irgend eine Beschränkung auf 2 oder 3 Ordnerebenen? Vielleicht gilt die auch nur beim Zugriff per IMAP. Mangels eigenem T-Online-Account kann ich das aber gerade nicht testen.
Die Frage ist, ob Abhilfe überhaupt notwendig ist.
GData hängt sich in den Datenstrom und schiebt Thunderbird ein selbst generiertes Zertifikat unter. Thunderbird hat also wegen GDATA gar nicht mehr direkt Kontakt mit Web.de sondern mit Deiner der Software von GData. GData wiederum verbindet sich mit Web.de. Nur so kann der Virenscanner als "Man-in-the-middle" den Datenstrom überwachen.
Dazu kannst Du beispielsweise hier viel lesen:
Warnmeldungen zu Zertifikaten von GMX und web.de
Wenn Du Deiner Antivirus-Software vertraust, dann kannst Du die (berechtigte) Meldung von Thunderbird mit "Sicherheits-Ausnahmeregel bestätigen" zur Kenntnis nehmen. Thunderbird akzeptiert dies dann und speichert es, sodass er nicht wieder fragt bis ihm ein wieder geändertes Zertifikat angeboten/untergeschoben wird. Manchmal scheint GData quasi täglich ein verändertes Zertifikat zu erstellen - dann wird Thunderbird zu Recht jedes mal fragen.
Hallo!
Bitte liefere uns mehr Informationen. Was ist mit den Angaben, die wir extra (siehe oben) abgefragt haben?!
Hast Du nur Thunderbird aktualisiert? Hast Du die Tage auch Windows (nutzt Du überhaupt Windows) aktualisiert? War womöglich beim Windows-Update "alles" weg? Wie hast Du Thunderbird aktualisiert: programminterne Update-Funktion oder durch eine quasi neue "Drüber-Installation"?
Hast Du ein aktuelles Backup, dass man bei Bedarf für die Wiederherstellung verwenden kann?
Versand direkt aus dem Mailkonto bei 1u1 kein Problem, dann ist es IMAP?
Nur der Form halber:
Nicht IMAP sondern SMTP ist beim Versand der Mails das Protokoll.
Bitte überarbeite Deinen Screenshot mal, sodass die E-Mail-Adresse dort anonymisiert ist - Danke!
