DKIM signing-regressies in Synology MailPlus Server 4.1.0-21778 oplossen

Geschreven door ASK-Solutions in Projecten

Na een update naar Synology MailPlus Server 4.1.0-21778 stopte onze interne mailrelay vrijwel volledig met het accepteren van SMTP-verbindingen. Clients kregen direct na het verbinden een 421 4.7.1 Service unavailable - try again later terug. In de Postfix-log stond de daadwerkelijke oorzaak:

warning: connect to Milter service inet:localhost:11336: Connection refused
NOQUEUE: milter-reject: CONNECT ... 421 4.7.1 Service unavailable - try again later

De configuratie van deze server is enigszins ongebruikelijk, maar bewust zo ingericht. Het systeem fungeert als interne SMTP-relay voor vertrouwde apparatuur. Spamfiltering, virusscanning en SMTP-authenticatie staan uit, terwijl uitgaande berichten wel met DKIM worden ondertekend. Juist die combinatie bleek een configuratiepad bloot te leggen dat in MailPlus Server 4.1 niet correct wordt afgehandeld.

In eerste instantie leek het vreemd dat Postfix überhaupt verbinding probeerde te maken met een Rspamd-milter terwijl spamfiltering uit stond. De configuratie van MailPlus Server 4.1 maakt echter duidelijk dat poort 11336 niet de gewone spamfilterroute is. Het is een afzonderlijke Rspamd proxy die na MIMEDefang wordt aangeroepen om het uiteindelijke bericht van een DKIM-handtekening te voorzien.

DKIM signing in MailPlus Server 4.1

Voor een uitgaand bericht ziet het relevante deel van de verwerking er vereenvoudigd als volgt uit:

SMTP client
    |
    v
Postfix
    |
    +---> MIMEDefang
    |
    +---> Rspamd proxy :11336
              |
              +---> DKIM signing
    |
    v
outbound SMTP relay / destination

De normale Rspamd-verwerking gebruikt onder andere poort 11332. Voor DKIM signing heeft Synology daarnaast een aparte proxy op localhost:11336 toegevoegd. Postfix configureert deze milter wanneer voor ten minste één domein DKIM signing is ingeschakeld.

Daarmee ontstaat een belangrijke afhankelijkheid: DKIM signing alleen is al voldoende reden om Rspamd te laten draaien. Spamfiltering, antiviruscontrole, SPF-verificatie, inkomende DKIM-verificatie en DMARC-controle hoeven daarvoor niet ingeschakeld te zijn.

MailPlus Server 4.1 configureert deze afhankelijkheid deels correct, maar twee stukken shellcode rondom Rspamd blijken niet volledig aangepast te zijn aan de huidige DKIM-implementatie.

Probleem 1: DKIM signing start Rspamd niet

Het eerste probleem zit in de beslissing of Rspamd en de bijbehorende Redis-instance moeten worden gestart.

Een oudere versie van MailPlus Server kende een globale instelling:

enable_dkim_sign=yes

Met ondersteuning voor meerdere maildomeinen is deze instelling domeinspecifiek geworden. De huidige configuratie bevat bijvoorbeeld:

enable_dkim_sign-1=yes
enable_dkim_sign-2=yes

MailPlus Server zelf kent dit verschil. De upgradecode in start-stop-status leest bijvoorbeeld bewust de oude instelling en migreert die naar enable_dkim_sign-1. Ook de door Synology meegeleverde data collector vraagt eerst de lijst met domein-ID's op en controleert vervolgens voor ieder domein enable_dkim_sign-${id}.

De normale startup-code doet dat echter niet. In MailPlus Server 4.1.0-21778 staat:

local DKIMSignEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal enable_dkim_sign`

Op een reeds gemigreerde installatie levert dit geen waarde op. Op ons systeem was het resultaat:

enable_dkim_sign        = <>
enable_dkim_sign-1      = <yes>
enable_dkim_sign-2      = <yes>

De startup-code concludeert daardoor dat DKIM signing niet is ingeschakeld. Wanneer ook spamfiltering, antivirus en de overige Rspamd-afhankelijke functies uit staan, wordt vervolgens noch Rspamd, noch de Rspamd Redis-instance gestart.

Tegelijkertijd heeft de configuratiegenerator wel gezien dat DKIM signing voor een domein actief is en heeft Postfix daarom localhost:11336 als milter opgenomen. Het resultaat is een gebroken afhankelijkheidsketen:

DKIM signing enabled for domain
        |
        v
enable_dkim_sign-1=yes
        |
        +------------------------------+
        |                              |
        v                              v
Rspamd/Postfix configuration      Package startup
understands per-domain DKIM      checks old key only
        |                              |
        v                              v
Postfix gets :11336           enable_dkim_sign = ""
        |                              |
        |                              X
        |                       Rspamd not started
        |                       Redis not started
        |
        v
SMTP client connects
        |
        v
Postfix connects to :11336
        |
        v
Connection refused
        |
        v
421 4.7.1 Service unavailable

De daemon wrappers maken dezelfde aanname

Er zit nog een tweede deel aan hetzelfde probleem. Zowel rspamd.sh als rspamd_redis.sh hebben een functie conf_status() waarmee wordt bepaald of de dienst volgens de huidige configuratie hoort te draaien.

In versie 4.1.0-21778 controleren beide scripts:

anti_virus_enable
spam_enable
mcp_enable
enable_arc

DKIM signing ontbreekt.

Daardoor konden beide processen handmatig worden gestart, maar rapporteerden de wrappers vervolgens status 6, oftewel SERVICE_UNKNOWN: de processen draaiden terwijl de configuratielogica dacht dat ze uitgeschakeld moesten zijn.

De oplossing moet dus twee dingen doen. De daemon wrappers moeten domeinspecifieke instellingen kunnen testen, en de package startup moet dezelfde domeinspecifieke DKIM-status gebruiken.

Patch 1: Rspamd starten voor DKIM-only configuraties

We hebben daarvoor eerst een generieke helper toegevoegd aan scripts/daemon/util.sh. Deze gebruikt dezelfde domeinlijst die Synology zelf elders gebruikt en retourneert enabled zodra de opgegeven instelling voor ten minste één domein op yes staat.

--- util.sh.orig
+++ util.sh
@@ -50,6 +50,20 @@
 	fi
 }
 
+checkDomainConfKey() {
+	local key="$1"
+	local domain_ids="$(${MAILPLUS_SERVER_BACKEND_BINARY} --getDomainIDList)"
+	local id
+
+	for id in ${domain_ids}; do
+		if [ "yes" == "$(${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal "${key}-${id}")" ]; then
+			return ${RUNKEY_ENABLE}
+		fi
+	done
+
+	return ${RUNKEY_DISABLE}
+}
+
 checkProcessRun()
 {
 	local target_proc_name=$1

Vervolgens kunnen zowel rspamd.sh als rspamd_redis.sh controleren of DKIM signing op ten minste één domein is ingeschakeld.

--- rspamd.sh.orig
+++ rspamd.sh
@@ -62,6 +62,10 @@
 	if [ "${RUNKEY_ENABLE}" -eq $? ]; then
 		return "${RUNKEY_ENABLE}"
 	fi
+	checkDomainConfKey "enable_dkim_sign"
+	if [ "${RUNKEY_ENABLE}" -eq $? ]; then
+		return "${RUNKEY_ENABLE}"
+	fi
 	return "${RUNKEY_DISABLE}"
 }

--- rspamd_redis.sh.orig
+++ rspamd_redis.sh
@@ -65,6 +65,10 @@
 	if [ "${RUNKEY_ENABLE}" -eq $? ]; then
 		return "${RUNKEY_ENABLE}"
 	fi
+	checkDomainConfKey "enable_dkim_sign"
+	if [ "${RUNKEY_ENABLE}" -eq $? ]; then
+		return "${RUNKEY_ENABLE}"
+	fi
 	return "${RUNKEY_DISABLE}"
 }

Ten slotte moet ook de normale package startup niet langer de oude globale instelling gebruiken. In start-stop-status vervangen we alleen de runtime-controle. Een eerdere lookup van enable_dkim_sign in hetzelfde bestand laten we bewust ongemoeid: die hoort bij migratiecode die de oude instelling juist omzet naar het nieuwe domeinspecifieke formaat.

--- start-stop-status.orig
+++ start-stop-status
@@ -1350,7 +1350,14 @@
 		local SpamEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal spam_enable`
 		local MCPEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal mcp_enable`
 		local SPFCheckEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal enable_spf_check`
-		local DKIMSignEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal enable_dkim_sign`
+		local DKIMSignEnable="no"
+		local DomainID
+		for DomainID in $(${MAILPLUS_SERVER_BACKEND_BINARY} --getDomainIDList); do
+			if [ "$(${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal "enable_dkim_sign-${DomainID}")" = "yes" ]; then
+				DKIMSignEnable="yes"
+				break
+			fi
+		done
 		local DKIMEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal enable_dkim`
 		local DMARCEnable=`${MAILPLUS_SERVER_BACKEND_BINARY} --getConfKeyVal enable_dmarc`

Na deze wijzigingen rapporteren beide wrappers de juiste status:

# /var/packages/MailPlus-Server/target/scripts/daemon/rspamd.sh status
# echo $?
0

# /var/packages/MailPlus-Server/target/scripts/daemon/rspamd_redis.sh status
# echo $?
0

We hebben MailPlus Server daarna via DSM gestopt en opnieuw gestart. Zowel Rspamd als zijn Redis-instance kregen een nieuw proces en de DKIM-milter kwam automatisch terug:

/var/packages/MailPlus-Server/target/usr/bin/redis-server 127.0.0.1:8505
rspamd: main process

127.0.0.1:11332 LISTEN
127.0.0.1:11334 LISTEN
127.0.0.1:11336 LISTEN

Daarmee is niet alleen de statuscontrole hersteld, maar ook het daadwerkelijke stop/start-pad van MailPlus Server.

Probleem 2: de DKIM Allow List bereikt Rspamd niet

Het tweede probleem staat los van het starten van de services. MailPlus Server heeft in de webinterface een aparte DKIM Allow List waarmee wordt bepaald vanaf welke niet-geauthenticeerde netwerken berichten voor DKIM signing in aanmerking komen.

Het wijzigen van deze lijst werkte in de GUI ogenschijnlijk correct. De database /var/packages/MailPlus-Server/etc/dkim_sign_whitelist.db werd bijgewerkt en het juiste backend-event werd gegenereerd. De daadwerkelijke Rspamd-map bleef echter ongewijzigd:

/var/packages/MailPlus-Server/target/etc/rspamd/local.d/multimap/dkim_sign_networks.map

Daardoor kon een host wel in de GUI zijn toegestaan terwijl Rspamd hem nog steeds niet als signing network zag.

De eventketen zag er als volgt uit:

DKIM Allow List in DSM
        |
        v
dkim_sign_whitelist.db
        |
        v
mailserver_dkim_sign_whitelist_db event
        |
        v
51-blackwhitelistChange.sh
        |
        +---> syno_set_config dkim_sign_whitelist
        |
        +---> syno_action dkim_sign_whitelist
        |
        X
        |
        |  missing Rspamd regeneration
        v
dkim_sign_networks.map remains stale

We hebben de beschikbare configuratiegeneratoren afzonderlijk getest. De uitkomst was opvallend duidelijk:

Generator	DKIM signing config	DKIM signing network map
`syno_set_config dkim_sign_whitelist`	niet voldoende	niet gegenereerd
`syno_set_config rspamd_dkim_signing`	gegenereerd	niet gegenereerd
`syno_set_config rspamd`	gegenereerd	gegenereerd

De daadwerkelijke omzetting van de MailPlus-configuratie naar de Rspamd-map zit in Synology's gecompileerde syno_set_config-programma. Die code blijkt gewoon correct te werken. Het probleem zit opnieuw in de shellcode eromheen: de callback voor een gewijzigde DKIM Allow List roept niet de configuratiegenerator aan die de nieuwe Rspamd-map beheert.

Patch 2: Rspamd regenereren na een wijziging aan de DKIM Allow List

De oplossing is daarom klein. In 51-blackwhitelistChange.sh behouden we de bestaande dkim_sign_whitelist-aanroep en voegen we daarna een volledige Rspamd-configuratieregeneratie toe.

--- 51-blackwhitelistChange.sh.orig
+++ 51-blackwhitelistChange.sh
@@ -22,6 +22,10 @@
 		err_log "Failed to set conf dkim_sign_whitelist"
 		exit 1
 	fi
+	if ! ${SET_CONF_BINARY} "rspamd"; then
+		err_log "Failed to set conf rspamd"
+		exit 1
+	fi
 fi
 
 if isKeyChanged "mailserver_dane_whitelist_db"; then

We vervangen de bestaande generator bewust niet. We weten niet welke aanvullende of compatibiliteitsfuncties dkim_sign_whitelist intern nog uitvoert. De extra Rspamd-aanroep zorgt alleen dat ook het configuratiebestand dat sinds MailPlus Server 4.1 voor DKIM signing wordt gebruikt opnieuw wordt opgebouwd.

Na deze patch hebben we de werking in beide richtingen getest. Na het toevoegen van een tijdelijk adres via de GUI werd de map automatisch:

127.0.0.1
192.168.0.0/16
10.10.10.10

Na het verwijderen van dat adres uit dezelfde GUI werd de map automatisch weer:

127.0.0.1
192.168.0.0/16

Daarmee is bevestigd dat zowel toevoegen als verwijderen via de MailPlus Server-interface nu correct doorwerkt naar Rspamd.

Relay Trusted List en DKIM Allow List zijn niet hetzelfde

Tijdens het analyseren van deze problemen bleek nog een belangrijk configuratiedetail. MailPlus Server kent twee afzonderlijke lijsten voor vertrouwde bronnen. Ze hebben verschillende functies en de ene vervangt de andere niet.

Onder Mail Delivery → Relay Control → Trusted List staat welke clients de server als SMTP-relay mogen gebruiken. Een voorbeeld voor een lokaal netwerk is:

Name:       Local network
Network:    192.168.1.0/24

Deze instelling bepaalt of een client mag relayen. Hij bepaalt niet of een bericht dat vanaf die client wordt aangeboden door DKIM wordt ondertekend.

Daarvoor bestaat onder Security → Authentication → DKIM → Allow List een tweede lijst. Voor hetzelfde voorbeeldnetwerk kan daarin staan:

Name:       Local network
Network:    192.168.1.0
Netmask:    255.255.255.0

Deze Allow List bepaalt welke niet-geauthenticeerde clients in aanmerking komen voor DKIM signing.

client 192.168.1.25
        |
        +--- Relay Trusted List? --- yes ---> relay permitted
        |
        +--- DKIM Allow List? ------ yes ---> DKIM signing permitted

Een host kan dus toestemming hebben om mail te relayen zonder automatisch in de DKIM signing Allow List te staan.

Controleer deze instellingen na een MailPlus Server-update

We hebben niet vastgesteld dat een MailPlus Server-update deze lijsten altijd verwijdert. Wel is het verstandig ze na een update expliciet te controleren voordat een probleem met de patches of met Rspamd wordt vermoed.

Controleer in de webinterface of de verwachte netwerken nog aanwezig zijn in zowel Mail Delivery → Relay Control → Trusted List als Security → Authentication → DKIM → Allow List. Controleer daarnaast of DKIM signing nog is ingeschakeld voor het bedoelde maildomein.

Indien nodig kan voor een lokaal 192.168.1.0/24-netwerk bijvoorbeeld opnieuw worden toegevoegd:

Relay Trusted List:
192.168.1.0/24

DKIM Allow List:
192.168.1.0
255.255.255.0

Op de commandline kan vervolgens worden gecontroleerd of de signing proxy actief is:

# netstat -lntp 2>/dev/null | grep '127.0.0.1:11336'

En welke netwerken Rspamd daadwerkelijk voor DKIM signing gebruikt:

# cat /var/packages/MailPlus-Server/target/etc/rspamd/local.d/multimap/dkim_sign_networks.map

Houd er tevens rekening mee dat een volgende MailPlus Server-update de aangepaste shellscripts opnieuw kan vervangen. De patches zijn daarom bewust als normale unified diffs bewaard, zodat eenvoudig kan worden gecontroleerd of Synology het probleem inmiddels zelf heeft opgelost en, indien nodig, de lokale wijzigingen opnieuw kunnen worden toegepast.

Conclusie

Rspamd en de DKIM signing-implementatie in MailPlus Server 4.1.0-21778 blijken op zichzelf goed te functioneren. Nadat de juiste processen draaien en de signing network map actueel is, worden berichten correct ondertekend. Een extern ontvangen testbericht werd daarbij niet alleen voorzien van een d=tnimble.nl DKIM-handtekening, maar die handtekening werd door de volgende mailserver ook daadwerkelijk als dkim=pass geverifieerd.

De twee regressies zitten in de glue-code rond die implementatie.

Bij het eerste probleem gebruikt de runtime startup nog de oude globale enable_dkim_sign-instelling terwijl DKIM signing inmiddels per domein in enable_dkim_sign-N wordt opgeslagen. De daemon wrappers vergeten daarnaast DKIM signing volledig mee te nemen bij hun beslissing of Rspamd en Redis horen te draaien.

Bij het tweede probleem wordt een wijziging aan de DKIM Allow List wel opgeslagen en wordt het juiste event gegenereerd, maar ontbreekt de aanroep van de Rspamd-configuratiegenerator die de nieuwe signing network map beheert.

Een configuratie waarin spamfiltering of een andere Rspamd-afhankelijke functie actief is kan het eerste probleem gemakkelijk maskeren, omdat Rspamd dan om een andere reden al wordt gestart. De combinatie van DKIM signing ingeschakeld met de overige scan- en verificatiefuncties uitgeschakeld lijkt daardoor een configuratiepad dat bij de overgang naar MailPlus Server 4.1 onvoldoende in de regressietests is meegenomen. Het tweede probleem wijst eveneens op een incomplete overgang van de oudere DKIM-configuratie naar de nieuwe Rspamd-gebaseerde implementatie.

Downloads

De fixes zijn bewust opgesplitst in twee patchbestanden, omdat het om twee verschillende fouten gaat. Daarnaast hebben we voor intern beheer een archief met de volledig aangepaste scripts gemaakt. Controleer voordat een dergelijk archief publiek wordt aangeboden of de licentievoorwaarden van Synology herdistributie van de oorspronkelijke scripts toestaan; de losse patchbestanden bevatten alleen de aangebrachte wijzigingen.

mailplus-4.1.0-21778-dkim-rspamd-startup.patch	August 29, 2026	1.0	Code	Patch	download
mailplus-4.1.0-21778-dkim-allowlist-regeneration.patch	August 29, 2026	1.0	Code	Patch	download
mailplus-4.1.0-21778-dkim-patched-scripts.tar.gz	August 29, 2026	1.0	Code	Archive	download

Labels: Systeembeheer, Privacy & Security

ASK-Solutions