Beiträge von Susi to visit

Ich habe die Logs bei mir nun ebenfalls aktiviert. Die Logs sehen ähnlich aus. Dass darin Enigmail auftaucht, hat offenbar nichts mit der ehemaligen Erweiterung zu tun. Man hat wohl die Bezeichnung für die Code-Teile, die nun integriert wurden, beibehalten. Daran liegt es also nicht.

Ist der für die alten Mails benötigte Schlüssel noch dein derzeit aktiv benutzter Schlüssel, also der, den du auch als externen Schlüssel im Thunderbird eingebunden hast? Oder ist das ein älterer, der nur noch in der Schlüsselverwaltung des OS zur Verfügung steht?

Grad noch was: Hast du zusätzlich auch die RNP-Log aktiviert? Sieht man darin vielleicht etwas?

Zitat von giwitz

hat noch TLS 1.0 , das habe ich in der Thunderbird-config entsprechend angepasst

Ich bin mir nicht sicher, ob TLS 1.0 überhaupt noch unterstützt wird. Das roter Banner oben ist leider nicht mehr da. Deshalb müsste ich jetzt nach den Links dazu suchen. Das überlassen ich aber dir. Was genau hast du angepasst?

Zitat von meywer

Speicherzugriffsfehler

Ist auf jeden Fall ein harter Fehler. Reiche bitte die schon von Boersenfeger nachgefragten Daten nach. Insbesondere die Thunderbird Version und ob es sich dabei um ein Flatpack handelt.

Ein Link zum Crash-Report könnte noch interessant sein. Den können zwar letztendlich nur die Entwickler komplett lesen, aber enthält auch ein paar für uns Anwender verständliche Hinweise.

Zitat von B. Mueller

Kann jemand mit Inline-verschlüsselten Mails das Verhalten nachvollziehen?

Ich kann diese Mails alle lesen. Viele habe ich nicht mehr, weil ich sie entschlüsselt archiviert habe. Aber ich habe ein paar Testmails aus 2018 gefunden. Die werden allen entschlüsselt.

Nur überflogen: Auffällig ist, dass bei dir im DebugLog von Enigmail die Rede ist.

Man kann sich Mühe geben, so viel man will. Egal ob man frech oder freundlich reagiert, ob man versucht, sich ganz auf den Sachverhalt zu beschränken oder selbst auch unsachlich antwortet, es hat alles keinen Zweck.

Mit solchen Anleitungen richtest du Schaden an. Nicht zum ersten Mal, wie wir wissen. Ich hoffe nur, dass nicht weitere Leser auf solche Tipps von dir hereinfallen.

Zitat von Rolf Weiss

Ich bevorzuge POP,

Dann bleib einfach dabei. Ich will dich auch nicht überreden, zu IMAP zu wechseln. Aber ein paar Infos zu deinen Beweggründen möchte dir schon noch geben:

Zitat von Rolf Weiss

[...] weil ich meine Daten lieber auf meinem Rechner habe.

Das kannst du bei IMAP auch haben, siehe oben. Das wäre dann zusätzlich zu den Daten auf dem Server. Daher kommt die doppelte Datensicherheit bei einem Aus- oder Unfall.

Zitat von Rolf Weiss

[...] will ich diesem Monster meine Mails nicht freiwillig zum Fraße vorwerfen.

Dann musst du wirklich andere Maßnahmen treffen. Für die Mails ist es egal, ob du sie per POP oder IMAP abrufst. Der jeweilige Provider hat sie schon, noch bevor du sie abrufen kannst. Selbst wenn du sie sofort löschen könntest, das Monster hätte sie längst gefressen.

Zitat von Rolf Weiss

Ich bin auch nicht mit dem Mäusekino unterwegs, sondern habe einen PC mit reichlich Speicher.

Selbst wenn du keine Smartphone benutzt, erleichtert IMAP das Leben. Zum Beispiel dann, wenn du auf einen anderen PC umziehst oder wenn dich dich irgendwann mal entscheiden solltest, vielleicht doch auf Outlook oder ein ganz anderes Mailprogramm umzusteigen.

Zitat von B. Mueller

Um deine Täuschung zu perfektionieren, fügst du die Identität deiner Kollegin B zu deinem Schlüssel hinzu (dein Vorschlag). Voilà - keine Warnmeldung mehr!

Mit diesem Einwand hatte ich gerechnet. Ich hatte sogar schon etwas dazu geschrieben, dann aber vor dem Absenden doch wieder gelöscht. Weil der Text zu lange wurde und weil zu ahnen war, dass du jede überflüssige Zeile weiterhin nutzen wirst, um abzulenken und auszuweichen, noch einen Nebenschauplatz zu eröffnen.

In Kurzform ist die Antwort ganz einfach: Einen so manipulierten Schlüssel bekomme ich niemals beglaubigt.

Vielleicht bis du dann doch mal so nett und beendest diese Vernebelungstaktik. Ich kann das beim besten Willen nicht mehr nachvollziehen. Deine Methode führt dazu, dass die Mailprogramme eine deutliche Warnung melden, weil die Identität des Absenders nicht stimmt. Was gibt es da zu diskutieren? Das ist doch eindeutig!

Dabei ist die Idee, eine Anleitung zur Benutzung der zusätzlichen Identitäten bzw. Aliase zu schreiben ja wirklich gut, weil das derzeit nicht allein über die grafische Oberfläche möglich ist. Zumindest habe ich keine Möglichkeit dazu gefunden und musste die Anpassungen in den prefs vornehmen.

So eine Anleitung wäre für den einen oder anderen sicher hilfreich. Warum wendest du deine Zeit und Energie nicht dafür auf anstatt das erkennbar Falsche weiterhin zu verteidigen? Das wäre doch viel besser als auf einer Lösung zu beharren, die mit einer falschen Identität arbeitet und deshalb beim Empfänger einen berechtigen Warnhinweis produziert.

Zitat von B. Mueller

Das überlasse ich gerne dir, wie man praxistauglich in TB weitere Identitäten zu OpenPGP-Schlüssel hinzufügt.

Nein, das mache ich nicht. Schließlich hast du das Thema hier aufgebracht und nicht ich.

Für alle anderen vielleicht ein Beispiel, das zeigt, warum das obigen Vorgehen zu einem Fehler führt. Und vor allem, warum das gut und wichtig ist.

Angenommen Person A hat meinen öffentlichen Schlüssel zu der Adresse Susi_at_irgendwas. Wenn ich ihr von dieser Adresse eine von mir signierte E-Mail sende, wird ihr bestätigt dass diese E-Mail definitiv von mir kommt und auch nicht verändert wurde. Genauer: Sie wurde von jemanden versendet, der meinen privaten Schlüssel benutzen konnte. Unter anderem deshalb gilt es, diesen Schlüssel zu schützen. Soweit alles so wie es sein soll.

Ich könnte nun meine Absenderadresse fälschen. Das ist gar nicht schwer. Sagen wir ich nehme die meiner Kollegin B, der ich schon immer eins auswischen wollte. Blöd ist, dass ich deren privaten Schlüssel nicht habe.

Mit dem "Trick" von oben gelingt es mir, diese E-Mail mit meinem Schlüssel (Susi_at_irgendwas) zu unterschreiben und unter dem Absender der Kollegin an Person A zu senden.

Person A empfängt die E-Mail und anhand meines öffentlichen Schlüssels stellt sie fest, dass die E-Mail a) nicht verändert wurde und b) korrekt unterschrieben wurde.

Wenn Person A jetzt nicht genau hinschaut, merkt sie gar nicht, dass die Unterschrift nicht von der Kollegin ist. Um das zu verhindern, damit der Empfänger nicht so einfach getäuscht werden kann, erscheint diese Warnmeldung. Sie besagt, die Unterschrift ist zwar technisch ok, aber die Absenderin ist vorgetäuscht.

Klar, letztendlich käme schon heraus, dass mit meinem Schlüssel unterschrieben wurde. Bis dahin ist die Kollegin aber vielleicht schon rausgeflogen und das Verhältnis mit dem Chef publik. Und mir fällt schon eine Ausrede ein. Ich sage, tut mit leid, ich habe meinen privaten Schlüssel leider verloren. Oder ich schiebe es auf meinen Mann.

Wenn also jemand der Anleitung von oben folgt, bekommt der Empfänger diese Warnmeldung. Nun sind Signaturen dazu gedacht, Vertrauen zu schaffen. Mag sich jeder selbst überlegen, ob er das dann so möchte. Ich würde dem Absender jedenfalls einen ganz bestimmten Finger zeigen.  

Die Hashwerte zur Verifizierung von Dateien (=Inhalt) sind etwas anderes als digitale Signaturen von E-Mails.

Ich möchte dich sehr bitten, deine Taktik des Verschleierns und Ablenkens zu beenden. Das hatten wir doch zu genüge. Es entsteht sonst wieder eine Endlosdiskussion und am Ende beantwortest du die technischen Argumente nicht.

Allein die Tatsache, dass sämtliche E-Mailprogramme bei Anwendung deiner Methode eine Warnung ausgegeben, sollte doch als Hinweis genügen, dass die Anleitung nicht gut ist. Dazu muss man gewiss kein Experte für digitale Signaturen sein, um das einzusehen.

Die berechtigten Warnmeldungen gehen nicht davon weg, dass du deine Methode weiterhin verteidigst. Wem also wäre mit deiner Anleitung geholfen, wo es doch es doch auch einen korrekten Weg dafür gibt?

Warum schreibst du nicht einfach eine Anleitung, wie man es richtig macht, wie oben in #2 kurz erwähnt. Das wäre viel sinnvoller als auf der jetzigen zu bestehen.

Du lenkst ab. Eine Signatur hat zwei Aufgaben:

1. Sie zeigt an, ob der Inhalt verändert wurde oder nicht. Das geschieht über Hash des Inhalts.
2. Sie zeigt an, ob der Absender wirklich der ist, der er vorgibt zu sein.
   Das ist bei dir nicht der Fall. Deine Absenderadresse passt nicht zu der, für die der benutze private Schlüssel erstellt wurde.
   Deshalb geben die E-Mailprogramme eine entsprechende Warnung. Du brauchst auch nicht versuchen, das weg zu diskutieren. Diese Warnungen erscheinen nicht aus Spaß sondern zurecht.

Außerdem gibt es einen vorgesehenen Weg, wie man einem Schlüssel mehrere Identitäten zuweisen kann. Aus welchem Grund sollten jemand deiner Anleitung folgen und beim Empfänger dieser Warnungen hervorrufen, wenn es doch auch richtig geht?

Ich muss gleich fort. Deshalb nur ganz kurz: Die ics im Anhang werden vom Thunderbird nicht bereits durch pures Ansehen ausgeführt, d.h. in einen Kalender übernommen. Du musst diesbezüglich also gar nichts ändern.

Eine ics ist eine Textdatei. Wenn dich dieser Eintrag dort nun stört, dann frage bitte denjenigen, der dir diesen Tipp gegeben hat und dessen Rat du gefolgt bist.

Zitat von B. Mueller

Das ist verständlich - die Signatur ist trotzdem korrekt.

Nein, das ist sie eben nicht. Und deshalb wird sie auch zurecht von allen E-Mailprogrammen als ungültig angezeigt.

Ich habe wirklich keine Lust, schon wieder mit dir zu streiten. Ich will auch nicht wie eine Zicke dastehen. Trotzdem, von deiner Anleitung ist schlicht und einfach abzuraten! Du brichst damit die digitale Signatur, quasi wie mit einem gefälschten Ausweis. Zum Glück fällt das natürlich auf und Jeder Empfänger bekommt sofort diesen Warnhinweis.

Eine digitale Signatur dient dazu zu, die Echtheit des Inhalts und des Absenders zu bestätigen. Im besten Fall sogar rechtssicher und nicht abstreitbar. Dein Gefummele macht die Signatur ungültig. Sie ist damit z.B. für den amtlichen Schriftverkehr unbrauchbar.

Wie es richtig geht, hat u.a. @muzel schon beschrieben. Man kann einem Schlüssel mehrere Identitäten zuweisen. Das ist der korrekte Weg. Dann klappt es auch es auch mit der Signatur.

Im Thunderbird mit OpenPGP muss man die Verschlüsselung für eine weitere Identität derzeit leider noch von Hand über die pref.js aktivieren und den Schlüssel zuordnen.

Dann mach' diese Änderung doch einfach rückgängig.

Zitat von Mapenzi

Ich hatte wohl zunächst selektiv gelesen

Ich auch, wie nun sehe. Ich hatte nämlich nur noch auf den Screenshot geschaut.

Zitat von K.Achim

[...] eine automatische Ausführung von ICS-Anhängen zu verhindern

Hast du das überhaupt mal ausprobiert? Wie ich schon in dem von dir verlinkten Thema geschrieben habe, wurden die ics bei meinen Tests überhaupt nicht automatisch ausgeführt. Du musst dazu gar nichts ändern.

Zitat von K.Achim

Ich gehe also davon aus, dass CalDAV den Zeichensatz auf ASCII (?) begrenzt.

CalDAV selbst begrenzt das nicht. Sonst könnten z.B. Asiaten das gar nicht gscheid benutzen. Der gewünschte Zeichensatz wird bei der Anfrage vom Client an den Webserver gegeben. Wie der reagiert, wenn er den Zeichensatz nicht unterstützt, weiß ich nicht. Vermutlich handeln Client und Server dann einen anderen aus.

Ich habe deine Monde eben per Copy&Paste in einen meiner CaldDAV-Kalender übernommen. Die werden dann auch korrekt im Kalender angezeigt.

Sollte es bei dir tatsächlich am Webserver liegen, probiere mal einen anderen Provider aus.

Zitat von Mapenzi

in dem der Senden Button allerdings ausgegegraut war.

Du schreibst "allerdings". Das ist doch hier auch der Fall. Das sollte doch passen?

Das Problem des inaktiven Senden-Buttons aufgrund oder in Zusammenhang mit defekten Adressbüchern hatten wir hier schon ein paar mal. Ich meine, es stand, wie Mapenzi bereits nachgefragt hat, stets in Verbindung mit einem Update. -> Suchfunktion

Soweit ich mich erinnere, war die Lösung dann ein neues Profil mit Import der alten Adressbücher, sofern vorhanden.

/* Das wär was! Aber ganz so weit sind wir noch nicht.

Unser Weinkeller ist ein kleines Holzregal, das wir hin und wieder nach einem Italienurlaub auffüllen. Mehr als 12 Flaschen hat es glaub' ich noch nie gesehen.

Hingegen haben wir eigentlich immer ein, zwei Tragerl Bier im Haus. Das mögen die Gäste einfach lieber. Selbstverständlich heimisches.

*/

Zitat von B. Mueller

Auch wenn lokal aus Versehen gelöscht und bei funktionierender Synchronisation …?

Bei einem IMAP-Konto sollte es selbstverständlich sein, vor allem in Hinsicht einer Archivierung und des Backups, eine Kopie unter Lokaler Ordner zu speichern. Zu diesem Zweck ist der schließlich gedacht. Das kann man sogar automatisieren. In diesem Fall lautet die Antwort "ja".

Hat man keine solchen Kopien, verhält es sich exakt so wie bei einem POP-Konto. Da gibt es keinen Unterschied. Versehentlich gelöschte Mails lassen sich, sofern nicht komprimiert wurde, aus den mbox-Dateien wieder herstellen. Ansonsten sind sie weg, genau wie bei POP. IMAP ist also in dieser Hinsicht schlimmstenfalls immer noch ebenso gut wie POP, bietet in den meisten Fällen aber ein Mehr an Datensicherheit.