ASK-Solutions

After upgrading to Synology MailPlus Server 4.1.0-21778, our internal mail relay almost completely stopped accepting SMTP connections. Clients immediately received 421 4.7.1 Service unavailable - try again later. The Postfix log showed the actual cause:

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

The configuration of this server is somewhat unusual, but deliberately so. It acts as an internal SMTP relay for trusted equipment. Spam filtering, virus scanning and SMTP authentication are disabled, while outgoing mail is still signed using DKIM. That particular combination exposed a configuration path which MailPlus Server 4.1 does not handle correctly.

At first it seemed odd that Postfix tried to contact an Rspamd milter at all while spam filtering was disabled. The MailPlus Server 4.1 configuration, however, makes clear that port 11336 is not the normal spam-filtering path. It is a dedicated Rspamd proxy called after MIMEDefang to DKIM-sign the final form of the message.

DKIM signing in MailPlus Server 4.1

For an outgoing message, the relevant processing path can be simplified to:

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

The normal Rspamd processing path uses, among others, port 11332. For DKIM signing Synology added a separate proxy on localhost:11336. Postfix configures this milter whenever DKIM signing is enabled for at least one domain.

This creates an important dependency: DKIM signing alone is sufficient reason for Rspamd to be running. Spam filtering, antivirus scanning, SPF verification, incoming DKIM verification and DMARC verification do not have to be enabled.

MailPlus Server 4.1 configures part of this dependency correctly, but two pieces of shell glue surrounding Rspamd have not been completely adapted to the current DKIM implementation.

Problem 1: DKIM signing does not start Rspamd

The first problem is in the decision whether Rspamd and its Redis instance need to be started.

An older MailPlus Server configuration used a global setting:

enable_dkim_sign=yes

With support for multiple mail domains this setting became domain-specific. A current configuration can for example contain:

enable_dkim_sign-1=yes
enable_dkim_sign-2=yes

MailPlus Server itself knows about this distinction. The upgrade code in start-stop-status deliberately reads the old setting and migrates it to enable_dkim_sign-1. Synology's own data collector also obtains the domain ID list first and then checks enable_dkim_sign-${id} for every domain.

The normal startup path does not. MailPlus Server 4.1.0-21778 contains:

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

On an already migrated installation this returns no value. On our system the result was:

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

The startup code therefore concludes that DKIM signing is disabled. If spam filtering, antivirus and the other Rspamd-dependent features are also disabled, neither Rspamd nor its Redis instance is started.

At the same time, the configuration generator has correctly noticed that DKIM signing is enabled for a domain and has therefore added localhost:11336 to Postfix. This produces a broken dependency chain:

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

The daemon wrappers make the same assumption

There is a second part to the same problem. Both rspamd.sh and rspamd_redis.sh contain a conf_status() function which determines whether the service should be running according to the current configuration.

In version 4.1.0-21778 both scripts check:

anti_virus_enable
spam_enable
mcp_enable
enable_arc

DKIM signing is missing.

As a result both processes could be started manually, but their wrappers subsequently returned status 6, or SERVICE_UNKNOWN: the processes were running while the configuration logic believed they should be disabled.

The fix therefore needs to do two things. The daemon wrappers need to be able to test domain-specific settings, and normal package startup needs to use the same domain-specific DKIM state.

Patch 1: starting Rspamd for DKIM-only configurations

We first added a generic helper to scripts/daemon/util.sh. It uses the same domain list mechanism Synology uses elsewhere and returns enabled as soon as the requested setting is yes for at least one domain.

--- 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

Both rspamd.sh and rspamd_redis.sh can then check whether DKIM signing is enabled on any domain.

--- 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}"
 }

Finally, normal package startup must no longer query the obsolete global setting. In start-stop-status we replace only the runtime check. An earlier lookup of enable_dkim_sign in the same file is deliberately left untouched: that is migration code which reads the old setting and converts it to the new domain-specific format.

--- 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`

After applying these changes both wrappers report the correct state:

# /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 then stopped and started MailPlus Server through DSM. Both Rspamd and its Redis instance received new processes and the DKIM milter automatically returned:

/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

This verifies not only the status logic but the actual MailPlus Server stop/start path.

Problem 2: the DKIM Allow List does not reach Rspamd

The second problem is independent of service startup. MailPlus Server provides a separate DKIM Allow List in its web interface to determine from which unauthenticated networks messages may be selected for DKIM signing.

Changing this list appeared to work correctly in the GUI. The database /var/packages/MailPlus-Server/etc/dkim_sign_whitelist.db was updated and the correct backend event was generated. The actual Rspamd map, however, remained unchanged:

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

A host could therefore be allowed in the GUI while Rspamd still did not regard it as a signing network.

The event chain looked like this:

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 tested the available configuration generators individually. The result was clear:

Generator	DKIM signing config	DKIM signing network map
syno_set_config dkim_sign_whitelist	not sufficient	not generated
syno_set_config rspamd_dkim_signing	generated	not generated
syno_set_config rspamd	generated	generated

The actual translation from MailPlus configuration to the Rspamd network map is implemented in Synology's compiled syno_set_config program. That code works correctly. Once again the defect is in the surrounding shell glue: the callback for a changed DKIM Allow List does not invoke the configuration generator which owns the new Rspamd map.

Patch 2: regenerate Rspamd after a DKIM Allow List change

The fix is consequently small. In 51-blackwhitelistChange.sh we retain the existing dkim_sign_whitelist call and add a full Rspamd configuration regeneration immediately afterwards.

--- 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 deliberately do not replace the existing generator. We do not know which additional or compatibility work dkim_sign_whitelist may still perform internally. The additional Rspamd call merely ensures that the configuration file now used for DKIM signing is rebuilt as well.

After applying the patch we tested the GUI in both directions. Adding a temporary address automatically produced:

127.0.0.1
192.168.0.0/16
10.10.10.10

Removing the same address from the GUI automatically returned the map to:

127.0.0.1
192.168.0.0/16

This confirms that both additions and deletions in the MailPlus Server interface now propagate correctly to Rspamd.

Relay Trusted List and DKIM Allow List are different settings

One important configuration detail became clear during the investigation. MailPlus Server has two separate lists for trusted sources. They serve different purposes and neither replaces the other.

Under Mail Delivery → Relay Control → Trusted List you specify which clients may use the server as an SMTP relay. An example for a local network is:

Name:       Local network
Network:    192.168.1.0/24

This setting determines whether the client may relay mail. It does not determine whether mail from that client will receive a DKIM signature.

For that purpose there is a second list under Security → Authentication → DKIM → Allow List. For the same example network it could contain:

Name:       Local network
Network:    192.168.1.0
Netmask:    255.255.255.0

This Allow List determines which unauthenticated source networks are eligible for DKIM signing.

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

A host can therefore be permitted to relay without automatically being permitted to receive a DKIM signature.

Check these settings after a MailPlus Server update

We have not established that MailPlus Server updates always remove these lists. It is nevertheless sensible to verify them explicitly after an update before assuming that Rspamd or the patches are malfunctioning.

Check that the expected networks are still present under both Mail Delivery → Relay Control → Trusted List and Security → Authentication → DKIM → Allow List. Also verify that DKIM signing remains enabled for the intended mail domain.

If necessary, a local 192.168.1.0/24 network could for example be re-added as:

Relay Trusted List:
192.168.1.0/24

DKIM Allow List:
192.168.1.0
255.255.255.0

On the command line, verify that the signing proxy is listening:

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

And inspect the networks Rspamd actually considers eligible for DKIM signing:

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

Also keep in mind that a future MailPlus Server update may replace these modified shell scripts. We therefore keep the fixes as normal unified diff patches. This makes it straightforward to determine whether Synology has fixed the defects in a later version and, if necessary, to reapply the local changes.

Conclusion

Rspamd and the DKIM signing implementation in MailPlus Server 4.1.0-21778 work correctly themselves. Once the correct processes are running and the signing network map is current, outgoing messages are signed successfully. In our external test the resulting d=tnimble.nl signature was not merely present: the next mail server independently verified it as dkim=pass.

The two regressions are in the glue code surrounding that implementation.

In the first problem, runtime startup still uses the old global enable_dkim_sign setting even though DKIM signing is now stored per domain as enable_dkim_sign-N. The daemon wrappers additionally omit DKIM signing altogether when deciding whether Rspamd and Redis are supposed to run.

In the second problem, a DKIM Allow List change is stored correctly and generates the proper event, but the callback does not invoke the Rspamd configuration generator which owns the signing network map.

A configuration with spam filtering or another Rspamd-dependent feature enabled can easily hide the first problem because Rspamd will already be started for another reason. The combination of DKIM signing enabled while the other scanning and verification features are disabled therefore appears to be a configuration path that was not adequately covered when MailPlus Server 4.1 was regression-tested. The second issue similarly points to an incomplete transition from the older DKIM configuration path to the Rspamd-based implementation.

Downloads

The fixes are deliberately provided as two separate patch files because they correct two distinct defects. For internal administration we also maintain an archive containing the completely patched scripts. Before publishing such an archive publicly, verify that Synology's licence terms permit redistribution of the original vendor scripts; the standalone patch files contain only the changes.

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