Vorweg: Das ist grundsätzlich möglich, aber es müssen ein paar Rahmenbedingungen erfüllt sein und es muss ein bisschen konfiguriert werden.

Betreibt man den gesamten mailcow: dockerized-Stack, so ist rspamd als Spamfilter grundsätzlich integriert und wird innerhalb des Stacks für eingehenden und ausgehenden Mail-Traffic genutzt. Unter anderem greift das System dabei auf externe

Eingebunden ist rspamd Stack-intern über einen separaten rspamd-Container, welcher via TCP und den Port 9900 angesprochen wird. Wieder wiederum wird durch die worker-proxy.inc Proxy-Konfiguration auf 11333 weitergeleitet.

In meinem Fall führte das zu einem komischen Symptom: Mails, welche von „extern“ kamen, wurden zweimal von rspamd verarbeitet, jeweils mit unterschiedlichen Scores, da bei jedem Durchlauf einige Metadaten verändert waren: So war immer beim jeweils zweiten Durchlauf die Source-IP 127.0.0.1.

Schritt 1: mailcow: dockerized Docker-Compose per override anpassen

Dazu die Datei /opt/mailcow-dockerized/docker-compose.override.yml wie folgt füllen:

services:

    rspamd-mailcow:
      ports:
        - "192.168.1.123:11332:9900"

Und den Stack anschließend mittels

docker compose up -d

starten.

Schritt 2: 127.0.0.1 als Weiterleitungshost eintragen

Das geht über die GUI. 127.0.0.1 muss als Weiterleitungshost in diesen Setup deshalb eingetragen werden, weil durch den worker-proxy die Mails einmal lokal zugestellt werden, was mit der Source-IP auf dem loopback-Interface (hier Standard, 127.0.0.1) passiert.

Schritt 3: Im externen Relay mittels smtpd_milters auf den mailcow rspamd verweisen

In der Postfix main.cf auf dem externen Relay setzen:

smtpd_milters = inet:192.168.1.123:11332, inet:127.0.0.1:12768

Es muss selbstverständlich sichergestellt sein, dass das externe Relay den rspamd auch erreicht. Außerdem ist anzumerken, dass die Kommunikation per Milter-Protokoll unverschlüsselt passiert. In internen Netzwerken mag das akzeptabel sein, übers Internet ist ein VPN-Tunnel zwischen rspamd und externem Relay empfehlenswert.