3.4.2010 von rmo.

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

Geschrieben in Kontact - Kmail, Verschlüsselung (Mail, SSH), Erfahrungsberichte, Postfix, Cyrus, Kmail | Keine Kommentare »

19.3.2010 von rmo.

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 !

Geschrieben in KDE, Kontact - Kmail, Erfahrungsberichte, Postfix, Cyrus, Kmail | Keine Kommentare »

29.1.2009 von rmo.

Einige unserer Bekannten, die unsere Mail-Konfiguration unter Linux gesehen haben, spielen jetzt mit dem Gedanken, in Ihrem Netz einen eigenen kleinen IMAP-Server zu installieren, um die Mail-Verwaltung und vor allem die Mailsicherung zu zentralisieren. Besonders Mutige möchten dabei sogar einen Open-Xchange-Server einsetzen. Als Client ist KDEs Kmail geplant (unter dem kommenden KDE 4.2).

Ein solches Vorhaben ist grundsätzlich lobenswert: Schon in einer dreiköpfigen Familie kann sich der Linux-Freund viel Zeit und Ärger ersparen, wenn er mit einem Server arbeitet.

Er sei aber gewarnt: Eine Mail-Server-Konfiguration ist nicht gerade eine einfache Übung. Die anfängliche Zeit- und Aufwands-Investition in ein solches Unterfangen ist erheblich. Als ich damit anfing, versuchte ich erst einmal, 2 Bücher zu dem Thema wenigstens ansatzweise zu verstehen, bevor ich praktisch loslegte. Es gibt einfach wahnsinnig viele Dinge, die man vorab wissen und richtig einordnen sollte.

Wir können in diesem Beitrag nur ganz kurz auf den Server eingehen - es geht uns mehr um die Anbindung von KDEs Kmail an den laufenden Server. Dennoch wollen wir wenigstens skizzieren, wie die Gesamtkonfiguration für ein kleines Netzwerk aussehen kann.

Mögliche Serverkonfiguration und Mailtransfer

Wir beschreiben der Einfachheit halber eine “isolierte” Server-Konstellation für ein kleines privates Netz oder das Netz einer kleinen Firma. Der Mailserver beinhaltet dabei folgende Komponenten:

• Fetchmail [zum Abholen von Mails aus Postboxen bei Mail-Providern im Internet]
• Postfix ( Mail Transfer Agent) [Fetchmail leitet Mails in die SMTP-Eingangsqueue von Postfix. Nach einer Aufbearbeitung gibt Postfix die Mails an einen IMAP-Server weiter. Postfix transferiert zudem ausgehende Mails über seine SMTP-Queues an einen SMTP-Relay-Server beim Provider weiter].
• Cyrus IMAP [Der IMAP-Server organisiert und verwaltet Mails, die ihm Postfix zuliefert in strukturierten Mailboxen (besser Mail-Directories). Auf diese Mailboxen greifen dann Linux-Clients im LAN mit Hilfe von Kmail als MUA (Mail User Agent) zu].
• Groupware-Komponenten von Open-Xchange [Kalender, Task-Folder etc., auf die mit KDE Kontact/Korganizer zugegriffen werden soll. Die Open-Xchange-Accounts sind dabei aber engstens mit den lokalen Mail-Accounts verbunden.]
• Ggf. eine lokale Firewall (z.B. auf Basis von IPtables)

Private Domaine im LAN vs. registrierte Domaine im Internet

Die Komponenten Postfix und Cyrus sind dabei nur zuständig für die lokale private Domaine des Firmen-LANs und die zugehörigen Mail-Accounts. Der Mail-Server hängt nicht direkt am Internet und darf nur von internen Clients zur Weiterleitung von Mails an einen SMTP-Server im Internet benutzt werden. Der lokale Mailserver liegt also möglicherweise hinter einer Firewall, die von außen keinen SMTP-Verkehr ins LAN hinein zulässt.

Der Mailverkehr im Internet läuft dagegen über Mailboxen und SMTP-Server bei einem Service-Provider ab: Der lokale Mailserver des LANs kommuniziert über Fetchmail bzw. SMTP mit den POP/IMAP- bzw. SMTP-Server des Providers, wenn Mails geholt bzw. Mails versendet werden.

Weitere Merkmale und Eigenschaften der Konfiguration sind:

1. Der MTA Postfix ist nur der “privaten” internen Domaine des lokalen Netzwerkes zugeordnet. Er ist als Endstation eines Mailtransfers ausschließlich für Mail-Accounts (Postboxen) von Usern dieser Domaine zuständig. Diese “Domaine” hat keine Entsprechung zu realen, registrierten Domainen im Internet. Sie ist nur einem lokalen DNS-Server im LAN, nicht aber offiziellen DNS-Servern im Internet bekannt.
2. Die Postboxen der lokalen Domaine sind die des IMAP-Servers. Sie können aus dem Internet nicht direkt beliefert werden. “Reale” Mailaccounts, die aus dem Internet beliefert werden können, befinden sich nur beim Mail-Service-Provider. Auch der Postversand ins Internet erfolgt über einen SMTP-Server beim Provider: der dortige SMTP-Server wird also als Zwischenstation - als sog. “Relay-Server” - verwendet.
3. Der “Cyrus” IMAP-Server ist dem Postfix-System nachgelagert. Postfix interagiert mit dem IMAP-Server über das Protokoll LMTP. Mail-Clients (MUAs) wie Kmail unterhalten sich mit dem IMAP-Server dagegen über das IMAP-Protokoll.
4. Postfix empfängt Mails über ein vorgeschaltetes Fetchmail-Modul, dass periodisch E-Mails aus den Postfächern bei Providern abholt (i.d.R. über POP3). Die Einspeisung in Postfix erfolgt lokal über SMTP. Postfix übermittelt dem Cyrus IMAP Server dann die eingegangenen Mails über LMTP weiter.

   Das skizziert allerdings nur die Grundstruktur der Behandlung eingehender Mails auf dem Server. Die Einbindung von Viren- und Spamscannern in die Postfix-Verarbeitungsmechanismen erfordert natürlich zusätzliche Maßnahmen. Wir setzen in diesem Zshg. z.B. auch “procmail” für Filteraufgaben ein. Auf Details können wir an dieser Stelle leider nicht eingehen.

5. Der Mailversand der Clients erfolgt über das SMTP-Protokoll zunächst an Postfix; Postfix leitet die Mails dann an den SMTP-Server des Providers (Relay-Server) weiter. Erst von dort werden die Mails in Richtung auf den Empfänger im Internet weitergeleitet. Auf dem Relay-Server muss Postfix sich i.d.R. authentifizieren. Hierzu müssen ensprechende Authentifizierungs- und Verschlüsselungsverfahren von Postfix unterstützt werden.

   Die Postfix-Konfigurationsdatei “main.cf” muss den passenden Relay-Server-Eintrag enthalten. Je nach Auth-Mechanismus beim Service-Provider müssen zudem passende sasl-Libs vorhanden sein. Ein Auszug aus der “/etc/postfix/main.cf” zeigt das Wesentliche:

   relayhost = smtp.strato.de
   smtp_sasl_auth_enable = yes
   smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
   smtp_always_send_ehlo = yes
   smtp_sasl_security_options = noanonymous

   Die Zugangsdaten sind in der Datei sasl_passwd zu hinterlegen und über das “postmap”-Komando zu aktivieren.

6. Die “realen” Mailadressen beim Provider (für eine im Internet registrierte eigene oder fremde Domaine) müssen auf die internen Accounts des IMAP-Servers in der “privaten” Domaine abgebildet werden. Auf dem Weg von der Mailbox beim Serviceprovider zum eigenen Postfix- und dem IMAP-Server erfolgt die Adress-Umsetzung dagegen durch Fetchmail, das entsprechend konfiguriert sein muss (Datei /etc/fetchmailc). Auf dem Weg nach außen erledigt dies dagegen Postfix über entsprechend konfigurierte “canonical maps” (Datei “/etc/postfix/sender_canonical” und Befehl “postmap”!).

Konfiguration und Anbindung von Kmail

Die Anbindung von Kmail an einen IMAP-Server (z.B auf einem Open-Xchange-Server) im eigenen LAN ist im Grunde simpel. Eine Sache gibt es es bei der Einrichtung aber doch zu beachten - die Festlegung der sog. Identität. Diese muss zu den eingerichteten Accounts des Open-Xchange [OX]-Systems passen - sonst lassen sich später (private) Kalender-Folder und Task-Folder wegen fehlender Rechte nicht sauber in Kontact/KOrganizer einbinden. Schwierigkeiten kann es dann auch bzgl. der Organisator-Rolle bei der Anlage von Gruppenterminen geben.

Folgende Punkte sind bei einer Anbindung von Kmail anzupassen:

Festlegung der sog. Kontact/Kmail - “Identität”

Die Konfiguration erfolgt über den Menüpunkt “Einstellungen -> Kmail einrichten”. Im sich öffnenden Fenster legt man die zu verwendende Identität unter der Rubrik “Identitäten” fest. (Die Möglichkeit, mehrere Identitäten anzulegen, blenden wir nachfolgend aus.)

Hinweis für OX-Clients:
Bei der Identitätsdefinition ist es wichtig, unter dem Reiter “Allgemein” bei der Email-Adresse exakt die Adresse anzugeben, die auch auf dem OX-Server verwendet wird und nicht diejenige Adresse, die im externen Mailverkehr als Antwortadresse verwendet wird. Der Grund hierfür liegt im OX-Rechtesystem. Will man später seine Kalenderordner an Kontakt anbinden, so werden die Rechte an den zugehörigen privaten Kalender-Ordnern des OX-Systems anhand des Mail-Accounts überprüft. Ferner wird die Mailadresse auch benutzt, wenn man als Organisator von Gruppenterminen im Kalender auftritt. Die Festlegung der Identität hat also Auswirkungen bei der Termin- und Aufgabenplanung im Team (Kontact - Kalender-Modul).

Um die Unterschiede zwischen den Mailangaben für die interne Identität und den Eigenschaften einer externen Mailidentität im Internet beim Mailverkehr nach aussen zu kompensieren, müssen entsprechende Einträge in der Postfix-Konfigurations-Datei “sender_canonical” vorgenommen werden (nicht vergessen “postmap” auszuführen, um die Umsetzungsregeln auch in die interne Postfixdatenbank zu übernehmen und damit wirksam zu machen). Postfix ersetzt dann in allen ausgehenden Mails automatisch interne Adress- und Domainangaben in passende Angaben realer Mailaccounts, die im Internet verwendbar und überprüfbar sind.

Unter dem Reiter “Kryptografie” pflegt man ggf. seine PGP-/S-Mime-Schlüssel für Signaturen und verschlüsselte Mails ein. OpenPGP sowie KGpg sollten dafür installiert und gepflegt sein. Die Warnung, dass die Signatur für eine andere Emailadresse (nämlich die reale im Internet) ausgestellt wurde, kann man bei korrekten Umsetzungsregeln in Postfix - für externe wie interne Empfänger - ignorieren.

Der Reiter “Erweitert” erlaubt später die Einrichtung der Ordner für versendete Dateien, Entwürfe und Vorlagen zur angelegten “Identität”. Damit man dabei auch Ordner des IMAP-Servers auswählen kann, muss die Anbindung an den Server erst einmal stehen. Man holt diese Ordner-Konfiguration einfach später nach. Unter diesem Reiter legt man übrigens auch die “Antwort”-Mail-Adresse (”Reply to” - Adresse) für seine Mails fest.

Unter dem Reiter “Signatur” pflegt man seine Signatur-Angaben ein - also den Abspann für Mails. Ob dieser Abspann bei zitierten Mails vor oder nach dem Zitat-Bereich eingefügt werden soll, legt man übrigens unter “Einstellungen - Kmail einrichten - E-Mail-Editor - Reiter Allgemein” fest.

Festlegung des IMAP-Zugangs

Die Einstellungen für den Zugang zu einer Mailbox des IMAP-Servers (samt der untergeordneten Mail-Directory-Struktur) nimmt man unter dem Menüpunkt “Einstellungen - Kmail einrichten - Zugänge” vor. Danach geht man zum Reiter “Empfang”. Hier muss man sich grundsätzlich entscheiden, ob man einen replizierenden, sog. “disconnected Imap” - Zugang oder einen gewöhnlichen IMAP-Zugang anlegen will.

Hierzu folgender Hinweis: Ich habe bei früheren KDE 3.5-Versionen immer einen “disconnected IMAP” Zugang angelegt, obwohl die Replizierung der Mails bei mir enorm viel lokalen Speicherplatz auf der Platte verbrauchte (2 GB). Das verursachte auch länglich Abgleichzeiten mit intensivem Plattenzugriff. Diese Nachteile habe ich in Kauf genommen, um etliche Kmail-Fehler bei der Anwendung von lokalen Filterbefehlen (z.B. für eine Virusanalyse) über mehrere 100 Mails hinweg zu umschiffen. Das sukzessive und automatische Abarbeiten vieler mails hat mit normalen IMAP-Zugängen nie so richtig ohne Fehler und Abbrüche bis Abstürze funktioniert. Sehr wohl ging das aber fehlerfrei mit den replizierten (lokalen) Mails der disconnected-IMAP-Variante.

Unter KDE 4.2 habe ich bisher allerdings keine Probleme feststellen können. Daher verwende ich hier inzwischen einen normalen IMAP-Zugang.

Nach der Festlegung der IMAP-Zugangs-Art wählt man “Hinzufügen” und arbeitet dann der Reihe nach die Reiter für den neuen Zugang ab.
Die Zugangsdaten (IMAP-Account-Id und zugehöriges Passwort; diese Daten muss man natürlich kennen) zur eigenen Mailbox auf dem IMAP-Server werden unter dem Reiter “Allgemein” eingegeben. Kreuzt man dabei “IMAP-Passwort merken” an, so wird das Passwort nach Rückfrage in Kwallet hinterlegt.

Unter dem Reiter “Erweitert” bekommt man neben den typischen Einstell-Möglichkeiten für abonnierte und versteckten Ordner auch die Möglichkeit, die für diesen Zugang zu verwendende Identität festzulegen. In der Regel hat man nur eine, nämlich die, die man schon weiter oben angelegt hat. Festgelegt wird hier auch der Ordner für den Mülleimer.

Bei der Pfad-Angabe “Persönlich” trägt man das Inbox-verzeichnis auf dem IMAP-Server ein (meist “INBOX/”). Bei Namensräumen i.d.R.: “user/”
- das ist der Pfad unter /var/spool/imap, der zu den Verzeichnissen der einzelenen IMAP-Accounts (IMAP-User) führt. Den Punkt “Freigegeben” läßt man <Leer>.

Unter dem Reiter “Sicherheit” kann man Sicherheitsfeatures des IMAP-Servers testen. Ich habe auf unserem OX unter anderem TLS eingerichtet. Im internen Netzwerk benötige ich die verschlüsselte Übertragung zu meinem Arbeitsplatz aber zumeist nicht. Dies mag in anderen Firmen anders sein.

Sieve-Filtering kann man unter dem letzten Reiter angeben, wenn man den IMAP-Server entsprechend eingerichtet hat. (Die OX-Oberfläche hilft beim Festlegen von Sieve-Einstellungen).

Alle IMAP-Zugangs-Einstellungen sind einfach zu überblicken. Hat man alles richtig gemacht, so kann man nun bereits sein Postfach auf dem IMAP-Server sehen. (Wurde ein “disconnected Imap”-Zugang angelegt, so muss man im nächsten Schritt die erstmalige Replikation aller (abonnierten Ordner) vornehmen. Menü “Datei - nach Email sehen “; dann den IMAP-Zugang wählen, den man zuvor konfiguriert hat.)

Hinweis: Das Menü “Datei” enthält einen Punkt “Alte Nachrichten aus allen Ordnern löschen”. Nicht benutzen! Und bitte auch für keinen Ordner Verfallszeiten für Mails einrichten. Das Löschen geht so schnell - und wehe, man hat dann keine regelmäßige IMAP-Sicherung ! Ich würde es gerne sehen, dass dieser Befehl aus dem regulären Satz an Menü-Befehlen verschwindet.

Festlegung des SMTP-Versands

Die Einstellungen für den Mailversand per SMTP nimmt man unter dem Menüpunkt “Einstellungen - Kmail einrichten - Zugänge” vor. Danach geht man zum Reiter “Versand”. Auch dort sind die Einstellungen einfach vorzunehmen. Wieder kann man TLS oder SSL für eine verschlüsselte Übertragung der Mails zum Server einrichten. Der Reiter “Erweitert” erlaubt die Eingabe von Authentifizierungsdaten und die Wahl des Authentifizierungsverfahrens (SMTP-AUTH Mechanismus). Wir setzen CRAM-MD5 ein. Der OX Server mit Postfix muss natürlich bzgl. der SMTP-Auth Mechanismen entsprechend eingerichtet sein. Postfix bedient sich diesbzgl. der (Cyrus) SASL-Mechanismen. Wir benutzen bei uns als Authentification Backends sowohl “saslauthd” als auch “auxprop” plugins (mit sasldb(2)). Die Fähigkeiten des Servers kann man vor der Festlegung des Auth-Mechanismus testen.

Festlegung von Verzeichnissen

Unter Kmail werden die Einstellungen für bestimmte Verzeichnisse an folgenden Orten festgelegt:

• Ordner für versendete Nachrichten : Einstellung unter Menü “Einstellungen - Kmail einrichten”, dann “Identitäten”, dort Reiter “Erweitert”
• Ordner für Entwürfe : Einstellung unter Menü “Einstellungen - Kmail einrichten”, dann “Identitäten”, dort Reiter “Erweitert”
• Ordner für Vorlagen : Einstellung unter Menü “Einstellungen - Kmail einrichten”, dann “Identitäten”, dort Reiter “Erweitert”
• Mülleimer für gelöschte Mails: Einstellung unter Menü “Einstellungen - Kmail einrichten”, dann “Zugänge - Reiter Empfang”, dann IMAP-Konto wählen - Reiter “Erweitert”
• Ordner, der beim Start von Kmail geöffnet werden soll: Menü “Einstellungen - Kmail einrichten”, dann “Diverses”

In allen Fällen können dort auch Verzeichnisse im Directory-Baum des IMAP_Servers angegeben oder ausgewählt werden, sobald der Zugang zum IMAP-Server etabliert wurde.

Hinweis:
Natürlich kann man neben dem IMAP-Zugang zum eigenen IMAP-Server auch weitere POP- und IMAP-Zugänge zu externen Servern im Internet einrichten. Für ganz besondere Konstellationen ist es dann im Menü “Einstellungen - Kmail einrichten - Identitäten - Reiter Erweitert” möglich, für jeden IMAP-Zugang einen eigenen SMTP-Versandweg einrichten, wenn dies erforderlich sein sollte.

Mehr ist für ein funktionierendes Zusammenspiel auf der Kmail Seite nicht zu tun. Dem Text kann man aber schon entnehmen, dass die eigentlichen Schwierigkeiten bei der Einrichtung eines funktionierenden Mailsystems im lokalen netzwerk eher auf der Seite des Servers - also bei der Postfix und Cyrus-Konfiguration liegen.

Wir werden uns einigen Details der Mailserver-Konfiguration vielleicht in späteren Beiträgen widmen.

Geschrieben in Open-Xchange 5, Kontact - Kmail, Postfix, Cyrus, Kmail, Open-Xchange | Keine Kommentare »