Schlagwort-Archive: Kontact

OpenSuSE 12.1 und kontact / kmail 4.7.x oder 4.8.x

Ein kleines Update zu meinen Problemen mit kontact und kmail2. Ich bin jetzt bei der Version 4.8.3 angelangt und die wesentlichen Dinge funktionieren noch immer nicht.

  1. Die Mails lassen sich nicht in ein spamassassin verträglichen mbox Format exportieren. Dies ist sehr lästig, da dadurch das training des Bayes Filter in Spamassassin seit Wochen nicht funktioniert.
  2. Nur ein kleiner Teil der Mails wird durch die Filter in die Ordner verschoben. dies ist sehr lästig, weil ich alle Mails der Arten CRON-Job, SPAM oder Newsletter von Hand nachträglich sortieren muss.
  3. Filtern von Hand wirkt neuerdings erst nach zwei bis drei Minuten.

Es bleibt dabei, KDE 4.7 / 4.8 ist nicht für den produktiven Einsatz geeignet.

OpenSuSE 12.1

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?

E-Mail Verschlüsselung unter Lotus Notes – Fortsetzung

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.

S/MIME Verschlüsselung in Kontact und Kmail

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.

  1. Mit TinyCA2 eine eigene CA eingerichtet.
  2. Ein eigenes Zertifikat erzeugt und in Kleopatra importiert
  3. Fremde Zertifikate importiert.
  4. Erster Versuch der Verschlüsselung schlug wegen mangelnder Vertrauenswürdigkeit der Zertifikate fehl. Schlüssel konnten nicht den Kontakten zugeordnet werden.
  5. Ein Schlüssel-Server für die Revocation Lists half nicht.
  6. Probiert einen Weg zu finden, die Vertrauenswürdigkeit zu ändern. Leider waren alle Meüeinträge für X.509 grau.
  7. Gegooglet – nichts hilfreiches gefunden – weiter gegooglet – im Forum versteckte Lösung gefunden. Keine Lust zum Anmelden, also noch mehr googeln.
  8. Endliche ein Hinweis auf gpg-agent und dem Parameter allow-mark-trusted in ~/.gnupg/gpa.conf sowie die Datei ~/.gnupg/trustlist.txt gefunden.
  9. Die vertrauenswürdige Keys in trustlist.txt angefügt, allow-mark-trusted eingefügt und siehe da es klappte. Leider an zwei Schrauben gedreht.
  10. Eine Schrauen zurück andere gedreht und siehe da, dass Geheimnis ist die Datei trustlist.txt.
  11. Befehl zum Anfügen der Keys in der trustlist.txt verfeinert.
  12. Beitrag geschrieben

Kleines Script um alle importierten Keys in die Datei trustlist.txt aufzunehmen.

trustthemall.sh

#!/bin/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