Category Archives: KDE

Beiträge zu KDE Programmen

Kmail: (Mit-) Leid mit Outlook-Empfängern

Posted on by

Heute bekam ich es mit einem wütenden Kunden zu tun, der Outlook benutzt. Ich hatte ihm für ein Projekt eine Excel-Datei mit Kalkulationsdaten geschickt. Diese Datei konnte er nicht öffnen. Vielmehr sei Nero mit einer Fehlermeldung am Schirm erschienen, hielt er mir entgegen. Ob ich ihm Musik statt Zahlen verkaufen wolle? Glücklicherweise hatte ich die Mail in Kopie noch an einen anderen Empfänger verschickt, der Thunderbird unter Windows XP benutzt. Letzterer konnte den Anhang – also die Excel-Datei – sofort und ohne Schwierigkeiten öffnen und weiterverarbeiten. (Ein erster aufmunternder Pluspunkt für mein gekränktes Gemüt!)

Wirklich überzeugt hat das meinen Kunden aber noch nicht. Selbst neugierig geworden, bat ich ihn, mir meine Mail zurückzuschicken. Sie enthielt meinen ursprünglichen Anhang tatsächlich in stark modifizierter Form – nämlich als Datei mit der Endung “.dat” und einem von Outlook dazugedichteten Namen. Beim erbosten Kunden führte diese Endung dazu, dass sich Nero öffnete und gleich wieder mit einer Fehlermeldung verabschiedete. (Auf einem Windows-System ohne Nero hätte wahrscheinlich der MS Media-Player versucht, den Anhang darzustellen.) Unter Linux öffnete Openoffice den verunstalteten Anhang übrigens ohne Klagen (Ein zweiter Pluspunkt – ich entspanne mich langsam wieder !).

Mails aus dem Microsoft Outlook/Exchange-Umfeld mit seltsamen dat-Datei-Anhängen kannte ich schon aus alten Lotus Notes und Domino Tagen. Diesmal war die Problemrichtung aber umgekehrt … Und nachdem die Excel-Datei eine Original-Excel-Datei war und nicht eine Datei, die ich mit OpenOffice erstellt und ins xls-Format umgewandelt hatte, kam ich dann doch ins Grübeln.

Was macht mein Kmail hier falsch? Liegt es vielleicht an Einstellungen von Cyrus und Postfix auf meinem Email-Server? Und natürlich stellt sich die Frage: Warum kann Outlook eigentlich eine von einem Microsoft-Programm erzeugten Datei als Email-Anhang nicht richtig verarbeiten?

In meiner Ratlosigkeit habe ich erst mal in den Einstellungen von Kmail gestöbert. Irgendwas mit Outlook hatte ich da doch schon mal gesehen … Und richtig: Unter “Komposer -> Anhänge” fand ich schließlich eine Option zur Outlook-Kompatibilität. Aktiviert man die, so erhält man einen netten und vielsagenden Hinweis der KDE-“Kontakt”-Entwickler:

“Sie haben sich dazu entschieden, die Namen von Anhängen, die nicht-englische Zeichen enthalten, so zu kodieren, dass Outlook(tm) und andere nicht den Standards folgende Programme diese verarbeiten können. Beachten Sie bitte, dass auch KMail in dieser Einstellung E-Mails erstellt, die eventuell nicht den Standards entsprechen und daher Probleme bei E-Mail-Programmen verursachen können, die sich an die Standards halten. Sie sollten diese Option also nur dann aktivieren, wenn es unbedingt nötig ist.”

Das ist wirklich deutlich genug und braucht nicht weiter kommentiert zu werden ! Balsam für die gedemütigte Linux-Seele !

Wie hatte ich doch gleich die Excel-Datei genannt ? Ach ja: “übersicht.xls”. Das war natürlich wenig vorausschauend – ist aber mal passiert.

Nachfolgende Tests und ein paar Recherchen im Internet ergaben:
Outlook hat vielfältige Schwierigkeiten mit der Behandlung von Umlauten (in Adressen, in Anhangsnamen, im Inhalt). Das Problem mit der Behandlung von Umlauten im Namen anhängender Dateien ist ein relativ spezielles. Die Schwierigkeiten rühren wohl daher, dass Outlook – im Gegensatz zu aktuellen Linux-, Apple- und Opensource Mailclients – einen veralteten RFC-Standard für den Transfer solcher Anhänge benutzt. Beim Empfang wandelt Outlook dann die betroffenen Dateien in “.dat”-Dateien mit selbst generiertem Namen um.

Die Aktivierung der Option in Kmail zur Outlook-Kompatibilität hilft denn auch tatsächlich, dieses Problem zu umgehen. Dann schaltet Kmail auf den alten Standard um. Aber will man sich eigentlich dem Diktat unzureichender Software beugen?

nNein: Die viel bessere Lösung ist natürlich, gar keine Dateinamen mit landesspezifischen Umlauten zu verwenden, wenn man als Linuxer über Kmail Anhänge an Kunden verschickt, die Outlook benutzen müssen. (Man muss halt nur wissen, dass es hier überhaupt ein Problem gibt!) Und bzgl. der Option in Kmail sollte man lieber die Warnung beherzigen und sie nicht aktivieren.

Mein Kunde hat inzwischen die schöne Kmail-Warnung und Hinweise auf entsprechende Artikel im Internet als Abendlektüre erhalten. Plus einer Datei namens “uebersicht.xls”. Ich vermute, der Vorgang wird nicht zur Abschaffung von Outlook in der Firma des Kunden führen – aber ein gutes Gefühl bleibt einem als Linux-Anwender am Ende doch.

Bei Kmail habe ich innerlich schon Abbitte geleistet – dort ist diese Sache vorbildlich geregelt und kommentiert. In Thunderbird gibt es übrigens eine entsprechende Option – viel Spaß beim Suchen.

Links:
http://forum.univention.de/viewtopic.php?f=28&t=128
http://www.maczeug.de/page1/page28/page28.html

Firefox 3.0 ohne verbesserte Bildskalierung unter Linux

Posted on by

Gerade habe ich Firefox 3.0 unter Windows und unter Linux installiert. Neben vielen positiven Dingen muss ein für Linux Anwender sehr enttäuschender Punkt angesprochen werden:

Im jetzigen Release 3.0 funktioniert das “smooth image scaling”, das im Vorfeld so viel Furore machte, unter Linux überhaupt nicht, während es unter Windows wirklich beeindruckende Ergebnisse zeitigt.

Inzwischen wurde bereits ein Mozilla-Bug zu dieser Thematik eröffnet. In einem Kommentar zur Bugmeldung wird allen Ernstes empfohlen, sich bei den Linux-Distributoren zu beschweren, da im X-Server benötigte Features fehlen würden. Dazu ist aus Anwender-Sicht Folgendes zu fragen bzw. anzumerken:

1) Fehlt nun etwas in Xorgs X-Server oder implementieren die Packages der Distributoren X nur eingeschränkt?
2) Man versteht als unbedarfter Mensch nicht, was X überhaupt mit der Thematik zu tun haben soll. Müsste dieses Thema nicht eine Ebene höher angegangen werden? Firefox ist doch unter Linux wohl GTK basiert und liefert GTK nicht etliche Funktionen, um eine ordentliche bikubische Interpolation von Images durchzuführen?

Egal wie: Als Linux User bin ich erstmal enttäuscht. Das wird jeder verstehen, wenn er folgende zwei Bilder vergleicht – das erste wurde im FF 3.0 unter Linux gemacht, das zweite im FF 3.0 unter Windows (das natürlich im VMware-Fenster läuft) – bei gleicher Vergrößerungsstufe :

anracon_logo_FF_linux anracon_Logo_windows

Die Enttäuschung ist umso größer, als hier eine Opensource-Firma die Anwender des Opensource-Betriebssystems Linux offenbar als Anwender zweiter Klasse behandelt. Denn dass eine gute Bildskalierung unter Linux ein prinzipielles und ernsthaftes Problem darstellen soll, glaube ich nicht. Das Gegenteil ist durch GIMP, Scribus und diverse PDF-Programme bereits bewiesen. Vielleicht lassen sich aber die Windows-spezifischen Algorithmen nicht 1 zu 1 auf X, KDE und Gnome übertragen. Man müsste wohl eigene Lösungen entwickeln. Die Veröffentlichung des jetzigen Releases zeigt aber wohl, dass die Mozilla-Entwickler dies bislang versäumt haben. Ein schnelles Windows-Release ist inzwischen wohl wichtiger als gute Qualität auf verschiedenen Betriebssystemen ……

KGpg – Schlüsselimport mit Fehlern

Posted on by

Man müht sich ab, seinen Kunden beizubringen, wichtige Informationen im Internet verschlüsselt zu übertragen. Eine Voraussetzung dafür, dass der Kunde sich mit den entsprechenden Verfahren anfreundet, ist, dass das Erzeugen eines Schlüsselpaares und das Verteilen des öffentlichen Schlüssels ohne größere Schwierigkeiten durchgeführt werden kann – unter Linux wie unter Windows. Leider können hier auch unter Linux Schwierigkeiten auftreten, die den Anfänger überfordern.

Vor kurzem konnte ich die Probe aufs Exempel machen – ein Kunde, der Thunderbird unter Windows einsetzt, lud sich das Enigmail-Plugin und GnuPG für Windows herunter. Die Installation verlief problemlos. Ebenso nach einer kurzen Einweisung die Suche nach meinem “public key” und der Import des Schlüssels von einem PGP-Server in den Schlüsselring. Der Kunde konnte mir dann auch ohne Schwierigkeiten verschlüsselte Mails schicken. So weit so gut.

Die Überraschung kam nach dem Generieren des eigenen Schlüssels. Die Erzeugung des Schlüsselpaares verlief wie erwartet. Der Kunde sah den Schlüssel, dessen Kennung (die letzten 8 Ziffern des Fingerprints) und bei einer Detailansicht auch den gesamten Fingerprint. Der Kunde versuchte dann seinen öffentlichen Schlüssel auf einen PGP-Server hochzuladen. Auch dies war ohne Problem möglich. Dann suchte der Kunde zur Probe nach seinem Schlüssel – zunächst mittels eines Statements der folgenden Art:

http://pgpkeys.pca.dfn.de/pks/lookup?op=vindex&hash=on&fingerprint=on&search=0x{16 Hex-Ziffern}

wobei “{16 Hex Ziffern }” durch die letzten 16 Hexadezimal – Ziffern des Schlüssel-Fingerprints zu ersetzen ist. Der Schlüssel wurde einwandfrei identifiziert und angezeigt. Dann probierte der findige Kunde jedoch folgendes Statement, bei der er dem “search”-Parameter nur die letzten 8 Stellen der Schlüssel-Kennung übergab (nur diese werden nämlich typischerweise in den Key-Verwaltungsprogrammen angezeigt):

http://pgpkeys.pca.dfn.de/pks/lookup?search=0x{8 Hex Ziffern = Schlüsselkennung}&fingerprint=on&hash=on&op=vindex

Wie es der (unwahrscheinliche) Zufall so will, kamen als Antwort 2 Schlüssel mit derselben 8-stelligen Kennung hoch – der des Kunden und einer, der im Jahre 1998 angelegt wurde. Diese “Konkurrenz” bzgl. der 8 stelligen Schlüsselkennung fand der Kunde sehr beunruhigend. Ich demonstrierte ihm dann, dass sein Schlüssel dennoch von dem des “Konkurrenten” verschieden war und dass die Schlüsselkennung und der Fingerprint ja eigentlich mehr als 8 Hex-Stellen umfassen. So zeigt z.B. KGpg unter KDE in der Detailansicht eines Schlüssels nicht 8 sondern die hinteren 16 Hex-Stellen des Fingerabdrucks an.

Der wirkliche Ärger begann aber, als ich versuchte, den öffentlichen Schlüssel des Kunden unter Linux/KDE in meinen eigenen Schlüsselring zu importieren. Das misslang unter KDE KGpg bei Einsatz des Standardimports von einem PGP-Server auf wirklich schlimme Weise:

Obwohl ich die eindeutige 16 stellige Kennung im Such/Import-Dialog angab, importierte KGpg beide Schlüssel – den des Kunden und des Konkurrenten. Noch schlimmer: In der Detailansicht wurde bei beiden Namen ein und derselbe Fingerprint (der des Kunden), aber die falsche Kennung (die des Konkurrenten) angezeigt. KGpg hatte also die beiden Schlüssel beim Import intern nicht sauber getrennt.

So etwas ist katastrophal! KGpg ist offenbar nicht in der Lage den Standard-Import von Schlüsseln zu regeln, wenn die letzten 8 Hex-Stellen der Kennung mit denen eines anderen Schlüssels identisch sind. Das Gleich geschah übrigens auch, wenn man nach der dem Schlüssel zugeordneten Namen bzw. der Web-Adresse suchte.

Testweise versuchte ich dann den Import unter Windows mit Thunderbird und den dahinter liegenden OpenPG-Programmen. Auch hier werden zwar zwei Schlüssel importiert – offensichtlich reagieren die Programme nur auf die letzten 8 Hex-Stellen. Aber der Import verlief mit der richtigen Zuordnung der Schlüssel zu den Namen und Webadressen.

Eine Lösung des Problems unter KGpg besteht darin, den Import des Kundenschlüssels manuell über die Zwischenablage durchzuführen. Für Einsteiger wäre das aber nicht zumutbar.