Roundcubemail installieren (auf Centos/RHEL 5.2)

Obwohl der Installer von Roundcubemail die PHP-Version 5.2 zwingend voraussetzt (CentOS hat nur Version 5.1.6), lässt sich die Software ohne Probleme installieren.

Man muß nur die Version-Überprüfung an geeigneter Stelle in installer/check.php auskommentieren.

Roundcubemail 0.3.1 scheint auch mit PHP 5.1.6 problemlos zu laufen. Zumindest konnte ich keine Probleme feststellen, auch in roundcubemail/logs/errors, /var/log/httpd/error_log bzw. /var/log/httpd/ssl_error_log konnte ich soweit keine relevanten PHP-Fehlermeldungen entdecken.

User-Managment

Das übliche Anwendungsszenario für Roundcube dürfte darin liegen für eine Organisation (eine oder mehrere definierte Maildomains) Webmail für den externen Zugriff zur Verfügung zu stellen. In dem Fall wird man in in der Datei main.inc.php bei ‘default_host’ eine Reihe von eigenen Domains eintragen und die Option ‘auto_create_user’ auf true stellen.

Hintergrund: Roundcube speichert persistente Daten (IMAP-Caching, Adressbuch, Identitäten für verschiedene Absendeadressen) zu jedem User-Account in seiner Datenbank. Ein User-Account besteht dabei aus der Kombination Username-Servername. Loggt man sich auf verschiedenen IMAP-Servern ein, so sind auch für Roundcube verschiedene User-Konten anzulegen. Steht ‘auto_create_user’ true, dann wird für jeder erfolgreicher Erst-Anmeldung an dem IMAP-Server automatisch ein neuer Roundcube-Account angelegt. Deshalb sollte man das nur in Verbindung mit einer definierten Liste von Servern unter eigener Kontrolle einsetzen.

Es gibt aber noch ein anderes Anwendungs-Szenario: Roundcubemail als universellen IMAP-Client für beliebige IMAP-Server, auch für solche, deren User-Verwaltung man nicht unter eigener Kontrolle hat (z.B. gmx, web.de). Roundcubes User-Managment-Konzept gibt sowas eigentlich nicht her – im Grunde hat es ja auch kein eigenes User-Managment. Was man sich in dem Fall wünschen würde, wäre eine Möglichkeit einen Roundcube-User anzulegen und in diesem Kontext auf mehrere IMAP-Accounts zuzugreifen. Die Idee ist nicht neu, wird aber z.Z. von Roundcubemail nicht unterstützt.

Standardmäßig bietet die Software drei Eingabefelder an: User, Passwort und Servername. Die Auswahlmöglichkeiten im Bereich Servername kann man noch einschränken mit der Option ‘default_host’. Will man alle seine Mail-Accounts/Domänen nicht gerade der Weltöffentlichkeit zeigen, sollte man hier aber nichts eintragen.

Wie gesagt sollte für das zweite Szenario ‘auto_create_user’ auf jeden Fall auf false stehen. Interessanterweise meldet sich roundcubemail auch an dem IMAP-Server
an, wenn ‘auto_create_user’ auf false steht und in der lokalen
roundcube-Userdatenbank noch gar kein Eintrag für diesen Server besteht. Das bedeutet, daß jeder mit Zugriff auf den Webserver zunächst (IMAP-)Connections zu beliebigen Servern aufbauen kann. Hoffentlich hat das keine anderen Implikationen. Vielleicht ist es doch besser die Roundcube-Installation hinter einer Basic-Authentication zu verbergen…

Bevor man sich also bei einem neuen – dem Programm unbekannten – Server einloggt, muß man manuell die Option ‘auto_create_user’auf false stellen, dann sich einloggen, die Option wieder zurücksetzen und zur Sicherheit in der Datenbank in der users-Tabelle nachschauen, ob das der Zwischenzeit niemand ausgenutzt hat. Nicht wirklich komfortabel.

Sicherheit

Zunächst hilft es, dem Webserver SSL beizubringen und die Option  ‘force_https’ einzuschalten. Auf entfernte IMAP-Server sollte man sich natürlich grundsätzlich mit SSL anmelden, dazu genügt es, dem Hostnamen ein "ssl://" voranzustellen. Unglücklicherweise verwendet der Webmailer die PHP-Funktion fsockopen zum Aufbauen von Netzwerkverbindungen. Genau diese Funktion prüft aber nicht die Zertifikate. Ein MITM-Angriff bleibt so unentdeckt. Von daher kein Ersatz zu einem ausgewachsenen IMAP-Client wie Thunderbird, das einen bei "gefälschten" Zertifikaten warnt.

Will man zumindest verhindern, daß auf diesem Weg IMAP-Passwörter ausgehorcht werden können (der Email-Inhalt wurde zuvor ohnehin unverschlüsselt übertragen), sollte man – soweit es der Server ermöglicht – CRAM-MD5 mit der Option ‘imap_auth_type’=’auth’ benutzen. An dieser Stelle macht Roundcube allerdings einen kapitalen Fehler und benutzt als Fallback "PLAIN".

Der Code von Version 0.3.1 enthält noch einen weiteren Fehler, der verhindert, daß die Option ‘imap_auth_type’ überhaupt korrekt ausgelesen wird und dazu führt, daß immer unverschlüsselt übertragen wird. Der Fix ist aber einfach:

--- /root/download/roundcubemail-0.3.1/program/lib/imap.inc	2009-10-05 11:26:33.000000000 +0200
+++ program/lib/imap.inc	2010-01-23 11:45:15.000000000 +0100
@@ -554,7 +554,7 @@
 	// set some imap options
 	if (is_array($options)) {
 		foreach($options as $optkey => $optval) {
-			if ($optkey == 'imap') {
+			if ($optkey == 'auth_method') {
 				$auth_method = strtoupper($optval);
 			} else if ($optkey == 'rootdir') {
     				$my_prefs['rootdir'] = $optval;
@@ -694,7 +694,7 @@
 			$conn->message .= "AUTH CRAM-MD5: $result\n";
 		} else {
 			$conn->message .= "AUTH CRAM-MD5: failed\n";
-			$auth_method = 'PLAIN';
+			return false;
 		}
 	}

Beide Fehler (Ticket #1486371 und #1486263) sind im Subversion-Trunk schon gefixt.

Leider bieten beispielsweise gmx und web.de keine verschlüsselte Passwort-Übertragung an. Man könnte nun auf die Idee kommen für diese Hosts die CRAM-MD5-Methode gezielt auszuschalten mit einer Host-spezifischen Konfiguration ‘include_host_config’. Allerdings sind hier nicht die IMAP-Hosts gemeint, sondern vielmehr die Domains des Webservers.