13.September.2014: Erneuert: Add-On für Mozilla Thunderbird: Enigmail (von Patrick Brunschwig) 1.8a1pre
Korrektur für fehlerhafte Signatur-Anzeige von buerger-cert.de
https://www.enigmail.net/download/nightly.php
> Extras > Add-Ons > Werkzeug-Symbol > Add-Ons aus Datei .. > enigmail-nightly-all.xpi
=> Die E-Mails von buerger-cert.de werden alle wieder als korrekt signiert angezeigt.
Habe leider erst jetzt folgende Seite gefunden:
http://sourceforge.net/p/enigmail/bugs/301/
Ich übersetze mal die Antwort von Patrick Brunschwig am 2014-08-10
"Ich kann den Fehler jetzt auch nachvollziehen.
Das Problem ist, dass die Signatur nur dann gültig ist, wenn man das <LF>-Zeilenende (z.B. Linux-Art) benutzt. Aber die Nachricht ist (richtig) gespeichert unter Benutzung des <CR><LF>-Zeilenendes, wie in RFC 3156 festgelegt.
Die Nachricht scheint ohne die "--textmode" -Einstellung von GnuPG erzeugt worden zu sein; deshalb ist die Signatur ungültig, wenn das richtige Zeilenende angewendet wird.
Dies muss Absender-seitig berichtigt werden."
Ich habe Bürger-Cert darüber informiert.
Thunderbird scheint in einer neueren Version das Abspeichern von E-Mails geändert zu haben, sodass die ursprünglich mit <LF>-Zeilenende geschickte E-Mail dann mit <CR><LF>-Zeilenende versehen wurde, allerdings nur dann, wenn ein IMAP-Ordner benutzt wird. Beim Kopieren unterhalb der lokalen Ordner wird das Zeilenende nicht verändert.
Ich hatte ja schon festgestellt, dass Thunderbird 31 die E-Mails beim verschieben/kopieren in IMAP-Ordner und beim Abspeichern als Datei so verändert, dass die Signatur von Enigmail als falsch erkannt wird.
Die führende From-Zeile wird beim Abspeichern entfernt.
*** edit ***
Vergesst das mit den fehlenden Zeilen: Thunderbird speichert die .eml mit Windows-Zeilenende.
Zumindest für die von Buerger-Cert als .eml-Datei abgespeicherten habe ich einen Weg gefunden, dass die Signatur wieder als korrekt erkannt wird:
> (unter Linux) > Bearbeiten mit gedit > ***Nichts ändern*** > Speichern unter > Zeilenende: Unix/Linux > Speichern.
Wenn man die .eml-Datei nun mit Thunderbird öffnet, zeigt Enigmail: Korrekte Unterschrift
Das ganze Problem tritt auch nur mit den Bürger-Cert-E-Mails auf.
Bei von mir selbst erstellten (Nicht-Multipart) gibt es keinen dieser Effekte, auch nicht beim abspeichern, trotz Windows-Zeilenende.
Sehr merkwürdig das Ganze.
Folgendes habe ich noch festgestellt:
1. Korrekte E-Mail in Thunderbird aus lokalem Ordner in anderen lokalen Ordner kopiert => Kopie wird von Enigmail als korrekt erkannt.
2. Selbe Korrekte E-Mail erst in einen IMAP-Ordner kopiert und dann in den selben lokalen Ordner => Diese Umweg-Kopie wird _nicht_ als korrekt erkannt.
3. Von Thunderbird angezeigten Quelltext beider Kopien in Textdateien.eml hineinkopiert und mit Unix/Linux-Zeilenende abgespeichert.
=> nach Öffnen in Thunderbird werden diese .eml _beide_ als korrekt erkannt.
Das Inkorrekte scheint also an der Speicherung/Behandlung innerhalb Thunderbirds für die IMAP-Ordner zu liegen.
Es könnte doch ein Problem von Thunderbird 31 sein:
Die älteren als korrekt erkannten E-Mails liegen bei mir in einem lokalen Ordner.
Wenn ich diese in einen anderen lokalen Ordner verschiebe/kopiere, werden diese nicht verändert und weiterhin als korrekt signiert erkannt.
Wenn ich diese jedoch als Datei speichere oder in einen IMAP-Ordner verschiebe/kopiere (auch zurück-verschiebe), dann hat sich der Quelltext wie folgt verändert: Oben wurde eine Zeile entfernt, z.B.:
From - Tue Mar 4 14:17:23 2014
Weiter unten wurden z.B. folgende Zeilen entfernt:
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Diese E-Mails mit den fehlenden Zeilen werden dann nicht mehr als korrekt signiert erkannt.
Die neueren bereits im lokalen Archiv gespeicherten, _nicht_ als korrekt signiert erkannten enthalten aber diese obigen Zeilen, allerdings fehlt die X-UIDL-Zeile.
Eine im IMAP-Posteingang befindliche E-Mail, die glaube ich nie verschoben wurde, enthält die ganzen führenden X-Zeilen nicht, sondern beginnt mit:
Return-Path: mailversand@buerger-cert.de
Allerdings wird auch die _nicht_ als korrekt signiert erkannt.
Beispiel: Quelltext-Anfang (Der Rest ist identisch):
1. Im lokalen Ordner gespeichert und als richtig erkannt:
---
From - Tue Mar 4 14:16:47 2014
X-Account-Key: account2
X-UIDL: ***Nummer-ID-gelöscht***
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: mailversand@buerger-cert.de
Received: from mail.cert-bund.de ([93.187.113.4]) by mx-ha.web.de (mxweb106)
with ESMTP (Nemesis) id ***Nummer-ID-gelöscht*** for <***GELÖSCHT***@web.de>;
Fri, 14 Feb 2014 16:50:38 +0100
2. In einen IMAP-Ordner kopiert und dort als falsch erkannt:
---
X-Account-Key: account2
X-UIDL: ***Nummer-ID-gelöscht***
X-Mozilla-Keys:
Return-Path: mailversand@buerger-cert.de
Received: from mail.cert-bund.de ([93.187.113.4]) by mx-ha.web.de (mxweb106)
with ESMTP (Nemesis) id ***Nummer-ID-gelöscht*** for <***GELÖSCHT***@web.de>;
Fri, 14 Feb 2014 16:50:38 +0100
Ich habe schon versucht, in die gespeicherte => falsche E-Mail die Zeilen aus dem richtigen Quelltext hineinzukopieren, aber sie wurde auch als falsch erkannt. * editiert: * Das lag wohl am falschen Zeilenende (Windows statt Unix/Linux). Mit dem Unix/Linux-Zeilenende funktioniert es wohl. ------------->>> siehe nächster Beitrag
Ubuntu-Linux 14.04.1 LTS, Thunderbird 31, IMAP, Web.de, Enigmail 1.7
Hallo, habe gerade das gleiche Verhalten festgestellt. Allerdings werden ältere E-Mails des Buerger-Cert als korrekt Signiert angezeigt.
Bis zum: 26.02.2014 > Details
"
Korrekte Unterschrift von Buerger-CERT Signatur-Schluessel <mailversand@buerger-cert.de>
Schlüssel-ID: 0xF4C48B4C / Unterschrieben am: 26.02.2014 19:17
Schlüssel-Fingerabdruck: 5774 E00D 9C28 19EC 9C86 D3B4 DD68 333B F4C4 8B4C
"
Ab dem: 05.03.2014 > Details
"Enigmail Unterschrift NICHT überprüft"
"FALSCHE Unterschrift von Buerger-CERT Signatur-Schluessel <mailversand@buerger-cert.de>"
> Schlüsseleigenschaften
"
Primäre Benutzerkennung: Buerger-CERT Signatur-Schluessel <mailversand@buerger-cert.de>
Schlüssel-Kennung: 0xF4C48B4C
Fingerabdruck: 5774 E00D 9C28 19EC 9C86 D3B4 DD68 333B F4C4 8B4C
"
