Roundcube Managesieve Plugin

Gestern stellte ich fest das Managesieve in Roundcube nicht mehr funktioniert, keine Ahnung seit wann dem so ist

Seit vielen Jahren habe ich einen eigenen Mailserver am laufen, zuerst hatte ich einen V-Server bei Hetzner, 2015 bin ich dann auf einen zu Hause selbst gehosteten Server gewechselt, bei dem ich alle aufgaben in Virtuelle Maschinen aufgeteilt habe

Meine Systeme sind hierbei immer eine minimale Ubuntu LTS Installation (Ubuntu Server) ohne grafische Oberfläche und mit dem Befehl

do-release-upgrade

kann man wunderbar das System aktualisieren, das klappte bei mir eigtl. immer ohne Probleme nur hat sich beim letzten mal wohl was an den Settings vom Managesieve Plugin geändert und das herauszufinden hat wirklich ewig gedauert daher lasse ich euch an meinen Erkenntnissen teilhaben

Eine typische Konfiguration unter /etc/roundcube/plugins/managesieve/config.inc.php sieht so aus

<?php
$config=array();

$config['managesieve_port'] = 4190;

$config['managesieve_default_host'] = 'meinmailserver';

$config['managesieve_auth_type'] = PLAIN;

$config['managesieve_auth_cid'] = null;

$config['managesieve_auth_pw'] = null;

$config['managesieve_usetls'] = true;
?>

Das meiste davon ist mittlerweile super egal so sieht das heute aus

<?php
$config=array();

$config['managesieve_host'] = 'tls://meinmailserver:4190';

$config['managesieve_auth_type'] = PLAIN;

$config['managesieve_auth_cid'] = null;

$config['managesieve_auth_pw'] = null;
?>

Zunächst es steht praktisch überall das $config['managesieve_usetls'] ist vollkommen unnötig es steht zwar im Internet überall wenn irgendwas nicht geht das das super wichtig ist aber grep sagt mir das das im PHP Code nirgendwo verwendet wird

$config['managesieve_port'] gibt’s auch nicht mehr und aus $config['managesieve_default_host'] wurde $config['managesieve_host'] was nun beide zusammen fast

Sieht doch alles eindeutig und easy aus, hm ja sieht es und ich wil gar nicht sagen wie lang ich daran saß das wieder zum laufen zu kriegen ich sag nur so viel ich habe Roundcube und PHP zwischenzeitlich neu installiert, den Plugin Code und NET_Sieve durch debugged, mit verschiedenen Tools gearbeitet um die Verbindung zu analysieren

Nur um am ende herauszufinden das ChatGPT lügt und ich mich nicht auf meine annahmen verlasen sollte

Gut was war jetzt das Problem, nun mein Dovecot verwendete StartSSL und nicht TLS, ich weiß ehrlich gesagt nicht warum ich das so eingerichtet habe ich bin damals vor mehr als 10 Jahren einem Tutorial gefolgt und da die Verbindung nur innerhalb meiner DMZ läuft ist das auch ziemlich egal

Schauen wir uns mal die URL an tls://meinmailserver:4190

Das Protokoll kann hier tls, ssl oder keines sein

• TLS –> StartSSL verschlüsselt nach Aufforderung durch den Client
• SSL –> TLS also verschlüsselt von beginn an
• keine Angabe –> Dovecot lehnt den Login ab außer für zwei formate in denen die Credentials übertragen werden

Wie man an SSL und TLS sieht sind hier beide logisch vertauscht und es hat wirklich ewig gedauert bis ich das gemerkt habe, Dokumentation dazu habe ich auch nirgends gefunden, ChatGPT und Google werfen dir irgendeinen Mist hin

Vielleicht sollte ich noch kurz zeigen wie das in der dovecot.conf aussieht

service managesieve-login {
    inet_listener sieve {
        port = 4190
        ssl = yes
    }
}

Wenn hier ssl = yes steht dann wird TLS verwendet, bei ssl = no wird StartSSL oder keine Verschlüsselung eingesetzt

Zum Abschluss noch ein paar nützliche Befehle

Mit sieve-connect kann man seinen Sieve Server also seine dovecot Konfiguation prüfen

sieve-connect -u <user>@<domain> -a <user>@<domain> -s <mailserverdomain> --port 4190

das klappt aber scheinbar nur bei StartSSL nicht bei TLS, was alles andere als hilfreich ist wenn man nach Fehler Ursachen sucht 😉

Wenn man seine Sieve Filter dann irgendwann eingerichtet hat, kann man bereits vorhandene Mails hiermit nach den filterregeln sortieren lassen

sudo sieve-filter -e -W -C -u <user>@<domain>.de /var/vmail/sieve/<domain>/<user>/active-script.sieve 'INBOX'