Too much to write about everything!
Fragt sich nur wie lange. 5 Minuten? 10 Minuten?
Ich frage mich, wie lange es noch dauert, bis KDE wieder einen stabilen Stand erreicht. Früher wurden solche Software als unstable bezeichnet. Die Zeiten scheinen vorbei.
Update 24.10.2013: Mit einigen Mühen bin ich wieder beim alten KDE 4.10.5, da ist der Fehler weg.
Wie ich schon berichtet habe, kann SpamAssassin mittels sa-learn nicht die im mbox-Format gespeicherten Mails lernen. sa-learn erkennt keine Mails in dem von kmail2 verwendetet mbox-Format. Nach langem Rätseln habe ich gestern eine minimale Mail erzeugt und diese mit kmail (Version 1.36.6) und mit kmail2 (Version 4.8.3) empfangen und gespeichert. Der Vergleich ergab einen wesentlichen Unterschied in der „From_“ Zeile und führte schließlich zur Klärung der Ursache.
In kmail (Version 1) Datum und Uhrzeit waren im ctime Format, wie unter RFC 4155 oder man 5 mbox beschrieben. kmail2 verwendet ein Datum-Zeit-Format wie in RFC 822 beschrieben. Leider gibt es keinen – einheitlichen – Standard für das mbox-Format bzw. die Definitionen für das Datums-Zeit-Format in der „From_“ Zeile widersprechen sich. Diese Zeile ist jedoch für die Trennung der Mails in der mbox -Datei entscheidend. SpamAssassin erkennt derzeit das zweite Format nicht als eine gültige „From_“ Zeile.
Dieses Problem habe ich bei KDE (Bug 297198) und bei SpamAssassin (Bug 6703) gemeldet.
Um SpamAssassin endlich wieder ein paar Mails lernen zu lassen, habe ich das – neue – Format mit sed quick and dirty in das – alte – ctime Format konvertiert. Da rechnen in sed nicht so einfach ist, habe ich von einer Anpassung der Uhrzeit an die Zeitzone UTC (+0000) abgesehen. Für eine bessere Lösung müsste ich wohl mit awk oder anderen Programmen arbeiten, was nicht so schnell umsetzbar ist. Hier der sed-Befehl in seiner vollen Schönheit:
Das einfachste wäre, kmail2 ginge zum alten Datum-Zeit-Format zurück. Vielleicht bewegt sich auf der einen oder anderen Seite etwas. Bei SpamAssassin bewegte sich in den letzten Stunden sehr viel – bei KDE nichts außer meine Kommentare.
Wer openSuSE 11.4 mit KDE und Kontact / Kmail nutzt, dem kann ich nur dringend raten, von einem Update auf 12.1 die Finger zu lassen. Kmail ist mit der Umstellung von 1.x auf 2. derart fehlerhaft, dass es für eine produktive Umgebung absolut ungeeignet ist. Auch ein Update der in 12.1 enthaltenen Version 4.7.x Version auf 4.8.0- über die Original Repositories von KDE bringt keine ausreichende Abhilfe. Durch die Verschiebung der Mails in ein MySQL Datenbank gibt es auch keinen einfachen Weg zurück.
So viel Schrott auf einen Haufen habe ich in den letzten 10 Jahren nicht erlebt. Wie konnte diese Software aus überhaupt aus dem Beta Stadium kommen?
Ein wenig probieren, auch mit anderen Adressaten, und die Tatsache, dass einige Mails richtig ankamen, brachte mich die letzten Tage einer Lösung der Frage näher, warum in kmail nicht alle s/mime verschlüsselten Mails automatische entschlüsselt werden (siehe hier).
Auf einigen Wegen kamen die Mails richtig an, auf anderen falsch. Im Thunderbird wurden sie immer entschlüsselt. Dies veranlasste mich im RfC 2633 nachzulesen. In Kapitel 3.8 ist beschrieben, wie ein Client einen s/mime Anhang erkennen soll. Siehe da, kmail müsste den Anhang auch anhand des Dateinamens und der Endung p7m, p7s oder p7c erkennen. Der RfC berücksichtigt bereits, dass es Gateways gibt, die mit s/mime nichts anfangen können und aus pkcs7-mime einfach octet-stream machen. Vermutlich ist der Lotus Notes Client nicht der Verursacher, denn er würde es jedes Mal falsch machen, sondern ein nicht richtig konfiguriertes Gateway, das auf dem Weg der Mail durch den Dschungel des Netzes steht.
Eine Prüfung meiner /etc/mime.types ergab: Hier fehlte für application/pkcs7-mime der Eintrag einer Dateinamenserweiterungen. Zufügen half nicht (ich hatte keine Lust auf einen Neustart, der Linuy-untypisch wäre.) Eine Kontrolle der Dateizuordnungen im konqueror zeigte: Auch hier war apllication/pkcs7-mime keine Erweiterung zugeordnet. Eine einfacher Eintrag half nur bedingt, weil jetzt kleopatra nicht damit umgehen konnte. Die Dame hielt die Datei für ein Zertifikat. Nun, dem konnte ich mit dem parameter –decrypt-verify statt –import abhelfen. Nur leider wird damit die Datei in kmail nicht in-line dargestellt, sondern nur entschlüsselt auf der Platte abgelegt. Da blieb mir nur, einen Bug Report (282882) bei Kde zu erzeugen.
So kann man auch den Abend verbringen.
Ein wunderbares Beispiel für das verzwickte Zusammenspiel von Rechnern und Protokollen.
Gute Nacht.
PS: Thunderbird macht es richtig. Evolution muss ich nochmal ausprobieren.
Update: Ich sollte nicht so müde und spät Artikel schreiben. Hoffe, nach dem Korrekturlesen sind jetzt weniger Fehler drin und die Sätze flüssiger.
Heureka!
Heute habe ich es endlich geschafft die X.509 Verschlüsselung unter Linux in Kontact / Kmail einzurichten. Meine früheren Bemühungen waren mangels Kommunikationspartner extrem halbherzig. Noch bin ich nicht ganz am Ziel, aber für meinen Zweck reicht es im Moment. Da viele Firmen Public Key Infrastuctures einführen, kann sich ein Mitarbeiter verschlüsselte Nachrichten an das private Postfach senden. Die IT-Sicherheit wird es freuen ;-).
Hier eine kleine Beschreibung des Weges.
Kleines Script um alle importierten Keys in die Datei trustlist.txt aufzunehmen.
trustthemall.sh
gpgsm –list-keys 2>/dev/null \
| egrep ‚(fingerprint|Issuer)‘ \
| sed ‚/fingerprint/ s#:##g; /fingerprint/ s#$# S#;s#^.*fingerprint ##;/Issuer/ s!^!#!‘ \
>>~/.gnupg/trustlist.txt
Das Einrichten der eigenen CA mit Hilfe der grafischen Anwendung von TinyCA2 ist ein Kinderspiel und selbst erklärend. Die Software findet sich hier. Es geht zwar auch händisch mit openSSL, wenn man etwas mehr Schlüssel verwalten und Zeit sparen will, rate ich davon ab.
Meine – öffentlichen – Zertifikate
CA-Certificate
Mein X.509 Zertifikat