Category Archives: Postfix, Cyrus IMAP, Kmail

Mailkomponenten im aktiven Einsatz

Cyrus IMAP unter Opensuse auf die Schnelle

Posted on by

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

Posted on by

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 ……

Kontact, Kmail, Adressbuch – Nachtrag

Posted on by

Am 19.03. habe ich mich ein wenig genervt über die Adressbuch-Philosophie der KDE-Kontact-Entwickler ausgelassen (Link zum Blog-Artikel).

Damals konnte ich die Adressen des “Default Adressbook” (Akonadi-Ressource), aber auch die Einträge eines unter Akonadi angelegten konventionellen Open-Xchange-Adressbuches (OX-Ressource) nicht unter Kmail nutzen. So funktionierte z.B. die automatische Adress-Vervollständigung während der Erstellung einer Mail nicht mehr. Die Lösung bestand darin, unabhängig von der Ressource “Default-Adressbuch” unter Kontact/Kontakte eine weitere Ressource in Form eines “herkömmlichen” Adressbuches anzulegen. Diese wurde – wenn ich mich recht erinnere – damals als Akonadi-Ressource, aber auch als KDE-Ressource bekannt gemacht.

Gestern setzte sich der Ärger bei der Neuanlage eines Users mit KDE 4.4 erneut fort: Das Anlegen einer “herkömmlichen” Adressbuches unter Kontact/Kontakte reicht definitiv nicht, um die Adressen eines externen Open-Xchange bei der Neuanlage von Mails unter Kontact/Kmail verwenden zu können. Vielmehr ist es notwenig, die externe Adressbuch-Ressource zusätzlich und manuell als KDE-Ressource über die KDE “Systemeinstellungen” anzulegen.

Wie ein normaler Anwender das bei der Einrichtung von Kontact/Kmail erkennen soll, ist mir ein Rätsel ….. aber ich wundere mich langsam über gar nichts mehr ….. und habe den alten Artikel entsprechend abgeändert.

Mails im Ausland über deutsche SMTP-Server

Posted on by

Immer wieder begegnet man dem Problem, dass man bei Auslandsaufenthalten genötigt wird, für den Mailversand den SMTP-Server desjenigen Providers zu verwenden, an dessen Netzwerk man gerade angebunden ist. Ich stosse auf dieses Problem u.a. immer wieder in Norwegen (Telenor, Tele2) und Frankreich (Orange, France Telekom, Bouygues, Free(box)).

Die Provider filtern Zieladressen für eine SMTP-Kommunikation (Port 25), die sich nicht auf den Provider-eigenen SMTP-Server beziehen. Angeblich, weil man auf diesem Wege Spam-Probleme besser in den Griff bekommen will. Na ja, wer’s glauben mag ….

Das Problem ist der dadurch für den Anwender generierte Aufwand. In der Regel hat man den Mail-Client (MUA, bei mir Kmail) auf seinem Notebook/Laptop ja so vorkonfiguriert, dass als SMTP-Server in der Regel ein Server des hauseigenen deutschen Providers eingestellt ist.

[Es kann aber auch auf Laptops noch komplizierter sein – nämlich dann, wenn ein eigener SMTP-Server, evtl. sogar ein lokaler SMTP-Server auf dem Laptop mit einer Relay-Server-Anbindung die SMTP-Kommunikation handhabt (z.B. in Form eines lokalen Postfix MTA mit einem IMAP MDA wie Cyrus) ].

In jedem Fall aber ärgert man sich bei Auslandsreisen jedesmal über die Notwendigkeit einer Re- oder Zusatzkonfiguration des Mail-Clients oder aber anderer Mailkomponenten (wie Postfix).

Am Schluss schleppt man eine Liste ausländischer SMTP-Server in seinen Mail-Programmen herum, aus der man je nach Standort einen bestimmten Server als den aktuellen Standard definieren muss. Schon bei manchen MUAs ist das ein Thema, denn der Mailclient sollte dann so intelligent ist, mehrere account-übergreifende SMTP-Server verwalten zu können ….

Bei einigen der ausländischen Netze habe ich deshalb mal mit einigen Linux-Tools überprüft, ob tatsächlich nur der Port 25 gefiltert wird. Dies war der Fall. Da kommt man dann auf den Gedanken, ob nicht ein anderer Port den Zugang zum SMTP-Server eines meiner deutschen Provider ermöglichen würde.

Man denkt dabei an eine TLS/SSL-Anbindung – in Frage kommen die Ports 465 und 587.

Und ja, tatsächlich ist bei zweien meiner deutschen Provider entweder der Port 465 (SMTP via SSL) oder der Port 587 zugänglich. Einer der Provider verwendet 465 in Kombination mit SMTP-AUTH, beim Port 587 ist eine Authentifizierung sowieso zwingend vorgeschrieben. Auf dem Mail-Client müssen dann natürlich die notwendigen Einstellungen für eine SMTP-Authentifizierung vorgenommen werden – was bei Kmail kein Problem darstellt.

Eine Anbindung über einen der beiden Ports 465 oder 587 kann man natürlich auch aus dem Inland vornehmen. Damit ist dann die Chance gegeben, im Inland wie auch in vielen ausländischen Netzwerken seinen Mailversand über den gewohnten SMTP-Server seines Vertrauens abzuwickeln. Standortspezifische Einstellungen entfallen dann. (Nebenbei finde ich, dass nicht jeden Provider mein Mail-Gebaren etwas angeht).

Nach meinen Erfahrungen klappt das Verwenden der Alternativports mindestens mal in Norwegen und Frankreich bestens – gefiltert wird dort nur der Port 25. Natürlich muss aber auch der eigene deutsche Provider mitspielen und die genannten Ports anbieten …..

Es lohnt sich bei häufigen Auslandsaufenthalten aber wirklich, das abzufragen und seine Mailprogramme (einmalig) auf einen der Ports 465 opder 587 umzustellen. Viel Spaß nun beim Mailen im Ausland !

Links:

http://de.wikipedia.org/wiki/E-Mail-Programm
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
http://de.wikipedia.org/wiki/SMTPS
http://de.wikipedia.org/wiki/SMTP-Auth
http://forum.df.
eu/forum/showthread.php?t=49183

KDE 4.4, Kontact, Kmail und das Adressbuch

Posted on by

In einem Beitrag am 25.12.2009 hatte ich nach einer ersten Entäuschung geschrieben, dass man den Weg zu KDE 4.4 noch nicht im produktiven Umfeld beschreiten sollte. Inzwischen habe ich diese Zurückhaltung aufgegeben – ich setze KDE 4.4 nun produktiv ein und fühle mich in dieser Desktop-Umgebung in der täglichen Arbeit gut unterstützt.

Entsprechend habe vor kurzem einem Kollegen empfohlen, doch mal KDE 4.4 auszuprobieren. Er fand das auch gut, kam aber nicht mir der Einrichtung von Kontact/Kmail klar. Sein Kontact Adressbuch funktionierte zwar irgendwie, aber er konnte die Adressen nicht unter Kmail nutzen. Das verstehe ich gut, weil ich selber große Schwierigkeiten hatte, die aktuelle Philosophie für Kontacts Adressbuch nachzuvollziehen.

Daher auch an andere Interessierte oder Betroffene zwei Hinweise:

1) Das “Default Adress Book” unter “Kontakte” ist nicht das “Default Adressbook” unter “Kmail” !

Ich habe das aktuelle Vorgehen der KDE-Entwicklung aus einem Forum-Dialog wie folgt verstanden: Offenbar gibt es den Plan, in der Zukunft diverse Ressourcen des KDE-Desktops über einen lokalen Akonadi-Server bereitzustellen. Um sich systematisch an das Thema heranzutasten, wurde Kontacts Adressbuch als erste Applikation auf Akonadi umgestellt. Das, was man als Unbedarfter dann erwartet, ist natürlich, dass das “neue” Akonadi-basierte Adressbuch auch unter Kmail genutzt werden kann.

Nun, da irrt man. Das Akonadi-basierte “Default Adressbook” im Adressbereich von Kontact ist im Moment (!) keineswegs ein Adressbuch, welches von anderen Kontact-Applikationen genutzt werden würde oder könnte – auch wenn unter Kmail in diversen Dialogfenstern ein “Default Adress Book” aufgeführt wird.

Wenn ich das richtig sehe, so ist das Akonadi-basierte Adressbuch zur Zeit das Ergebnis eines ersten Test- und Übungsbeispiels für die KDE-Entwickler – das verwirrende Resultat für den normalen Anwender ist bislang eine “stand alone”-Lösung, die im Kontakte-Bereich von Kontact als (sinnentleerte?) Zugabe herumgeistert. Dieses Adressbuch wird im PIM nicht von anderen Applikationen benutzt !

So ist es auch kein Wunder, dass mein Freund und ich verzweifelt, aber vergeblich Testeinträge im Adressbuch anlegten, um dann herauszufinden, dass diese unter Kmail (z.B. im Rahmen der automatischen Adress-Vervollständigung) nicht angezeigt werden – obwohl sie natürlich in voller Schönheit im Adressbuch-Bereich such-, sicht- und editierbar sind. Da half und hilft kein Rumprobieren an den Einstellungen des Kmail-Editors oder das Verändern der Adressbuch-Reihenfolge – das unter diversen Kmail erwähnte “Default Adress Book” hat halt leider rein gar nix mehr mit dem im Adressbuch-Bereich angelegte “Default Adress Book” zu tun.

Liebe KDE-Truppe, der/die dafür Verantwortliche sollte wissen, dass sich das einem Anwender wahrlich nicht erschließt. Mit einer solchen Idee rechnet man schlicht nicht – ich selbst konnte es nach Jahren KDE-Verwendung auch überhaupt nicht glauben und habe das Ganze erst nach mehrmaligem Lesen eines Dialogs zwischen einem frustrierten Anwender mit einem KDE-Entwickler begriffen. Wenn man die User beim Umstieg auf KDE 4.4 verwirren wollte – dann wurde dieses Ziel in preisverdächtiger Weise erreicht.

Als fehlersuchender KDE-Anwender experimentiert ja man nicht nur mit Kontact-Einstellungen herum – nein, man wirft natürlich auch einen Blick auf den Akonadi-Server und die dort erscheinenden Ressourcen. Dieser Ausflug in eine bislang unerforschte Welt war natürlich hochinteressant – aber er nutzt einem bzgl. des Kmail-Problems nichts. Unter Akonadi erschien bei mir alles fehlerfrei – sprich der Akonadi-Server lief anstandslos und die Adressbuch-Ressource wurde auch angezeigt. Nur unter Kmail ließen sich die Adressen halt nicht verwenden.

Übrigens: Falls man bei der Einrichtung von Akonadi Probleme
haben sollte, hilft vielleicht Folgendes:

a) Virtuoso installieren

b) Bzgl. der Desktop-Suchmaschine Nepomuk folgenden Eintrag in der Datei “~/.kde4/share/config/nepomukserverrc” prüfen:

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend

c) Ggf. “~/.config/akonadi/akonadiserverrc” löschen und den Akonadiserver über die Akonadi-Einrichtung neu starten

2) Lösung: Ignoriere im Moment das Akonadi-basierte Adressbuch und richte ein konventionelles Adressbuch unter Kontakt und ggf. auch unter KDE ein!

Hat man die obige “Philosophie” erst einmal verdaut, ist natürlich der Weg zur Lösung nicht weit. Man muss in Kontacts Adressbuch-Bereich (und ggf. unter den KDE-Ressourcen; s.u. den Hinweis vom 25.06.2010) einfach ein weiteres “Standard”-Adressbuch einrichten.

Zum Einrichtungs-Dialog für ein neues Adressbuch kommt man durch einen Klick mit der rechten Maustaste in den Seitenbereich “Adressbücher” unter “Kontakte”. Im erscheinenden Kontextmenü wählt man dann “Adressbuch hinzufügen”. In der nachfolgenden Auswahl schließlich “KDE-Adressbuch (herkömmlich)”. Es erscheint erneut ein Auswahldialog – hier muss man die für sich richtige Ressource anklicken. In meinem Fall ist das ein Adressbuch eines Open-Xchange-Servers, für das man dann die Verbindungsdaten wie in früheren Kontact-Versionen auch einträgt:

Adresse: http://my-OX-Server
User: my_user_name
Passwort: my_password

Danach Auswahl des OX-Adressbuch-Verzeichnisses – z.B. des globalen Adressbuches unter den OX-Systemordnern. Dieses so angelegte Adressbuch erscheint dann übrigens auch als Akonadi-Ressource – was einem unter Kmail aber leider nichts nutzt. ..

*******Wichtige Ergänzung vom 25.06.2010: *******
In der bei mir aktuellen Version (Kontact 4.4.5 und KMail 1.13.5) aus dem Factory-Repository von SUSE reicht der eben beschriebene Schritt unter “Kontakte” leider nicht (mehr?) aus, um die Ressource auch im KMail-Bereich verfügbar zu machen (z.B. für die automatische Adressvervollständigung). Vielmehr muss man die Adressbuch-Ressource nochmals manuell anlegen – und zwar in den KDE- “Systemeinstellungen” als allgemeine KDE-Ressource:

Entweder im KDE-Menü “Systemeinstellungen” starten oder in einem Terminalfenster “system-settings &” eingeben. Dort den Reiter “Erweitert” betätigen und dann den Eintrag “KDE-Ressourcen” wählen. Mit Hilfe der Auswahl-Combobox die Kategorie “Kontakte” einstellen. Prüfen, ob die gewünschte Adressbuch-Ressource schon als Eintrag vorhanden ist. Wenn – wie bei mir – nicht: “Hinzufügen” anklicken und in den folgenden Dialogen zum Hinzufügen einer Ressource die gleichen Schritte vornehmen, die oben für den “Kontakte”-Bereich von “Kontact” beschrieben wurden.

Im aktuellen Zustand von Kontact führt das Anlegen einer (herkömmlichen) Adressbuch-Ressource unter “Kontakte” offenbar nicht mehr zu den notwendigen KDE-Einträgen für die Ressourcen, die dann von KMail aufgegriffen werden. Was denkt der normale Anwender: Schade eigentlich … und regt sich am besten nicht auf ….
****** Ende Ergänzung 25.06.2010 *******

Hinweis: Für ein lokales Adressbuch sollte die zugehörige Datei übrigens auf

/home/user_xyz/.kde4/share/apps/kabc/std.vcf

verweisen, wenn das vcf-Format gewählt wurde.

Die so angelegten (herkömmlichen) Adressbücher werden schließlich auch unter Kmail erkannt und an den gewohnten Stellen aufgelistet. Der Adressbuch-Inhalt wird auch wie gewohnt in der automatischen Adress-Suche und -Vervollständigung beim Verfassen von Mails herangezogen. Die Reihenfolge, in der die “herkömmlichen” Adressbücher dabei verwendet werden sollen, legt man mit den üblichen Dialogen, z.B.
“Einstellungen – Kmail einrichten – E-Mail-Editor –
Vervollständigungsreihenfolge einstellen ….”,
fest. Alles wie gehabt. Ich kann seitdem wieder normal arbeiten.

Links

Einen Sinn hatte das ganze Theater aber doch: Man fängt an, sich für Akonadi zu interessieren. Als Einstieg hier ein paar Links:

http://de.wikipedia.org/wiki/Akonadi
http://pim.kde.org/akonadi/
http://userbase.kde.org/Akonadi

Schön ist übrigens die Einleitung zur UserBase (mit Hinweisen zur Fehlerbehebung):

“This page is mainly concerned with troubleshooting Akonadi, as there are inevitable glitches in early stages of migration. For many people the first signs of Akonadi activity will be in KDE SC 4.4, and many will be confused by it. ”

Oh, yes !