Da ist das Mailkonto so eingestellt, dass es automatisch eine BCC an mich selbst schickt.
Kannst Du das bitte näher erläutern? Sendest Du letztendlich an zwei verschiedene Deiner Konten oder zweimal an dasselbe? Wenn ich eine E-Mail an mich@provide sende und dabei mich@provider in bcc setze, dann bekomme ich diese E-Mail nur ein Mal zugestellt. Ich weiß nicht, ob bereits der TB die doppelte Adresse ausfiltert oder ob dies dann serverseitig geschieht, aber es kommt nur eine E-Mail an.
Kannst Du das bitte näher erläutern? Sendest Du letztendlich an zwei verschiedene Deiner Konten oder zweimal an dasselbe? Wenn ich eine E-Mail an mich@provide sende und dabei mich@provider in bcc setze, dann bekomme ich diese E-Mail nur ein Mal zugestellt. Ich weiß nicht, ob bereits der TB die doppelte Adresse ausfiltert oder ob dies dann serverseitig geschieht, aber es kommt nur eine E-Mail an.
Ich sende auf dem einen Rechner von meinem Konto z.B. bei Tonline und in der Mail steht:
Von: Sender@konto_tOnline.de
BCC: Sender@konto_tOnline.de
An: Empfänger@konto_gmx.de
Und auf dem zweiten Rechner kommen 2 Mails an. Eines an Sender@konto_tOnline.de und eines an Empfänger@konto_gmx.de
Ach ja: Einstellen kannst Du das unter "Konten-Einstellung" / "Kopien & Ordner" "Blindkopie an xyz".
Ok, wenn ich an zwei meiner Adressen sende, dann kann ich den Fehler nachvollziehen. Eines der beiden Konten wird blockiert. Ich muss den Prozess beenden, um TB neu starten zu können. Ähnlich wie bei bug 443, den ich dazu eröffnet hatte. Es könnte daran liegen, dass TB die Filter parallel ausführt.
Ich würde sagen, jetzt bist Du an der Reihe. Hänge Dich an meinen bug und lade die Logs hoch. Wenn es an Enigmail liegt, dann wird das sicher rasch gefixt. Mit etwas Glück noch in der 8.1.2.
Nachtrag: Ich habe den existierenden bug#443 um diese Fehlermeldung ergänzt und, für den Fall das Patrick es lieber in einem getrennten bug nachverfolgen möchte, mit bug#485 auch einen neuen eröffnet. Die 443 gilt ja bereits als gefixt, und die Ursache kann eine andere sein.
Ich habe eh ein wenig die Befürchtung, dass das eigentliche Problem im TB gelöst werden müsste. Aber, warten wir es mal ab.
Hallo,
ich möchte um die Mithilfe weiterer Tester bitten, vor allem vom PCCounselor aber auch von Linux- und Mac-Nutzern.
Es geht um den vom Counselor beschriebenen Fehler. Nachdem Patrick den Fehler nicht hat nachstellen können, habe ich heute unter Windows xp in einer VM getestet. Und siehe da, der Fehler tritt nicht auf. Wohl aber unter Ubuntu. Patrick vermutet einen Fehler in der für Ubuntu angepassten Version des TB.
Dazu passt aber nicht, dass dieser Fehler beim PCCounselor, der ihn ja entdeckt hat, unter Windows aufgetreten ist.
Schritte zum Reproduzieren:
Bitte benutzt für den Test die aktuelle Enigmail-Nightly von hier: https://www.enigmail.net/download/night…-branch-all.xpi
Falls es bei euch ebenfalls dazu kommt, dass einer der beiden Accounts die Nachricht nicht herunterlädt sondern beim Download hängen bleibt, dann geht bitte auf Enigmail > Fehlersuche -> Log anzeigen und speichert die Logs ab. Dann bitte in den Bug#485 hochladen: http://sourceforge.net/p/enigmail/bugs/485/
Danke
Susanne
Ich habe heute erneut einige Tests dazu gemacht. Ergebnis: Unter Windows konnte ich den Fehler nicht reproduzieren, unter Ubuntu zwar schon, aber nur mit der für Ubuntu angepassten Version des TB. Mit der Version von mozilla.org tritt der Fehler nicht auf.
PCCounselor, wenn Du diesen Fehler tatsächlich unter Windows mit der 1.8.2pre3 erzeugen kannst, dann wäre es wichtig, dass Du die logs dazu zur Verfügung stellst.
PCCounselor, wenn Du diesen Fehler tatsächlich unter Windows mit der 1.8.2pre3 erzeugen kannst, dann wäre es wichtig, dass Du die logs dazu zur Verfügung stellst.
Hallo Susanne,
mich hat das Thema auch nicht ruhen lassen. Und ich habe zuerst mal bei mir selbst gesucht.
Habe dazu mittels MozBackup meine Mails aus den letzten 10 Jahren gesichert und dann Thunderbird und das entsprechende Profil kpl. gelöscht.
Habe dann Thunderbird neu installiert und all meine Add-ons wieder eingespielt. Habe dann „enigmail-nightly-enigmail-1.8-branch-all.xpi“ eingespielt und das System so konfiguriert, das es mir gefällt.
Und nun ist der oben beschriebene Fehler weg. Sorry.
Vermutlich war meine Konfiguration irgendwie buggy. Zumindest kann ich den Fehler nun nicht mehr erzeugen.
Ist die „enigmail-nightly-enigmail-1.8-branch-all.xpi“ eigentlich wirklich identisch mit „enigmail-1.8.2-pre3.xpi“?
Dafür ist mir aufgefallen, dass ein anderer Fehler vorhanden ist.
Bei falschem Passwort werden Mails doppelt entschlüsselt
Habe mir dazu von einem anderen Rechner eine verschlüsselte Mail geschickt von Name@gmx.net an Name@t-online.de.
Basis ist ein Testrechner mit Win 8.1 und Thunderbird 31.6.0, sowie gpg4win-2.2.4;
Unter TB ist ein Filter angelegt: Bei "Manuellem Ausführen" + "bei Nachrichtenabruf" "nach Junk-Erkennung ausführen.
Als Bedingung habe ich definiert: "An enthält (u.a.) name@t-online.de" und als auszuführende Aktion: "Entschlüsselte Kopie anlegen (Ennigmail) in Ordner "Ennigmail" in Persönliche Ordner"
Also, irgendwie ist die neue Version noch nicht rund.
Grüße aus dem Bergischen Land
Hallo PCCounselor,
zunächst zum Problem des cc. Das gestaltet sich sehr merkwürdig. Ich hatte mir gestern ein neues Test-Profil angelegt, um mit dem TB von mozilla.org zu testen. Ich habe darin ein paar Änderungen bzgl. des Offline-Bereithaltens vorgenommen und schon klappte alles wunderbar. Dann habe ich diese Änderungen wieder rückgängig gemacht, und es funktionert immer noch, mit beiden TB-Builds. Seitdem kann in den Fehler in diesem Profil nicht mehr erzeugen.
Es deutet alles darauf hin, dass der Fehler im TB-Profil zu steckt(e). Dazu passt, dass es bei nun auch nicht mehr auftritt.
Ist die „enigmail-nightly-enigmail-1.8-branch-all.xpi“ eigentlich wirklich identisch mit „enigmail-1.8.2-pre3.xpi“?
Nein, die beiden Versionen sind nicht identisch. Patrick hat in den Nightly noch die Option hinzugefügt, den Download abzubrechen. Falls der Download hängt erscheint eine Message-Box, über die man abbrechen kann. In meinen Tests hing das Konto dann zwar immer noch, aber im Gegensatz zu vorher konnte ich TB normal beenden und neu starten.
Dein neues Problem kann ich nicht nachvollziehen. Das scheitert schon bei Schritt 7. Wenn ich in Schritt 6 die korrekte Passphrase eingebe, dann wird sie nicht wie bei Dir in Schritt 8 als ungültig abgewiesen. Bei mir geht alles normal weiter. Auch die Kopie wird erst angelegt, wenn ich das Filter dann ausführe.
Ich vermute auch, dass Enigmail für das Anstarten des Filters gar nicht zuständig ist, sondern dass dies aus dem TB erfolgt. Zumal das Filter in diesem Fall ja auf "manuell" steht.
Ich habe auch getestet, indem ich das Filter vor der Eingabe der Passphrase, also noch bevor ich die E-Mail anklicke, manuell ausführen lasse. Dann fragt Enigmail nach der Passphrase. Auch wenn ich diese zunächst falsch eingebe verhält sich alles normal.
Ich schlage vor, dass Du zu diesem Thema einen eigenen Faden eröffnest. Hier wird es sonst sehr unübersichtlich, weil wir bereits über drei verschiedene Probleme schreiben, von denen eines bereits behoben wurde und ein anderes irgendwie am TB-Profil hängt.
Gruß
Susanne
Hallo,
bezüglich des Request for Enhancements, die Möglichkeit zu schaffen, eine entschlüsselte Kopie nicht nur per Filter sondern auch über das Kontextmenü (rechte Maustaste) zu ermöglichen, gab es gestern ein Update von Patrick. Er hat die Funktion in den aktuellen Nightly (1.9a1pre) integriert. Dort gibt es nun einen zusätzlichen Menüeintrag "Decrypt to Folder".
Man beachte, dass Enigmail 1.9 nicht mehr mit GnuPG 1.x funktionieren wird.
Gruß
Susanne
Danke Susanne für den Hinweis,
habe die Version 1.9a1pre installiert. Irgendwie sehe ich aber (nach einem Klick auf die rechte Maustaste) keinen entsprechenden Menüpunkt "Decrypt to Folder".
Also bei mir ist der Eintrag vorhanden. Hab's unter Windows getestet, weil ich nur dort GPG 2.x zur Verfügung habe. Falls Du die 1.9 "drüberinstalliert" hast, versuche es einmal mit entfernen und neu installieren.
Nachtrag: Hab's jetzt auch unter Linux getestet. Alles gut. Vielleicht musst Du einfach mal wieder den Monitor putzen? 
Falls Du die 1.9 "drüberinstalliert" hast, versuche es einmal mit entfernen und neu installieren.
Danke, der Tipp war gut. Jetzt sehe ich es auch
