Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I

In diesem und den folgenden Beiträgen möchte ich die Installation eines Cyrus IMAP-Dienstes beschreiben, der unter Opensuse zum Laufen gebracht werden soll und dessen Anwender über ein LDAP-System authentifiziert werden. Themen der Artikel werden sein :

  1. Einfache Varianten der benötigten Konfigurationsdateien unter Berücksichtigung von SASL (genauer “saslauthd“) und STARTTLS.
  2. Eine bestimmte Authentifizierungsvariante über SASLAUTHD, PAM, SSSD, LDAP. Diese ist aus meiner Sicht in einem kleinen internen Netzwerk durchaus ausreichend.
  3. Test der Funktionstüchtigkeit des Authentifizierungsverfahrens.
  4. Starten des Servers und Einrichten einer Test-Mailbox.
  5. Prüfen der Funktionstüchtigkeit des IMAP-Servers per “telnet” und “imtest”.
  6. Anbindung Kmail.
  7. Webmin zur Mailbox-Verwaltung.

Einschränkung
Ich gehe in diesem Beitrag ausschließlich auf die Installation des IMAP-Dienstes auf einem Linux-Host ein. Dem Zusammenspiel mit dem MTA Postfix widme ich dagegen eine andere Artikelserie. Will man einen kompletten E-Mail-Server mit Fetchmail, Postfix, Cyrus IMAP aufbauen, lohnt es sich aus meiner Sicht aber, das Pferd von hinten aufzuzäumen:

Für Tests der gesamten Verarbeitungskette muss man letztlich in der Lage sein, E-Mails entgegen zu nehmen und abzulegen. Dafür ist ein bereits laufender IMAP-Server das richtige. Der Zugriff eines Mailclients wie Kmail auf den IMAP-Dienst ist schnell umgesetzt. Im übrigen lohnt sich der Einsatz einer “Stand Alone”-IMAP-Instanz auch für die Aufnahme von Mail aus einem Backup. Siehe hierzu den Artikel:
https://linux-blog.anracom.com/2011/11/28/cyrus-imap-auf-die-schnelle/

Getestet habe ich die gesamte Vorgehensweise auf einem System unter Opensuse 12.3. Ich gehe aber davon aus, dass die Konfiguration auch unter Opensuse 13.1 laufen würde.

Voraussetzungen: Hostkonfiguration mit SASL, PAM, SSSD und LDAP-Zugriff

Da LDAP ins Spiel kommen soll, muss der Host, auf dem der Cyrus IMAP-Dienst implementiert werden soll, eine Reihe von Voraussetzungen erfüllen. Ferner muss im Netzwerk natürlich ein LDAP-System vorhanden sein, auf den unser IMAP-Host zugreifen kann und darf. Ich kann weder die Einrichtung eines LDAP-Systems an dieser Stelle besprechen, noch die Bereitstellung aller oder spezieller Zugriffsvarianten von bestimmten Serverdiensten auf ein LDAP-System. Ich betrachte weiter unten vielmehr eine einfache, etwas spezielle Variante des LDAP-Zugriffs. Dabei werde ich bestimmte Dinge voraussetzen, die ich bereits früher in anderen Artikeln behandelt habe:

Cyrus IMAP kann (wie manche andere Dienste auch) auf das Authentifizierungs-Framework Cyrus SASL zurückgreifen. SASL wiederum kann eine ganze Reihe unterschiedlicher Backends einsetzen. In einem der letzten Beiträge in diesem Blog hatte ich bereits dargestellt, wie man eine Kette aus

SASLAUTHD => PAM => SSSD => LDAP

nutzen kann, um damit eine Authentifizierung vorzunehmen. Siehe hierzu den Blog-Artikel:
SASL mit PAM, SSSD, LDAP unter Opensuse

Die Ausführungen des genannten Beitrags werden hier vorausgesetzt. D.h., ich gehe davon aus,

  • dass es einen LDAP-Server im Netz gibt, der Standard-Information zu Usern beherbergt, die einen IMAP-Zugang erhalten sollen,
  • dass die Userinformationen
    auf dem LDAP-Server in einem von SuSE’s YaST eingerichteten Zweig des LDAP-Baums angelegt wurden,
  • dass SASL, PAM und SSSD wie im obigen Artikel besprochen auf unserem Host “mycyrus” eingerichtet sind,
  • dass Server-SSL-Zertifikate sowohl auf dem IMAP-Host wie auch auf dem LDAP-Host eingerichtet wurden und zwar jeweils nach dem Muster des SuSE “Common Server Certificates”.

Wie man unter Opensuse zu einem LDAP-Server gelangt und die Server-Zertifikate von einem CA-System auf die Server bringt, habe ich in früheren Artikeln beschrieben.
Opensuse 12.1 – LDAP I // Opensuse 12.1 – LDAP II // Opensuse 12.1 – LDAP III // Opensuse 12.1 – LDAP IV // Opensuse 12.1 – LDAP V

Host-, Server- und Testuser-Bezeichnungen in den Artikeln dieser Serie

Der Host, der den IMAP-Server beherbergen soll, heiße nachfolgend “mycyrus“. Der LDAP-Server heiße dagegen “ldap-serv“.
Auf dem LDAP-System sei ferner ein Eintrag für eine Test-Userin “tarja” angelegt worden (Password: TARJAPWD).

Benötigte CYRUS IMAP Pakete

Unter Opensuse installiert man sich per YaST oder Yum folgende Pakete aus den Standard- und Update-Repositories für sein Opensuse-System:

cyrus-imapd, cyrus-sasl, cyrus-sasl-plain, cyrus-sasl-saslauthd, perl-Cyrus-IMAP, perl-Cyrus-SIEVE-managesieve,
perl-Authen-SASL-Cyrus, perl-Authen-SASL

CYRUS IMAP Konfigurationsdateien

Meine Cyrus Konfigurationsdateien sehen wie folgt aus:

/etc/cyrus.conf:

# standard standalone server implementation
 
START {
# do not delete this entry!
recover cmd=”ctl_cyrusdb -r”
 
# this is only necessary if using idled for IMAP IDLE
idled cmd=”idled”
}
 
# UNIX sockets start with a slash and are put into /var/lib/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=”imapd” listen=”imap” prefork=0
imaps cmd=”imapd -s” listen=”imaps” prefork=0
pop3 cmd=”pop3d” listen=”pop3″ prefork=0
pop3s cmd=”pop3d -s” listen=”pop3s” prefork=0
sieve cmd=”timsieved” listen=”sieve” prefork=0
 
# at least one LMTP is required for delivery
# lmtp cmd=”lmtpd” listen=”lmtp” prefork=0
lmtpunix    cmd=”lmtpd” listen=”/var/lib/imap/socket/lmtp” prefork=0
 
# this is only necessary if using notifications
# notify cmd=”notifyd” listen=”/var/lib/imap/socket/notify” proto=”udp” prefork=1
}
 
EVENTS {
# this is required
checkpoint cmd=”ctl_cyrusdb -c” period=30
 
# this is only necessary if using duplicate delivery suppression
delprune cmd=”cyr_expire -E 3″ at=0400
 
# this is only necessary if caching TLS sessions
tlsprune cmd=”tls_prune” at=0400
 
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL
messages older then 30 days.
# enter ‘man 8 ipurge’ for more details
 
# cleanup cmd=”ipurge -d 30 -f” period=60
}

Details zu den Parametern findet man etwa hier: http://linux.die.net/man/5/cyrus.conf.
Diese Datei ist nach der Installation unter Opensuse fast schon genau so vorhanden wie oben dargestellt. Geändert habe ich, dass die Bereitstellung der IMAP und POP-Dienste auch auf verschlüsselten Ports (imaps: 993, pop3s: 995) erfolgen soll.

Wichtig ist die Vorbereitung der LMTP-Socket-Kommunikation innerhalb des Blockes SERVICES {} dann, wenn man später Postfix als MTA einsetzt will: Postfix kann seine Mails lokal auf demselben System (Socket !) per LMTP-Protokoll an den Cyrus-IMAP -Server und dessen Mailboxen übergeben. Beachte: Die LMTP-Socket-Bereitstellung wird durch die gestartete Cyrus IMAP-Instanz selbst vorgenommen. Es ist keine zusätzliche Paketinstallation erforderlich. (In der Postfix-Konfiguration muss dann allerdings auch genau auf den hier angegebenen Socket Bezug genommen werden.)

Wichtig für die Authentifizierung im Rahmen eines User-Zugriffs auf den IMAP-Dienst ist folgende Konfigurationsdatei für den IMAP-Dämon:


/etc/imapd.conf:

# Configuration
# ************
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
sievedir: /var/lib/sieve
 
servername: mycyrus
admins: cyrus
 
reject8bit: no
poptimeout: 10
timeout: 30
 
# DRAC
# ******
drachost: localhost
dracinterval: 0
 
# Quota und Autocreate
# ******************
quotawarn: 90
autocreatequota: 5242880
autocreateinboxfolders: Drafts|Sent|Trash|Junk|Spam
autosubscribeinboxfolders: Drafts|Sent|Trash|Junk|Spam
 
# LMTP
# ****
lmtp_overquota_perm_failure: no
lmtp_downcase_rcpt: yes
 
# SASL
# ****
allowplaintext: yes
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN LOGIN
 
# TLS (STARTTLS)
# *************
tls_key_file: /etc/ssl/servercerts/serverkey.pem
tls_cert_file: /etc/ssl/servercerts/servercert.pem
tls_ca_file: /etc/ssl/certs/YaST-CA.pem

Genauere Informationen zu den einzelnen Parametern findet man unter den man-Seiten:
http://linux.die.net/man/5/imapd.conf.
Oder hier: http://www.postfix-howto.de/v1/cyrus_conf.html
Ich gehe kurz auf einige der wichtigeren Einträge ein:

Drac deaktivieren
DRAC realisiert “pop/imap before smtp” unter Cyrus IMAP. Das wird hier nicht benötigt und durch “dracinterval: 0” deaktiviert.

Nutzung von SASL für die Authentifizierung
Cyrus IMAP nutzt das SASL-Framework zur Authentifizierung allein aufgrund der 3 Zeilen unter meiner Kommentarzeile “# SASL”. Dabei werden eingehende Klartext-Passwörter zugelassen.
Dass der “saslauthd”-Dämon PAM nutzen soll, wird durch saslauthd’s eigene Startup-Dateien auf dem Host geregelt. Beschrieben habe ich das in meinem oben zitierten Blog-Beitrag SASL mit PAM, SSSD, LDAP unter Opensuse . Dort findet man auch,

  • wie man PAM zur Nutzung von SSSD einstellen muss und
  • wie man SSSD konfigurieren muss, damit ein LDAP-Server als Auth-Backend über eine TLS-gesicherte Verbindung genutzt werden kann.

Bereitstellung von STARTTLS für den sicheren Zugang zum IMAP-Dienst
Um das potentielle Sicherheitsloch mit den Klartext-Passwörtern zu kompensieren, soll der Cyrus-Server TLS-Verschlüsselung für Clients anbieten (STARTTLS). Dies
geschieht über die Einträge unterhalb meiner “# TLS”-Kommentarzeile.

Wie gesagt: Die host-spezifischen TLS/SSL-Schlüssel-Dateien sind von einer zentralen YaST-CA erstellt worden. Die zugehörigen Dateien wurden exportiert und auf “mycyrus” als “Common Server Certificate” importiert. Dann landen die Schlüssel-Dateien mit den angegebenen Standard-Namen und passenden Rechten in den angegebenen Verzeichnissen.

Wichtig ist, die Datei “YaST-CA.pem” der eigenen CA für SSL/TLS gesicherte Verbindungen auch auf allen späteren IMAP-Clients im eigenen Netzwerk bereitzustellen – und dort unter dem jeweiligen Verzeichnis “/etc/ssl/certs” (Opensuse-spezifisches Standard-Verzeichnis). Diese Datei wird später auf den Clients für die Prüfung der Vertrauenswürdigkeit des Zertifikats benötigt. (Natürlich kann es sein, dass die öffentliche Zertifikatsdatei für die eigene oder eine externe CA einen anderen Dateinamen als YaST-CA.pem aufweist. Unter anderen Linux-Distributionen ist ggf. auch ein anderer Pfad zu wählen, an den dann die Einstellungen in der imapd.conf anzupassen sind.)

Modifizierte Anzeige des Posteingangs
Die Mailverzeichnisse des Cyrus IMAP-Servers sind hierarchisch aufgebaut. Unter “/var/spool/imap/user” werden wir später für unsere Testuserin “tarja” explizit Mail-Verzeichnisse anlegen. Das Verzeichnis für den Posteingang ist dabei im Filesystem identisch mit “/var/spool/imap/user/tarja”. IMAP-intern wird die Mailbox unter “user.tarja” verwaltet. Unter diesem Knoten werden dann typische weitere Subverzeichnisse für “Drafts”, “Spam”, “Sent” etc. angelegt. Mail Clients wie Kmail zeigen diese Hierarchie an Mailfoldern auch genauso an. Mich stört dabei regelmäßig die übergeordnete Rolle des Posteingangs. Um das (spezielle) Posteingangsverzeichnis auf der gleichen Ebene wie die eigentlich untergeordneten Ordner anzeigen zu lassen, nutzt man die Option

altnamespace: yes

Quota und Autocreate-Optionen
Der aufmerksame Leser mag sich über die automatische Quota-Zuteilung von 5GB an neue User wundern. (Der numerische Wert von “autocreatequota” bezieht sich auf die Einheit KB). Würde er die User kennen, die sich auf meinem System tummeln werden, würde er sich nicht mehr wundern. Aber hier muss jeder selber wissen, was er sich und seinen Usern zugestehen will.
Zu den Autocreate-Optionen für die automatische Anlage neuer Verzeichnisse bei Posteingang für User, für die bislang noch keine Mailbox angelegt wurde, und zu den erforderlichen Voraussetzungen für die automatische Anlage muss ich auf die Literatur verweisen.

Ein paar Checks und Vorbereiten des “cyrus”-Users

Wir prüfen vorab, dass folgende Services ordnungsgemäß gestartet sind und fehlerfrei laufen:

  • systemctl status saslauthd.service
  • systemctl status sssd.service

Beide Services sollten für den automatischen Start durch systemd auf dem IMAP-Server bereits “enabled” sein oder spätestens jetzt werden.

Ferner testen wir, wie im früheren Beitrag beschrieben, dass “saslauthd” im Kern funktioniert.

mycyrus:/etc/init.d # testsaslauthd -u tarja -p TARJAPWD
0: OK “Success.”
mycyrus:/etc/init.d #

Ferner prüfen wir, ob ein Login auf dem System “mycyrus” für “tarja” möglich ist – z.B. über ssh von einem Remote-System; SSH muss dafür auf “mycyrus” aktiviert sein. Der Login ist möglich, wenn man auf “mycyrus” alles so eingerichtet hat, wie ich das im oben zitierten Artikel SASL mit PAM, SSSD, LDAP unter Opensuse vorgegeben hatte:

user@tux:~> ssh -X tarja@mycyrus
Password:
Last login: Wed Mar 12 18:21:16 2014 from tux.anraconx.de
nHave a lot of fun…
tarja@mycyrus:~>

Passwort und TLS-Gruppe für den User “cyrus” setzen
Der User “cyrus” wurde zwar bei der IMAP-Installation automatisch als Mitglied der Gruppe “mail” angelegt. Aber wir sollten nun sein Passwort mit einem Tool unserer Wahl (z.B. YaST oder usermod) setzen. Der Platzhalter für das “cyrus”-Passwort ist nachfolgend CYRUSPWD.

Zudem: Sowohl dieser User “cyrus” als später auch der User “postfix” benötigen für TLS den lesenden Zugang zum privaten SSL-Key. Ich will diese User aber natürlich nicht der root-Gruppe zuordnen. Mein Lösungsansatz ist, eine Gruppe “tls” einzurichten, der auf dem IMAP-Server nur die User “cyrus” und “postfix” angehören. Ich setze dann die Rechte wie folgenden Zeilen entnehmbar:

mycyrus:/etc/ssl/servercerts # ls -l
total 8
-rw-r–r– 1 root root 1809 Jan 18 15:03 servercert.pem
-rw-r—– 1 root tls 1704 Jan 18 15:03 serverkey.pem

Damit genug für den ersten Artikel dieser Serie. Was haben wir bis jetzt erreicht? Wir haben bislang nur Konfigurationsdateien vorbereitet und gecheckt, dass für eine Testuserin eine saslauthd-basierte Authentifizierung über einen LDAP-Server funktioniert. Leider kann sich unsere Testuserin auf dem geplanten IMAP-Server-Host auch einloggen. Wollen wir das? Klare Antwort: Nein ! Im nächsten Beitrag
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
müssen wir daher die Grundeinstellungen des Authentifizierungsverfahrens zuerst noch etwas modifizieren.

Cyrus IMAP unter Opensuse auf die Schnelle

Mein Freund Michael fragte mich mal, was ich tue, um alle meine gesammelten (alten) Mails auf Reisen einsehen zu können, wenn ich keine Verbindung zum Internet habe.

Ich denke, dass die Voraussetzung mit dem Internet gar nicht so entscheidend ist, denn nicht jeder möchte alle seinen Firmenmails oder auch seinen privaten Mails dauerhaft bei einem Provider vorrätig halten. Und nicht jeder hat einen eigenen Root-Server mit IMAP-Komponente im Internet.

In unserer kleinen Firma laden wir z.B. alle Mails von unseren verschiedenen Internet-Providern per “fetchmail” herunter und transferieren sie über Postfix auf einen lokalen, eigenen IMAP-Server (Cyrus) im Hausnetz. Dort werden Sie nach Kunden vorgefiltert.

Schon aus Sicherheitsgründen lassen wir unsere Mails nicht im Internet herumstehen. Wenn wir dann mal länger verreisen müssen, gibt es für uns zwei Methoden, unsere bisherigen Mails, die z.T. mehrere Gigabyte umfassen, unter Linux auf einem Laptop einzusehen:

  1. Disconnected IMAP-Account unter Kmail:
    Ich lege unter Kmail einen sog. “Disconnected-IMAP-Account” an und synchronisiere den vor unserer Abreise mit den Inhalten der mir zugänglichen Mailverzeichnisse auf unserem IMAP-Server. Das funktioniert in der Regel recht gut und ist sicher die einfachste Methode, seine IMAP-Mails vom hauseigenen Server auf Reisen mitzunehmen.

    Mit folgenden nicht unwesentlichen Einschränkungen: Solange man sich auf seine KDE-Installation verlassen kann, diese nicht grundlegend ändert oder updated, und keine versehentliche Synchronization des Disconnected-Imap-Accounts mit dem Nirwana anstößt …. Ein weiterer Nachteil ist natürlich der lokal auf dem Laptop benötigte Plattenplatz – in unserem Fall doch einige Gigabyte.

  2. Zugriff auf ein IMAP-Backup unter einem lokalen IMAP-Server:
    Ich kopiere zur Sicherheit den kompletten Inhalt des Verzeichnisses “/var/spoool/imap” von unserem SLES auf ein geschütztes Verzeichnis meines Laptops (mit cp -dpRv) oder eine kryptierte externe USB-Harddisk. Das ist ein sehr nützlicher Backup. Zur Not implementiere ich mir nämlich auf die Schnelle einen lokalen Cyrus-Server auf meinem Laptop und rekonstruiere mir dann die Mailverzeichnisse, die mich interessieren. Dann kann ich mit KMail auf dem Laptop auf den lokalen Cyrus-Server zugreifen und die benötigten Mails einsehen.

    Ein Vorteil dieser Lösung ist u.a. der, dass man nicht immer gleich alle Mailverzeichnisse zur Verfügung stellen muss, sondern evtl. nur die gerade interessanten, z.B. kundenbezogene. (Voraussetzung ist eine hinreichende Gliederung der Mailverzeichnis-Hierarchie)

Die Variante 2) ist auch dann ein schöner Rettungsanker, wenn man sich bei einem KDE-Upgrade in der Fremde (z.B. von KDE 4.5 auf 4.7) seine Akonadi- und Kmail-Installation auf einem Opensuse 11.4 praktisch zwangsweise zerschießen muss. Denn der Sprung vom Kmail 1.x zu Kmail2 und die entsprechend notwendigen Migrationen von IMAP-Resourcen funktionieren schlicht nicht fehlerfrei.

Oft genug muss der KDE-Nutzer seit der Akonadi-Einführung feststellen, dass Kmail sich nach fehlgeschlagenen Migrationsversuchen nicht mehr starten läßt. Dann bleibt einem nur mehr der Neuaufbau der Akonadi-Ressourcen und von Kmail durch Löschen der Inhalte entsprechender Akonadi- und Kmail-Konfigurationsdateien. Leider können dabei auch die “Disconnected-IMAP-Verzeichnisse” vom alten Kmail verloren. Das passierte mir neulich in Norwegen. Hat man dann seine IMAP-Dateien in Form eines Backups dabei, ist das kein Weltuntergang.

Wie kommt man also auf die Schnelle unter Opensuse zu einem lokalen Cyrus IMAP-Server, mit dem man die Mails eines IMAP-Backups einsehen kann? Das ist gar nicht so schwer, wenn man bei der Sicherheit Abstriche macht und auf eine Open-SSL-Umgebung für den lokalen IMAP-Server
verzichtet. Den IMAP-Port des Cyrus-Servers kann man durch eine Firewall ja nach außen gezielt sperren, wenn man sich mit seinem Laptop während einer Reise ins Internet begibt.

Die nachfolgende Installation ist allerdings so simpel, dass sie kaum für mehr als das Lesen alter Mails aus einem Backup geeignet ist. Sie kann nicht für einen produktiven Betrieb – z.B. zusammen mit Postfix – eingesetzt werden. Aber das ist in diesem Artikel auch gar nicht die Zielsetzung.

Wer sich genauer mit CYRUS IMAP und SASL befassen will, sei auf dir Dokumentation unter

/usr/share/doc/packages/cyrus-imapd/doc/

und

/usr/share/doc/packages/cyrus-sasl/doc/

hingewiesen. (Hierzu muss man sich unter Opensuse natürlich die RPMs für die Paket-Dokumentation installiert haben.)

Schritt 1: Notwendige Pakete der Opensuse Repositories

Eine Voraussetzung der Cyrus-Installation ist , dass man sich bereits die RPM-Pakete von Opensuse für den lokalen Cyrus-Imap-Server und den SASL-Authentifizierungsmechanismus installiert hat. Folgende Pakte stellen nach meiner Erfahrung das notwendige Minimum dar:

  • cyrus-imapd
  • cyrus-sasl
  • cyrus-sasl-plain
  • cyrus-sasl-saslauthd
  • perl-Cyrus-IMAP
  • perl-Athen-SASL

Will man neben “Plain” andere sicherere SASL-Mechanismen wie z.B. “digest-MD5” (für die Passwortverschlüsselung) benutzen, so muss man sich die entsprechenden Pakte zusätzlich installieren. Ich gehe auf solche Varianten aber nachfolgend nicht ein.

Schritt 2: Starten der Dämonen

Bevor man administrativ tätig werden kann, müssen die Cyrus- und SASL-Dienste laufen. Man prüft den Status der Dienste mit

#   rccyrus status
#   rcsaslauthd status

Nötigenfalls startet man die Dienste unter Opensuse explizit per

#   rccyrus start
#   rcsaslauthd start

Für ein dauerhaften Start beim Hochfahren trägt man die Dienste über “Yast >> Systemdienste (Runlevel)” für die gewünschten Runlevels [ z.B. 3 und 5 ] ein.

Schritt 3: User “cyrus” als Mitglied der Gruppe “mail” überprüfen

Wir prüfen dann, dass es einen User “cyrus” im System gibt. Dieser wird unter Suse normalerweise bei der RPM-Installation automatisch angelegt und ist Mitglied der Gruppe “mail”. Sein Homeverzeichnis ist “/var/lib/imap”. Er sollte ferner Owner des Verzeichnisses “var/spool/imap” sein.

laplux:~ # ls -l /var/spool
…..
drwxr-x— 3 cyrus mail 4096 Nov 17 17:26 imap
….

Schritt 4: SASL für imap als Authentifikations-Mechanismus festlegen

Der Cyrus-SASL-Mechanismus muss in der Datei “/etc/imapd.conf” als Auth-Verfahren für den Cyrus IMAP-Server festgelegt werden. Siehe hierzu die rot markierten Einträge im nachfolgenden Listing der “imapd.conf”-Datei. Diese sehr einfache Datei wurde mit der Installation der RPM-Pakete angelegt (bis auf einen Eintrag “allowplaintext”, den wir weiter unten erläutern):

configdirectory: /var/lib/imap
partition-default: /var/spool/imap
sievedir: /var/lib/sieve
admins: cyrus
allowanonymouslogin: no
autocreatequota: 10000
reject8bit: no
quotawarn: 90
r
timeout: 30
poptimeout: 10
dracinterval: 0
drachost: localhost
sasl_pwcheck_method: saslauthd
lmtp_overquota_perm_failure: no
lmtp_downcase_rcpt: yes
 
# Changed by cyrus for an installation of intern backup server
allowplaintext:yes
 
#
# if you want TLS, you have to generate certificates and keys
#
#tls_cert_file: /usr/ssl/certs/cert.pem
#tls_key_file: /usr/ssl/certs/skey.pem
#tls_ca_file: /usr/ssl/CA/CAcert.pem
#tls_ca_path: /usr/ssl/CA

Danach starten wir den IMAP-Server per

#   rccyrus restart

neu.

Hinweis 1: Die Konfigurationsvielfalt für einen ausgewachsenen IMAP-Server kann man nach einem Blick in die Manpage erahnen:

#  man 5 imapd.conf

Für unsere einfachen Zwecke genügen die obigen Einträge aber vollkommen.

Schritt 5: SASL-Passwort für den User “cyrus” setzen und die Datei “sasldb2” lesbar machen

Auch der User “cyrus” muss sich natürlich gegenüber dem IMAP-Server authentifizieren. Als User “root” legen wir nun das SASL-Passwort für cyradm fest. Hierzu benutzten wir das Programm “/usr/sbin/saslpasswd2”:

laplux:~ # saslpasswd2 -c cyrus
Password:
Again (for verification):

Dabei geben wir das gewünschte Passwort (nachfolgend mit “CYRUS_PWD” bezeichnet) zweimal ein.

Zudem müssen wir dafür sorgen, dass der User “cyrus” die Datei “/etc/sasldb2” lesen kann. Am einfachsten geschieht dies in unserem Fall, indem man “cyrus” zum Owner macht:

laplux:~ # chown cyrus /etc/sasldb2*

Bei komplexeren Konfigurationen, in denen mehrere Programme SASL nutzen, muss hier bei Bedarf geeignete Gruppen aufbauen, die noch andere User mit aufnehmen.

Schritt 6: Mailverzeichnis für einen neuen Mailuser “rmx” anlegen

Unser Mailuser, unter dessen ID wir auf die Mails zugreifen wollen, habe die UID “rmx”. Wir legen nun einen Mailordner (Eingangskorb) für den User “rmx” an. Dazu wechseln wir zum User “cyrus” und führen dann das Kommando “cyradm” aus, das uns in eine eigene Kommandoumgebung für den Cyrus-Server führt:

lap3lux64:~ #   su – cyrus
cyrus@lap3lux64:~> cyradm
cyradm> connect localhost
Password:
localhost.localdomain> lm
user.rau (\HasChildren)

user.rau.Gesendete Objekte (\HasNoChildren)
user.rau.alpha_inbox (\HasNoChildren)

localhost.localdomain> cm user.rmx
localhost.localdomain> lm
user.rau (\HasChildren)

user.rau.Gesendete Objekte (\HasNoChildren)
user.rau.alpha_inbox (\HasNoChildren)

user.rmx (\HasNoChildren)

localhost.localdomain>

Zu den Kommandos im Einzelnen:

Bevor wir ein Verzeichnis anlegen können, müssen wir uns mit unserem lokalen cyrus-Server verbinden. Dies geschieht über das cyradm-Kommando “connect” – hier “connect localhost”. Das einzugebende Passwort ist nun genau das zuvor eingerichtete SASL-Passwort “CYRUS_PWD”.

Nach der erfolgreichen Verbinung zum lokalen IMAP-Server sehen wir uns zunächst einmal um. Das oben dargestellte Kommando “lm” zeigt alle bereits vorhandenen Mailverzeichnisse an. Beginnt man von
Scratch wird hier natürlich kein Verzeichnis angezeigt. Im obigen Beispiel sind bereits Verzeichnisse für einen User “rau” vorhanden.

IMAP arbeitet mit ganzen hierarchischen Mail-Verzeichnisbäumen. In der IMAP-Verzeichnishierarchie wird ein User-Zweig für den User mit der ID “uid” normalerweise durch Erzeugen des Verzeichnisses “user.uid” angelegt.

Der Schlüsselbefehl für das Anlegen eines Mailverzeichnisses ist “cm”. Legt man keinen speziellen Posteingang an, so kann dieses Verzeichnis auch als Default-Posteingangskorb benutzt werden. Das abschließende “lm” zeigt an, dass das gewünschte Verzeichnis erstellt wurde.

Hinweis 2: Man kann alle Befehle, die einem unter der “cyradm”-Oberfläche zur Verfügung stehen, durch Eingabe von “help” einsehen. Die cyradm-Umgebung verläßt man mit “quit” oder “exit”.

Hinweis 3: Hier lohnt es sich, als root einen vergleichenden Blick auf die Verzeichnisstruktur unter “/var/spool/imap/user/rmx” zu werfen.

laplux:/var/spool/imap/user/rmx # ls
cyrus.cache cyrus.header cyrus.index

Man erkennt, dass bereits Filestrukturen zur Indizierung und zum Cachen der Verzeichnisinhalte angelegt wurden. Diese sind zu füllen, sobald wir das Verzeichnis mit Inhalt versehen.

Hinweis 4: Die Hierarchie der Mailverzeichnisse wird in der “cyradm”-Umgebung durch eine einfach qualifizierende Punkt-Notation erfasst – z.B.: user.uid.suppliers.suse.

Schritt 7: SASL-Passwort für den Mail-User “rmx” setzen und dem User Rechte an seinem Mailverzeichnis geben

Dem Leser ist sicher aufgefallen, dass auch der User “rmx” natürlich noch SASL bekannt gemacht werden muss. Ferner kann man sich denken, dass ein IMAP-User hinreichende Rechte bekommen muss, um auf die ihm zugeordneten IMAP-Verzeichnisse auch zugreifen zu dürfen. Wir benutzen zunächst wieder “saslpasswd2” als root:

laplux:~ # saslpasswd2 rmx
Password:

Again (for verification):

Das Passwort für den User “rmx” sei “RMX_PWD”. Nun gehen wir noch einmal in die “cyradm”-Umgebung und verbinden uns mit dem lokalen Server und schauen nach, wie wir Rechte abfragen und vergeben können :

ap3lux64:~ # su – cyrus
cyrus@lap3lux64:~> cyradm
cyradm> connect localhost
Password:
localhost.localdomain> help
 
authenticate, login, auth authenticate to server
chdir, cd change current directory
createmailbox, create, cm create mailbox
deleteaclmailbox, deleteacl, dam remove ACLs from mailbox
deletemailbox, delete, dm delete mailbox
disconnect, disc disconnect from current server
exit, quit exit cyradm
help, ? show commands
info display mailbox/server metadata
listacl, lam, listaclmailbox list ACLs on mailbox
listmailbox, lm list mailboxes
listquota, lq list quotas on specified root
listquotaroot, lqr, lqm show quota roots and quotas for mailbox
mboxcfg, mboxconfig configure mailbox
reconstruct reconstruct mailbox (if supported)
renamemailbox, rename, renm rename (and optionally relocate) mailbox
server, servername, connect show current server or connect to server
setaclmailbox, sam, setacl set ACLs on mailbox
nsetinfo set server metadata
setquota, sq set quota on mailbox or resource
subscribe, sub subscribe to a mailbox
unsubscribe, unsub unsubscribe from a mailbox
version, ver display version info of current server
xfermailbox, xfer transfer (relocate) a mailbox to a different server
 
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
 
localhost.localdomain> sam
usage: setaclmailbox mailbox id rights [id rights …]
 
localhost.localdomain> sam user.rmx rmx all
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
 
localhost.localdomain> sam user.rmx rau all
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
rau lrswipkxtecda
 
localhost.localdomain> cm user.rmx.sent
localhost.localdomain> lam user.rmx.sent
rmx lrswipkxtecda
rau lrswipkxtecda
 
localhost.localdomain> sam user.rmx rau none
localhost.localdomain> lam user.rmx
rmx lrswipkxtecda
localhost.localdomain>

Das Help-Kommando führt uns zu den Kommandos “lam” für die Anzeige der Access-Rights und “sam” zum Setzen der Rechte. Die oben im Listing angezeigten Kommandos sind dann kaum erläuterungsbedürftig.

Wir erkennen, dass der User “rmx” bereits automatisch alle Rechte am Mail-Verzeichnis “uxer.rmx” zugeteilt bekommen hat. Diese Rechte werden auch auf weitere Subverzeichnisse “vererbt”. Dies gilt übrigens auch für andere User – hier z.B., wenn man auch dem User “rau” sämtliche Rechte am Verzeichnis “user.rmx” einmal testweise zuordnet. Am Schluss nehmen wir dem User “rau” die zugewiesenen Rechte wieder weg.

Hinweis 5: Welche Rechte es in Bezug auf Mailverzeichnisse unter Cyrus IMAP gibt und was sie bedeuten, erfährt man durch Studium der folgenden Doku-Seite, die man in einem Browser betrachten kann:

file:///usr/share/doc/packages/cyrus-imapd/doc/overview.html#aclrt

Schritt 7: Mails aus dem Backup kopieren und Mailverzeichnis rekonstruieren

Nun wollen wir das Verzeichnis “user.rmx” mit Mailinhalt füllen. Dies geschieht einfach durch Umkopieren der Inhalte des korrespondierenden Verzeichnisses in unserem Backup von “/var/spool/imap”, das wir von unserem richtigen IMAP-Server angelegt hatten.

Typischerweise haben wir unsere Sicherung auf einem USB-Stick oder einer USB-Platte dabei. Diese sei lokal am Laptop unter unter dem Verzeichnis “/backup” gemountet und die ursprüngliche Verzeichnisstruktur “/var/spool/imap” sei unter dem Verzeichnis “/bup_cyrus” abgelegt.

Dort – also am Ort des Backups – suchen wir unter den obigen Annahmen als “root” das Verzeichnis “/var/spool/imap/user/rmx”. Unter den obigen Annahmen finden wir es unter:

/backup/bup_cyrus/var/spool/imap/user/rmx”

(Natürlich können wir ggf. auch ein anderes Verzeichnis wählen, welches uns interessiert und das wir anschließend im lokalen Cyrus gerne unter user.rmx öffnen möchten. Nur Mails aus unterschiedlichen Usprungs-Verzeichnissen sollte man nicht im selben Zielverzeichnis mixen.)

Wir kopieren dann vom Backup alle Files (Mails) vom gewünschten Verzeichnis – hier also aus “/backup/bup_cyrus/var/spool/imap/user/rmx” – in das korrespondierende Mailverzeichnis “/var/spool/imap/user/rmx” auf unserem lokalen IMAP-Server

Ausgenommen werden vom Kopiervorgang evtl. vorhandene Subverzeichnisse und Files, die mit “cyrus.” beginnen (cyrus.cache, cyrus.header, cyrus.index).

Abschließend ändern wir mit


laplux:~ # cd /var/spool/imap/user/rmx
laplux:/var/spool/imap/user/rmx # chown cyrus.mail *

den Owner und die Gruppe der kopierten Dateien (= Mails) ab.

Nun gehen wir wieder in den “cyradm”-Bereich und “rekonstruieren” das Verzeichnis für den Gebrauch. Dies geschieht über den Befehl “reconstruct”, der die Cyrus -Index- und Cyrus-Datenbankstrukturen gebrauchsfähig macht und auf den tatsächlichen aktuellen Inhalt des Verzeichnisses abstimmt:

lap3lux64:~ # su – cyrus
cyrus@lap3lux64:~> cyradm
cyradm> connect localhost
Password:
localhost.localdomain> reconstruct user.rmx
localhost.localdomain> quit
cyrus@lap3lux64:~>

Je nach Größe des Inhaltes der transferierten Dateien dauert das etwas – nach meinen Erfahrungen geht der “reconstruct”-Prozess aber auch bei größeren Mailverzeichnissen recht zügig vonstatten.

Schritt 9: LOGIN über PLAIN-Mechanismus zulassen und Test des Zugangs mit “imtest”

Uns fehlt noch ein wichtiger Eintrag, der sicherheitsrelevant ist und in der Datei “imapd.conf” vorgenommen werden muss. Da wir uns nur lokal einloggen wollen, ist keine SSL-Struktur mit Zertifikaten erforderlich – wenn wir auf unserem Laptop den potentiellen Zugriff von außen per Firewall dicht machen.

Ein Plain-Login muss für den Cyrus-Server aber explizit zugelassen werden! Sie finden den notwendigen Eintrag

# Changed by cyrus for installation of intern backup server
allowplaintext:yes

bereits im obigen Dateil-Listing. Wir hatten ihn dort nur noch nicht angesprochen.

Wir starten nach der obigen Änderung den Imap-Server per

#   rccyrus restart

zur Sicherheit nochmal.

Schritt 10: LOGIN mit imtest testen

Wir können nun den ordnungsgemäßen Zugang zum IMAP-Server mit dem Befehl “imtest” testen.

lap3lux64:~ #   imtest -v -a rmx -u rmx -m login localhost
 
S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=GSSAPI AUTH=LOGIN AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
SASL-IR COMPRESS=DEFLATE] laplux.mydomain.de Cyrus IMAP v2.3.16 server ready
Please enter your password:
C: L01 LOGIN rmx {7}
S: + go ahead
C:
S: L01 OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED COMPRESS=DEFLATE ACL RIGHTS=kxte QUOTA MAILBOX-
REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE X-NETSCAPE URLAUTH]
 
User logged in
Authenticated.
Security strength factor: 0

Als Passwort muss man hier natürlich das “RMX_PWD” angeben. Wenn alles OK ist, sollte dann die Meldung “authenticated” erscheinen. Weitere Optionen zum “imtest”-Kommando liefert die zugehörige “man page”.

Schritt 11: IMAP-Zugang in Kmail konfigurieren und testen

Nach diesem positiven Zwischenergebnis ist alles bereitet, um sich unter Kmail oder einem anderen E-Mail-Programm einen neuen, zusätzlichen Account für den lokalen IMAP-Server einzurichten. Man verfährt hierbei genauso wie mit jedem anderen IMAP-Account.

Bei der Einrichtung gilt: Der anzugebende IMAP-Server ist “localhost”, die User-Id ist “rmx”, das zugehörige Password in unserem Fall dasjenige, das wir mit “RMX-PWD” bezeichnet hatten.

Danach taucht
der lokale Server mit dem bislang einzigen Verzeichnis und dessen Mail-Inhalt auf.

Sind wir an einer Einsicht in andere Verzeichnisse aus unserem Backup interessiert, so legen wir über “cyradm” einfach entsprechende weitere Verzeichnisse an, kopieren die Inhalte aus dem Backup hinein und führen jeweils ein “reconstruct” für das neue Verzeichnis der entstehenden Hierarchie durch.

Viel Spass nun beim Lesen der IMAP-Mails aus einem Backup in der Fremde.

KDE 4.6 Beta, K3b, Kmail, Akonadi, virtuoso-t, OX5

No risk no fun ! Dachte ich und habe mir mal KDE 4.6 Beta auf einem meiner Opensuse 11.3 Systeme installiert. Aus drei Gründen war das für mich ein interessantes Experiment :

  1. Weil unter KDE 4.5.2, KDE 4.5.3 K3b nicht mehr funktionierte und ich gemäß der Einträge bei den entsprechenden KDE-Bugs aber die Hoffnung bekam, es könne nun wieder laufen.
  2. Weil unter KDE 4.6 das Akonadi-Subsystem nicht mehr nur für das Adressbuch sondern auch für die Verwaltung der Mailordner zuständig wird. Hier ist das Wechselspiel mit IMAP-Systemen interessant.
  3. Weil Akonadi auch mit den Kalender-Ressourcen eines Open-Xchange 5 Servers zusammenarbeiten sollte.

Um es vorweg deutlich zu sagen: Solche Experimente mit Beta-Systemen wie zu Punkt 2 sollten keine produktiven IMAP- oder OX-Server einbeziehen, sondern nur Server, die Kopien der eigentlichen IMAP-Mail-Ordner und Kalenderdaten beinhalten! Zur Not richtet man sich einen IMAP-Testserver halt auf einem Laptop oder einem virtuellen System ein. Bei OX5 oder OX6 ist das zugegebenermaßen schon schwieriger.

Zu Punkt 1 – K3b:

K3b läuft unter Opensuse 11.3 und KDE 4.6 wieder – allerdings nur mit den letzten K3b RPM-Paketen 2.0.1-44.1 im Opensuse Factory Repository. Eine CD habe ich mal testweise gebrannt – das lief ohne Probleme. Genauer getestet habe ich das Brennen von unterschiedlichen Medien (DVD+-R, DVD+RW, etc. aber noch nicht. Das Rippen von CDs läuft mit der aktuellen Version aber wie gewohnt. Anzumerken bleibt: Die aktuellen RPMs von Packman 2.0.1.pm.2.26 laufen nicht. (Vermutlich wegen der erfolgten Änderungen im HAL-Bereich)

Zu Punkt 2 – Kmail, Akonadi, IMAP – und die problematische Wirkung von Filtern :

Die Verwaltung von Mailordnern durch Akonadi stelle ich mir persönlich als eine komplexe Angelegenheit vor. Im Besonderen dann, wenn die Mailordner auf einem IMAP-Server liegen und die Filterung von Mails (Spam und andere Filter) aber lokal unter KDE’s Kmail erfolgt. Ich habe auf meinem Desktop-System eine ganze Reihe von Filtern eingestellt. Nicht nur zum zusätzlichen Filtern von Spam, der auf dem Server nicht erkannt oder zu vorsichtig behandelt wurde, sondern auch themen- und kundenbezogene Filter.

Für mich als Anwender stellt sich doch die Frage, wie der mindestens zweistufige Weg der Filterung von Kmail über die Akonadi-Maschinerie hin zum IMAP-Server abläuft. Kmail als Frontend zu Akonadi initiiert die Filterung und als Reaktion werden dann ggf. Verschiebungen von Mails aus dem Posteingangsordner hin zu anderen Ordnern durchgeführt. Das Ergebnis muss sich zunächst auf dem lokalen Akonadi-System und dessen Abbildung der Mailordner niederschlagen. Die vorgenommenen Ergebnisse der Filteraktionen wie Löschungen im Ursprungsordner und entsprechende Neuzugang in definierten Zielordnern müssen ja aber auch periodisch zwischen Akonadi und dem IMAP-Server abgeglichen werden. In einer solchen Verarbeitungskette – MUA-Client <> Akonadi (als zwischengeschobenes zentraler Puffer) <> IMAP-Server – eröffnen sich zahlreiche Möglichkeiten für Fehler.

Meine Erfahrungen waren entsprechend :
Die Migration der vorhandenen Mail-Ordner aus dem alten Kmail hin zu Akonadi ging grundsätzlich ohne Probleme vonstatten. Es dauerte allerdings etliche Minuten, da unsere Mailordner mehrere Gigabyte umfassen. Die Zeitdauer für die Migration war aus meiner Sicht absolut OK. Probleme verursachten dann aber die bereits konfigurierten Mail-Filter aus meiner KDE 4.5.3-Kmail-Version. Diese fingen nämlich beim Füllen meiner doch zahlreichen Mailordner an zu wirken – und zwar nicht in der gewohnten Weise. Es wurde in andere lokale Ordner verschoben, die begonnen Filtervorgänge schluckten
enorm viel CPU-Zeit, die Kmail-Oberfläche kam letztlich zum Stillstand und war nicht mehr bedienbar …. Ursache war hier vermutlich, dass viele Mailordner im Zuge der Migration gleichzeitig neu befüllt wurden.

Kurzum:
Die Filter verursachten zeitversetzt und im Nachgang zum eigentlichen Migrationslauf zunächst ein ziemliches Chaos und ungewohnte Verschiebungen in lokale (!) Spam- und Trash-Ordner. Offenabr war ein teil der alten Konfiguration – nämlich die Festlegung der Zielordner – verloren gegangen. Nun ließen sich die laufenden Filterprozesse wegen des Stillstands der Kmail-Oberfläche leider auf konventionellem Wege auch nicht mehr aufhalten. Ein Killen der entsprechenden Prozesse, ein Löschen der Konfigurationsdatei kmail2rc und ein Neustart verhalfen mir schließlich zu der Möglichkeit, meine Filter zu entfernen und komplett neu anzulegen. Danach verhielt sich Kmail ruhiger und ließ sich fast (s.u.) normal bedienen. Die fälschlich verschobenen Mails habe ich dann wieder in ihre Ursprungsordner einstellen können.

Ich kann daher jedem, der größere Mailordner sein eigen nennt, nur raten, vor einem Umstieg auf das neue KDE und sein Kmail alle eingerichteten Filter zunächst mindestens zu deaktivieren, wenn nicht gar zu löschen – und sie erst im Nachheinein neu einzurichten.

Aber auch dann bereiten die lokalen Filter in Kmail noch weitere Probleme:

Im Gegensatz zu früheren Kmail-Varianten werden nämlich alle auf dem IMAP-Server für das Löschen markierte – aber im IMAP-System aus den Ursprungsordnern physikalisch noch nicht gelöschte Mails – erneut in den Mail-Ordnern von Kmail angezeigt (in grauer Schriftfarbe). Regeln zur Kompaktifizierung der IMAP-Ordner – sprich zu einem sofortigen Löschen von Mails in den IMAP-Ordnern auf dem Server – sind bei mir deaktiviert. Mails werden daher auf dem IMAP-Server bei Lösch- oder Verschiebe-Vorgängen in ihrem Ursprungsordner nur zum Löschen markiert. Die eigentlichen Löschungen laufen dann am IMAP-Server zwar periodisch, aber mit deutlichem zeitlichem Abstand. Das ist eine reine Vorsichtsmaßnahme, von der die User an ihren Clients (wie dem alten Kmail) normalerweise gar nichts mitbekommen.

Aus der Anzeige der zum Löschen markierten Mails in Kmail lässt sich schließen, dass Akonadi beim Filtern und Verschieben der Mails in neue Ordner also mitbekommt, dass die verschobenen Mails auf dem IMAP-Server noch im Ursprungsordner vorhanden sind – wenn auch mit geändertem Status. Nun wirkt sich das leider negativ auf die Filter in Kmail aus. Die Filter bewerten die markierten Mails offenbar als neu eingegangene (möglicherweise wegen der Statusänderung) und filtern sie deshalb auch erneut. Obwohl sie ja schon früher behandelt und in andere Ordner verschoben wurden. Und das setzt sich dann so fort ….

Ergebnis:
Nach einigen periodischen Abgleichen zwischen Akonadi und dem Imap-Server wächst der Inhalt in Trash oder Spam-Ordnern linear an. Mit immer den gleichen Dateien. Das ist im Produktivbetrieb ein Desaster. Als Anwender kann man hier das Gesamtsystem nur so einstellen, dass bei der Löschung/Verschiebung einer Mail aus einem Ordner durch eine Kmail-Aktion auch eine sofortige Löschung der Mail in ihrem Ursprungsordner auf dem IMAP-Server vorgenommen wird. Das ist zumindest riskant. Oder man muss die Filter um sehr spezielle Einstellungen und Kriterien erweitern – was man vom normalen User nicht verlangen kann.

Die Lösung aus meiner Sicht wäre eine andere Behandlung von Mails, die auf dem IMAP-Server zum Löschen markiert sind, in Akonadi wie in der Anzeige und den Filter-Routinen von Kmail.

In der jetzigen Form ist das Kmail/Akonadi-Verhalten im Zusammenspiel mit IMAP-Servern zwar schon erstaunlich stabil und auch die Migration der Mailordner zu Akonadi-Ressourcen funktioniert im Kern schon richtig. Aber die Behandlung von Mails, die aufgrund von Client-Aktionen auf den IMAP-Servern zum Löschen vormarkiert werden, muss für den produktiven Einsatz geändert werden.

Hinzu
kommt ein weiteres Problem, dessen Ende ich auf meinem Versuchssystem noch nicht absehen kann. Mindestens am ersten Tag der Umstellung fraß der “virtuoso-d”-Prozess mit führendem Abstand die allermeiste CPU-Zeit auf meinem System (in Form von nice-Last). Ursache ist die Indizierung von Mails durch Nepomuk mit Virtuoso als Backend (virtuoso-t ist wohl ein zugehöriger Datenbank-Prozess).

Dabei war die Konkurrenz um die Prozessorzeit keineswegs gering – auf zwei von 4 CPU-Cores habe ich andauernd unter VMware auf einem virtuellen Windows-System gearbeitet. Normalerweise würde VMware die meiste CPU-Zeit beanspruchen. Bei KDE 4.6 Beta war es bislang aber der Prozess “virtuoso-d”. Er verbrauchte doppelt soviel CPU-Zeit wie VMware – und zwar im bereich mehrerer Stunden. Das ist wirklich viel!

Ob das daran liegt, dass ich Gigabytes an Mails habe, vermag ich im Moment nicht zu sagen. Ich hoffe jedenfalls noch, dass “virtuoso-t” nach vielleicht weiteren 12 Stunden endlich Ruhe gibt. Im Moment ist er immer noch fleißig am Werkeln. Fairerweise muss ich sagen, dass vituoso-t sich auf einen Prozessor-Core beschränkt und nach ersten Eindrücken auch nur dann so richtig aktiv wird, wenn tatsächlich noch CPU-Zeit verfügbar ist. Na ja, wir werden sehen, ob die Nepomuk- Indizierung auch mal zu einem Ende kommt. Insgesamt ist das Ganze aber in Indiz dafür, dass man Virtuoso oder aber das Zusammenspiel von Akonadi und Virtuoso ggf. noch effizienter machen muss.

Im Moment würde ich wegen der geschilderten Erfahrungen noch niemanden raten, auf produktiven Systemen auf das neue Kmail umzusteigen.

Zu Punkt 3 – Korganizer, Kadressbuch, OX5:

Das funktioniert im Moment schlicht und einfach nicht. Die Einrichtung von Kalendern als Teil einer OX5-Verbindung zu Kontakt scheitert. Einen entsprechenden Bug habe ich eingestellt. Das ist für mich im Moment übrigens der Hauptgrund, bei KDE 4.5.3 zu bleiben.

Auf einige Ungereimtheiten beim Umgang mit dem OX5-Adressbuch mag ich hier nicht mehr eingehen. Das läuft zwar als Relikt aus 4.5.3 zwar irgendwie, aber dennoch habe ich den Eindruck, dass die zugehörige Akonadi-Ressource nicht wirklich migriert wurde. Denn wenn ich auf die Eigenschaften der entsprechenden Akonadi-Resource zum OX5-Adressbuch gehe, öffnet sich ein Dialog zur Migration – in dem leider Open-Xchange gar nicht als Alternative erscheint. Womöglich arbeitet das “übernommene” Adressbuch also auf einer alten, nicht upgedateten Akonadi-Resource, die keine Verbindung zum OX-Server mehr aufweist. Bin im Moment aber zu faul, mir das genauer anzusehen.

Fazit:

Interessant war es schon, Akonadi nun mal im breiten Einsatz für Gigabytes an Mail zu sehen und nicht nur als Quelle für simple und in der Anzahl überschaubare Adressbuch-Daten. Im Kern funktioniert das schon. Bis auf “Kleinigkeiten” wie die Anzeige von zum Löschen markierten Mails des IMAP-Server und die Behandlung von Filteraktionen für solche Mails.

Ich bin daher sehr gespannt, wie sich KDE 4.6.Beta 2 bzw. der Release-Kandidat präsentieren werden. Im Moment ist Kontact KDE 4.6 in unserem Arbeits-Umfeld jedenfalls noch nicht reif für den produktiven Einsatz. Was ich bei einer ersten Beta-Version auch keinesfalls überbewerten will, sondern als normal ansehe.

Nachtrag: Problem mit der FROM-Adresse

Gerade macht mich meine Frau darauf aufmerksam, dass Mails, die ich von meiner Testinstallation verschicke, eine leere FROM-Envelope-Adresse aufweisen. Dies geschieht seit der Installation der letzten Kmail-RPM-Variante 4.5.80-261.2 vom Opensuse Factory-Repository unter KDE 4.6 Beta. Obwohl alle notwendigen Daten in der Kmail-“Identität” gepflegt sind. Na ja, Beta halt ……