<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[hMailServer 6.2.18: a stalled database bounced valid mail instead of retrying it]]></title><description><![CDATA[<p dir="auto">A recipient lookup that failed because the database did not answer returned 550, exactly as a lookup that found nothing did. The two cases were indistinguishable inside the server, so a database briefly locked by a backup told the sending server that a valid mailbox did not exist and the mail was bounced instead of retried. That is mail loss with a delivery receipt. Anyone running against a database that stalls under backup, maintenance or load was affected. Those lookups now return 451.</p>
<p dir="auto"><strong>What the upgrade involved</strong></p>
<p dir="auto"><code>DBConnectionAcquireTimeout</code> now defaults to 60 seconds rather than 0. It shipped disabled in 6.2.17 precisely because timing out an acquisition turned a slow database into a bounce. The 451 fix is what made it safe to turn on, but the pool deadline is live after this upgrade, so check the value if you set it explicitly.</p>
<p dir="auto"><strong>Bounded waits (#23, #24)</strong></p>
<ul>
<li>Outbound delivery sessions get an absolute ceiling, <code>ClientSessionCeiling</code>, 30 minutes, separate from the idle timeout. The idle timeout re-arms on every byte received, so a peer dribbling one byte at a time held a delivery thread indefinitely.</li>
<li>ClamAV on the delivery path (#23) is bounded and reports a timeout rather than holding the thread.</li>
<li>DNS queries, event scripts and external scanner processes (#24) are bounded by <code>DNSQueryTimeout</code> (10s), <code>ScriptTimeout</code> (60s) and <code>ExternalProcessTimeout</code> (300s).</li>
<li>Work queue saturation is reported on a schedule and names the task holding each thread, with its session and peer IP.</li>
<li>Pre-authentication IMAP command buffering is capped at 11 MB. An unauthenticated peer could previously buffer without limit.</li>
<li>Backup restore validates the source archive before deleting the target. It deleted first, so a corrupt archive destroyed the data it was restoring over.</li>
</ul>
<p dir="auto"><strong>Other</strong></p>
<p dir="auto">A first static analysis pass fixed a buffer overrun on long paths in <code>GetExecutableName</code> and two MySQL path helpers, and a shadowed <code>fileExists</code> in <code>Logger::WriteLogFile</code> that made rotation test an uninitialised value.</p>
<p dir="auto">A correction to the roadmap: ARC sealing is narrower than previously described. <code>Arc::Seal</code> sits after every early return in <code>DKIMSigner::Sign</code>, so relayed third-party mail is never sealed.</p>
<p dir="auto">Discussion #18 is fixed and bounded, but not yet confirmed against the original reporter's Postfix/PMG setup. If you are affected, the per-stage timings in the troubleshooting guide will name the culprit in one log line. Please post it on the discussion.</p>
<p dir="auto"><a href="https://www.progressiverobot.com/hmailserver-downloads/" rel="nofollow ugc">Full release notes, checksums and signatures</a></p>
]]></description><link>https://www.hmailserver.co.uk/topic/28166/hmailserver-6.2.18-a-stalled-database-bounced-valid-mail-instead-of-retrying-it</link><generator>RSS for Node</generator><lastBuildDate>Wed, 23 Sep 2026 04:30:31 GMT</lastBuildDate><atom:link href="https://www.hmailserver.co.uk/topic/28166.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 12 Aug 2026 05:29:19 GMT</pubDate><ttl>60</ttl></channel></rss>