Hallo,
seit gestern ahne ich wie sich mein Vater fühlt wenn ich im etwas zu EDV erkläre 
und warum ich mich nie an das Thema herangetraut habe…
Eine von vielen Unklarheiten:
Wie kann ich (WIN 7, Outlook 2010, pgp4win 3.1.2) signierte versandte Mails in andere Ordner verschieben?
Drag + Drop klappt nicht und Befehl “verschieben” auch nicht.
Danke für Hilfe
Grüsse aus Nordhessen
Marc
Hallo,
Wir hatten dazu leider ein schwieriges technisches Problem ( https://dev.gnupg.org/T3459 ) das wir erst vor kurzem gelöst haben. Mit der nächsten Gpg4win Version wird das verschieben von Krypto Mails genau so wie mit anderen Mails möglcih sein.
Bis dahin musst du schauen das die Mails während des verschiebens nicht geöffnet sind. Im Task auf dev.gnupg.org ist eine kleine Animation in einem Kommentar um zu zeigen was damit gemeint ist.
Nächstes Release kommt bald. Ich hoffe das ich diese Woche noch min. eine Beta hochladen kann.
Gruß,
Andre
Hallo Andre,
vielen Dank für schnelle Info und so ist es zwar nicht komfortabel aber “erträglich”. Lag es doch nicht an mir
Der ganzen engl. Diskussion vermag ich aus mehreren Gründen nicht zu folgen, aber Dank Deines Hinweises habe ich die Lösung. Besten Dank.
Grüsse
Marc
Vielleicht anzumerken das die Beta mittlerweile veröffentlicht ist:
Danke für den Hinweis. Betas sind (zuweilen ) etwas für ambitionierte Zeitgenossen. Feiglinge wie ich warten bis die stabile Version einige Zeit auf dem Markt ist.
Nach 30 Jahren Windows wird man mit dem Alter vorsichtiger (deshalb auch kein Interesse an WIN 10 Zwangsbeglückung…)
Also nochmals Danke, aber ich warte lieber ein bissel
Hallo Marc,
Du musst allerdings bedenken, dass “Beta”-Versionen bei Freier Software
manchmal stabiler sind, als andere “Gold”-Versionen.
Ernsthafter: In der Beta-Phase können wir einfach schneller auf Problemberichte reagieren,
es lohnt sich also, die zu probieren, wenn jemand sicher sein möchte, dass die eigenen
Nutzungsmuster auch gut gehen.
Gruß,
Bernhard
Hallo,
in der Beschreibung der Beta steht “Mails can be automatically secured if pubkeys are available”. Wo stelle ich das ein? Danke!
Albert
Das ist per default an. Im Optionsdialog ist es “Nachrichten automatisch absichern” (Siehe Screenshot)
GpgOL wählt das absichern nur aus wenn keys mit min. Marginaler Gültigigket (beglaubigte keys) verfügbar sind. Ich vermute daher funktioniert es für dich nicht.
Vielleicht sollten wir da noch eine Option machen einfach “jeden” key zu akzeptieren. Zumindest solange bis wir dann auch mal ein automatisches vertrauensmodell implementiert haben.
Vielleicht sollten wir da noch eine Option machen einfach “jeden” key zu akzeptieren.
Lieber nicht. Das öffnet das Tor doch sehr weit.
Eine Option wäre prima. Ich sehe auch kein Sicherheitsproblem darin, da ja jeder Schlüssel mit einer Vertrauenseinstellung gekennzeichnet werden muss.
Mit einer solchen Option sich GpgOL auch der Benutzerfreundlichkeit von Enigmail nähern und dort ist es auch kein Problem.
Albert
Ich denke auch, zumindest solange bis wir die Umstellung auf “Automatisches Vertrauen” mit drin haben ist eine Option sinnvoll für Nutzer die das Verhalten von Enigmail oder Mailvelope erwarten.
Der grund warum wir zum “automatischen Verschlüsseln” nicht jeden key verwenden wollen sondern nur welche mit “Trust Level 1” ( https://wiki.gnupg.org/AutomatedEncryption ) ist kein Sicherheitsgrund sondern wir wollen hauptsächlich verhindern das der Empfänger die Mail nicht lesen kann weil er den Schlüssel z.B. nicht mehr verwendet oder verloren hat.
Habe mich entschieden das in diesem Release nicht zu machen.
Ich habe ganz oben auf meiner feature TODO das wir endlich das auf Kommunikations Historie gewählte Vertrauensmodell richtig verwenden. Dann wird auch das automatische verschlüsseln besser und sicherer als in Enigmail.
Wenn du schonmal damit expierimentieren willst (Und Gpg4win nicht für Dateien benutzt) kannst du in den GpgOL Optionen unter “GnuPG System” → OpenPGP → “trust-model”
“tofu+pgp” eintragen (ohne Anführungszeichen).
Alles klar. Was kann ich denn bei dem Parameter “tofu+pgp” in Bezug auf das automatische Verschlüsseln erwarten?
Sobald du von jemandem eine signierte Mail gesehen hast wird der Key zum verschlüsseln verwendet. Das soll verhindern das du einen Key verwendest den der empfänger nicht mehr verwenden kann.
In einer Idealen Welt stellen wir uns das so vor:
UserX signierte Mail:
→ Hallo Albert Ich habe dir was wichtiges zu sagen.
Albert Camus antwortet verschlüsselt und signiert:
→ Alles Klar ich kann verschlüsselte Mail.
UserX hat die signierte Mail gesehen und kann nun auch verschlüsseln:
→ Hier ist das wichtige
Ich habe mir selber eine Mail zugeschickt: Mit Smime klappt das automatische Verschlüsseln und Signieren, mit GPG nicht. Allerdings kann die Mail nicht entschlüsselt werden. Fehlermedlung: Input-Output-Fehler. Outlook konnte die Mail problemlos entschlüsseln.
Eine Smime-Mail von einem Arbeitskollegen konnte entschlüsselt werden und das Zertifikat wurde automatisch importiert. Allerdings dauerte das Entschlüsseln eine gefühlte Ewigkeit.
Mit GPG hat es nun geklappt. Merkwürdig, aber prima. Das erstmalige Prüfen und Entscntschlüsseln mit GPG4Win von S/Mime-Mails dauert aber viel zu lange und ich halte es so nicht für praxistauglich.
Bei S/MIME sind wir im prinzip deutlich schneller geworden mit 3.1.3.
Was aber immer noch ewig dauern kann sind “CRL Checks”. Die sind leider teil des S/MIME Standards und je nachdem wie lange der Server braucht um CRL’s zu senden können die beliebig lange dauern.
Berüchtigt ist cacert bei denen dauert es bis zu 30 Minuten bis Sie die CRL gesendet haben :-/
Und ja das ist unbenutzbar aber ich weiß nicht was wir da machen sollen. Wenn wir CRL’s nicht prüfen sind wir nicht mehr nach S/MIME Standard sicher.
Du kannst das in der Konfiuration unter GnuPG System → S/MIME → Never consult a CRL (ich glaube ist übersetzt als niemals eine CRL prüfen). Deaktivieren. Dann sollt es schneller gehen.
Vielleicht ist es eine Idee bestimmte CRLs ausschließen zu können
(und dann cacert einzutragen).
Ich glaub ich hab ne bessere idee (Siehe: https://dev.gnupg.org/T4118 ) Wir sollten erstmal nicht den “Grünen Balken” / Vertrauenswürdig anzeigen. Aber schonmal den Inhalt der Mail. Im Hintergrund kann dann die langsame Signaturprüfung weiterlaufen so das bei der nächsten Prüfung die CRL hoffentlich gecached ist.
Verkompliziert wird das ganze durch unsere “EFail” Schutzmechanismen die Mails anders behandeln wenn eine Signatur vorhanden ist. Daher müssen wir dann noch ein zweites mal ohne CRL checks prüfen.
In den Eigenschaften heißt es: “Niemals eine CRL konsultieren” und die Prüfung der Mail verläuft fast so schnell wie in Outlook-Original.
Vielleicht können manuell importierte Zertifikate, bei denen die Zertifikatinstanz bestätigt werden muss, anders behandelt werden als die, die über eine Mail importiert werden.