Wer Roundcube als Webmail-Lösung nutzt und seinen Server zusätzlich mit ModSecurity (modsecurity.org) und dem OWASP Core Rule Set (CRS) absichert, hat vielleicht schon einmal dieses Phänomen erlebt: Der Mailversand funktioniert tagelang absolut reibungslos, doch plötzlich bricht das Weiterleiten oder Antworten bei einer ganz bestimmten E-Mail mit einer kryptischen Fehlermeldung ab:

„Verbindungsfehler (Fehler beim Erreichen des Servers)!“

Das Kuriose daran: Andere E-Mails gehen zeitgleich problemlos raus. Ein Blick in die Mailserver-Logs (z. B. Postfix) zeigt gähnende Leere – der Sendeversuch kommt dort gar nicht erst an. Wo liegt also der Fehler?

Die Ursache: Wenn Textinhalte wie Angriffe aussehen

Die Fehlerursache liegt meist nicht am Mailserver oder an Roundcube selbst, sondern an der vorgeschalteten Web Application Firewall (WAF). Beim Weiterleiten einer E-Mail sendet Roundcube den gesamten Text der alten Nachricht als HTTP-POST-Request an den Webserver. ModSecurity scannt diesen Inhalt auf potenzielle Angriffe.

Enthält die E-Mail nun eine völlig harmlose Passage wie „delete this“ oder das Wort „delete“ gefolgt von einem Zeilenumbruch, schlägt das OWASP-Regelwerk fälschlicherweise Alarm.

Ein Blick in das Apache- oder Nginx-Error-Log entlarvt den Übeltäter:

ModSecurity: Warning. Pattern match "(?:get|post|head|options|...|delete|...)" at ARGS:_message. 
[file "/usr/share/modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf"] [line "53"] 
[id "921110"] [msg "HTTP Request Smuggling Attack"]
[data "Matched Data: delete this found within ARGS:_message..."]
[severity "CRITICAL"] ModSecurity: Access denied with code 403 (phase 2).

Was passiert hier genau? Da DELETE eine offizielle HTTP-Methode (wie GET oder POST) ist, vermutet ModSecurity hinter dem Wort am Zeilenanfang einen sogenannten HTTP Request Smuggling Angriff (Regel-ID 921110). Der Webserver blockiert die Anfrage sofort mit einem Fehler 403 (Access Denied) und kappt die Verbindung zum Browser. Roundcube verliert abrupt den Kontakt zum Server und interpretiert das fälschlicherweise als Netzwerk- oder Verbindungsproblem.

Die Lösung: Gezielte Ausnahme statt Rundumschlag

Um das Problem zu lösen, muss man ModSecurity nicht komplett deaktivieren. Es reicht völlig aus, die fehlerhafte Regel exakt für die Roundcube-Instanz abzuschalten.

Wenn Roundcube unter Apache läuft, lässt sich dies sauber über die .htaccess-Datei im Hauptverzeichnis von Roundcube oder direkt in der VirtualHost-Konfiguration der Webmail-Domain lösen:

<IfModule mod_security2.c>
    # Verhindert False Positives durch harmlose Textpassagen (z.B. "delete") in E-Mails
    SecRuleRemoveById 921110
</IfModule>

Unter Nginx (mit dem entsprechenden ModSecurity-Modul) wird die Ausnahme im location-Block von Roundcube definiert:

location /roundcube {
    modsecurity_rules '
        SecRuleRemoveById 921110
    ';
}

Nach einem schnellen Reload des Webservers (systemctl reload apache2 bzw. nginx) ist das Problem behoben. Die betroffene E-Mail lässt sich jetzt ohne Blockade und ohne Sicherheitsrisiko für den restlichen Server weiterleiten.

Wenn Webmail-Clients bei spezifischen Inhalten streiken, lohnt sich der erste Blick fast immer in die Webserver- und WAF-Logs statt in die Mail-Konfiguration.