Connection surge caused by empty Sender Address

[velifire]

I have noticed the following connection surge spikes happening apprx every 5’ and starting after I installed the latest IPFire update (IPFire 2.29 (x86_64) - Core-Update 198)

When I looked under Status / Connections I noticed an very large number of connections initiated from my red0 to the Recipients domain MX servers.

Looking at the email service’s system log I found thousands of …

16:00:31	dma[14105b.3d132d50]:	remote delivery deferred: mx1.xxxxxxxxxxx.net [121.213.321.3] failed after connect: 421 Too many concurrent connections from 212.123.12.1

The MX servers in use had thousands of those messages

ID XXXXXXXXXXXXXXXXXXXXX
DATE 11/3/25, 4:00 PM
RCPT TO YYYYYYYY
FROM MAILER-DAEMON <>
SUBJECT Mail delivery failed
550 Your message must contain one valid email address in the "From" header

At that point my IPFire configuration had

1. Populated the Recipients addresses
2. Left the Sender Address empty
3. Activated the “Send email on alert” option
4. Had not setup the email service under “System / Mail”

First I tried to populate the Sender Address however the issue persisted with the same error message on my MX servers

Then, I setup “System / Mail” with the missing SMTP settings however the issue persisted with the same error messages on the MX servers

Then I rebooted and the issue disappeared.

I didn’t try to repro the issue, however I suspect activating the Send email on alert option with empty “Sender” is triggering the connection spike surges.

[velifire]

Unfortunately I thought I had found the issue however although the number of concurent connections has been reduced to just over 1k I still get those connectivity surges

I have noticed that I have a large number of dma processes running, 789!!

ps -e | awk '$4=="dma" { c+=1; } END { print c; }'
789

After some further digging I realised the spooler was full of messages (~1800 of those) missing the “Sender Address”

ID	: 140fd6.386a7d50
From	:
To	: abc@abcderg.me

I couldn’t find out how to stop the dma processes so I had to terminate all manually, and then delete manually the spooler queue

cd /var/spool/dma
rm -f M*
rm -f Q*

I assume here those malformed messages never get cleaned up hence they stay on the spooler queue causing the spawning of large number of dma processes causing the connection surge to the MX domain servers.

Following a reboot, things appear quiet

PS: realised there is this command on the cron task, which I wish I new earlier

# Cleanup the mail spool directory
%weekly * * /usr/sbin/dma-cleanup-spool