Beiträge von MoNeo

    Hallo,

    ich habe jetzt doch ein wenig gebastelt.

    • Das Löschen des einzelnen Registry Zweiges hat (trotz Neustarts) keinen Effekt erzeugt.
    • Deinstallation und Löschen der gesamten RIT-Registry mit anschließender Installation und Nutzung des alten Datenverzeichnis (und damit der Konten) führt wieder zum gleichen Effekt - doppelter Header-Eintrag
    • Neuinstallation (Löschen der REG inklusive) in ein sauberes Verzeichnis und Neuanlage der Konten lässt das Phänomen verstummen.

    Insofern sieht es so aus, als würde die Einstellung nicht in der Registry gespeichert, sondern in irgendeiner der Kontodateien. Wobei hier wieder die Frage auftaucht, wieso das Problem dann bei allen Konten aufgetaucht ist.

    Egal wie, ich richte das jetzt komplett neu ein und hoffe, dass es nicht wieder vorkommt.

    Ich nehme an, dass deswegen eine Neuinstallation nicht geholfen hat, weil dieser Registry-Zweig unverändert geblieben war.

    Danke , sanyok, für diesen Hinweis. Da ich lange ausschließlich mit Voyager unterwegs war, hatte ich komplett ausgeblendet, dass TB! ja in der Registry rumschreibt.

    Da mir jedoch das Rumfrickeln in der Registry zu doof ist - und es meist doch mit einer Neuinstallation endet, werde ich es wohl mit einer Deinstallation, Bereinigen der Registry (RIT/Ritlabs komplett raus), Neuinstallation der aktuellen Final und dem Einspielen des gerade laufenden BackUps versuchen.

    Wenn Du Recht hast und diese Einstellung aus der Registry kommt, sollte es danach ja wieder passen. Oder werden die 'falschen' REG Einträge auch ins BackUp geschoben? Komme ich mit einem externen Programm an die Dateiliste des BackUps - um ggf. die *.reg Dateien raus zu schmeißen?

    Hallo,

    nach langer Zeit habe ich mal wieder ein Problem, das ich nicht selbst lösen kann. Ich habe im Forum auch nichts dazu gefunden, darum also neues Thema.

    Vorab für die Leute, die Signaturen ausblenden: Version 7.x (inkl. aktuellste Final), 32-bit, auf Win7 oder Win10, XMP und AntiSpamSniper als Plugins.

    Bei mir ist im Header das 'Von' Feld doppelt definiert. Wie es dazu gekommen ist, weiß ich nicht. Und eben auch nicht, wie ich das wieder los werde.

    Das eigentlich störende jedoch ist, dass eines dieser Felder immer leer zu sein scheint - und gerade dieses wird beim Schreiben einer neuen Mail standardmäßig angezeigt. Das heißt, ich kann nicht auf einen Blick sehen, mit welcher Absenderadresse ich die Mail versenden werde. Und ich kann die Identität über dieses Feld auch nicht ändern. Dazu muss ich zusätzlich das zweite Von-Feld einblenden - dann gehts.

    Da ich einige Postfächer und diverse Aliase habe, nervt das doch ein wenig. Wenn ich über Ansicht - Nachrichtenkopf das zweite Von Feld einblende, sehe ich auch die Adresse.

    Egal welches der beiden Felder ich übrigens einzeln einblende - es ist immer das leere. ;(

    In der Definition des Nachrichtenkopfes im Konto ist allerdings nur ein Von-Feld angezeigt. Das zu löschen, wäre jetzt wahrscheinlich auch blöd - dann sehe ich vermutlich gar keine Absenderadresse mehr.

    Das Deaktivieren der Plugins ändert nichts, ich kann auch nicht nachvollziehen, seit wann das Problem besteht - irgendwann war es da.

    Hatte jemand schon mal so ein Problem und kann mir die Lösung verraten? Oder auch eine Idee/Hinweis wo ich mit dem Editor ran muss, um das zu korrigieren?

    Neuinstallation und Einspielen des BackUps hilft jedenfalls nicht, eine komplette Neuinstallation inklusiver manueller EInrichtung aller Kontoeinstellungen würde ich eigentlich gern vermeiden, das wäre doch eine Menge Arbeit.

    Danke für Eure Hilfe schon mal vorab!

    Nur nochmal zum Verständnis:
    Wenn ich diese Funktion "Unverschlüsseltes Senden bestätigen" angehakt hatte,
    hat er nicht nur nicht verschlüsselt gesendet ...sondern garnichts gesendet ,
    bis ich in dem aufpoppenden Dialog nochmals die Empfängeradresse eingegeben habe....

    Ok, das hatte ich so nicht verstanden. Ich war davon ausgegangen, dass nach der Bestätigung im Dialog auch bei Dir die Mail verschlüsselt gesendet wurde. Herauszufinden, warum sich das Programm hier unterschiedlich verhält, könnte man natürlich ... will aber glaub ich keiner.


    Das kann passieren, wenn er z.B. nur ein einziges Mailkonto hat und nicht alle Nachrichten verschlüsselt. Deswegen hat er zwar OpenPGP global aktiviert, aber nicht auch "Nachricht verschlüsseln", sondern macht das dann immer manuell bei Bedarf. Nun hat er das aber vergessen und geht davon aus, dass die Nachricht verschlüsselt versandt wird, was aber nicht der Fall sein wird. Für ihn ist daher ein solcher Hinweis sicherlich sehr nützlich.

    Hmmm, ich fände auch in diesem Fall die Meldung etwas übertrieben (und würde sie vermutlich nach der ersten abgelehnten Mail an, sagen wir mal, 10 Empfänger direkt verfluchen). <X Apropo - hat das mal jemand mit mehreren Empfängern versucht? Muss man dann jede Mailadresse einzeln eingeben oder alle Empfänger in die eine Dialogbox? Mit Komma getrennt, Semikolen? Gibt's ein Makro dagegen? 8o

    Ich kann auch Deinen Einwand, sanyok, dass Windows (also auch TB! User) möglicherweise jeden störenden Dialog erstmal wegklicken, verstehen, dieses Problem löse ich mit dem hier besprochenen Dialog allerdings auch nur sehr bedingt. :P

    Ganz konkret ist die Funktion (und damit auch der Dialog) aus meiner Sicht nur sinnvoll, wenn ich

    • grundsätzlich alle Mails verschlüsseln will ODER
    • konkret diese Mail verschlüsseln will UND
    • dies aus irgendeinem Grund nicht geht.

    Hier wäre es aber auch sinnvoll, mitzuteilen, warum denn das Verschlüsseln nicht geht.

    So viel geschrieben, aber ich denke, nun ist genug - Faktotum ist mit der bisherigen Lösung (die keine ist) zufrieden und ansonsten warten wir auf die Bugbehebung durch RITlabs.

    Schönes Pfingstwochenende! :thumbup:

    Grundsätzlich ist dieser Warnhinweis natürlich notwendig, wenn man z.B. vergessen hat, auf "Nachricht verschlüsseln" zu klicken oder die Nachricht sofort zu verschlüsseln.


    Hmmm, jetzt wird es philosophisch. ;) Der Hinweis ist meiner Meinung nach nur dann sinnvoll, wenn der User - auf welche Art auch immer - vorher seinen Willen kundgetan hat, dass er die Mail verschlüsseln will (z.B. weil er die entsprechende Option in den Kontoeinstellungen ausgewählt hat). Sonst ist der Hinweis per se überflüssig.

    Im zweiten Fall ist er ebenfalls nur dann sinnvoll, wenn trotz aktivierter Option 'Alle Mails verschlüsseln' die Mail nicht verschlüsselt wurde - was ja hier offensichtlich auch nicht der Fall war.

    Man könnte jetzt die beiden Optionen in den Einstellungen verknüpfen - dann würde für Konten, die grundsätzlich nicht verschlüsseln, die Option 'Warnen' gar nicht zur Verfügung stehen. Und Leute, die ihre Mails prinzipiell verschlüsseln, finden die Warnung ja dann ganz passend. Vielleicht.

    Zitat

    Interessant ist, ob das schon immer so war. Die Option "Unverschlüsseltes Senden bestätigen" ist ja standardmäßig deaktiviert und kaum jemand aktiviert sie. Es kann also sein, dass es einfach bisher niemandem aufgefallen war, der Bug aber seit Anfang an dabei ist. Hätte aber eigentlich längst auffallen müssen.

    Man könnte das in langen Testreihen mit jeder Version durchprobieren - da es aber einen recht einfachen WorkAround gibt, ist das vermutlich genauso überflüssig wie die Meldung selbst in dem hier geschilderten Fall. 8)

    @MoNeo
    Öhh...Nööö....

    Deswegen hatte ich ja den ganzen Streß, weil er eben nicht verschlüsselt,
    wenn diese Option "->Konto->Eigenschaften->Unverschlüsseltes Senden bestätigen"
    angehakt ist.

    wäre es nicht so,dann hätte ich es doch auch nicht gemerkt...

    Ich habe sozusagen das unverschlüsselte Senden bestätigt (durch Eingabe der Zieladresse) und siehe da, die Mail kam verschlüsselt an. Ließ sich auch problemlos entschlüsseln, insofern ist wirklich nur dieser Dialog überflüssig.

    Inwiefern ist ein Frickelprojekt aus von Spenden lebenden Hobbyisten seriöser als eine Lösung, für die Spezialisten bezahlt werden?

    Gwen spielt wohl eher darauf an, dass die Menschen, die hinter GnuPG stehen sich in die Karten schauen lassen, die Software mit offenem Quellcode zur Verfügung steht und somit von jedem, der es sich zutraut, geprüft werden kann. Das geht bei PGP leider nicht, insofern kann ein Nutzer von PGP nicht sicher sein, dass die Menschen hinter PGP (freiwillig oder auf Druck von außen) kein Backdoor in die Software eingebaut haben.

    Übrigens ist 'Frickelprojekt' ziemlich weit hergeholt. Die Entwicklung von GnuPG (und in DE von GPG4Win) wird auch von vielen staatlichen und großen privaten Institutionen gefördert - z.B. durch die Bereitstellung von Entwicklerressourcen.

    Da das eine ausschließlich browserseitige Lösung ist, funktioniert sie nur mit Webmail bzw. mit der entsprechenden App und darüber hinaus nur zwischen den o.g. Anbietern. Über einen MUA wie TB! kann man sie also nicht nutzen.

    Das ist so nicht ganz korrekt. Das eingesetzte Mailvelope erlaubt den Export der Schlüssel (sowohl public als auch private) und ermöglicht damit auch die Nutzung der Verschlüsselung und das lesen der signierten/verschlüsselten Mails außerhalb des WebMailers.

    Möchte man dies nutzen, benötigt man innerhalb von TB! keine PlugIns, allerdings muss GnuPG auf dem Rechner installiert sein und in TB! entsprechend konfiguriert werden.

    Solange der Text der Mail (also im Body) nicht geändert wird, läuft das Makro beim Wechsel in das Body-Feld erneut. Erst wenn TB! Änderungen im Body erkennt, wird das Initial-Makro nicht noch einmal durchlaufen.

    Wenn Du also erst die Mail selbst und am Ende den Betreff änderst, sollte es klappen.

    Nein, ich habe die 32-bit Version im Einsatz und werde auch mit dieser die Tests durchführen. Ich wüsste aber nicht, dass die 64-bit Version andere Ergebnisse erzeugt als die 32-bit. Wenn das Programm bei der Mail und/oder Signatur-Erzeugung abbricht, hat das ja keinen Einfluss auf das zu versendende Ergebnis. Oder?

    Für Teilnehmer vielleicht noch eine Info, die ich direkt vom Organisator bekommen habe: "

    Zitat von J. Kubieziel

    Bitte betrachte die E-Mails, die du schreibst, als öffentlich. Ich will das Mailarchiv und den privaten Schlüssel von <gnupg-test@kubieziel.de> veröffentlichen. Andere sollen das auch mit deren Mailprogramm testen können.

    Wer also z.B. seine Mailadresse nicht veröffentlicht wissen möchte, sollte sich vielleicht eine dedizierte Wegwerfadresse (und einen passenden Schlüssel) einrichten. GMX oder Web.DE wäre da ob Ihrer aktuellen Initiative eine Idee.

    Hallo,

    der Krautspace Jena hat vor einiger Zeit ein Projekt aufgelegt, das die Fähigkeiten verschiedener Mailprogramme bzgl. der Zusammenarbeit mit GnuPG untersuchen will.

    In deren Wiki sind bereits einige Programme bewertet worden. In der Liste der MUAs ist auch The Bat! aufgeführt, leider noch ohne entsprechende Bewertung.

    Auf der Projektseite ist das gewünschte Vorgehen ausführlich beschrieben. Ich werde mich mit meiner 'veralteten' 6.8.8 und GnuPG 2.1 (aus GPG4Win) daran versuchen und würde mich freuen, wenn jemand mit abweichender Konfiguration (z.B. interne PGP Implementierung) auch einschalten würde.

    Hallo,

    der Hinweis mit 'Teil.txt' würde meiner Meinung nach darauf hinweisen, dass die Mail mit verschiedenen Parts kodiert wird.

    Wenn Du Dir die Mails im Quelltext anschaust (standardmäßig mit F9 aufrufbar) - siehst Du da Unterteilungen? Wäre es vielleicht möglich eine dieser falsch angezeigten Mails zur Verfügung zu stellen?

    Hallo,

    das klingt, als würden die Mails einen Signaturtrenner (üblicher weise "-- " oder "-----" - jeweils ohne die Anführungszeichen) enthalten.

    Man kann einstellen, ob für die Texte hinter den Signaturtrennern eine andere Schrift gewählt werden soll und/oder ausgeblendet werden soll. Wo genau, habe ich gerade nicht parat, aber das Stichwort Signaturtrenner sollte weiteres Suchen erleichtern.