v6: excessive complexity and a failed upgrade

[cdr1981]

Hi
I upgraded from hMailServer 5.6.8-B2574 to 6.3.7-B46 on Windows Server 2016. Incoming mail continued to work, but outgoing messages remained in the queue. Disabling MTA-STS did not resolve the problem. After reverting to v5, outgoing delivery worked again. The precise cause remains unresolved.

For my installation, this was a failed upgrade.

v6 feels overloaded with settings, checklist warnings and optional features. Identifying what actually matters for a straightforward mail server has become unnecessarily difficult. The interface gives me the impression of AI-driven feature accumulation, with insufficient attention to a coherent administration experience.

Please focus on reliable mail delivery, understandable defaults, actionable error messages and a clear separation between essential settings and optional functionality. Preserving working installations during upgrades should be a priority.

In my view, this project will fail if it continues down its current path. The simplicity and manageability that made hMailServer attractive are being lost. I have returned to v5 because it does the job successfully.

Those who sow complexity will reap failure.

[RainbowWizard-coder]

Thank you for writing this up, and I'm sorry the upgrade cost you time. A server that takes mail in and sends nothing out is a serious failure, so we're treating this as a bug.

We're trying to reproduce it now: 5.6.8-B2574 upgraded to 6.3.7-B46, delivering directly to recipients' mail servers. Our upgrade tests sent mail through a relay and a route but not directly, so that's a gap we're closing.

If you still have them, these would help a lot:

• Did your server deliver directly, or through an SMTP relay?
• The hmailserver_<date>.log and any ERROR_hmailserver_<date>.log from the day of the upgrade, with passwords and real addresses removed.
• Anything the delivery queue showed for a stuck message, such as its next try or number of tries.

Your point about telling what matters from what's optional is noted too. We're going through what an upgraded server shows when it's first opened.

[RainbowWizard-coder]

We've found a bug that fits what you reported, though we can't yet say it's what hit you.

On 6.3.7, a server delivering directly holds messages to some DNSSEC-signed domains in the queue, even with a working DNS server, because our DNSSEC check misreads a valid answer as incomplete. We've seen it with paypal.com, seznam.cz, kpnmail.nl and xs4all.nl. Incoming mail isn't affected, turning off MTA-STS doesn't help, and 5.x has no such check, which all matches your report. The fix is in testing for 6.3.9.

A DNS server or firewall that drops DNSSEC data can cause the same thing, and then nearly all outgoing mail waits. We've reproduced that too.

Two things would tell us which it was:

• Which domains were your stuck messages going to? All of them, or only some?
• If you have a log from that day, does it say the DNSSEC lookup "could not be completed"?

If you try 6.3.x again before 6.3.9, this gets mail moving: Control Panel, Transport security, Encryption tab, DANE & DNSSEC, untick "Honour recipient DANE/TLSA records when sending", Save changes, then Deliver all now in the delivery queue. That turns off DANE checks for outgoing mail, so tick it again once you're on 6.3.9.

More detail, for anyone else who sees this: https://www.hmailserver.co.uk/topic/28279/known-issue-in-6.3.7-and-6.3.8-mail-to-some-dnssec-signed-domains-stays-in-the-queue