Category Archives: Kontact – Kmail

Beiträge zur Integration von KDE Kmail mit OX 5

Kmail, GnuPG, Thunderbird, enigmail und kryptierte HTML-Mails zwischen Linux und Windows Usern

Posted on by

Man kann sich nicht immer aussuchen, mit wem man in Projekten wie kommuniziert. So bin ich als Linuxer natürlich oft mit Kunden konfrontiert, die ein MS Betriebssystem nutzen. Einige dieser Kunden setzen in der Kommunikation mit mir inzwischen vernünftigerweise folgene Mittel ein:

  • Sie stellen entweder kryptierte Verbindungen zu speziellen ihrer Mail-Server zur Verfügung
  • oder aber sie verwenden die Kombination Thunderbird/GnuPGP/enigmail, um Mails zu verschlüsseln und an mich zu versenden, in denen schützenswerte geschäftsrelevante Informationen hinterlegt sind. Hierzu haben wir unsere Public OpenPGP Keys ausgetauscht.

Generell hat die Bereitschaft von Kunden, Mails (Ende zu Ende) zu verschlüsseln, seit den publizierten Ereignissen im IT-Security-Umfeld der letzten zwei Jahre zugenommen.

Manchmal taucht nun das Thema auf, dass Kunden in der Mail Dinge farblich oder fett markieren wollen. Das sind sie aus der firmeninternen Kommunikation so gewohnt. Damit steht dann der Wunsch nach etwas auf der Tagesordnung, das eine Quelle von viel Unheil darstellt – nämlich der Wunsch nach HTML-formatierten Mails. Aus Security-Perspektive stellt das etwas dar, was man aus meiner Sicht unbedingt vermeiden sollte. Formatierte Information gehört in Anhänge, nicht in den Body einer Mail. Aber ist dieser Anspruch praxisnah und vermittelbar? Mein Erfahrung ist: Nicht jeder Kunden kann und will mit dieser Einschränkung leben und arbeiten – auch bei aller vorhandener Bereitschaft zur Verschlüsselung nicht.

Potentielles Problem unter Kmail beim Öffnen von HTML-Mails, die mit Thunderbird/enigmail kryptiert wurden

Will der Kunde unbedingt HTML-Mails austauschen, so ergibt sich u.U. das Problem,

  • dass der Kunde (unter MS Win 7) mit Hilfe von Thunderbird/enigmil zwar eine von mir unter Linux mit Hilfe von Kmail erstellte und mit GnuPG/GPG kryptierte HTML Mail empfangen und ansehen kann,
  • aber ich selbst eine unter Thunderbird verfasste, mit “enigmail” kryptierte HTML Mail nur in Plain Text Form erhalte und der HTML-Anhang der Mail beim Öffnen nur krypierte Anweisungen enthält.

Der Grund liegt in einer speziellen unter Thunderbird/enigmail standardmäßig eingestellten Variante der Verschlüsselung – nämlich “Inline PGP”. Siehe hierzu:
http://de.wikipedia.org/ wiki/ PGP/ INLINE
https://www.enigmail.net/ forum/ viewtopic.php? f=3&t=134

Ein Grund für den standardmäßigen Einsatz von “Inline PGP” ist u.a. der, dass etliche (u.a. MS-lastige) Mail Clients mit der normierten Verschlüsselungsvariante “PGP/Mime” nicht richtig umgehen können. Siehe z.B.:
http://www.phildev.net/ pgp/ pgp_clear_vs_mime.html

Leider führt “Inline PGP” dazu, dass HTML Mails im Rahmen der Verschlüsselung nicht korrekt als Attachment-Streams kryptiert werden. Letzteres zieht bei meinem Kunden dann konsistenterweise Warnungen beim Versuch der Verschlüsselung einer erstellten HTML-Mail nach sich – nämlich dass vorgenommene Formatierungen beim Verschlüsseln und Signieren verloren gehen werden.

Gibt es einen Ausweg? Zumindest im Prinzip: ja. Man muss “enigmail” so einstellen, dass es den definierten Standard “PGP/MIME” zur Kryptierung anstelle von Inline PGP verwendet. Dann ist für eine standardkonforme Verschlüsselung von Mail-Attachments und damit – bei Wahl einer entsprechenden Versandart – auch für eine ordnungsgemäße Behandlung von HTML-Mails gesorgt.

Linux Mail Clients, die GnuPG/GPG einbinden, können i.d.R. mit Mails und Attachments umgehen, die gemäß der “PGP/MIME”-Regeln
kryptiert wurden. Siehe zu “PGP/MIME” etwa :
http://de.wikipedia.org/ wiki/ PGP/ MIME
http://de.wikipedia.org/ wiki/ OpenPGP

Dies trifft natürlich auch auf Kmail zu. So ist also der Einsatz von “PGP/Mime” durch den Kunden (mit MS Win, Thunderbird) zumindest in der Kommunikation mit mir kein Problem. Die entsprechenden Einstellungen können unter “Thunderbird/enigmail” zudem spezifisch für einen Mail Account vorgenommen werden. Hat der Kunde die Möglichkeit, einen spezifischen Mail-Account für die Kommunikation mit mir zu nutzen, so ist man als Linux-Kmail-Nutzer aus dem Schneider – nicht jedoch zwangsläufig als Security-Berater; s.hierzu einen speziellen Absatz weiter unten.

Erforderliche Einstellungen unter Thunderbird/enigmail

Zwei Schritte sind erforderlich, damit mit Thunderbird erstellte und mittels “enigmail” kryptierte HTML Mails auf einem Linux-System mit Kmail-Client nach Dekryptierung als HTML Mails geöffent werden können und danach alle vom Absender vorgenommenen Formatierungen auch angezeigt werden:

  • Schritt 1: Aktivierung von “PGP/MIME”
    Das entsprechende mit Häkchen zu versehende Feld findet man unter Thunderbird für Windows unter
    Extras >> Konten-Einstellungen >> dein relevanter Mail Account >> OpenPGP-Sicherheit >> PGP/MIME standardmäßig verwenden.
  • Schritt 2: Versand im Format “Reintext und HTML”
    Vor dem Versenden der E-Mail aus dem E-Mail-Erstellungsdialog von Thunderbird muss der Anwender explizit die Einstellung “Reintext und HTML” unter dem Menüpunkt “Optionen >> E-Mail Format” vornehmen.

Letzteres könnte man zwar auch als globale bzw. empfängerspezifische Option festlegen. Ich persönlich würde das aber nicht tun, sondern als Standard “Reintext” wählen. Es gilt ja nach wie vor die Maxime, dass HTML-Mails in der Mail-Kommunikation mit mir nur im Ausnahmefall zum Zuge kommen sollen.

Eine ausführlichere Beschreibung zu den vorzunehmenden Einstellungen von Thunderbird findet man z.B. unter:
https://micahflee.com/ 2013/ 09/ html-email-attachments-and-flowed-text-in-enigmail/

Sicherheitsaspekte

Nun ein paar Worte zu einigen potentiellen und interessanten Sicherheitsproblem von “enigmail” im Zusammenhang mit PGP/MIME, nämlich u.a. dem atomatischen Öffnen und Dekryptieren von Mails im Hintergrund. Siehe hierzu im Besonderen den Kommentar von Alan Eliasen zu dem eben zitierten Artikel
https://micahflee.com/ 2013/09/ html-email-attachments-and-flowed-text-in-enigmail/
und weitere entsprechende Hinweise unter
https://futureboy.us/ pgp.html
Letzterer Artikel enthält übrigens auch grundsätzliche und interessante Hinweise zum Einsatz von OpenPGP/GnuPG.

Besonders interessant und lehrreich im Zusammenhang mit “enigmail” ist die Diskussion zu dem besonders kritisierten Punkt im Zshg. mit PGP/MIME, der den enigmail-Entwicklern als Bug gemeldet und danach heftig diskutiert wurde. Siehe hierzu:
http://sourceforge.net/ p/ enigmail/ bugs/226/
und die dortigen Kommentare.

Was ist nun meine Meinung zu deser Debatte ? Grob Folgendes :

Ich verstehe die Kritik und die Bedenken von Hrn. Eliasen gut; inbesondere den von ihm geäußerte Kritik an der durch Thunderbird (mit Hilfe von enigmail) automatisch in Gang gesetzten Dekryptierung von PGP/MIME-verschlüsselten Mails samt Anhängen im
Hintergund. Auch die grundsätzlich in Betracht gezogenen Angriffsmethoden auf akustischer Ebene waren bis zu Gegenmaßnahmen auf der GnuPG-Seite relevante Punkte.

Aber: 100%-ige Sicherheit gibt es nicht – und in der Praxis werden nach Abwägung von Risiken immer wieder Kompromisse zu schließen sein. Dabei muss auch die sichere und bequeme Handhabung einer SW durch den Anwender einbezogen werden. Das ist hier durchaus relevant.

Nehmen wir mal an, nur autorisierte User haben Zugang zum PC/Laptop des Kunden: Wenn dann – also im Normalbetrieb – im Hintergrund dekryptierte Mails von einem Angreifer mitgeschnitten werden sollten, dann bestünde bereits ein grundsätzliches, über Thunderbird weit hinausgehendes Problem auf dem attackierten Computer bzw. im umgebenden Netzwerk. Auch akustische Attaken würden ein hohes Maß an krimineller Energie am Standort des empfangenden Computers voraussetzen.

Ferner geht es ja zunächst vor allem darum, dass der Kunde Mails überhaupt verschlüsselt über das Internet transportiert. Man muss ja (leider) schon dankbar sein, wenn man einen Nicht-IT-Fachmann dazu bewegen konnte, die für entsprechende Verschlüsselungsmaßnahmen notwendige Energie aufzuwenden. Bequem und einfach ist das für den Normalverbraucher eher nicht. Als wenig praxistauglich bis realitätsfern muss man gar Eliasen’s Aufruf zu einer manuellen Verschlüsselung des Mail-Bodies durch den Windows-Anwender einstufen.

In einer Hochsicherheitskommunikation ist die “Ende zu Ende”-Verschlüsselung auf dem Transportweg natürlich nur ein Teil der erforderlichen Maßnahmen. Die sichere kryptierte Ablage der Mails auf dem sendenden wie auf dem empfangenden System gehört mit in ein umfassendes Maßnahmenpaket. Aber sobald ein funktionierender Transfer mit einer “Ende zu Ende”-Verschlüsselung etabliert wurde, hat man immerhin einen wichtigen Schritt in Richtung einer verbesserten Sicherheit im Informationsaustausch hinter sich gebracht.

Alles weitere betrifft dann die Sicherheit der Informationsablage und Informationssnutzung auf den sendenden bzw. empfangenden Systemen. U.a. will man ja bei kryptierten Mails eine gewisse Grundsicherheit auch dann noch aufrecht erhalten, wenn ein physikalischer Zugriff (z.B. auf einen gestohlenen oder unbewachten Laptop) durch unautorisierte User erfolgt und ggf. nach Einsatz von Passwort-Crackernein Login durch den ungebetenen Gast gelingt. Hier zieht dann das Argument von Eliasen bzgl. der automatischen Dekryptierung wirklich:

Ohne explizit geforderte Dekryptierung durch einen autorisierten User sollte kein System eine Dekryptierung von Mails in Gang setzen. Der potentielle nicht-autorisierte Angreifer erhielte hier ggf. Zugang zu den geheim zu haltenden Informationen, ohne das Passwort für den privaten Schlüssel überhaupt benutzen zu müssen. Letzteres wäre z.B. dann gegeben, wenn der Angreifer Thunderbird nutzen kann und enigmail das erforderliche Passwort noch aus einem meist stadardmäßif vorkonfigurierten Zwischenspeicher bezieht.

Dieser Bedrohung kann man aber bei Bedarf dadurch begegnen, dass man den Schlüssel mit einem sicheren Passwort versieht und enigmail/GnuPG anweist, das Passwort für den privaten Schlüssel nicht – auch nicht für einen kurzen Zeitraum – zwischenzuspeichern. Bequemer wird der Einsatz von Thunderbird/enigmal dadurch aber nicht. (Steht Sicherheit wirklich über allem, so wird man ferner die Harddisks verschlüsseln, um im Verlustfall grundsätzlich mehr Sicherheit zu haben.)

Ferner möchte ich anmerken, dass die enigmail-Entwickler ja schließlich gerade aufgrund der geführten Debatte (dankenswerterweise) Schritte in Richtung einer besseren und kontrollierteren Handhabung der Dekryptierung vorgenommen haben.

Bleibt das Restrisiko, dass größere mit PGP/Mime verschlüsselte HTML-Anhänge eine Menge an bekannten Textfragmenten wie etwa Tags enthalten. Dies kann gut ausgestatteten Angreifern mindestens theoretisch eine Grundlage für statistik-basierte Dekryptierungsversuche
verschaffen. Sollte dieses Problem wirklich bestehen, dann würde ich darin insgesamt aber eher eine Schwäche des Kryptierungsverfahrens (also von GnuPG) sehen als von “enigmail”.

Habe ich die Wahl zwischen weiter bestehenden Rest-Risiken und einem total unverschlüsselten Email-Verkehr, so ziehe ich – nach entsprechender Unterweisung des Kunden – immer noch den Einsatz einer Verschlüsselung vor.

Abschließend gilt grundsätzlich :

Mit HTML-Mails sind jenseits von Wechselwirkungen mit Verschlüsselungsprogrammen weitere schwerwiegende Risiken verbunden, denen man sich im Rahmen einer sicheren Kommunikation (bei allem gegenseitigen Vertrauen der Kommunikationspartner) erst gar nicht aussetzen sollte. Der Kunde sollte also dahingehend beraten werden, HTML-Mails im Normalfall auch in der Kommunikation mit vertrauenswürdigen Kommunikationspartnern (in diesem Falle u.a. mit mir) zu vermeiden.

Selbst sollte man seinen E-Mail Client so einstellen, dass er HTML-Mails zunächst nur im Plain Text Format öffnet. Im Falle, dass HTML-Formatierungen wirklich eine wichtige Rolle spielen, kann man den PGP/MIME HTML-Anhang immer noch öffnen. Als Paranoiker auch bei vertrauenswürdigen Quellen ggf. zunächst in einem Standard-Editor, um den HTML-Code vor einer Ausführung zu analysieren. 🙂

 

Kmail 4.9 – Datenverlust durch Spamfilterung

Posted on by

Bin letzte Woche unter Opensuse 12.1 auf KDE 4.9 umgestiegen, was mir generell ganz gut gefällt. Besonderes Augenmerk habe ich jedoch wieder mal auf KMail im Zusammenspiel mit IMAP-Servern und (OX-) Adressbüchern gelegt.

Hierzu erste Eindrücke:

Zuerst das Positive:

Mit etwas Mühe und viel Geduld kann man Kmail 4.9 im Gegensatz zu Kmail 4.8.2 – 4.8.4 x nun sogar davon überzeugen, dass die automatische Adress-Suche und -Vervollständigung beim Erstellen neuer Mails halbwegs funktioniert. (Als Linux Fan einen solchen Satz schreiben zu müssen, ist eigentlich peinlich!) Zur “address autocompletion” etwas mehr in einem späteren, separaten Beitrag.

An die Mängel bei der Adress-Autocompletion hatte man sich als Anwender ja schon seit einiger Zeit gewöhnt (siehe https://bugs.kde.org/show_bug.cgi?id=259949 ). Damit und zugehörigen Workarounds kann man leben

Nun aber das Negative:

Der Suchdialog funktioniert nach wie vor nicht:
Der Kmail-Suchdialog zum Suchen von Mails ist nach wie vor nicht benutzbar. Bei mir werden nun gar keine Treffer mehr angezeigt. Das ist fast besser als das, was früher am Schirm erschien. Also: Das Einzige, was bzgl. der Suche von Mails wirklich funktioniert, ist unter Kmail die Schnellsuchleiste oberhalb der Anzeige der Mailliste. Alles andere funktioniert nicht oder nicht richtig. Dieser Punkt allein disqualifiziert Kmail im Moment für den professionellen Einsatz.

Leider, leider, leider … Viel schlimmer ist aber noch Folgendes: Im Moment besteht die Gefahr eines (ggf. umfänglichen) Datenverlustes durch Spamfilterung an KDE’s E-Mail-Client.

Spamfilter eliminieren Mailinhalte:
Meine Frau hat gestern Abend Bogofilter für die Spam-Elimination auf ihrem Kmail eingerichtet. Hauptgrund ist, dass sie auch Mailkonten auf externen IMAP-Servern und nicht nur unserem eigenen benutzt. (Auf unserem eigenen Server werkelt Spamassassin und macht dort einen guten Job). Der Einsatz von Bogofilter unter Kmail sah anfänglich auch gut aus. Mails, die bereits als gelesen markiert waren und danach der Spamfilterung unterzogen wurden, wurden richtig und wie in den Filtereinstellungen vorgesehen behandelt. Die große Überraschung kam jedoch am nächsten Morgen:

Aus allen neuen Mails, die von Bogofilter als Spam eingestuft wurden, wurde der Mail-Body entfernt. Sprich: Diese Mails waren danach leer!

Dies betraf alle neuen ungelesen Mails – egal aus welcher IMAP-Quelle. Das ist keineswegs nur ein Darstellungsproblem am (K-)Mail-Client: Die Mails werden über Akonadi als leere Mails mit den jeweiligen IMAP-Server “abgeglichen”. Ein kurzer Test zeigte übrigens, dass das gleiche Problem unter Kmail auch bei Einsatz des Perl-basierten Spamassassin auftritt.

Irgendwie führt die Modifikation des Mailheaders durch Bogofilter/Spamassassin am Kmail-Client dazu, dass im Zusammenspiel von KMail – Akonadi – IMAP-Server die Mailinhalte von Mails gelöscht werden, die noch nicht als gelesen markiert wurden.

Nebenbei: Ein weiterer Bug ist der, dass diese derart malträtierten Mails nicht – wie in den Filterregeln vorgesehen – in einen SPAM-Ordner verschoben wurden. Und Spamassassin braucht beim Durchkämmen von größeren Verzeichnissen unglaublich viel CPU. Aber was solls … ich rege mich nicht mehr auf – sonst kommt gleich wieder ein Entwickler und macht mich mit Nachdruck darauf aufmerksam, dass seine Arbeit freiwillig ist und nicht bezahlt wird. (Das finde ich auch schlimm, meine aber trotzdem, dass SW-Qualität primär etwas mit vernünftigen Change Management und Release-Prozessen zu tun hat …)

Jedenfalls finde ich: Das Entfernen des Mailinhalts macht nicht nur keinen Spaß – das ist ein echtes Problem ! Und es ist keineswegs neu – wie ich nach ein wenig Recherche lesen musste:
https://bugs.kde.org/show_bug.cgi?id=295484

Ich habe die Spamfilterung bei meiner Frau jedenfalls vorläufig abgestellt. Sie hofft jetzt auf bessere Zeiten und sucht mal wieder nach Alternativen …

Um böse Überraschungen zu vermeiden, kann ich jedem Kmail-Anwender im Moment nur raten, Spam-Filter vor einem Einsatz wirklich ausführlich zu testen und auf umfängliche Trainingsläufe mit produktiven Mailfoldern zu verzichten – bis man sicher ist, dass nichts passiert.

Fazit:
Seit der Einführung von Akonadi, Nepomuk, Strigi reißen die Probleme mit Kmail für die Anwender leider immer noch nicht ab.

Kmail 4.8.4 – Probleme/Crash plus Workaround

Posted on by

Installiert man KDE 4.8.4 und Kmail oder Kontact aus dem Opensuse KDE 4.8 Release Repository, so ist man ggf. mit ernsthaften Problemen konfrontiert. U.a.: :

  • Mails lassen sich unter Kontact nicht länger beantworten oder weiterleiten.
    Kontact schließt sich dann einfach.
  • Kmail stürzt beim Starten von der Command Line ab (Kmail Crash).
  • Kmail stürzt beim Wechsel zwischen Foldern ab.

Jeder, der diese Probleme hat, sollte sich den Workaround von “Peter” (UNIX-Pete) aus folgendem Beitrag eines Opensuse Forums zu Gemüte führen :

http://forums.opensuse.org/english/get-technical-help-here/applications/476040-re-kmail.html

Die Installation der Soprano RPMs aus Opensuse’s “KDE Unstable Repository” hilft tatsächlich und beseitigt die Schwierigkeiten! Die Probleme liegen also wohl an der Kombination von Kmail 4.8.4 und seinen Helferdiensten mit dem Soprano RPM in der Version 2.7.6.

Statt der Version 2.7.6 sollte man also die Versionen 2.7.56 aus dem KDE Unstable Repository
[http://download.opensuse.org/repositories/KDE:/Unstable:/SC/openSUSE_12.1]
für folgende Pakete verwenden:

  • libsoprano4
  • soprano
  • soprano-backend-virtuoso
  • soprano-backend-redland

Einen erneuten längeren Kommentar hinsichtlich der mangelnden Qualitätssicherung von KDE-Kernkomponenten, die von Distributoren wie Opensuse in sog. “Release”-Repositories angeboten werden, erspare ich mir. Als Endverbraucher ist es mir dabei auch egal, ob nun das KDE Release Repository von Opensuse fehlerhaft erstellt wurde oder ob die Fehler schon im KDE 4.8.4 – Release bzw. in den ausgelieferten Soprano-Bibliotheken lagen.

Gott sei Dank gibt es experimentierfreudige Menschen wie “Peter (UNIX-Pete)”, die auch dann noch einen Ausweg finden.
Auch das ist Linux ! Danke “Peter” !

Kmail 4.8 – Suchfunktionalität weiterhin im Eimer

Posted on by

Seit der Umstellung auf das akonadi-basierte Kmail2 (unter Opensuse passierte das nach KDE 4.6.4) gibt es Probleme mit der Suche nach Mails unter Kmail. Diese Feststellung ist mehr als traurig, denn im täglichen professionellen Einsatz von Mail-Programmen benötigt man Suchfunktionen, die einen schnell mehrere Suchkriterien miteinander kombinieren lassen – z.B. für den Mail-Text und für das Absender-Feld.

Kmail 1.13.7 wies hierfür einen voll funktionsfähigen eigenen Such-Dialog auf. Auf einem unserer Rechner ist die alte Version noch unter KDE 4.6.4 installiert. Da läuft alles noch prima – auch im Zusammenspiel mit IMAP-Servern.

Wie ist der Zustand seit KDE 4.7 und auch jetzt noch unter KDE 4.8 ?

  • Weder unter Kmail 4.7.4 noch unter Kmail 4.8 gibt der Suchdialog einem eine Möglichkeit zur Eingabe eines Mailverzeichnisses, den man durchsuchen will.
  • Wenn gesucht wird, so wird (manchmal) in allen Mailverzeichnissen gesucht.
  • Unter KDE 4.7.4 liefern viele Suchvorgänge Ergebnislisten mit leeren Zeilen am Anfang.
  • Unter KDE 4.8 liefert eine Suche mit mehreren kombinierten Such-Kriterien leere Resultsets, obwohl es viele Mails gibt, die die Kriterien erfüllen.
  • Manche Suchen nach Begriffen im vollständigen Mailtext liefern Resultsets – aber auch die nicht immer zuverlässig. Die Suchergebnisse sind nicht immer vollständig.

Das Ganze ist so fehlerhaft, dass man den Suchdialog unter Kmail im Moment als nicht benutzbar ansehen muss. Im Grunde ein Desaster! Hingewiesen hat mich darauf übrigens Martin Lüchem. Ich wollte es ihm zunächst gar nicht glauben, aber leider hat er recht.

Die einzige Suche, die bei mir z.Z. noch funktioniert, ist die über die Eingabezeile im normalen Kmail-Fenster. Das ist eine Volltext-Suche. Die scheint zu klappen. Aber wie gesagt, das reicht für den professionellen Einsatz überhaupt nicht.

Da fragt sich der KDE-Anwender erneut: Wie kann es sein, dass sich solche Mängel über zwei größere Releases von KDE 4 hinweg halten können?

Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil II

Posted on by

Einleitung und Inhalte dieses 2-ten Beitrags zu einer OX 6 Testinstallation

Im ersten Teil dieses Beitrages zu einer OX6-Testinstallation haben wir eine OX6-Grundinstallation auf einem “Opensuse 11.4”-Server vorgenommen. Siehe auch:
https://linux-blog.anracom.com/2011/08/21/kontact-47-und-ox-6-unter-opensuse-114-teil-i/ .

Es stand noch aus, einen ersten OX-Kontext und zugehörige OX6-User anzulegen.

Letztere sollen unter der OX-eigenen Web-Oberfläche auf den externen IMAP-Server zugreifen können. Der IMAP-Server, mit dem der OX6-Server kooperieren soll, läuft in unserer Testkonfiguration auf einem separaten Server. Wir werden uns nachfolgend daher damit auseinander müssen, wie sich diese Trennung der Serversysteme auf die Einrichtung von OX6-Usern auswirkt.

In einem nachfolgenden dritten Blog-Beitrag wollen wir abschließend testen, ob und wie der Zugriff von Kontact auf den OX6-Server funktioniert.

Anlegen eines Default-Kontextes

Im ersten Teil sind wir bereits auf Kontexte eingegangen. Wir legen nun als “oxadminmaster” den sog. Default-Kontext an und kreieren dabei gleichzeitig den zugehörigen Default-Kontext-Administrator, dem wir hier willkürlich den Usernamen “oxadmin” geben. Das Ganze geschieht wieder durch ein Skript:

#   /opt/open-xchange/sbin/createcontext  −oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 1  −u oxadmin  −d “Context Admin”  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −L defaultcontext  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Ein paar Hinweise zu den Optionen (s. auch die Befehlsbeschreibung im OX6-Manual “OX6-Provisioning.pdf”):

  • Das “-c 1” definiert die Kontext-Id,
  • das “-u” die User-ID,
  • das “-d” den Displaynamen für den Kontext-Admin,
  • das “-g” den “Given Name” (Vorname),
  • das “-s” den Nachnamen,
  • das “-L” das sog. Login-Mapping (hier eben auf den Defaultkontext),
  • das “-e” die E-Mail-Adresse des Kontext-Admins,
  • das “-q” den kontext-weiten Quota-Betrag in MByte (!),
  • ein “-N” einen Kontext-Namen.

Ein Kontext kann auch einen Namen erhalten – hierzu ist der Parameter “-N” einzusetzen. Dieser Name kann z.B. beim Login-Mapping verwendet werden (s.u.).

Als Email-Adresse sind wir von einem IMAP-Account “oxadmin@mydomain.de” ausgegangen, der über unseren IMAP-Server versorgt wird. Unser IMAP-Server ist dabei wie gesagt nicht identisch mit dem Server des OX6-Systems.

Obwohl die Kommandos für die spätere Anlage normaler OX6-Anwender ähnlich sind, ist die Anlage des “Kontext-Administrators” ein besonderer Akt, der initial die Berechtigung des OX6-Adminmasters erfordert.

Hinweis zu mehreren Kontexten und zum kontextspezifischen Login-Namen eines Users

Legt man später mehrere Kontexte an, so geschieht dies für den zweiten Kontext etwa über

#   /opt/open-xchange/sbin/
createcontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −u oxadmin  −d “Context Admin”  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Man beachte 2 Dinge:

  • Für das Anlegen des Kontextes und gleichzeitig des Kontext Admin ist die Autorisierung als “oxadminmaster” erforderlich. Die weitere Gestaltung des jeweiligen Kontextes und auch die Pflege der zugehörigen User obliegt danach aber dem jeweiligen Kontext-Admin!
  • Jeder User-Account ist kontextspezifisch. Auch der “oxadmin”-User für den Kontext 2 ist keineswegs identisch mit dem “oxadmin”-user für den Kontext 1 !
  • In der Praxis sollten die Kontext-Administratoren natürlich besser unterschiedliche Bezeichnungen bekommen.

Der Login in einen spezifischen Kontext durch Angabe der Kontextnummer nach dem Usernamen, also z.B. durch “oxadmin@1” für den Kontext mit der Nummer 1 oder “oxadmin@2” für den Kontext 2, falls – wie im obigen Beispiel – in jedem Kontext ein User “oxadmin” angelegt wurde. Möchte man statt mit Kontext-ID-Nummern lieber mit “Kontextnamen” operieren, so kann man ein entsprechendes “Login-Mapping” durch folgende “Kontextänderung” bewirken:

#   /opt/open-xchange/sbin/changecontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −N verwaltung  −L 2,verwaltung

Dieser Befehl ordnet dem Kontext 2 den Namen “verwaltung” zu. Ein Login in diesen Kontext würde für den User “oxadmin” danach also auch mit der Eingabe der Userbezeichnung “oxadmin@verwaltung” in einer Login-Maske möglich sein.

Hinweis zu einem typischen Fehler aufgrund bestimmter anfänglich zu viel installierter OX6-Pakete

Bei mir schlug das Kommando zur Kontextanlage trotz Variationsversuchen zunächst zig-fach fehl, weil ich unvorsichtigerweise das Paket “open-xchange-admin-plugin-autocontextid” installiert hatte (s. hierzu auch die Warnung in Teil 1).

Ich wurde dann mit Fehlermeldungen der Art

Error: Unrecognized options on the command line: Unknown option “-c’

oder

com.openexchange.admin.plugins.PluginException: com.openexchange.admin.rmi.exceptions.StorageException: Table ‘configdb.sequence_context’ doesn’t exist

konfrontiert. Letzteres wenn ich testweise das “-c” weggelassen habe. Das Paket “open-xchange-admin-plugin-autocontextid” setzt nämlich Zusatztabellen voraus, die bei unserer Grundinstallation nicht implementiert wurden.

Siehe zu diesen Fehlern
https://forum.open-xchange.com/showthread.php?5935-Error-option-c-not-recognized-when-running-createcontext

Ich habe in meinem Fall dann eine Neuinstallation mit genau den Paketen durchgeführt, die in der Referenz-Installationsanleitung (s. Teil 1) aufgeführt sind. Danach lief das Kommando einwandfrei durch.

Unzureichende Default-Einträge für den IMAP-Mail-Account des Kontext-Administrators

An dieser Stelle lohnt sich nun ein Blick mit PhpMyAdmin in das lokale MySQL-RDBMS, Datenbank “oxdatabase_{ID}”, Tabelle “user“. Es zeigt sich, dass nun für den Kontext 1, der bislang auch unser
Defaultkontext ist, ein Eintrag mit folgender Feldbelegung existiert:

  • cid = 1
  • id = 2
  • imapServer = imap://localhost:143
  • mail = oxadmin@anracona.de
  • smtpServer = smtp://localhost:25
  • etc.

Einen korrespondierenden Eintrag findet man in der Tabelle “user_mail_account“. Man beachte dort auch das Feld “default-flag”, das für diesen ersten Maileintrag zum User “oxadmin” auf “1” gesetzt ist. Für weitere Maileinträge, die man später über die Web-Oberfläche des OX6-Systems erzeugen kann, ist das nicht der Fall. Dort findet man dann eine “0”.

Das obige Kommando für die Kontexterzeugung geht für den User “oxadmin” im jeweiligen Kontext also von der Existenz eines Default-Email-Accounts auf dem lokalen OX6-Server nach dem Muster “imap://localhost:143” aus.

Der würde in unserem Fall aber unglücklicherweise nicht funktionieren, da unser IMAP-System ja auf einem anderen Server vorausgesetzt wurde. Login-Versuche des eben angelegten Users “oxadmin” über die Web-Oberfläche des OX6 würden mit nachaltigen Fehlermeldungen und einer Abschaltung des E-Mail-Subsystems für diesen User quittiert werden. Also müssen wir die Angaben für den User ändern (s.u.).

Dabei gilt es zu beachten, dass dem Default-Email-Account eines OX6-Users eine besondere Bedeutung zukommt.

Behandlung des Default-Mail-Accounts für OX6-User auf einem separaten IMAP-Server

Durch etwas Lesen und Herumprobieren findet man folgenden, eigentlich logischen Punkt heraus:

Jeder User auf dem OX-Server erhält eine Default-Mail-Adresse zugeordnet. Die implizite Annahme ist dabei wohl die, dass dieser Default-Mailaccount ein fester Bestandteil der OX6-Einrichtung ist und auf dem gleichen Server wie das OX-System selbst eingerichtet sein sollte. Alle anderen IMAP-Accounts eines Users sind davon externe unabhängige Dinge. Aber der Anspruch einer OX6-Einrichtung ist der, dass das OX6-System jedem seiner User einen eigenen Mail-Account anbietet. Nun habe ich aber bereits einen separaten IMAP-Server im Netz. Und dort will ich natürlich auch die Default-Accounts des OX6-Systems betreiben!

Wichtig für das erfolgreiche Zusammenspiel des OX-Servers mit unserem separaten IMAP-Server im Netz ist nun, dass der User-Name z.B. des “oxadmin”-Users auf dem OX6-Server identisch mit dem Login-Namen des Useraccounts auf dem Linux-IMAP-Server ist – auf Betriebssystemebene wie auf IMAP-Ebene.

Auch das verwendete Passwort muss auf beiden Servern (zunächst) identisch sein ( – wiederum auf Betriebssystemebene wie auf IMAP-Ebene).

Das gilt nicht nur für den “oxadmin”-Account sondern auch für alle anderen OX6-User-Accounts, die problemfrei auf ihren jeweiligen Default-IMAP-Account zugreifen sollen. Man sollte also einen eigenen, im Netz vorhandenen IMAP-Server von vornherein als eine dem OX6-System fest zugeordnete Einheit begreifen.

Das halte ich nebenbei gesagt für einen kleinen Nachteil der OX 6 Grund-Installation. Denn dies setzt vorab eine aufgeräumte Netzwerkumgebung mit “Single Sign On”-Charakteristik voraus. Was ja keineswegs verkehrt ist, aber dennoch nicht überall gegeben ist. Das Dumme ist dann, dass der OX6-Anwender bei Problemen mit der Default-Mail-Account-Einrichtung spürbare Schwierigkeiten beim Öffnen seiner OX6-Weboberfläche bekommt. Er erhält dann regelmäßig Fehlermeldungen, die das Abschalten des Email-Moduls der Groupware-Oberfläche ankündigen. Und dann ist man als Admin gefordert.

Ich habe übrigens nicht explizit geprüft, ob die Linux UID-Nummern auf den unterschiedlichen Servern auch identisch sein müssen; ich gleiche die aus anderen
Gründen aber sowieso immer ab. Hier hilft natürlich ein zentrales LDAP-System als universales Backend enorm, aber dessen Einrichtung würde hier wirklich zu weit führen.

Nebenbei:
Man kann durch Eingriffe jenseits der verfügbaren OX6-Verwaltungskommandos auch unterschiedliche Passwörter auf dem IMAP-Server und dem OX6-System verwenden. Dazu muss man das abweichende IMAP-Passwort direkt in die Tabelle “user_mail_account” eintragen. Natürlich ist das Passwort verschlüsselt – also ist die spezifische Hash-Methode Crypt in der Tabelle “user_mail_account” zu beachten! (In der Tabelle “users” wird für das OX6-Passwort dagegen SHA1 als Hashverfahren verwendet). Da mir dabei das von OX6 verwendete Salt zur Crypt-Hash-Generierung nicht bekannt ist, behelfe ich mir hier regelmäßig, indem ich gezielt Dummy-User mit dem von mir gewünschten Mail-Passwort anlege, den erzeugten Hash dann in den zu ändernden User-Record kopiere und danach den Dummy-User mit “deleteuser” wieder entferne.

Weitere IMAP-Accounts jenseits des Default-Accounts?

Nach diesen Hinweisen zum Default-Mail-Account eines OX6-Users stellt sich die Frage, wie es um weitere IMAP- oder POP-Accounts bestellt ist und ob man die in der OX6-Web-Oberfläche auch nutzen und die zugehörigen Mailordner einsehen kann.

Ja, das geht natürlich! Jeder User kann später auf beliebige weitere IMAP- oder POP-Accounts auf externen Mail-Servern zugreifen – selbst dann, wenn es mit dem Default-Account des OX6-Systems Probleme geben sollte. Für das Anlegen von Mail-Accounts gibt es in der OX6-Web-Oberfläche einen entsprechenden Menüpunkt unter

“Einstellungen >> E-Mail >> Accounts”.

Nur seinen Default-Account kann der User dort weder löschen noch in seinen Grunddaten ändern. Dies kann nur der Kontext Administrator. Das unterstreicht die besondere Rolle des Default-Mail-Accounts als Teil der OX6-Services.

Beim Anlegen weiterer Accounts kann man die auf dem jeweiligen IMAP-Server gültigen Login-Daten anstandslos verwenden – und die müssen dann natürlich auch nicht identisch mit den Account-Daten auf dem OX-Server sein. Die zusätzlichen Mail-Accounts werden nahtlos in die Struktur der Web-Oberfläche integriert; man kann auf die entsprechenden Mail-Ordner-Inhalte zugreifen sowie eigene Mails mit spezifischen SMTP-Einstellungen versenden. Siehe hierzu auch die Abbildungen weiter unten.

Anpassen der Einträge auf dem OX6-Server für einen Default-Email-Account auf einem separaten IMAP-Server

Nehmen wir an, der von uns betriebene IMAP-Server habe die IP-Adresse “192.168.0.10”. Gehen wir weiter davon aus, dass es auf dem IMAP-Server 192.168.0.10 in unserem Netz einen Account und Postfach für den User “oxadmin” gibt. Dieser soll per E-Mail unter der Adresse “oxadmin@mydomain.de” erreichbar sei. Dann können wir unseren OX6 “oxadmin”-Account für den Kontext 1 wie folgt abändern, damit er mit diesem Postfach verbunden wird:

#   /opt/open-xchange/sbin/changeuser  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u oxadmin  −e oxadmin@mydomain.de  −−imaplogin oxadmin  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Man beachte, dass wir uns hier bzgl. der Authorisierung auf den “Kontext Administrator” und nicht auf den OX6-Admin-Master “oxadminmaster” beziehen !!! Innerhalb eines Kontextes ist es – wie gesagt – der Kontext Administrator, der die Useraccounts ändert – auch seinen eigenen! Wir überprüfen das Ergebnis der Maildatenänderung wieder durch einen Blick in die Datenbank.

Hinweis: Der Zugriff auf den Default-Email-Account per OX6-GUI
muss für Kontext Administratoren explizit freigeben werden !

Theoretisch könnten wir uns als User “oxadmin” nun über einen Browser bereits auf unserem OX6-Server einloggen. Das würde aber immer noch zu Fehlermeldungen führen, denn aus Sicherheitsgründen ist der Zugriff der Kontextadministratoren auf ihre IMAP-Default-Postfächer per OX6-Browser-Oberfläche defaultmäßig abgeschaltet. Diesen Umstand kann man aber durch Änderung eines Eintrags in den Konfigurationsdateien unter “/opt/open-xchange” ändern:

In der Datei “/opt/open-xchange/etc/groupware/mail.properties” muss man dazu den Wert des Parameters “com.openexchange.mail.adminMailLoginEnabled=true” auf true statt false setzen.

Man sollte das Flag in der Konfigurationsdatei wirklich kennen. Sonst wundert man sich – wie ich – evtl. stundenlang, warum die E-Mail-Anzeige in der OX6-Oberfläche für alle normalen User auf Anhieb funktioniert, nur nicht für den Kontext-Administrator – und das obwohl man über Kmail auf den E-Mail-Account des Kontextadmin ebenfalls problemlos zugreifen kann. Noch verwirrender wird die Angelegenheit, wenn man für den “oxadmin” über den Default-Mailaccount hinaus testweise weitere IMAP-Mailaccounts anlegt und sich mit denen auch sofort verbinden kann! Die Ursache für evtl. Probleme mit dem Default-Mail-Account des Kontext-Administrators liegt nur in besagtem Konfigurations-Flag!

Nebenbei:

Als Admin (root) des OX 6 Servers wird man sich neben dem Zugang zu seinem ureigenen Mail-Account ggf. auch einen Zugang zu dem “oxadmin”-IMAP-Account z.B. unter Kontact/Kmail/Akonadi anlegen, falls man die Groupware-Verwaltung nicht deligieren kann. Hierbei sollte man wie immer natürlich wegen des serverseitigen Abonnements von weiteren Ordnern als den Account-Standardordnern des IMAP-Servers aufpassen. Man will ja als Admin nicht alle möglichen Ordner des IMAP-Servers doppelt und dreifach synchronisiert bekommen.

Anlegen eines ersten normalen Users im Kontext 1

Wir legen nun einen ersten “normalen” User im Kontext 1 an. Dieser User muss natürlich bereits einen passenden E-Mail-Account auf dem IMAP-Server besitzen – mit auf beiden Servern gleicher UID und Passwort. Das Passwort heiße USER_PWD. Auf meinem Cyrus-Server sind die IMAP-User-Namen identisch mit den Linux-User-Namen – unser erster User habe den Login-Namen “rlu” (Ralf Lustig). Sein Mailaccount sei “rlu@mydomain.de”.

#   /opt/open-xchange/sbin/createuser c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −d “RLU”  −g Ralf  −s Lustig  −p USER_PWD  −e rlu@mydomain.de  −−imaplogin rlu  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Änderungen an diesen Daten führt man im nachinein wieder mit Hilfe des Scripts “changeuser” durch, wie wir das bereits weiter oben für den “oxadmin” vorgeführt haben. Will man dem User z.B. den Zugriff auf das Adressbuch des OX6-Systems gestatten ( in dem die User des OX6-Systems aufgeführt sind), so erreicht man dies durch :

#   /opt/open-xchange/sbin/changeuser  −c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −−access-global-address-book-disabled true

Spätestens jetzt sollte man sich als Admin für weitere Optionen und Einstellungen mit dem Dokument OX6-Manual “OX6-Provisioning.pdf”
https://linux-blog.anracom.com/category/open-xchange/ox6/(http://software.open-xchange.com/OX6/doc/OX6-Provisioning.pdf]
vertraut machen.

Login in die Web-Oberfläche des OX6-Servers

Hat man den OX6-Server wie im ersten Teil dieser Serie beschrieben angelegt, so wäre er jetzt im eigenen Netz unter der Adresse “http://oxs3” erreichbar. Wir probieren dies zum Abschluss unserer Anstrenugungen nun abschließend für den User “oxadmin” aus.

OX6 Login-Maske

Danach erhalten wir – wenn wir alles richtig gemacht haben – die aufgeräumte Web-Anwender-Oberfläche für das OX6-System:

OX6 Benutzer Oberflaeche

Man erkennt hier – etwas mühsam – dass neben dem geöffneten Default-Email-Account noch ein zweiter IMAP-Account auf einem IMAP-Server “oxs2” eingerichtet worden ist. Man kann einen solchen Account einrichten, indem man auf das Zahnradsysmbol in der Icon-Leiste oben links klickt. Man erreicht dann das Menü “Einstellungen” und seine Unterpunkte. Hiermit sollte man sich auch als Admin vertraut machen.

ox6 Menue Einstellungen

Die Einstellung eines zusätzlichen Email-Accounts erfolgt dann über den Menüpunkt “Einstellungen >> E-Mail >> Accounts”:

Ox6 zusaetzlicher Mail Account

Nach diesem ersten Erfolg wünsche ich viel Spass beim Einrichten weiterer User und beim Vertrautmachen mit den Möglichkeiten der OX6 GUI! Man lese hierzu auch das User-Manual

http://software.open-xchange.com/OX6/doc/OX6-User-Guide-German.pdf

Im nächsten Beitrag zum OX6 sehen wir uns dann den Zugriff auf den OX6-Server von KDE Kontact aus an.