Fixing Exim and SpamAssassin configuration conflicts (IPv4 vs IPv6)

This incident had two linked failures: Exim startup broke due to duplicated configuration, then anti-spam filtering failed because spamc attempted IPv6 while spamd listened on IPv4 only.

1) Startup failure: duplicate Exim directive

Error:

Exim configuration error in line 3 of /etc/exim.variables.conf:
"av_scanner" option set for the second time

Diagnostics:

grep -n "^av_scanner" /etc/exim.variables.conf
exim -bV | head -n 20

Fix:

1. keep a single av_scanner declaration;
2. restart Exim;
3. validate service state.

systemctl restart exim
systemctl status exim --no-pager

2) Queue issue after restart: ::1 connection refused

Observed:

spamc[...] connect to spamd on ::1 failed: Connection refused

Socket proof:

ss -lntp | grep 783

Typical output shows spamd bound to 127.0.0.1:783 only.

3) Functional fix: force IPv4 destination in spamc

transport_filter = /usr/bin/spamc -d 127.0.0.1 -u ${lookup{$domain}lsearch*{/etc/virtual/domainowners}{$value}}

Reload and process queue:

systemctl restart exim
exim -qff

4) Persistence in DirectAdmin CustomBuild

Direct edits in /etc/exim.conf can be overwritten.

mkdir -p /usr/local/directadmin/custombuild/custom/exim/conf
cp /etc/exim.conf /usr/local/directadmin/custombuild/custom/exim/conf/exim.conf

Optional rebuild cycle:

cd /usr/local/directadmin/custombuild
./build exim_conf
./build exim
systemctl restart exim

5) Acceptance validation

1. Exim starts cleanly.
2. no more spamc loopback refusal.
3. queue drains normally.
4. fix survives DirectAdmin updates.

Monitoring commands:

tail -f /var/log/exim/mainlog | egrep -i "spamc|spamd|refused|error"
exim -bp | head -n 40

Stabilizing this class of incident requires parser cleanup, loopback alignment, and panel-aware persistence together. Treating just one layer is not enough in production MTA operations.

This post is licensed under CC BY-NC.