© Deutsche Post AG

Skalierbarkeit hat sich zu einer Kernfrage für Linux-Mailserver entwickelt. IMAP-Proxies wie Perdition, Imapproxy oder Cyrus Aggregator helfen die E-Mails auf mehrere IMAP-Backends zu verteilen, ohne dabei einen Cluster einrichten zu müssen.

Immer mehr IMAP-Server ächzen unter der Last des wachsenden Mailverkehrs. Die Admins stehen vor einem Problem, denn nur mit gehörigem Aufwand können sie ihre IMAP-Server clustern. Damit für die Postfächer der Benutzer eine gemeinsame Datenbasis vorliegt, sind dann teuere SANs für Shared Storage oder aufwändige Replikationsmechanismen notwendig. Die Kosten für kommerzielle Clustersysteme wie Red Hats Cluster-Suite RHCS treiben manchem IT-Leiter die Schweißperlen auf die Stirn, und muss die IT-Abteilung den alten IMAP-Server in den Cluster migrieren, wird\’s auch technisch richtig interessant.

Linux-Admins, die derartige Systeme selbst und mit freier Software aufbauen wollen, kämpfen in der Regel mit den durchwachsenen HA-Fähigkeiten der verfügbaren IMAP-Server. Während die MTAs (Mail Transfer Agents) gängiger SMTP-Server durch einfaches DNS- oder IP-basiertes Load-Balancing redundant auslegbar sind, steht und fällt ein IMAP-Cluster mit dem Storage-Backend.

IMAP-Cluster: Es geht auch einfacher

Aber es muss nicht immer ein Cluster sein, oft übersehen Admins eine einfache und flexible Möglichkeit: IMAP-Proxies. Derartige Server trennen Nachrichten-Transport und -Zustellung von der Speicherung der Daten. In solchen Setups verbinden sich E-Mail-Clients über IMAP oder POP nicht mit einem Mailserver, sondern nur mit einem Proxy-Server. Der Stellvertreter schaut in seiner Datenbank nach, findet dort den für den User zuständigen IMAP-Server und leitet den Benutzer zu dem Backend weiter, das die Maildaten des Accounts vorhält.

In Proxy-Delivery-Setups, wenn also der Stellvertreter auch die Zustellung übernimmt, leitet Serversoftware wie Cyrus Aggregator [1] auch alle eingehenden Nachrichten über das Local Mail Transfer Protocol (LMTP) an die Backends weiter. Sinnvollerweise übernehmen in großen Netzwerken mehrere MTA-MDA-Server diese Arbeit, der IMAP-Proxy konfiguriert sie anhand der Einstellungen in seiner Datenbank und die Mails landen auf dem zuständigen IMAP-Server.

Frontends für IMAP

Ein IMAP-Proxy ist also ein Frontend für die eigentlichen Mailserver. Wo die Daten des Benutzers gespeichert sind, steht in seiner Datenbank. Dieses Verfahren bringt ungeahnte Flexibilität, denn der Client verbindet sich immer mit demselben Host, auch wenn sein Mailstore mittlerweile ganz woanders gelandet ist, weil der Admin ein neues System mit größeren Festplatten eingebaut hat.

Bereits der Standardumfang des IMAP-Protokolls bietet zahlreiche Funktionen für Weiter- oder Umleitung, aber die Implementierungen der verschiedenen Softwareprojekte verfolgen im Detail eigene Ansätze. Dennoch haben alle zwei grundlegende Gemeinsamkeiten:

• Frontend und Backend müssen zueinander passen und die
  gleichen IMAP-Funktionen beherrschen.
• Der Proxy verwendet eine Datenbank, um die Mappings, also die
  Zuordnung User-Server, zu erhalten. Dieser Zugriff erfolgt lokal
  oder übers Netz.

Das ist so simpel, wie es klingt, daher gibt es mehrere Softwarepakete, die diese Features beherrschen.

Wohl der bekannteste und flexibelste IMAP-Proxy ist Perdition [2]. Die Entwickler von Imapproxy [3] legten dagegen besonderen Wert auf Webmail-Clients. Server-spezifische Pakete wie Cyrus IMAP Aggregator [1] bieten umfangreiche Funktionen, in der Regel aber eben nur für den passenden IMAP-Server. Der Aggregator fällt trotzdem positiv auf, weil er sowohl als Proxy für die Zustellung als auch fürs Abholen von Mails fungieren kann, er ist eben auch ein Mail-Delivery-Proxy.

Der Allrounder: Perdition

Perdition dient zwar nur als Stellvertreter für das Abholen von Mails, erweist sich aber trotzdem als Allrounder. Er unterstützt als Standards IMAP4 und POP3, auf Wunsch auch über SSL- oder TLS-Verbindungen. Dabei ist es möglich, die Clientverbindungen zu verschlüsseln, während er die lokalen IMAP-Server im hoffentlich sicheren LAN schneller und unverschlüsselt anspricht.

Perdition versteht im Wesentlichen nur die für die Authentifizierung notwendigen IMAP-Kommandos und schleift ansonsten nur Daten durch. Deshalb kann er die Backend-Server auch nicht im Stil einer Application-Level-Firewall schützen. Für tiefer Interessierte enthält das “Perdition Paper” von Simon Horman [4] alle Details über Features und Arbeitsweise. Auch wenn das Dokument bereits einige Jahre auf dem Buckel hat, gilt es immer noch als die Referenzdokumentation für Perdition.

Dieser IMAP-Proxy führt eine Datenbankabfrage durch und erhält als Antwort den richtigen Server für den Client, der sich gerade verbindet. Ein bemerkenswertes Feature ist die Unterstützung für mehrere, verschiedene Datenquellen. Perdition spricht LDAP-, ODBC-, MySQL- und PostgreSQL-Backends an, bei Bedarf auch gemischt, eigene Module sind ebenfalls möglich. Damit stehen dem Entwickler beliebige Datenquellen für die Mappings zwischen User und IMAP-Backend-Server zur Verfügung.

Perdition ist einfach und kann trotzdem viel, das macht das Programm zu einem handlichen Tool. Im einfachsten Fall arbeit es lediglich als Frontend vor einem Team von Backend-Servern, wobei die zuständigen Admins Vorgaben definieren, wie die Last verteilt sein soll.

Ideal für Migration

Ein anderes, besonders interessantes Setup ermöglicht beliebige IMAP-konforme Server als Backends für Perdition. Gerade in Migrationsszenarien hat sich dieses Setup bewährt, wenn ein neues Rechnerteam den altehrwürdigen Mailserver ablöst. An der Universität Huntington in Virginia konnten die Admins so 30000 Postfächer ohne Downtime von OpenVMS auf Linux-Systeme mit Cyrus IMAP migrieren [5]. Einzige Voraussetzung dafür ist, dass alle beteiligten Systeme IMAP sprechen. Die strategischen Vorteile dieser Lösung sind groß:

• Mailclients bekommen nichts von den unterschiedlichen Backends
  mit. Auf den Arbeitsplatzrechnern ist keine Interaktion
  nötig.
• Alle IMAP-Clients verbinden sich über einen identischen
  Hostnamen mit ihrem Server, egal ob die Mails noch auf einem alten
  oder schon dem neuen System liegen.
• Beim Umzug von Accounts brauchen die Admins nach der
  Übertragung des Message-Store nur die Mapping-Einträge in
  der Perdition-Datenbank anzupassen, fertig.

Installation

Auch die Installation von Perdition gestaltet sich sehr einfach. Linux-Benutzer haben die Wahl: entweder den Sourcecode runterladen und kompilieren oder die binären RPM-Pakete verwenden. Wer noch erweitertes Logging einrichten möchte, installiert den Vanessa Logger [6] hinzu. Listing 1 zeigt die Konfiguration von Perdition für eine Lookup Table in einer MySQL-Datenbank. In diesem Beispiel befindet sich die Datenbank auf dem lokalen Rechner, Listing 2 zeigt ihren Inhalt.

01 connection_logging
03 connection_limit 1000
03 map_library /usr/lib/libperditiondb_mysql.so.0
04 map_library_opt "localhost:3306:dbPerdition:tblPerdition:perdition:x:username:servername:port"
05 username_from_database

01 mysql> select * from dbPerdition.tblPerdition;
02 +------+---------------------------+------+
03 | user | servername                | port |
04 +------+---------------------------+------+
05 |name1 | imap01.company.com        | 143  |
06 +------+---------------------------+------+
07 |name2 | imap02.company.com        | 143  |
08 +------+---------------------------+------+
09 ...

Während einer Migration können automatisierte Skripte die Mailboxen von einem Server auf den neuen kopieren und die Einträge in der Datenbank aktualisieren. Der Perdition-Proxy leitet die migrierten User automatisch auf den neuen Backend-Server weiter, während die noch nicht umgestellten Benutzer weiter auf dem alten IMAP-Server arbeiten. Auf den Clients sind keine Änderungen nötig, alle Benutzer können unterbrechungsfrei E-Mail nutzen.

Der Spezialist: Imapproxy

Das Einsatzgebiet von Imapproxy ist im Vergleich zum Generalisten Perdition eher beschränkt. Seine Domäne ist es, die Performance von Webmail-Servern zu beschleunigen, indem er die Verbindungsdaten zu POP/IMAP-Servern zwischenspeichert.

Als IMAP-Cache verringert er die Anzahl an Verbindungen, die ein Webmailer benötigt. Normalerweise verursacht jede Aktion in diesen Interfaces eine Lese- und/oder eine Schreib-Operation auf dem IMAP-Server samt Austausch zahlreicher Datenpakete. Imapproxys Cache kann viele Anfragen direkt beantworten und beschleunigt so den Webmailer.

Damit erweist sich allerdings der Name der Software als etwas irreführend, denn im Gegensatz zu Perdition handelt es sich hier eher um ein Optimierungstool als um einen echten Proxy. Imapproxy bietet sich aber überall dort an, wo Benutzer vom Browser aus auf den IMAP-Server zugreifen, und lässt sich problemlos mit einem Perdition-Proxy kombinieren, wie Abbildung 1 zeigt.

Abbildung 1: Während Perdition ein echter Proxy-Allrounder für IMAP und POP ist, hilft Imapproxy im Wesentlichen nur Webmailern auf die Sprünge, indem es IMAP-Verbindungen lokal cacht.

Mächtig mit Cyrus-Backends

Der dritte im Bunde hört auf den Namen Cyrus IMAP Aggregator Proxy (kurz Cyrus IMAP Proxy) und ist wohl der robusteste seiner Art. Er unterstützt sowohl Mail-Retrieval (POP/IMAP) als auch -Delivery (LMTP), liegt aber nur in einer Implementierung für den Cyrus-Server vor. Cyrus IMAP ist neben UW, Courier und Dovecot einer der großen vier IMAP-Server und stellt wohl die umfangreichste Funktionalität bereit [7].

Aber bei diesem Server läuft einiges etwas anders. So legt er im Gegensatz zu den klassischen Mailbox- oder Maildir-Dateien E-Mails in einem eigenen Format auf dem Server ab und geht auch beim Multiserver-Setup eigene Wege. Mit dem Cyrus Murder Aggregator sollen High-Performance- und Load-Balancing-Clustering möglich sein, indem Frontend-Server mit Storage-Backends kommunizieren. Für Bastler gibt es mit paarweiser Replikation [8] und Shared Storage über Cluster-Filesystemen wie GFS genug Möglichkeiten, sich auszutoben. Doch braucht\’s dafür Zeit, Ehrgeiz oder Geld, denn Red Hats Dateisystem ist nicht umsonst zu haben.

Das erklärt auch, warum sich der Aggregator so erfolgreich als IMAP-Proxy für den beliebten Cyrus-Mailserver schlägt. In diesem Szenario teilen sich mehrere Backends die Arbeit, das Frontend verteilt die Anfragen. Die Informationen, welcher Benutzer auf welchem Server zu Hause ist, liegen auf einer eigenen Maschine, dem so genannten Mupdate-Server. Dieser Server funktioniert als eine Art Master-Node und händigt dem Frontend über das Mupdate-Protokoll [8] die für STMP, IMAP oder POP relevanten Daten aus.

Der Aggregator als Mail-Delivery-Proxy

Abgesehen von der Zustellung der Mails funktioniert Cyrus Aggregator ähnlich wie Perdition, wobei allerdings ein eigener Serverdienst und ein angepasstes Protokoll zum Einsatz kommen. Der besondere Nutzen des Aggregator liegt aber in der Tatsache, dass er eben auch SMTP und LMTP unterstützt und so im Verbund mit Cyrus (und leider nur mit diesem) ein komplettes Mailproxy-System abbildet.

Abbildung 2 zeigt schematisch den Ablauf beim Eingang einer E-Mail. Das Mail-Gateway liefert die Nachricht an den SMTP-Server aus. Dieser, hier Postfix, reiht die Mail in seine LMTP-Warteschlange ein und übergibt die Nachricht schließlich per LMTP an den Frontend-Server. Hier erfolgen die Abfrage der Mailbox-Location vom Master-Node und die anschließende Zustellung auf das passende Backend (Final Delivery).

Abbildung 2: Der Cyrus IMAP Aggregator kann im Gegensatz zu Perdition auch Delivery-Proxy sein, allerdings nur für den Cyrus-Mailserver. Eingehende Mails lösen einen Lookup im Verzeichnis des Master-Node aus, erst mit diesen Informationen kann der LMTP-Dienst die Mail an das richtige Backend zustellen.

Fazit

IMAP-Proxies bringen mit wenig Aufwand ähnliche Funktionen in eine bestehende Umgebung, wie dies sonst nur teuere Cluster-Szenarien bieten. Alle vorgestellten Programme, wenn sie sich auch nicht für alle Setups eignen, erleichtern dem Admin die Bewältigung der Mail-Flut. Wer eine Servermigration plant und auf Kompatibilität setzt, ist bei Perdition richtig. Imapproxy erfüllt seinen Job als Cache für Webmailer gut, ist aber keine Konkurrenz zu Perdition, sondern eher eine sinnvolle Ergänzung. Der Cyrus Aggregator kann sogar die Zustellung von E-Mails auf mehrere Backend-Server verteilen. (mfe)